Esta página contém os detalhes de um projeto de escrita técnica aceito para a temporada de documentos do Google.
Resumo do projeto
- Organização de código aberto:
- Linux Foundation
- Redator técnico:
- PIYUSHgoyal16
- Nome do projeto:
- Tutorial e diretrizes de design para drivers de impressora/leitor em aplicativos de impressora
- Duração do projeto:
- Duração padrão (3 meses)
Project description
Informações gerais
Os drivers de impressora clássicos que consistem em filtros específicos da impressora e arquivos PPD (Descrição da Impressora Postscript, descrevem os recursos da impressora e quais filtros devem ser chamados) que devem ser colocados em determinados diretórios do sistema de arquivos são substituídos pelos chamados Aplicativos de Impressora, emulação de uma impressora em rede IPP.
A maioria das impressoras de uso geral modernas são de IPP, que permitem impressão sem driver. Eles se anunciam via DNS-SD, os clientes podem consultar as informações de capacidade deles por meio de solicitações de IPP e usam formatos de dados padrão para trabalhos de impressão. Impressoras que não oferecem essa funcionalidade, geralmente impressoras legadas ou especializadas precisam de um driver.
Um aplicativo de impressora é um daemon que detecta as impressoras compatíveis e as divulga no localhost como uma impressora IPP Everywhere. Printer Applications contém o software para imprimir trabalhos recebidos nas impressoras compatíveis, convertendo os dados para o idioma nativo da impressora, e fornece informações sobre os recursos da impressora aos clientes, mediante solicitação. O Aplicativo de Impressora tem até uma interface de administração da Web, como uma impressora em rede real.
Como sabemos, o Linux está migrando para pacotes em sandbox (como o Snap, por exemplo) e a impressão também está indo nessa direção. Em um pacote em sandbox, não é possível modificar o conteúdo do diretório depois que ele é criado. Nosso sistema não é mais modular. Não podemos escolher qual pacote de drivers de impressora instalar. Os aplicativos de impressora resolvem esse problema de modularidade e oferecem a mesma liberdade dos drivers de impressora.
Os drivers de impressora e scanner no Snaps não são apenas um requisito para um CUPS alinhado e um aplicativo ajustado, mas também funcionam em sistemas completamente clássicos. Em contraste com os drivers de pacotes clássicos, eles são independentes de distribuição de SO. Você cria um driver de impressora como o Snap e ele funciona em todas as distribuições de SO que executam o Snap, sem precisar empacotar drivers de impressora para cada distribuição (e versão) de forma independente e gerar um grande número de dependências. A outra vantagem é que o conceito antigo de arquivos PPD provenientes de impressoras PostScript é descontinuado. Além disso, ao acoplar o sistema CUPS e o driver da impressora por uma conexão IP, em vez de descartar arquivos no sistema CUPS, tanto o sistema CUPS quanto o aplicativo de impressora podem estar em pacotes separados no sandbox.
Minha tarefa será descrever como projetar os drivers para impressoras e scanners para essa forma de embalagem e como empacotá-los no Snaps. A intenção é ajudar qualquer pessoa que escreva drivers de impressora ou scanner, especialmente os fabricantes de hardware, no futuro a fazer isso da maneira correta.
O fluxo de trabalho do Aplicativo de Impressora pode ser resumido com o fluxograma fornecido:
A base para a criação de aplicativos de impressora/leitor é a PAPPL, uma biblioteca que oferece mais funcionalidades para isso, além de "cups-filters" que contém o código a ser usado para aplicativos de impressora. O conceito ainda está em desenvolvimento, principalmente no Google Summer of Code deste ano. Porém, no dia 14 de setembro, quando começa o período de escrita da documentação, o período de codificação da GSoC já terminou, e é nesse momento que o OpenPrinting precisa do tutorial.
Modelo para drivers de impressora Definir a estrutura dos dados do JOB
Declarar matriz de constantes para tamanhos de mídia
Declarar funções i) Callback ou init. Uma função booleana que aceita o nome e os dados do driver etc., e define os atributos do driver de forma correspondente. Se os detalhes fornecidos forem adequados, ele retorna verdadeiro e falso em caso de falha.
ii) imprimir a função booleana que aceita o trabalho, as opções para o trabalho e o dispositivo. Ela imprime um arquivo e retorna verdadeiro em caso de sucesso e falso em caso de falha.
iii) Função rendjob que aceita o trabalho, opções para a tarefa e o dispositivo. Ela encerra o job e retorna verdadeiro em caso de sucesso e falso em caso de falha.
iv) Função rendpage que aceita o job, opções para o job, dispositivo e número da página. Ela encerra a página e retorna verdadeiro em caso de sucesso e falso em caso de falha.
v) rstartjob Função booleana que aceita o job, opções para o job e o dispositivo. Ela inicia o job e retorna verdadeiro em caso de sucesso e falso em caso de falha.
vi) Função rstartpage que aceita o job, opções para o job, dispositivo e número da página. Ela inicia a página e retorna verdadeiro em caso de sucesso e falso em caso de falha.
vii) reescrever função booleana que aceita job, opções para o job, dispositivo, número de linha e matriz de caracteres. Ele escreve a linha e retorna verdadeiro em caso de sucesso e falso em caso de falha. viii) funções opcionais, como "identificar" (ajuda na identificação de impressoras com base na ação fornecida), "compactar" (compactar uma linha de gráficos) etc.