# Alguma Base Teórica: o &CUPS;, o IPP, o &PostScript; e o GhostScript

Este capítulo tenta dar uma base teórica para a impressão em geral, e particularizando com o &CUPS; em especial. Se não tiver necessidade disto, poderá saltar directamente para o próximo capítulo. Eu aposto que o utilizador irá voltar a este capítulo a uma certa altura de qualquer forma, por causa da necessidade da teoria extra para resolver um problema prático.

## Bases sobre a Impressão

A impressão é um dos capítulos mais complicados da tecnologia das TI.

Antigamente, todos os criadores de um programa que fosse capaz de devolver resultados imprimíveis tinham também de criar os seus próprios controladores de dispositivos. Isto era muito complicado, porque os diferentes programas tinham diferentes formatos de ficheiros. Mesmo os programas com utilizações semelhantes, como por exemplo os processadores de texto, muitas das vezes não compreendiam os formatos dos outros. Por isso, não existia uma interface comum para todas as impressoras, uma vez que os programadores apenas suportavam alguns modelos.

A aparição de um novo dispositivo no mercado requeria que os autores do programa criassem um novo controlador se quisessem que o programa deles o suportasse. Também para os fabricantes era impossível garantir que o dispositivo deles era suportado por algum programa conhecido (porém, existiam muito menos nessa altura).

Se tivesse de suportar dez aplicações e uma dúzia de impressoras, um administrador tinha de lidar com 120 controladores. Por isso o desenvolvimento de interfaces unificadas entre os programas e as impressoras tornou-se uma necessidade urgente.

A aparência das Page Description Languages que descrevem a representação gráfica dos tinteiros e 'toners' nas folhas de papel (ou noutros dispositivos, como os monitores, reveladores de fotografias, &etc;) de uma forma comum foi uma movimentação que descobriu uma grande falha.

Um desenvolvimento nesse prisma foi o &PostScript; da Adobe. Significava que o programador de uma aplicação poder-se-ia concentrar em fazer o seu programa devolver uma descrição na linguagem &PostScript; da sua página a imprimir, enquanto que os programadores dos dispositivos de impressão poder-se-iam focar em tornar os seus controladores capazes de compreender &PostScript;.

Claro que foram aparecendo outros métodos de descrição com o tempo. Os competidores mais importantes com o &PostScript; foram a PCL (Print Control Language, da &Hewlett-Packard;), o ESC/P (da Epson) and GDI (Graphical Device Interface da &Microsoft;).

A aparição dessas linguagens de descrição facilitou a vida e o desenvolvimento posterior para todos. Porém o facto de que ainda existem linguagens diferentes, incompatíveis e concorrentes entre si complica quanto baste a vida aos utilizadores, administradores, programadores e fabricantes.

### &PostScript; na memória - Imagens no Papel

O &PostScript; é usado em grande escala nos ambientes de impressão profissionais como a PrePress e as indústrias de serviços de impressão. Nos domínios do &UNIX; e do &Linux;, o &PostScript; é a norma dominante como PDL. Aqui, praticamente todos os programas geram uma representação em &PostScript; das suas páginas quando o utilizador carrega no botão Imprimir. Vejamos um exemplo simples de código &PostScript; (feito à mão). A seguinte listagem descreve dois simples desenhos:

#### Código &PostScript;

    %!PS
    100 100 moveto
    0 50 rlineto
    50 0 rlineto
    0 -50 rlineto
    closepath
    .7 setgray fill
    % first box over; next
    160 100 moveto
    0 60 rlineto
    45 10 rlineto
    0 -40 rlineto
    closepath
    .2 setgray fill

Isto indica à caneta imaginária do &PostScript; para desenhar um caminho com uma determinada forma, para depois preenchê-lo com diferentes tons de cinzento. A primeira parte traduz-se para Português como Vá para a coordenada (100,100), desenhe uma linha de comprimento 50 para cima, depois outra para a direita, depois outra para baixo e finalmente feche este caminho. Agora defina um preenchimento de cinzento a 70%, e use-o para preencher a forma desenhada.

