PDFTK, CODE128 e UTF-8

Question

Estou acostumado a preencher formulários PDF do PHP usando o PDFTK. Recentemente, me pediram para inserir um código de barras code-128 em um PDF. Para fazer isso, criei um PDF com vários campos de texto para entradas legíveis por humanos, além de campos de texto especiais cujo texto é renderizado com uma fonte especial que representa símbolos code-128. Esta fonte pode ser encontrada aqui: link . A única diferença entre os campos de leitura humana e de código de barras é a fonte usada para exibir os caracteres.

Até este passo, tudo funciona bem. Com o Adobe Reader, eu sou capaz de copiar e colar um código de barras preparado no meu campo especial, ele renderiza muito bem, este código pode ser verificado por leitores de código de barras. Um exemplo de amostra é Ñ000002HÓ ( Ñ é uma partida, então são meus dados 000002 , a soma de verificação H segue, e o todo termina com a rolha Ó ).

Depois, tenho problemas ao tentar preencher o formulário com o PDFTK. Se eu tentar preencher meu campo especial com Ñ000002HÓ , ele renderizará caracteres somente na tabela ASCII (ou seja, 000002H ) e exibirá alguns tipos de quadrados em vez dos símbolos de código de barras esperados para Ñ e Ó . Mais surpreendente, tentar preencher campos legíveis por humanos com a mesma frase Ñ000002HÓ funciona como um encanto.

Eu verifiquei que ambos os tipos de campos recebem exatamente a mesma sequência de caracteres (incluindo a codificação utf-8), verifiquei se a fonte estava bem incorporada para evitar problemas de exibição, assegurei que o arquivo XFDF está bem formado etc.

Aqui, um exemplo de XFDF usado para preencher um formulário em PDF com campos chamados 'human' e 'barcode'

<?xml version="1.0" encoding="UTF-8"?>
<xfdf xmlns="http://ns.adobe.com/xfdf/" xml:space="preserve">
    <fields>
        <field name="human"><value>Ñ000002HÓ</value></field>
        <field name="barcode"><value>Ñ000002HÓ</value></field>
    </fields>
</xfdf>

Receio não ter mais ideias sobre como resolver este problema. Se você fizer isso, sua ajuda seria muito apreciada.

    

Answer 1

Finalmente, encontrei uma solução. Mais precisamente, uma solução alternativa.

Parece que o PDFTK não manipula os caracteres UTF-8 da maneira correta com as fontes incorporadas Identity-H aplicadas aos campos de formulário. Para renderizar o arquivo PDF da maneira correta, em vez de substituir um campo por um conteúdo, simplesmente defina esse conteúdo como o valor padrão desse campo. Isso fará com que o Acrobat manipule o processo de renderização do campo de formulário em vez de delegá-lo ao PDFTK.

Para isso, simplesmente adicione need_appearances à linha de comando do PDFTK.

OBSERVAÇÃO - O campo de formulário permanece no PDF criado pelo PDFTK, o que significa que seu conteúdo pode ser modificado pelo usuário no Adobe Reader.