Este capítulo tem o objetivo de fornecer um bit de embasamento teórico sobre impressão em geral, e sobre o ∪︀ especialmente. Se você não está interessado nisso, você pode pular para o próximo capítulo. Você terá chance de retornar a este capítulo quando desejar, porque algumas vezes você precisará de um conhecimento extra para resolver um problema prático. A impressão é um dos mais complicados capítulos na tecnologia IT. No início, cada desenvolvedor de um programa que fosse capaz de produzir saída impressa também tinha que escrever seus próprios drivers de impressora. Isto era um pouco complicado, porque programas diferentes possuem diferentes formatos de arquivo. Mesmo programas com o mesmo propósito, por exemplo: processadores de texto, freqüentemente não reconhecem os formatos de arquivo de outros programas. Não havia nenhuma interface comum para todas as impressoras, uma vez que os programadores freqüentemente inseriam suporte somente a alguns poucos modelos. O surgimento de um novo dispositivo no mercado forçava aos autores do programa escreverem um novo driver se desejassem que seu programa suportasse a nova impressora. Também para os fabricantes, era impossível ter certeza de que seus dispositivos seriam suportados por qualquer programa conhecido no mudo (embora houvessem bem menos programas do que hoje). Dar suporte em dez programas de aplicativos à uma dúzia de impressoras, significava que o administrador de sistema teria que programar 120 drivers. Logo o desenvolvimento de interfaces unificadas entre os programas e impressoras tornou-se uma necessidade urgente. O surgimento de Linguagens de Descrição de Página, descrevendo a representação gráfica da tinta e toner nas folhas de papel (ou em outros dispositivos, como monitores, plotadoras fotográficas, &etc;) de uma maneira unificada, já serviu para preencher uma grande lacuna. Um destes desenvolvimentos foi o &PostScript; da Adobe. Isto significava que um programador de aplicativo podia se concentrar em fazer com que seu programa gerasse uma descrição em linguagem &PostScript; de sua página imprimível, enquanto desenvolvedores de dispositivos de impressão poderiam focar-se em tornar seus dispositivos literalmente &PostScript;. É claro, ao longo do tempo, surgiram o desenvolvimento de outros métodos de descrição. Os mais importantes competidores do &PostScript; eram o PCL (Linguagem de Controle de Impressão, da &Hewlett-Packard;), o ESC/P (da Epson) e o GDI (Interface de Dispositivo Gráfico da &Microsoft;). O surgimento destas linguagens de descrição de página tornou a vida mais fácil, e facilitou o desenvolvimento futuro para todos. No entanto, o fato destas linguagens de descrição de páginas competidoras permanecerem diferentes e incompatíveis, torna a vida de usuários, administradores, desenvolvedores e fabricantes difícil o suficiente. O &PostScript; é a mais pesadamente usada em ambientes de impressão profissional, como Pré-Impressão e indústrias de serviços de impressão.No mundo &UNIX; e &Linux;, o &PostScript; é o padrão predominante como o PDL. Aqui, praticamente todo programa gera uma representação &PostScript; de suas páginas assim que você pressiona o botão Imprimir. Vamos dar uma olhada num exemplo simples de código &PostScript; (feito à mão). A seguinte listagem descreve dois desenhos simples: %!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 diz para a caneta imaginária do &PostScript; desenhar uma linha de uma determinada forma, e então preenchê-la com diferentes tons de cinza. A primeira parte traduzida para um Português compreensível diz Vá para coordenada (100,100), desenhe uma linha com 50 de comprimento para cima; e então um a partir dela para direita, então para baixo novamente, e finalmente feche esta forma. Agora preenche a forma com 70% de cinza escuro. exemplo de uma imagem renderizada É claro, o &PostScript; pode ser muito mais complicado do que este simples exemplo. Ele é uma linguagem de programação completa com muitos operadores e funções diferentes. Você tanto escrever programas &PostScript; para computar o valor de Pi, formatar um disco rígido ou escrever para um arquivo. A principal vantagem e força do &PostScript; no entanto está na maneira de descrever a disposição de objetos gráficos numa página: ele pode também escalonar, espelhar, traduzir, transformar, rotacionar e distorcer tudo que você possa imaginar num pedaço de papel -- como letras em diferentes representações de fonte, figuras, formas, sombras, cores, linhas, pontos, quadriculados... Um arquivo &PostScript; é uma representação de uma ou mais páginas a serem impressas, de uma maneira relativamente abstrata. Preferencialmente, ele serve para descrever páginas de uma maneira independe de dispositivo. O &PostScript; não é visível diretamente; ele somente reside no disco rígido e na RAM como uma representação codificada de futuras saídas de impressão. O que você vê num pedaço de papel é quase sempre uma imagem quadriculada. Apesar de seu cérebro sugerir que seus olhos vêem uma linha: de uma boa ampliada na visão e você descobrirá milhares de pequenos pontos... (Um exemplo do contrário são linhas que foram desenhadas por plotadoras). E isto é a única coisa que as máquinas de marcação das impressoras de hoje podem colocar no papel: simples pontos de diferentes cores, tamanhos e resoluções, para criar uma página de imagem completa composta de diferentes padronagens de mapas de bits. Impressoras diferentes precisam de uma imagem quadriculada preparada de modos diferentes. Pense num dispositivo de jato de tinta: dependendo de sua resolução, o número de cores usadas (um muito bom precisa de 7 cores diferentes, enquanto os mais baratos podem precisar somente de 3), o número de jatos disponíveis (algumas cabeças de impressão possuem mais de 100!) dispersando tinta simultaneamente, o algoritmo de suavização usado, e muitas outras coisas, o formato da quadriculação final e a ordem de transferência para o mecanismo de impressão é fortemente dependente do modelo exato usado. No início da criação do Serviço de Impressão Linear, impressoras eram máquinas que martelavam linhas de texto ASCII mecanicamente por toda a mídia, dobrada como uma serpente de papel em zig-zag, puxado de uma caixa de formulário colocada embaixo da mesa... Que diferença para hoje! Antes das imagens finais quadriculadas serem colocadas nas folhas de formulário contínuo, elas tinham que ser calculadas de algum modo a partir da representação abstrata do &PostScript;. Este é um processo de computação muito intensivo. Ele é chamado de Processo de Quadriculação da Imagem, mais comumente RIP). Com impressoras &PostScript; o RIPiamento é responsabilidade do dispositivo propriamente dito. Você apenas envia o arquivo &PostScript; para ele. O Processador de Quadriculação de Imagem (também chamado RIP) existente dentro da impressora é responsável (e especializado) por cumprir completamente e muito bem esta tarefa de interpretação das descrições de páginas &PostScript; e colocar a imagem quadriculada no papel. Pequenos dispositivos &PostScript; possuem um RIP por hardware embutidos neles; ele é gravado em silício, num chip especial. Grandes impressoras profissionais freqüentemente possuem seus RIP implementados como um RIP por software executado dentro de um computador &UNIX; rápido, freqüentemente um Sun SPARC Solaris ou uma máquina &SGI; &IRIX;. Mas o que acontece se você não tem a sorte suficiente de possuir uma impressora &PostScript; disponível? Você precisa fazer o RIPiamento antes de enviar os dados de impressão para o mecanismo de impressão. Você precisa adequar o &PostScript; gerado por seu aplicativo na máquina cliente (a impressora cliente) propriamente dita. Você precisa saber como o formato quadriculado exato do mecanismo de impressão da impressora destino deve ser composto. Em outras palavras, como você não pode delegar para a impressora o trabalho de compreensão e interpretação do &PostScript; por si só, a impressão se torna um pouco mais complicada. Você precisa de um software que tente resolver para você os processos envolvidos. Isto é exatamente o que o onipresente pacote do &ghostscript; está fazendo para muitas distribuições &Linux;, *BSD e outros &UNIX; que precisam imprimir para impressoras não-&PostScript;: o &ghostscript; é um interpretador &PostScript;, um software de RIP capaz de funcionar com muitos dispositivos diferentes. Para produzir um mapa de bits quadriculado de uma entrada &PostScript;, o conceito de filtros é usado pelo &ghostscript;. Existem muitos filtros diferentes no &ghostscript;, alguns deles especializados para um determinado modelo de impressora. Filtros do &ghostscript; especializados em dispositivos freqüentemente são desenvolvidos sem a permissão ou suporte do respectivo fabricante. Sem acesso às especificações e documentação, isto se torna um processo extremamente difícil de engenharia reversa de protocolos e formatos de dados. Nem todos os filtros do &ghostscript; funcionam tão bem em suas impressoras. Por outro lado, alguns dos novos, como o Filtro stp do projeto de Impressão do Gimp, produzem excelentes resultados com qualidade fotográfica semelhantes ou superiores aos drivers desenvolvidos para o &Microsoft; &Windows;. O &PostScript; é o que a maioria dos programas aplicativos produzem para impressão no &UNIX; e &Linux;. Filtros são o grande cavalo de batalha de qualquer sistema de impressão aqui. Essencialmente eles produzem mapas de bits corretos a partir de qualquer entrada &PostScript; para mecanismos de impressão não-&PostScript;. O ∪︀ usa seus próprios filtros, embora o sistema de filtragem seja baseado no Ghostscript. Os filtros chamados pstoraster e imagetoraster são derivados diretamente do código do Ghostscript, O ∪︀ reorganizou e melhorou todos os mecanismos do código original e organizou-o em alguns poucos módulos compactos e distintos. O próximo desenho (feito com a ajuda do &kivio;) fornece uma visão geral dos filtros e backends existentes no ∪︀ e como eles trabalham juntos. O fluxo é de cima para baixo. Backends são filtros especiais: eles não convertem dados para um formato diferente, mas eles enviam os arquivos prontos para a impressora. Existem backends diferentes para diferentes protocolos de transferência. diálogo do &kprinter; iniciado (desenho do &kivio;) diálogo do &kprinter; iniciado (desenho do &kivio;) Ao lado da parte pesada da tarefa de filtragem para gerar um mapa de bits pronto para impressão, qualquer software de impressão precisa usar o mecanismo de fila de impressão: este é o que organiza os diferentes trabalhos de diferentes usuários para diferentes impressoras e diferentes filtros e envia-os de acordo com seus destinos. O serviço de impressão toma conta de tudo isso. Este serviço é que mantém a casa em ordem: ele também é responsável pelo controle do trabalho: usuários devem poder cancelar, parar, reiniciar, &etc; seus trabalhos (mas não trabalhos de outras pessoas) e assim por diante. Agora que você sabe como um arquivo em linguagem &PostScript; (que descreve a disposição da página de uma maneira independente de dispositivo) é transformado numa Imagem Quadriculada, você deve se estar perguntando: Bem, existem diferentes tipos de dispositivos de saída de quadriculação: primeiro eles diferem em sua resolução; então eles possuem tamanhos de papel diferentes; eles vem com muitas opções de acabamento (impressão em frente e verso, panfletos, saída perfurada e grampeada com diferentes folhas de papel colorido sendo alimentadas a partir de diferentes bandejas, &etc;). Como fazer isto se adequar ao nosso modelo independente de dispositivo do &PostScript;? A resposta vem com os chamados arquivos de Descrição de Impressora &PostScript; (&PPD;). Um &PPD; descreve todos os recursos dependente do dispositivo que podem ser utilizados por um determinado modelo de impressora. Ele também contém os comandos código que devem ser usados para chamar determinados recursos do dispositivo. Ma os &PPD; não são um livro fechado, eles são simplesmente arquivos texto em ASCII. Os &PPD;s foram inventados pela Adobe para tornar mais fácil para os fabricantes implementar seus próprios recursos em impressoras &PostScript;, e ao mesmo tempo manter um modo padronizado de fazer isto. &PPD;s são muito bem documentados e descritos pela Adobe. Suas especificações são um padrão aberto de fato. Lembre-se, a impressão avançada com &PostScript; foi originalmente desenvolvida somente para uso com sistemas &Microsoft; &Windows; e &Mac; da Apple. Por muito tempo, todos os melhores recursos de impressão dos dispositivos modernos estavam simplesmente inacessíveis aos usuários do &Linux; e &UNIX;. O ∪︀ mudou isto decisivamente. O ∪︀ intimamente ligado aos &PPD;s e deste modo &PPD;s existentes podem ser utilizados sem problemas com todos os sistemas que possuem o ∪︀ instalado. Usando os &PPD;s os fabricantes de impressoras serão capazes de inserir recursos de hardware específicos em seus produtos, recursos como impressão em frente e verso, saídas grampeadas, saídas furadas, acabamento, &etc;. Os drivers de impressoras carregam este &PPD; apenas como um arquivo de configuração adicional. Assim o driver de impressora aprende sobre as opções disponíveis do dispositivo e como chamá-las; o driver também fornece uma &GUI; ao usuário. Através deste mecanismo você ainda será capaz de imprimir arquivos de linguagem de descrição de página &PostScript; independentes do dispositivo e com as opções de acabamento específicas de cada dispositivo no topo, que serão adicionadas ao aplicativo gerador de &PostScript;. Os &PPD;s não foram originalmente rotinados em sistemas &UNIX; e &Linux;. Os vendedores nunca fornecem estes &PPD;s disponibilizando-os para qualquer outro &OS; diferente dos originalmente suportados: &Microsoft; &Windows; e &MacOS;. Como existe um brilhante movimento para o suporte completo e utilização da especificação &PPD; existente, o ∪︀ agora fornece o poder de usar todos os recursos das impressoras modernas aos usuários de sistemas &Linux; e estilo &Linux;. O &tdeprint; torna este uso ainda mais confortável do que os desenvolvedores do ∪︀ jamais sonharam. O ∪︀ pode usar &PPD;s originais do &Windows;, distribuídos pelos vendedores no caso de impressoras &PostScript;. Eles normalmente são grátis, e podem ser obtidos de qualquer computador &Windows; com um driver &PostScript; instalado para o respectivo modelo, ou dos discos fornecidos com a impressora. Existem também diversos lugares na web para baixá-los. Agora você sabe como Impressoras-&PostScript; podem usar &PPD;s. Mas e as impressoras não-&PostScript;? O ∪︀ tem um truque muito bom: usando o mesmo formato e estrutura de dados das Descrições de Impressoras &PostScript; (&PPD;s) do mundo &PostScript;, ele pode também descrever opções de trabalho de impressão disponíveis para impressoras não-&PostScript;, Para este propósito especial, o ∪︀ apenas adicionou algumas poucas opções especiais (como a linha que define o filtro a ser usado para posterior processamento do arquivo &PostScript;). Logo, os desenvolvedores podem usar o mesmo motor de software para procurar nos Arquivos de Descrição de Impressora por opções disponíveis para todo tipo de impressora. É claro que os desenvolvedores do ∪︀ não podem esperar que os fabricantes de hardware não-&PostScript; de repente desenvolvam &PPD;s. Eles tem a dificuldade de iniciar, eles mesmos, e escrevê-los a partir do zero. Mais de 1000 destes arquivos estão disponíveis na versão comercial do ∪︀, chamada ESP PrintPro. Entretanto existem muitos &PPD;s específicos do ∪︀ disponíveis. Mesmo agora eles não são, na maioria dos casos, originários dos fabricantes de impressora, mas de desenvolvedores de software Livre. O ∪︀ os popularizou, e outros seguirão o caminho: onde o sistema de impressão no &Linux; e &UNIX; um ou dois anos atrás ainda era feito de quebra-galhos, hoje ele é capaz de suportar um grande número de impressoras, incluindo jatos de tinta com 7 cores capazes de impulsioná-lo à saída com Qualidade de Foto. Você pode obter &PPD;s para serem usados com o ∪︀ e impressoras não-&PostScript; de diferentes lugares na Web: primeiro, existe o repositório em www.linuxprinting.org, que permite-lhe gerar um &PPD;-CUPS-O-Matic online para qualquer impressora que seja já suportada pelo pelo tradicional &ghostscript;. Isto lhe auxilia a mudar para o ∪︀, com um mínimo de esforço, se você desejar. Se sua impressora funciona bem com o modo tradicional de impressão do &ghostscript;, use o CUPS-O-Matic para conectar seu driver ao sistema ∪︀ e você terá o melhor dos dois mundos. em segundo, existem &PPD;s do ∪︀ para mais de 120 modelos de impressoras, que são suportados pelo novo driver universal stp. O stp (criado originalmente para a Stylus Photo) é agora desenvolvido pelo projeto de impressão do gimp; ele foi iniciado por Mike Sweet, o primeiro desenvolvedor do ∪︀ e agora está disponível através do gimp-print.sourceforge.net. Este driver imprime com qualidade real de Foto em muitas jatos de tinta modernas e pode ser configurado para criar 120 &PPD;s do ∪︀ durante sua própria compilação. &HP; Laser- e Jato de Tinta, Epson modelos Stylus e Photo Color bem como algumas Canon e Lexmark são suportadas. em terceiro, existe a extensão comercial do ∪︀ a partir dos próprios desenvolvedores do ∪︀: ela é chamada ESP PrintPro e vem com mais de 2.300 drivers de impressora. Existem também melhorias nos filtros imagetoraster e pstoraster incluídas. O ∪︀ torna realmente fácil para os fabricantes iniciarem o suporte a impressão no &Linux; e &UNIX; para seus modelos por um custo razoavelmente baixo. O ambiente de trabalho modular do ∪︀ facilita adicionar qualquer filtro (=driver) com um mínimo de esforço e acessar e utilizar todo o ambiente de trabalho de impressão que o ∪︀ está criando. Leia mais sobre os empolgantes recursos do ∪︀ na documentação do ∪︀ disponível em http://www.cups.org/documentation.html e http://www.danka.de/printpro/faq.html. Também em http://www.linuxprinting.org/ existe um repositório universal para todos os assuntos relacionados com impressão no &Linux; e &UNIX;. Por muito tempo muitos desenvolvedores ficaram profundamente insatisfeitos com o bom e velho LPD. Alguns poucos novos projetos foram iniciados para melhorar a impressão: LPRng é o exemplo mais conhecido. Outros são o PDQ, PPR, PLP, GNUlpr e RLPR. Mas nenhum destes novos programas foram vistos com a grande solução; a maioria deles apenas implementavam a mesma e velha especificação LPD com pequenas (ou muitas) novas extensões, o que tornavam-nos incompatíveis uns com os outros. Vendo o desenvolvimento de não apenas uma, mas diferentes alternativas viáveis ao venerável estilo BSD do LPD, GrandTaylor, autor doComo Fazer Impressão no Linux, finalmente juntou-se ao chamado LPD Deve Morrer! em sua Campanha Para Abolir o Serviço de Impressão Linear. Junto com o acima, no lado industrial das coisas, existiram esforços no sentido de superar a bem conhecida fraqueza do LPD. Isto começou com extensões proprietárias para melhorar o antigo LPD, e prosseguiu até a tentativa da &Hewlett-Packard; de estabelecer o JetDirect &HP; como um novo padrão para protocolo de impressão em rede. O resultado foi cada vez mais incompatibilidades. No final, uma iniciativa definiu um novo padrão industrial e o padrão IETF tomou forma. O Grupo de Trabalho de Impressão ou PWG, uma agregação aberta de vendedores de hardware, software e sistemas operacionais, rascunhou o no Protocolo de Impressão para Internet, &IPP;. O &IPP; v1.1 foi agora aprovado pelo IETF (Força-Tarefa de Engenharia da Internet) como um padrão proposto, e agora conta com o suporte da unanimidade das indústrias na Europa, EUA e Japão. A maioria dos modelos de impressora de rede atuais agora possuem suporte embutido ao &IPP; ao contrário do tradicional LPR/LPD ou Impressão JetDirect. O &IPP; promete resolver muitos dos problemas que os administradores de rede têm. Este trabalho normalmente lida com ambientes de rede heterogêneos e gasta mais da metade de suas horas de trabalho lidando com problemas de impressão. Com a criação de um conjunto unificado de funções de consulta para que o &IPP; possa habilitar impressoras e servidores, transferir arquivos e configurar atributos de controle de trabalho, &etc;, o &IPP; está destinado a trabalhar com qualquer plataforma do SO. Isto no entanto não acontecerá do dia para a noite, uma vez que muitos dispositivos de impressão legados ainda estarão em uso por muitos anos ainda. Contudo, no &IPP; existe uma previsão de criar compatibilidade retroativa de todas as implementações do &IPP;. O ∪︀ está fornecendo a possibilidade de impressão &IPP; em todos os ambientes. A vantagem mais determinante será sua integração com o conjunto existente de outros robustos protocolos IP. Sendo uma extensão do comprovado e robusto protocolo HTTP 1.1, para a tarefa especial de manipular um arquivo de impressão e dados relacionados, é também muito fácil conectá-lo a outros padrões conforme eles se desenvolvam e se disseminem: Autenticação Básica, Sumária e Certificada para usuários que busquem o acesso à serviços de impressão. Criptografia SSL3 e TLS para transferência de dados. Comunicação bi-direcional dos clientes com os dispositivos de impressão, usando o mecanismo HTTP/&IPP; GET e POST Integração com o serviço de diretório LDAP para manter um banco de dados consistente das impressoras disponíveis, suas capacidades e custos de página, &etc;, bem como senhas de usuário, ACLs, &etc;. Impressão Puxada (ao contrário do usual modelo Empurrada), onde um servidor ou impressora apenas precisa dizer a &URL; de um documento, de onde ele é obtido a partir de um recurso na internet, e imprimir. Você já viu uma demonstração das possibilidades do ∪︀ numa rede? Você deve ter ficado bem impressionado se você não sabia exatamente o que esperar. Imagine você como administrador de uma LAN. Para fins de teste você instalou uma distribuição &kde;/∪︀ numa máquina da sua rede, completando com uma dúzia de impressoras configuradas e funcionais: &PostScript;, Laser, Jatos de Tinta, Bolhas de Tinta, e outras. Seus usuários do &kde; desta distribuição estão muito contentes, pois eles podem imprimir como nunca antes, tocando todos os sinos e assobios de cada impressora. Você gastou 2 horas para fazer tudo funcionar perfeitamente... e agora todos os outros 100 usuários da rede querem o mesmo. Duas horas novamente para cada máquina? Impossível fazer isto antes do próximo ano, você pensa? Errado. Apenas mude uma configuração na máquina onde o ∪︀ foi originalmente instalado para torná-la um servidor. Instale o ∪︀ em cinco outras máquinas, como clientes. Ao retornar ao seu primeiro cliente, você encontra usuários alegremente brincando com as configurações para as doze impressoras que você tinha definido anteriormente no servidor. De algum modo magicamente as impressoras apareceram nos diálogos Imprimir das cinco novas máquinas clientes do ∪︀. Seus usuários imprimem, mas nenhum driver foi instalado nos clientes, nenhuma fila de impressão definida. Ora, como esta mágica funciona? A resposta para isso não é nem um pouco complicada. Se um servidor ∪︀ estiver na LAN, ele procura pelos nomes de todas as impressoras disponíveis na LAN, usando o protocolo UDP e porta 631. A porta 631 é reservada como uma porta conhecida pela IANA (a Autoridade para Atribuição de Números na Internet) para utilização pelo &IPP;. Todos os clientes ∪︀ ouvem as informações do servidor ∪︀ enviadas para sua porta 631. Deste modo eles tomam conhecimento das impressoras disponíveis, e deste modo eles obtém o caminho para as impressoras também. Usando o &IPP;, que é realmente uma inteligente extensão do HTTP v1.1, o ∪︀ é capaz de endereçar todos os objetos relacionados ao sistema de impressão através de Localizadores de Recurso Universal ou URLs. Trabalhos de impressão são excluídos ou reiniciados, impressoras são consultadas ou modificadas, tarefas de administração são realizadas no servidor, com o &IPP; e o ∪︀, tudo é endereçável através de determinadas URL. Muitas coisas importantes podem ser feitas através da interface web do ∪︀, acessível por exemplo com o &konqueror;. E mais, os clientes basicamente podem administrar e usar qualquer impressora que verem, da mesma maneira que fariam com elas instaladas localmente. É claro, você pode configurar restrições através de listas de controle de acesso, &etc;, de modo que nem todo cliente possa usar toda impressora como desejar. Os clientes podem até mesmo ser capazes de imprimir sem o filtro (ou driver) apropriado instalado localmente. Como isto funciona? Se um cliente deseja saber como e selecionar opções específicas da impressora, ele envia uma solicitação (chamada CUPS-get-ppd) ao servidor. O servidor passa para o cliente tudo sobre todas as opções específicas da impressora, conforme lido no &PPD; existente no lado servidor. O usuário no lado cliente pode ver as opções e selecionar as que desejar. Ele então envia o arquivo a ser impresso, normalmente um raw &PostScript; sem filtragem, juntamente com as opções de impressão para o servidor de impressão, usando o &IPP; como protocolo de transporte. Todo processamento posterior, especialmente a filtragem para gerar o formato final para a impressora destino, é então feito pelo servidor. O servidor deve ter os programas necessários (drivers ou filtros) para fazer isto. Deste modo um cliente imprime sem precisar instalar um driver localmente. Qualquer mudança no servidor, como a adição ou modificação de uma impressora, é instantaneamente conhecida pelos clientes sem nenhuma configuração posterior necessária. Alguns outros recursos avançados existentes no ∪︀ são capazes de fazer o balanceamento da carga. Se você definir a mesma fila de impressão em dois ou mais servidores diferentes, os clientes enviarão seus trabalhos para o primeiro que responder ou servidor disponível. Isto implica num balanceamento automático da carga nos servidores. Se você tiver que desligar um servidor da rede para manutenção os outros receberão suas tarefas sem que os usuários percebam alguma diferença.