#### &PostScript; Desenhado

coded-postscript exemplo desenhado como uma imagem.

Claro que o &PostScript; pode ser muito mais complicado do que este exemplo simples. É uma linguagem de programação completa com muitas funções e operadores. O utilizador até poderá escrever programas em &PostScript; para calcular o valor de PI, formatar um disco rígido ou escrever num ficheiro. A mais-valia e o poder do &PostScript; é no campo da descrição do formato de objectos gráficos numa página: também pode escalar, fazer imagens em espelho, transladar, transformar, rodar e distorcer tudo o que possa imaginar num pedaço de papel -- como as letras em diferentes formas, figuras, tons, cores, linhas, pontos, imagens...

Um ficheiro &PostScript; é uma representação de uma ou mais páginas a imprimir de uma forma relativamente abstracta. Idealmente, pretende descrever as páginas de uma forma independente do dispositivo. O &PostScript; não é visível normalmente; só reside nos discos rígidos e na memória RAM como uma representação em código das impressões futuras.

### Imagens em Folhas de Papel

O que o utilizador vê normalmente numa folha de papel é quase sempre uma imagem rasterizada. Mesmo que aos seus olhos pareça uma linha, pegue numa boa lupa e verá os pequenos pontos (um contra-exemplo são as folhas que foram desenhadas em plotters). Isto é praticamente a única coisa que os motores de desenho das impressoras actuais sabem pôr no papel: pontos simples de diferentes cores, tamanhos e resoluções de modo a gerar uma imagem completa na página.

As diferentes impressoras precisam da imagem preparada numa forma que difere de umas para outras. Pensando num dispositivo de jacto de tinta: dependendo da suas resolução, número de tinteiros usados (as impressoras muito boas usam 7 cores, enquanto que uma mais barata só tem 3), o número de jactos disponíveis (algumas cabeças de impressão têm mais de 100) a emitir tinta em simultâneo, o algoritmo de dithering usado, entre muitas outras coisas, o formato final da imagem e a ordem de transferência são fortemente dependentes do modelo exacto usado.

No início do Line Printer Daemon, as impressoras eram máquinas que martelavam linhas de texto em ASCII mecanicamente em papel longo, dobrado como um cobra de papel em ziguezague, a partir de caixas de cartão por baixo da mesa... Que diferença!

### RIP: Do &PostScript; para a Imagem

Antes das imagens finais serem postas nas folhas de papel, elas têm de ser calculadas de alguma forma a partir da sua representação abstracta em &PostScript;. Este processo intensivo computacional é chamado de Raster Imaging Process ou mais conhecido por RIP.

Com as impressoras &PostScript;, este processo é tratado pelo próprio dispositivo. O utilizador só terá de enviar para ele o ficheiro &PostScript;. O Raster Imaging Processor (também conhecido como RIP) dentro da impressora é responsável (e especializado) no desempenho desta tarefa de interpretação da descrição da página em &PostScript; e da impressão no papel.

Os dispositivos &PostScript; mais pequenos têm incluído um RIP em 'hardware', que é implementado em silício, num chip especial. As impressoras maiores e mais profissionais têm muitas vezes o seu RIP implementado em 'software' dentro de um computador rápido em &UNIX;, sendo normalmente uma máquina Sun SPARC Solaris ou um &IRIX; da &SGI;.

### O GhostScript como um RIP por Software

Mas o que acontece se não tiveres a sorte de ter uma impressora &PostScript; disponível?

O utilizador precisa de realizar o RIP antes de enviar os dados de impressão para o dispositivo. Precisa de digerir o &PostScript; gerado pela sua aplicação na própria máquina. Tem de conhecer o formato final das impressoras para as quais irá compor o resultado.

