Après que la tâche d'impression a été assignée au planificateur, elle est passée au système de filtrage de CUPS. Ceci convertit les données dans un format exploitable par l'imprimante. Durant le démarrage, le démon CUPS charge deux bases de données MIME : mime.types qui définit les types de fichiers connus dont CUPS accepte les données, et mime.convs qui définit les programmes qui traitent chaque type MIME particulier.
Le fichier mime.types a la syntaxe suivante :
mimetype { [extension-fichier] | [chemin-associé] }
La deuxième ligne associe le contenu du fichier au type MIME spécifié en déterminant que le premier kilo-octet du texte dans le fichier contient des caractères imprimables et que ceux-ci incluent des balises HTML.
Le fichier mime.convs a la syntaxe suivante :
source — destination — cost — program
Le champ « source » est le type MIME qui est déterminé au vu du fichier mime.types, pendant que le champ destination liste le type de sortie requise et détermine quel programme devrait être utilisé. Le champ « cost » donne une assistance dans la sélection de jeux de filtres quand on convertit un fichier. Le dernier champ, « program », détermine quel programme de filtre est utilisé pour réaliser les conversions de données.
Quelques exemples :
application/vnd.cups-postscript application/vnd.cups-raster 50 pstoraster
Le planificateur de CUPS peut implémenter l'IPP (protocole d'impression réseau) ou LPD (protocole d'impression réseau Daemon). Il accepte les requêtes HTTP 1.1, et il fournit une interface web pour la gestion de la file d'attente, la configuration du serveur, et sa documentation. Cette interface est accessible par défaut en tapant http://localhost:631/ dans un navigateur. Il reste nécessaire de connaître le mot de passe administrateur pour effectuer certaines opérations.
Un module d'autorisation contrôle quels messages IPP et HTTP peuvent passer au travers le système. Une fois que les paquets IPP/HTTP sont autorisés, ils sont envoyés au module client qui écoute et traite les connexions entrantes. Le module client est aussi responsable de l'exécution externe du programme CGI comme du support web des imprimantes, du contrôle et de l'administration. Une fois que ce module a traité ses requêtes, il les envoie vers les modules IPP qui valident l'URI afin d'empêcher un client de contourner l'identification du serveur HTTP. L'URI est une chaîne qui indique le nom ou l'adresse d'un élément du réseau physique ou logique.
Le planificateur autorise les classes d'imprimantes ; les applications peuvent envoyer des requêtes à des groupes d'imprimantes d'une classe, ce qui permet au planificateur de diriger le travail vers la première imprimante libre. Un module de travaux gère les travaux d'impression, il les envoie vers le filtre et vers le programme pour finaliser la conversion et l'impression, et pour contrôler le statut de ces processus.
Au début avec Red Hat Linux 9, un gestionnaire d'impression pré-installé basé sur CUPS et intégré dans GNOME était fourni. Cela permettait l’ajout d’imprimantes via une interface utilisateur similaire à celle de Microsoft, où une nouvelle imprimante pouvait être ajoutée en utilisant un logiciel de configuration wizard, avec lequel on pouvait changer les propriétés de l'imprimante par défaut dans une fenêtre contenant une liste d'imprimantes installées. Les processus d'impression pouvait également être démarrés et stoppés en utilisant un gestionnaire d'imprimantes, et l'imprimante pouvait être mise en pause en utilisant un menu contextuel qui apparaît à l'écran après un clic droit sur l'icône de l'imprimante.
Ce système a été critiqué par Eric Raymond dans son œuvre The Luxury of Ignorance (Le luxe de l'ignorance). Raymond a essayé d'installer CUPS en utilisant le gestionnaire d'imprimantes de FedoraCore 1. Il ne l'a pas trouvé intuitif et a critiqué l'interface en se basant sur le fait que celle-ci ne prenait pas en compte le "point de vue de l'utilisateur". Il a trouvé que l'idée des listes d'imprimantes n'était pas claire car les utilisateurs créaient des listes en local sur leur ordinateur mais ces listes étaient en réalité créées sur le serveur CUPS.
Il a également trouvé la surabondance des choix de types de liste d'impression confuse du fait qu'il pouvait choisir les réseaux CUPS (IPP), Unix (LDP), Windows (SMB), Novell (NCP) ou JetDirect. Il a trouvé le(s) fichier(s) de configuration remarquablement inutile(s) et largement non-pertinent(s) pour répondre aux besoins de l'utilisateur. Raymond a utilisé CUPS en tant que thème général pour montrer que l'interface utilisateur des bureaux Linux avait besoin d'être repensée. Il a déclaré :
« Le gros problème ici, est que l'assistant de configuration effectue tous les processus approuvés (GUI, avec des boutons à cliquer standards, l'aide apparaissant dans un navigateur, etc., etc.) mais ne possède pas l'attribut central qu'ils sont supposés atteindre : l'accessibilité de la découverte. Ce qui fait la qualité d'une interface, c'est le fait qu'à chaque action soit associé un commentaire, depuis lequel vous pouvez apprendre que faire par la suite. Votre projet a-t-il cette qualité ? »