Pdf.js: Suporte de formulário interativo (AcroForm)

Este é um metaproblema para rastrear o suporte de formulário interativo (AcroForm) de acordo com o Capítulo 8.6 da referência PDF (https://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/pdf_reference_1-7. pdf # page = 671 & zoom = auto, -246.244).

Pode ser uma boa ideia basear o trabalho na versão mais recente da especificação do PDF, caso haja alguma diferença: http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/ pdfs / PDF32000_2008.pdf # G11.2110737.

Além disso, talvez seja uma boa ideia adicionar um item TODO "Geral" sobre como garantir a cobertura de teste adequada?

Ambos os itens foram tratados. Obrigado!

Acho que também teremos que analisar o conteúdo do dicionário AcroForm , caso contrário, não poderemos, por exemplo, carregar todos os recursos de fonte necessários.
Obviamente, não podemos usar fontes personalizadas na camada de exibição, mas devemos ser capazes de pelo menos inferir a família de fontes correta (e coisas como negrito / itálico) que deve ser usada e passar essa informação para a camada de exibição.

Além disso, para imprimir formulários, podemos ser capazes de utilizar (ou construir sobre) a funcionalidade appendToOperatorList já existente, mas isso definitivamente exigirá que os recursos de fonte presentes no dicionário AcroForm tenham sido carregados.

Outra coisa que provavelmente devemos tentar oferecer suporte é o uso da cor correta do texto na camada de exibição (observe como no Adobe Reader o texto nos campos de formulário de f1040.pdf é azul). Isso provavelmente está relacionado a um suporte de stream Appearance melhor e mais completo.

Finalmente, uma pergunta geral: Seremos realmente capazes de oferecer suporte a formulários de uma forma significativa, sem suporte de script parcial (e bem higienizado)?

Bons pontos. Acabei de adicioná-los à lista de itens acima. Não acho que realmente precisamos de suporte de script, pois os AcroForms geralmente requerem apenas preenchimento e impressão. Os scripts AFAIK são usados ​​apenas para interação entre elementos, mas podemos implementar a funcionalidade mais usada por nós mesmos (como redefinir o formulário ou ações de botão para imprimi-lo). Teremos que ver como essa funcionalidade de script é amplamente usada.

Manipular sinalizadores: multilinha e somente leitura

Existem outros sinalizadores que podemos precisar tentar e suportar também, um exemplo é comb que controla o espaçamento entre os caracteres em um campo de entrada. Esse é realmente usado na segunda página de f1040.pdf , consulte o campo "Número de identificação pessoal (PIN)".

Parece uma boa ideia. Eu o adicionei à lista.

Provavelmente também seria uma boa ideia ver se o código WidgetAnnotation que cria a propriedade fullName pode ser limpo ou melhorado, consulte https://github.com/mozilla/pdf.js /blob/6c263c19946af23b723f148d9f05118971e18b36/src/core/annotation.js#L640 -L670.

Além disso, em relação a WidgetAnnotation s, parece que diferentes tipos podem ter diferentes requisitos para a entrada V no dicionário de anotações, então pode ser melhor buscar e validar data.fieldValue em _cada_ subclasse WidgetAnnotation .

O primeiro ponto está agora na lista, para a qual tenho algumas ideias. Eu descobri sobre o segundo ponto em um patch que estou finalizando para anotações de widget de escolha, então isso será abordado lá.

Ei @timvandermeij
Quando essa funcionalidade estará disponível? Como posso ajudar?

No momento, estamos no processo de implementação, mas é uma grande funcionalidade que levará algum tempo antes de ser concluída. As caixas marcadas acima mostram quais elementos já estão implementados e para outras caixas já existem solicitações pull de trabalho em andamento, portanto, estamos no caminho certo com essa funcionalidade. Sinta-se à vontade para testá-lo usando o branch master e definindo o parâmetro renderInteractiveForms como true . Ele está desabilitado por padrão porque ainda não está pronto.

Obrigado tim, o que você pode me dizer sobre assinaturas digitais? Há progresso de acordo com este tópico de discussão https://github.com/mozilla/pdf.js/issues/1076

Isso foi relatado pelo usuário: soa-x abriu este problema em 13 de janeiro de 2012

Quase 5 anos se passaram desde que foi relatado.

Até mesmo alguém já fez grande parte da implementação

viveksjain comentou em 22 de fevereiro
@complience Olá, tenho uma prova de conceito funcionando em https://github.com/viveksjain/pdf.js/tree/sig-verify-support. Você pode tentar usando git clone --recursive https://github.com/viveksjain/pdf.js.git. Com um pouco mais de trabalho, ele deve estar pronto para uma solicitação de pull no esta repo, mas ainda não tive tempo.

Você sabe se esses trabalhos foram adicionados às versões recentes do pdf.js?

Re: https://github.com/mozilla/pdf.js/issues/7613#issuecomment -251692825

Assinaturas em arquivos PDF é um tópico grande e complexo, um tanto ortogonal à implementação do suporte básico do AcroForm (que é o que _este_ problema em particular está rastreando).

O problema atual é apenas um problema de rastreamento para implementação de recursos básicos do AcroForm, as assinaturas já são rastreadas em outro lugar (em # 1076, que é onde esse recurso deve ser discutido).

@lexcorp Evite postar informações não relacionadas e / ou fazer perguntas aqui, pois isso prejudica o propósito deste problema (que é rastrear o suporte para recursos básicos do AcroForm).
Além disso, agora você postou basicamente as mesmas informações em _três_ problemas diferentes, não envie spam para o rastreador de problemas desta forma!

Olá @timvandermeij @Snuffleupagus ,
Nós realmente gostamos da sua solução para adicionar suporte para campos AcroForm. Estamos planejando usar esses recursos em um aplicativo que estamos desenvolvendo atualmente. Agradeceríamos muito se você pudesse nos fornecer uma data provisória em que pudesse adicionar suporte para todos os tipos de campos de formulário, como caixas de seleção, etc. e exportar os dados preenchidos para um arquivo XFDF ou qualquer outro formato. Obrigado.

@anujgeek Como já mencionei em https://github.com/mozilla/pdf.js/issues/7613#issuecomment -251699579, este é um problema de _tracking_ e não é realmente um bom lugar para este tipo de discussão geral e / ou fazendo perguntas!

Há uma série de TODOs bastante difíceis de implementar, veja a lista possivelmente incompleta acima, portanto, _não_ é possível dar qualquer tipo de estimativa de quando, ou mesmo se, esse recurso será completamente implementado.

Além disso, observe que até agora todo o trabalho foi feito por colaboradores e, considerando que o Mozilla está substituindo o PDF.js no Firefox (consulte https://wiki.mozilla.org/Mortar_Project), o suporte a formulários provavelmente demorará um pouco para ser concluído.

Este é um problema de rastreamento (consulte https://github.com/mozilla/pdf.js/issues/7613#issuecomment-251895091), portanto, este não é o lugar para discussão ou perguntas. Contate-nos no IRC em caso de dúvidas ou registre um problema separado se você encontrou um bug. Obrigado.

_ (Estou desbloqueando a conversa para permitir que os usuários usem o botão de reação para medir o interesse por esse recurso, mas os comentários irrelevantes serão removidos.) _

Olá juntos!

Qual é o progresso com o preenchimento do AcroForm?
O exemplo usado https://www.irs.gov/pub/irs-pdf/f1040.pdf (e outros) ainda não funciona. Ou não está configurado por padrão?
Algum JavaScript básico, como definir campo (s), limpar campo (s), enviar suporte ao botão mencionado?

Obrigado.

@ Alex-DE-74 Leia os comentários acima com atenção, em particular https://github.com/mozilla/pdf.js/issues/7613#issuecomment -251895091 e https://github.com/mozilla/pdf. js / issues / 7613 # issuecomment -287907674 são relevantes.
Além disso, você já fez essas perguntas em # 9261 (onde as respostas foram fornecidas); por favor, vamos tentar manter este problema de rastreamento livre desse tipo de discussão geral.

@Snuffleupagus

Com licença, mas para mim não é realmente rastreável através de muitos tópicos, qual item tem qual estágio. E as referências cíclicas não são úteis em nada. Do ponto de https://github.com/mozilla/pdf.js/projects/1 é claro para mim, que parte de AcroForms é suportada agora (completamente) e o que está no plano. Além disso, muitos tópicos tratam de renering / visualização, mas nenhuma palavra sobre recurso interativo preencher / verificar / selecionar / enviar etc. Assim, por exemplo, a parte "Widgets de texto" acima não tem nada sobre "Digitação de texto". Então, se o "Dicionário do AcroForm" não for analisado, como pode funcionar realmente bem?
Talvez seja útil para os "usuários" ver uma tabela simples onde o AcroForm apresenta suas propriedades e um estado de suporte completo / particular / planejado listado. (por que mostrou negrito = ?!)

PS É uma pena para mim, não sou especialista em JS / HTML5, mas fiz muitas coisas no outro site (criando PDF com C #) e estou familiarizado com outras linguagens de programação também. Vale a pena tentar entender o código atual para fornecer um suporte mais interativo e ajudar no desenvolvimento deste projeto? Ou isso vai levar muito tempo apenas para entender a arquitetura atual?

Eu removi o estilo ousado para você. Gostaria de enfatizar novamente que este não é o lugar para tal discussão; um canal como o IRC seria mais apropriado para que possamos dar algumas informações básicas. O preenchimento / envio / impressão de formulários está na lista de opções acima, mas ainda não foi implementado. A parte dos "widgets de texto" trata da renderização de widgets de texto, o que significa os campos de entrada que você pode digitar. Isso é feito; a parte que resta está armazenando os valores inseridos. Qualquer pessoa é bem-vinda para ajudar na implementação disso.

BTW: o Chrome também não é capaz de salvar PDFs com formulários, mas há uma solução alternativa. Os formulários são renderizados por padrão e é possível imprimi-los e até mesmo imprimi-los como PDF por padrão, incluindo a entrada do formulário.

Talvez isso seja aplicável para pdf.js também e podemos apenas utilizar o FF existente salvo como PDF (https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/tabs/saveAsPDF)?

Estou brincando com o pdf.js tentando imprimir os valores dos campos de texto do formulário inseridos. Eu tenho uma prova de conceito de trabalho rudimentar onde posso renderizar valores inseridos para o PDF de impressão. Agora quero discutir minha abordagem e ver se alguém surge com uma melhor ou mais simples.

Em minha abordagem, passo os valores inseridos para a tarefa do trabalhador adicionando um mapa à tarefa. Este mapa está atualmente preenchido no evento 'beforeprint'.
No mehtod 'getOperatorList' de 'TextWidgetAnnotation', li o fluxo do objeto e substituo o valor de texto antigo do operador 'Tj' pelo novo. Isso funciona, mas tem muitos problemas surgindo. O primeiro é, que falha, se o fluxo não tiver nenhum operador 'Tj' porque o campo não tinha valor. O segundo é que o posicionamento dos alinhamentos diferentes de 'esquerdo' estará errado.
Portanto, a próxima ideia é criar um fluxo completamente novo calculando todos os valores sozinho. Isso vai dar muito trabalho, então eu queria discutir essa abordagem primeiro.
Já posso criar um novo fluxo e exibir os valores, mas, novamente, há o problema com os valores de deslocamento da operação 'Td'. Pesquisei um pouco no código e acho que preciso calcular o deslocamento das posições X e Y levando em consideração a largura e a altura da String com a fonte fornecida. Encontrei o FontDescriptor para uma fonte incorporada, mas não para uma fonte do sistema. Com o descritor de fonte, tenho o valor de subida e descida da fonte, com o qual acho que posso calcular o deslocamento y O deslocamento x será fixo para textos alinhados à esquerda, mas precisa ser calculado para textos centralizados ou alinhados à direita . Acho que posso fazer isso com a matriz de larguras do Font xRef, mas, novamente, não existe tal para fontes do sistema. Portanto, acho que teria que usar uma tela e o método measureText.

Então, como você vê, há muito 'pensamento'. Mas antes de tentar implementar e testar minha abordagem, gostaria de saber o que os outros estão pensando a respeito.

Algum tempo atrás, discutimos como poderíamos abordar isso. Consulte https://mozilla.logbot.info/pdfjs/20161219. A ideia é ter duas listas de operadores diferentes: uma para a IU e outra para impressão. No de impressão, substituiríamos as operações com base no valor inserido / selecionado no widget.

Acho que isso é um pouco mais fácil do que o que você está descrevendo, pois deixamos que a lógica restante faça o trabalho pesado por nós; nós apenas temos que fornecer a lista de operadores correta.

Este é um problema que temos que resolver em várias etapas pequenas. A primeira etapa é tornar o código de anotação assíncrono, o que é feito por @dmitryskey em # 9822. A próxima etapa seria analisar o dicionário AcroForm para, por exemplo, fontes e analisar a entrada de aparência padrão no dicionário de anotações para todas as informações de aparência. Para isso, provavelmente podemos usar o avaliador para obter as informações como uma lista de operadores, que exigia que o código de anotação fosse assíncrono. Em seguida, podemos criar as listas de operadores de impressão para cada tipo de anotação.

Também pensei em criar a lista de operações sozinho, mas isso seria mais complicado para mim do que minha abordagem. Acabei de criar o fluxo do objeto pdf com 'BMC ... EMC' e passar o fluxo para o avaliador, que gera a lista de operações.
Se eu mesmo criar o array da lista de operações, terei os mesmos problemas que ao gerar um novo fluxo de objetos. Mas imho é mais complicado criar a lista de op do que criar uma string e convertê-la em um objectstream. Isso já funciona na minha prova de conceito.

Achei que o Opera / Chrome também usasse pdf.js, mas o Opera é capaz de imprimir e usar dados de formulário. Talvez haja algo. podemos reutilizar?

Eles usam PDFium, que é principalmente código C ++.

Olá a todos, a empresa para a qual trabalho está começando a aproveitar o PDFJS e me disseram que preciso fazer o "Armazenamento de valores inseridos para quando a página for destruída quando não estiver visível" funcionando. Não tenho certeza se este tópico é o lugar certo para discuti-lo. @timvandermeij , parece que você é o principal impulsionador deste projeto. Há alguma maneira de entrarmos em contato com você ou alguém da comunidade que possa ajudar. Tenho uma estratégia para implementar esse recurso, mas quero ter certeza de que o que faço também pode ser incorporado de volta a este repositório. Também estamos dispostos a patrocinar ou criar alguma recompensa de recursos, se isso ajudar a tornar as coisas mais rápidas.

Se você tiver ideias sobre como isso deve ser feito, é melhor abrir uma edição separada para discuti-la. A principal questão é o que fazer com os dados inseridos. Renderizar na tela ao imprimir? Fornece uma opção para baixar os valores no formato FDF? Renderizar um novo arquivo PDF com os valores preenchidos? Et cetera. Depende do que o usuário espera e do que outros leitores de PDF fazem.

O fechamento porque o suporte para AcroForm está concluído e ativado. As edições restantes agora são arquivadas em edições individuais e coletadas com a tag 4-form-acroform ; consulte https://github.com/mozilla/pdf.js/labels/4-form-acroform.