Por outras palavras, como não podes esperar que a impressora compreenda o &PostScript; em si, o problema torna-se um pouco mais complicado. Precisas de 'software' que tente resolver por ti a maior parte desse problema.

Isto é exactamente o que o pacote omnipresente &ghostscript; faz em muitas das máquinas de &Linux;, *BSD e outros &UNIX;es para imprimir em impressoras não-&PostScript;. É um interpretador de &PostScript;, ou seja, um RIP por software para muitos dispositivos diferentes.

### Controladores (Drivers) e Filtros no Geral

Para produzir as imagens rasterizadas a partir do resultado em &PostScript;, é usado o conceito de filtros pelo &ghostscript;. Existem diversos filtros no &ghostscript;, em que alguns são especializados para um determinado modelo de impressora. Os filtros do &ghostscript; para certos dispositivos foram muitas vezes desenvolvidos sem o consentimento ou o suporte do fabricante correspondente. Sem acesso às especificações e à documentação, era um processo altamente doloroso de descobrir os protocolos e formatos de dados.

Nem todos os filtros do &ghostscript; funcionam bem para as suas impressoras. Mesmo assim, alguns dos mais recentes, como o stp do projecto Gimp-Print, produzem resultados excelentes que conduzem a uma qualidade fotográfica igual ou superior aos seus equivalentes em &Windows;.

&PostScript; é o que a maioria das aplicações produzem para imprimir no &UNIX; e no &Linux;. Os filtros são os verdadeiros elementos trabalhadores de qualquer sistema de impressão. Basicamente, eles produzem as imagens certas de qualquer resultado em &PostScript; para os destinatários não-&PostScript;.

### Controladores, Filtros e Infra-estruturas do CUPS

O &CUPS; usa os seus próprios filtros, ainda que o sistema de filtragem seja baseado no Ghostscript. Nomeadamente, os filtros pstoraster e imagetoraster são derivados directamente do código do ghostscript. O &CUPS; reorganizou e alinhou a mecânica deste código legado, repartindo-a em alguns módulos claros e distintos.

Este próximo desenho (feito com a ajuda do &kivio;) dá uma ideia geral dos filtros e infra-estruturas do &CUPS; e como estes se encaixam. O fluxo é de cima para baixo. As infra-estruturas são filtros especiais: não convertem os dados para um formato diferente, mas enviam os ficheiros para a impressora. Existem diferentes infra-estruturas para diferentes protocolos de transferência.

A janela do &kprinter; iniciada (rascunho do &kivio;) A janela do &kprinter; iniciada (rascunho do &kivio;)

### Escalonadores e Servidores de Impressão

Para além da tarefa pesada de filtragem para gerar uma imagem pronta a imprimir, qualquer 'software' de impressão precisas de usar um mecanismo de escalonamento: este permite alinhar as diferentes tarefas de diferentes utilizadores para diferentes impressoras e filtros e enviá-los correctamente para o destino. O servidor de impressão toma conta de tudo isto.

Este servidor mantém a casa em ordem: é também responsável pelo controlo de tarefas: os utilizadores devem ter a possibilidade de cancelar, parar, reiniciar &etc; as suas tarefas (mas não as dos outros) entre outras coisas.

## Excursão: Como o CUPS usa o poder dos &PPD;s

Agora que o utilizador sabe como um ficheiro na linguagem &PostScript; (que descreve o formato da página de uma forma independente do dispositivo) é processado para se transformar numa imagem rasterizada, poderá perguntar:Bem, existem diferentes tipos de dispositivos de saída: em primeiro lugar, diferem na sua resolução; depois existem os diferentes tamanhos de papel; passa ainda por diferentes formas de finalização (impressões em duplex, panfletos, papel prensado e agrafado com diferentes folhas de papel colorido a sair de bandejas diferentes, &etc;). Como é que isto se encaixa no nosso modelo do &PostScript;?

