Estou com um problema estranho com um PDF e o /ToUnicodeCMap contido nele, que afeta apenas o macOS Preview. Todos os outros visualizadores testados funcionam bem. O problema é que não sei se o /ToUnicodeproblema é o CMap contido ou o Preview.
Aqui está o PDF em questão: https://github.com/user-attachments/files/19538203/example.pdf e o problema do Github onde esse problema apareceu.
Se o PDF for aberto no macOS Preview e o texto for selecionado e copiado, tudo após "Olá do HexaPD" estará errado. Outros visualizadores copiam o texto inteiro sem problemas.
Situação atual (editado):
HexaPDF, a biblioteca que gera o PDF, está usando uma otimização que evita a criação de códigos de caracteres contendo os caracteres ASCII
\r,(e).\O motivo é que eles precisariam ser escapados ao serializar como string literal de PDF.Se essa otimização estiver desativada, o arquivo resultante (consulte https://github.com/user-attachments/files/19575820/example.pdf ) funcionará perfeitamente no macOS Preview (ou seja, copiar e colar funciona).
Remover o
/ToUnicodeCMap completamente resulta em texto não copiável. Isso significa que o macOS Preview está de fato usando este CMap e que ele é o provável culpado.Adicionar uma entrada fictícia
<0000><0000>não funciona.Adicionar uma entrada fictícia como
<000D><0044>no/ToUnicodeCMap não funciona.Começar os códigos de caracteres não em 1, mas em 14, faz com que os primeiros 13 caracteres sejam inválidos, ou seja, piora a situação.
Depois de ler as partes respectivas da especificação do PDF e a "Especificação dos arquivos 5014 Adobe CMap e CIDFont", acredito que o
/ToUnicodeCMap em ambos os arquivos vinculados acima está correto.
Qualquer informação sobre se o /ToUnicodeCMap gerado é inválido ou se é culpa do macOS Preview é bem-vinda!