Problema com o mapa /ToUnicode apenas no macOS Preview

Acredito que agora entendi o problema e estou razoavelmente confiante de que isso é um erro no Apple Preview.

Explicar isso é, infelizmente, complicado.....

O arquivo PDF usa uma fonte incorporada, subconjunto. Como é comum, a fonte contém apenas os glifos (as descrições reais das formas dos caracteres) usados ​​pelo arquivo PDF. Como também é comum, a "codificação" é tal que o primeiro caractere usado recebe o código de caractere 1, o segundo recebe o código de caractere 2 e assim por diante.

As codificações em PDF são semelhantes às páginas de código no Windows, ou ASCII; elas mapeiam valores numéricos para caracteres específicos.

No caso deste arquivo, a fonte é, na verdade, uma CIDFont, o que complica as coisas, pois esses tipos de codificação podem ter tamanhos variáveis. Novamente, assim como no UTF-8, o número de bytes necessários para um código varia. Felizmente para nós, neste caso, todos os códigos têm dois bytes.

O CMap é a cola que une tudo isso; ele determina quantos bytes de entrada são necessários para mapear caracteres específicos. O CMap recebe códigos de caracteres e retorna CIDs; se você estiver usando um CIDFont, o CID é o "índice" da fonte que encontra um programa de glifo específico. Se a sua fonte for TrueType (como é o caso aqui), o CIDToGIDMap converte CIDs em GIDs (porque é isso que as fontes TrueType usam). Novamente, felizmente para nós, o CIDToGIDMap é /Identity. Simples e prático.

Agora a parte importante do CMap se parece com isso:

1 begincodespacerange
<0000> <FFFF>
endcodespacerange
2 begincidrange
<0001><000C> 1
<000E><001D> 13
endcidrange

Isso significa que o espaço de código (valores válidos) vai de 0 a 0xFFFF, dentro do qual o CMap define dois intervalos de números. O primeiro intervalo é de 0x01 a 0x0C e mapeia para o CID 1 (portanto, 0x01 = 1, 0x02 = 2 e assim por diante). O segundo intervalo é de 0x0E a 0x1D e estes mapeiam para CIDs a partir de 13.

Até aqui, tudo bem. Mas como isso nos leva a copiar e colar? Bem, a resposta é que não. Existe uma tabela opcional chamada ToUnicode CMap. Ela pode ou não estar presente; se estiver, os usuários de PDF podem descobrir com segurança para qual ponto de código Unicode um determinado código de caractere mapeia. Se não estiver lá, é pura suposição. Em um arquivo como este, com um mapeamento personalizado e uma fonte subset, simplesmente não seria possível determinar os valores Unicode.

Felizmente para nós, existe um ToUnicode CMap:

1 begincodespacerange
<0000> <FFFF>
endcodespacerange
24 beginbfchar
<0001><0048>
<0002><0065>
<0003><006c>
<0004><006f>
<0005><0020>
<0006><0066>
<0007><0072>
<0008><006d>
<0009><0078>
<000A><0061>
<000B><0050>
<000C><0044>
<000E><0046>
<000F><002e>
<0010><0054>
<0015><0076>
<0016><0079>
<0017><0063>
<0018><0070>
<0019><0026>
<001A><0075>
<001B><0077>
<001C><006e>
<001D><0021>
endbfchar
2 beginbfrange
<0011><0012><0068>
<0013><0014><0073>
endbfrange

Basicamente, é o mesmo que o CMap anterior. Você pode ver que o código de caractere 1 mapeia para o ponto de código Unicode U+0048. É um "H" maiúsculo. Como mencionei no início, os códigos de caractere são atribuídos conforme são usados. O primeiro caractere é um "H" e este é atribuído ao código de caractere 1.

Portanto, o "texto" no arquivo PDF é, na verdade, armazenado (como KJ disse) como dados binários. Como o arquivo foi produzido de forma a evitar o uso de caracteres de escape, evitamos o uso de 0x0D, o que significa que o "texto" se parece com:

0001 0002 0003 0003 0004 0005 0006 0007 0004 0008 0005 0001 0002 0009 000A 000B 000C 000E

1 = H, 2 = e, 3 = l, 4 = o, 5 = ' ', 6 = f etc.

Então pegamos os códigos dos caracteres e consultamos o ToUnicode CMap. Isso resulta

U+0048, U+0065, U+006C, U+006C e assim por diante. O importante é que usamos o código de caractere para consultar o CMap ToUnicode.

Então, por que o Apple Preview erra? Bem, ele "parece" aplicar o CMap da fonte ao código de caractere para obter um CID e, em seguida, usar o CID para consultar o CMap ToUnicode. O problema é que os CIDs são executados de forma contígua de 1 a 28, mas os códigos de caractere são executados de 1 a 12 e, em seguida, de 14 a 29.

Isso causa duas falhas: primeiro, o CID 13 não tem entrada no CMap ToUnicode e, segundo, todos os CIDs além de 13 estão 'errados em 1'. O CID 14 recebe o ponto de código Unicode atribuído ao código de caractere 13 e assim por diante.

Modifiquei o exemplo original com falha para que o CMap da fonte mapeie os CIDs corretamente para renderização e modifiquei o CMap ToUnicode para que ele mapeie corretamente quando os CIDs forem usados ​​na consulta em vez de códigos de caracteres. O arquivo está aqui:

https://www.dropbox.com/scl/fi/ua6zzr8hr0hlazaf1f8yl/preview.pdf?rlkey=e6amwr722xjtrn2o9b44p6r7u&st=ifq46ngw&dl=0

Esse arquivo copia/cola corretamente do Apple Preview (bem, funciona no meu antigo MacOS, Big Sur). Ele não copia/cola corretamente de nenhum consumidor de PDF compatível, porque, obviamente, o CMap ToUnicode está configurado para que CIDs sejam usados ​​em vez de códigos de caracteres.

Resumindo: o Apple Preview está realizando a consulta incorretamente. A única maneira de fazer com que o Apple Preview e um consumidor de PDF em conformidade obtenham o resultado correto é que os códigos de caracteres e os CIDs sejam os mesmos, para que o ToUnicode funcione independentemente de um código de caractere ou CID ser usado para realizar a consulta.