A resposta a isto são os ficheiros &PPD; (&PostScript; Printer Description). Um ficheiro &PPD; descreve todas as características dependentes do dispositivo que podem ser utilizadas por um certo modelo de impressora. Também contém os comandos codificados que devem ser usados para invocar certas funcionalidades do dispositivo. Todavia, os &PPD;s não são fechados, são ficheiros de texto em ASCII simples.

Os &PPD;s foram inventados pela Adobe para facilitar aos fabricantes a implementação das suas próprias funcionalidades nas impressoras &PostScript;, e ao mesmo tempo definir uma forma normalizada de o fazer. Os &PPD;s estão bem documentados e descritos pela Adobe. A sua especificação é uma norma aberta de facto.

### Opções de Impressão Dependentes do Dispositivo

Lembre-se, a impressão avançada em &PostScript; foi desenvolvida inicialmente só para os sistemas do &Microsoft; &Windows; e Apple &Mac;. Durante bastante tempo as funcionalidades avançadas de impressão nos dispositivos modernos simplesmente não estavam disponíveis no &Linux; e no &UNIX;. Agora, os &PPD;s existentes podem ser utilizados por completo em todos os sistemas que tenham o &CUPS;.

Através dos &PPD;s, os fabricantes de impressoras foram capazes de inserir as funcionalidades específicas do 'hardware' nos seus produtos, para coisas como a impressão duplex, a colocação de agrafos, a finalização, &etc;. Os controladores de impressoras carregam este &PPD; tal como um ficheiro de configuração adicional. Deste modo o controlador da impressora aprende as opções disponíveis do dispositivo e como as invocar; o controlador também as mostra numa interface gráfica ao utilizador. Através deste mecanismo, o utilizador tem ainda a possibilidade de imprimir os ficheiros da linguagem de descrição da página em &PostScript; independente do dispositivo e especificar as opções de finalização dependentes do dispositivo no topo, que são adicionadas ao &PostScript; produzido pela aplicação.

### Onde obter os &PPD;s para as Impressoras &PostScript;

Os &PPD;s não eram usados normalmente nos sistemas &UNIX; e &Linux;. Os fabricantes que forneciam esses &PPD;s nunca pretenderam disponibilizá-los para outros sistemas operativos que não fossem os suportados inicialmente: o &Microsoft; &Windows; e o &Mac; OS. Através da sua estratégia brilhante de suportar por completo e usar a especificação do &PPD; existente, o &CUPS; permite agora a possibilidade de usar todas as potencialidades das impressoras modernas para os utilizadores do &Linux; e compatíveis. O &kdeprint; torna a sua utilização ainda mais confortável do que os programadores do &CUPS; alguma vez pensariam.

O &CUPS; pode usar os &PPD;s originais do Windows distribuídos pelos fabricantes no caso das impressoras &PostScript;. Estes normalmente não custam nada, e podem ser obtidos em qualquer computador de &Windows; com um controlador de &PostScript; instalado para o modelo em questão, ou a partir dos discos que vêm com a impressora. Existem também bastantes locais na Web onde os obter.

### Como os &PPD;s Especiais São Úteis Agora Mesmo Para Impressoras Não-&PostScript;

Agora já sabes que as impressoras de &PostScript; podem usar os &PPD;s. E com as impressoras não-&PostScript;? O &CUPS; realizou um truque bastante bom: usando o mesmo formato e estrutura de dados que os &PPD;s no mundo do &PostScript;, ele consegue descrever as opções de impressão disponíveis para as impressoras não-&PostScript; exactamente da mesma forma. Para os seus próprios fins o &CUPS; acrescentou algumas opções especiais (nomeadamente a linha que define o filtro a ser usado para o processamento posterior do ficheiro &PostScript;).

