Esta página contém os detalhes de um projeto de redação técnica aceito para a Google Season of Docs.
Resumo do projeto
- Organização de código aberto:
- The Linux Foundation
- Redator técnico:
- PIYUSHgoyal16
- Nome do projeto:
- Tutorial e diretrizes de design para drivers de impressora/scanner em aplicativos de impressora
- Duração do projeto:
- Duração padrão (três meses)
Project description
Visão geral
Os drivers de impressora clássicos, que consistem em filtros específicos da impressora e arquivos PPD (descrição da impressora PostScript, que descreve os recursos da impressora e quais filtros chamar), que precisam ser descartados em determinados diretórios do sistema de arquivos, são substituídos por chamados aplicativos de impressora, a emulação de uma impressora de rede IPP.
A maioria das impressoras modernas de uso geral são impressoras IPP que permitem a 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. As impressoras que não oferecem essa funcionalidade, geralmente as legadas ou especiais, precisam de um driver.
Um aplicativo de impressora é um daemon que detecta as impressoras com suporte e as anuncia no localhost como uma impressora IPP Everywhere. A guia "Printer Applications" contém o software para imprimir trabalhos de entrada nas impressoras compatíveis, convertendo os dados para o idioma nativo da impressora e fornece as 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 de rede real.
Como sabemos, o Linux está migrando para o sandboxing de empacotamento (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 é possível escolher qual pacote de driver de impressora instalar. Os aplicativos de impressora resolvem esse problema de modularidade e nos dão a mesma liberdade que no caso dos drivers de impressora.
Os drivers de impressora e scanner em Snaps não são apenas um requisito para um CUPS e um aplicativo fixados, eles também funcionam em sistemas completamente clássicos, mas, ao contrário dos drivers empacotados de forma clássica, eles não dependem da distribuição do SO. Você cria um driver de impressão do Snap e ele funciona em todas as distribuições de SO que executam o snapd. Não é necessário empacotar drivers de impressão para cada distribuição (e versão delas) de forma independente e enfrentar o inferno de dependências. A outra vantagem é que o conceito antigo de arquivos PPD provenientes de impressoras PostScript foi descontinuado. Além disso, ao acoplar o sistema CUPS e o driver da impressora por uma conexão IP em vez de soltar arquivos no sistema CUPS, o sistema CUPS e o aplicativo da impressora podem estar em pacotes sandbox separados.
Minha tarefa será descrever como projetar os drivers para impressoras e scanners para esse tipo de embalagem e como empacotá-los em Snaps. A intenção é ajudar qualquer pessoa que escreva drivers de impressora ou scanner, especialmente os fabricantes de hardware, a fazer isso da maneira certa.
O fluxo de trabalho do aplicativo de impressora pode ser resumido com o fluxograma abaixo:
A base para a criação desses aplicativos de impressora/scanner é a PAPPL, uma biblioteca que fornece a maioria das funcionalidades para isso, mas também filtros de xícaras 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, mas em 14 de setembro, quando o período de criação de documentação começar, o período de programação do GSoC já terá terminado e é quando o OpenPrinting vai precisar do tutorial.
Modelo para drivers de impressora Definir estrutura para dados de 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 do driver, dados do driver etc. e define os atributos do driver de forma correspondente. Se os detalhes fornecidos forem adequados, ele vai retornar "true" e "false" em caso de falha.
ii) Imprimir a função booleana que aceita job, opções para o trabalho e o dispositivo. Ele imprime um arquivo e retorna "true" em caso de sucesso e "false" em caso de falha.
iii) Função booleana rendjob que aceita o job, opções para o job e o dispositivo. Ela encerra o job e retorna "true" em caso de sucesso e "false" em caso de falha.
iv) rendpage Função booleana que aceita o job, opções para o job, o dispositivo e o número da página. Ele encerra a página e retorna "true" em caso de sucesso e "false" em caso de falha.
v) rstartjob Função booleana que aceita o job, opções para o job e o dispositivo. Ele inicia o job e retorna verdadeiro em caso de sucesso e falso em caso de falha.
vi) rstartpage Função booleana que aceita job, opções para o job, dispositivo e número da página. Ele inicia a página e retorna "true" em caso de sucesso e "false" em caso de falha.
vii) escreva uma função booleana que aceita job, opções para o job, dispositivo, número da linha e matriz de caracteres. Ele grava a linha e retorna "true" em caso de sucesso e "false" 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.