Assim, os programadores conseguiam usar o mesmo motor de 'software' para analisar os ficheiros &PPD; para as opções disponíveis em todos os tipos de impressoras. É óbvio que os programadores do &CUPS; não podiam confiar nos fabricantes de impressoras não-&PostScript; para começarem a desenvolver de repente &PPD;s. Tinham que fazer a parte difícil eles próprios e recriá-los do zero. Existem mais de 1000 destes disponíveis na versão comercial do &CUPS;, chamada ESP PrintPro.

Entretanto existe uma grande quantidade de &PPD;s específicos do &CUPS; disponíveis, mesmo os que não são provenientes dos fabricantes das impressoras mas sim dos programadores de software gratuito. Os programadores do &CUPS; provaram-no, e outros os irão seguir: onde a impressão em &Linux; ou &UNIX; há um ou dois anos era uma confusão, agora consegue suportar uma gama apreciável de impressoras, incluindo as de jacto de tinta com 7 cores para qualidade fotográfica.

### Diferentes Formas de Obter &PPD;s para Impressoras Não-&PostScript;

Podes obter &PPD;s para usar com o &CUPS; em impressoras não-&PostScript; em diferentes áreas na Web:

- em primeiro lugar, existe o repositório em www.linuxprinting.org, que te permite gerar um &PPD; CUPS-O-Mático de uma forma 'online' para qualquer impressoras que já fosse suportada pelo &ghostscript;. Isto ajuda-te a mudar para o &CUPS; sem grandes dificuldades, se o preferires. Se a tua impressora funcionava bem com a alternativa do &ghostscript;, utiliza o CUPS-O-Matic para ligares o teu controlador no sistema do &CUPS; e teres o melhor de dois mundos.

- em segundo lugar, existem &PPD;s do &CUPS; para mais de 120 modelos de impressora, que são suportados pelo controlador universal stp. O stp (que significava originalmente Stylus Photo) é desenvolvido pelo projecto do gimp-print; foi iniciado pelo Mike Sweet, o programador principal do &CUPS; e está disponível agora em gimp-print.sourceforge.net. Este controlado imprime com qualidade fotográfica em muitas impressoras de jacto de tinta modernas e pode ser configurado para gerar 120 &PPD;s do &CUPS; ao longo da sua compilação. Os modelos LaserJet e DeskJet da &HP;, os modelos Epson Stylus e Photo Color assim como alguns da Canon e da Lexmark são suportados.

- em terceiro lugar, existe a extensão comercial do &CUPS;, feita pelos próprios programadores do &CUPS;: chama-se ESP PrintPro e vem com mais de 2300 controladores de impressora. Existem até filtros de imagem e &PostScript; incluídos.

O &CUPS; torna muito simples para os fabricantes o suporte em &Linux; e &UNIX; dos seus modelos. A plataforma modular do &CUPS; facilita a ligação de qualquer filtro ou controlador com o mínimo de esforço e o acesso e utilização do ambiente de impressão que o &CUPS; cria.

Podes ler mais acerca das potencialidades excitantes do &CUPS; na sua documentação que está disponível em http://www.cups.org/documentation.html e http://www.danka.de/printrpo/faq.html. Também existe em http://www.linuxprinting.org/ um repositório universal com tópicos relacionados com a impressão em &Linux; e &UNIX;.

## Como o Suporte de &IPP; Torna o &CUPS; a Melhor Opção

### O LPD Deve Morrer!

Durante bastante tempo os vários programadores estavam largamente insatisfeitos com o arcaico LPD. Vários projectos novos foram iniciados para melhorar a impressão: o LPRng é o melhor exemplo conhecido. Os outros são o PDQ, o PPR, o PLP, o GNUlpr e o RLPR. Mas nenhum dos novos programas foi visto como uma grande maravilha; a maioria deles é apenas uma reimplementação da especificação do LPD com algumas (ou muitas) novas extensões, que os tornam incompatíveis entre si.

Depois de ver o desenvolvimento de não apenas uma, mas muitas alternativas viáveis ao LPD do BSD, o Grant Taylor, autor do Linux Printing HOWTO, citou a frase O LPD Deve Morrer! na sua Campanha para Abolir o Line Printer Daemon.

### Como o &IPP; Foi Pensado

Em conjunto com os acima citados, na perspectiva industrial das coisas, existiram esforços para ultrapassar as fraquezas por demais conhecidas do LPD. Começou com as extensões proprietárias do LPD original, e foi-se projectando até à tentativa da &Hewlett-Packard; de estabelecer o &HP; JetDirect como uma nova norma para um protocolo de impressão na rede. O resultado foram ainda mais incompatibilidades.

No fim, tomou lugar uma iniciativa para definir uma nova indústria comum e uma norma do IETF. O Printer Working Group ou PWG, uma agregação de fabricantes de hardware, software e sistemas operativos, elaboraram uma versão preliminar do novo Internet Printing Protocol ou &IPP;, um protocolo de impressão através da Internet. O &IPP; v1.1 foi já aprovado pelo IETF (Internet Engineering Task Force) como uma norma proposta, e goza agora de um suporte unânimo em toda a indústria de impressoras na Europa, EUA e Japão. A maioria dos modelos de impressoras de rede actuais têm suporte de &IPP; incluído, para além da impressão com o LPR/LPD tradicional ou o JetDirect.

### Porque o &IPP; Resolve Muitos Problemas

O &IPP; pretende resolver muitos dos problemas que os administradores de redes enfrentam. Este passa por vários ambientes de rede e passa mais metade do seu tempo a lidar com problemas de impressão.

Ao criar um conjunto unificado de funções de pesquisa para as impressoras e servidores de &IPP;, para transferir ficheiros e definir atributos de controlo das tarefas, entre outras coisas, o &IPP; está destinado a funcionar em todas as plataformas de sistemas operativos. A sua implementação não será, contudo, da noite para o dia, dado que muitos dispositivos de impressão legados irão continuar a ser usados nos próximos tempos. Por isso, no &IPP; existe uma opção de retro-compatibilidade para todas as implementações de &IPP;- O &CUPS; tenta provar a viabilidade da impressão com o &IPP; em todos os ambientes.

A vantagem mais notória será a sua integração com o conjunto existente dos protocolos robustos do IP. Sendo uma extensão do protocolo HTTP 1.1, para a tarefa especial de lidar com os dados dos ficheiros de impressão e relacionados, é também bastante simples ligar com outras normas à medida que vão sendo desenvolvidas e instaladas:

- Autenticação Básica, por Digest e com Certificados para os utilizadores que desejam aceder aos serviços de impressão.

- Cifra SSL3 e TLS para a transferência de dados.

- Comunicação bidireccional dos clientes com os dispositivos de impressão usando o mecanismo de `GET` e `POST` do HTTP/&IPP;.

- Integração com o serviço de directório do LDAP para manter uma base de dados consistente das impressoras disponíveis, as suas capacidades e custos de páginas, &etc;, assim como as senhas de utilizadores, ACLs, &etc;.

- Impressão Pull (em oposição ao modelo usual Push), onde um servidor ou impressora apenas precisa de ver indicado o &URL; de um documento, a partir do qual é obtido o recurso na Internet e impresso.

### Plug'n'Play de Impressoras para os Clientes

Alguma vez viste uma demonstração das capacidades do &CUPS; na rede? Deves ter ficado bastante surpreendido se não sabias de antemão o que te esperava.

Imagina que és o administrador de uma LAN. Para fins de teste, instalaste completamente uma máquina de &kde;/&CUPS; na tua rede, em conjunto com uma dúzia de impressoras configuras e funcionais: &PostScript;, LaserJets, InkJets e BubbleJets, e assim por diante. Os teus utilizadores do &kde; nessa máquina ficarão bastante satisfeitos, dado que podem imprimir como nunca o fizeram, a tirar partido de todas as funcionalidades das várias impressoras. Levou-te 2 horas a pôr tudo a funcionar... e agora os outros 100 utilizadores da rede querem o mesmo. Outra vez duas horas para cada máquina? Nem no fim do ano que vem, pensas tu?

Errado. Basta mudares uma configuração na máquina de &CUPS; para a tornar um servidor. Instala o &CUPS; noutras cinco máquinas como clientes. Na altura em que voltares ao teu primeiro cliente, verás que o utilizadores já deram com as configurações das diversas impressoras que definiste no servidor. Como por magia, as impressoras apareceram nas janelas de Imprimir das cinco novas máquinas de &CUPS;.

Os teus utilizadores imprimem, mas nem um único controlador foi instalado nos clientes ou uma fila de impressão definida.

Então, como é que esta magia funciona?

### Ver Impressoras Não Instaladas Localmente?

A resposta não é nada complicada.

Se existir um servidor de &CUPS; na LAN, este difunde os nomes de todas as impressoras disponíveis para a LAN, usando o protocolo UDP e o porto 631. O porto 631 está reservado como porto conhecido pelo IANA (Internet Assigning Numbers Authority - a autoridade de atribuição de números na Internet) para o &IPP;. Todos os clientes de &CUPS; esperam informação do servidor de &CUPS; no seu porto 631. É assim como eles sabem das impressoras disponíveis, e é assim que eles aprendem a localização das mesmas.

Usando o &IPP;, que é de facto uma extensão inteligente do HTTP v1.1, o &CUPS; é capaz de endereçar todos os objectos relacionados com o sistema de impressão através de Universal Resource Locators ou URLs. As tarefas de impressão a serem apagadas ou reiniciadas, as impressoras a serem pesquisadas ou modificadas, as tarefas de administração a serem efectuadas pelo servidor, com o &IPP; e o &CUPS;, tudo é endereçável através de um determinado URL. Muitas das coisas importantes podem ser feitas através da interface Web do &CUPS;, acessível por exemplo através do &konqueror;.

### Imprimir sem Instalar um Controlador

Mais ainda, os cliente podem, basicamente, administrar e usar todas as impressoras que vejam, tal como se estivessem instaladas localmente. Claro que podes definir restrições a elas com listas de controlo de acesso &etc;, de modo a que nem todos os clientes possam usar todas as impressoras que desejem.

Os clientes até são capazes de imprimir sem o filtro apropriado (ou controlador) instalado localmente.

Então como é que isto funciona? Se um cliente quiser conhecer e seleccionar as opções específicas da impressora, envia um pedido (chamado `CUPS-get-ppd`) para o servidor. O servidor indica ao cliente todas as opções específicas da impressora, tal como estão descritas no &PPD; do servidor. O utilizador do lado do cliente pode ver as opções e seleccionar as necessárias. Ele envia então o ficheiro de impressão, normalmente &PostScript; por filtrar, em estado bruto, em conjunto com as opções da impressora, para o servidor da impressora, utilizando o &IPP; como o protocolo de transporte. Todo o processamento posterior, especialmente a filtragem para gerar o formato final da impressora de destino, é então efectuado pelo servidor. O servidor tem os programas necessários (controladores ou filtros) para o fazer.

Desta forma um cliente imprime sem necessitar de instalar um controlador localmente.

Qualquer mudança no servidor, como a adição ou modificação de uma impressora é instantaneamente notificado nos clientes sem mais configurações.

### Administração Nula, Balanceamento de Carga e Mudança por Falha

Algumas das funcionalidades adicionais incluídas no &CUPS; são a capacidade de efectuar balanceamento de carga.

Se definires as mesmas filas de impressão em dois ou mais servidores diferentes, os clientes irão enviar as suas tarefas para a primeira impressora disponível. Isto implica um balanceamento da carga automático entre os servidores. Se tiveres que retirar um servidor da rede para manutenção, os outros irão tratar as suas tarefas sem que os utilizadores notem a diferença.