O PDF tem um espaço em branco extra em todas as palavras depois de executar o Ghostscript

Question

Este PDF foi produzido por Abbyy Finereader 10:

link

Você pode copiar & cole a primeira frase e obtenha este resultado de texto (muito bom):

Der »Bund Deutscher Gymnastik-Schulleiter« wurde am 20. November 1955 anläßlich einer Zusammenkunft der Leiterinnen und Leiter der privaten deutschen Gymnastik-Ausbildungsstätten gegründet.

Após algum processamento com o Ghostscript 9.02 (Windows de 64 bits), recebo este arquivo:

link

Agora, a primeira frase parece estranha - há um espaço extra antes do último caractere de cada palavra.

Der »Bun d Deutsche r GymnastikSchulleiter « wurd e a m 20 . Novembe r 195 5 anläßlic h eine r Zusammenkunf t der Leiterinne n un d Leite r de r private n deutsche n GymnastikAusbildungsstätte n gegründet .

Isso tem o principal efeito negativo de que você não pode procurar por palavras inteiras no Acrobat Reader. Eu posso reproduzir o efeito com o seguinte conjunto mínimo de parâmetros para o Ghostscript:

-sDEVICE=pdfwrite ^
-dBATCH ^
-dNOPAUSE ^
-sstdout="myStdOut" ^
-sOutputFile="myDestFile.pdf" ^
 mySourceFile.pdf

Alguma idéia?

    

Answer 1

Eu achei este um problema interessante e tive um olhar mais atento ...

Primeiro, usei a ferramenta de linha de comando qpdf para descompactar fluxos de dados PDF para poder ver melhor os códigos-fonte de ambos os arquivos:

qpdf.exe ^
   --qdf ^
     from_abbyy.pdf ^
     qdf--from_abbyy.pdf

qpdf.exe ^
   --qdf ^
     after_ghostscript.pdf ^
     qdf--after_ghostscript.pdf

Olhando para uma das primeiras ocorrências onde um espaço extra é inserido (é a string original "Bund Deutscher Gymnastik-Schulleiter" transformando-se em "Bun d Deutsche GymnastikSchulleiter" ), eu encontro os seguintes trechos em PDF:

Em qdf - from_abbyy.pdf:

( Deutsche) Tj
0 Tc
(r) Tj
1 0 0 1 143.236 265.140 Tm     %% Tm = 'text matrix' operator
3.569 Tw
0.706 Tc
( Gymnastik-Schulleite) Tj

Em qdf - after_ghostscript.pdf:

( Deutsche)Tj
0 Tc
36.235 0 Td                    %% extra Td = 'move text current point' operator
(r)Tj
2.16501 0 Td                   %% Td = 'move text current point' instead of Tm
3.569 Tw
0.706 Tc
( Gymnastik-Schulleite)Tj

Para você ter uma pequena ideia do que os operadores gráficos em PDF usaram aqui, aqui está uma pequena lista:

Tj - show text
Tc - set character spacing
Tm - set text matrix
Tw - set word spacing
Td - move text current point

Como você pode ver, o Ghostscript substituiu o operador original Tm ( matriz textual ) por um Td ( mover ponto atual do texto ), e também adicionou um extra 2.16501 0 Td ... Eu não sei porque isso é. Vou enviar um relatório de bug para o bugzilla do Ghostscript [*] e ver se eles estão interessados em resolvê-lo.

Note, no entanto, que este problema não ocorre, se eu usar o Linux Acrobat Reader 9.4.2 e usar a ação do menu "Arquivo -> Salvar como texto ..." . Nesse caso, não há espaços adicionais (mas algumas quebras de linha extras). No Linux também, o texto não é pesquisável corretamente e também mostra os espaços extras ao fazer copy'n'paste ....

^{[*] Vou atualizar aqui com o número do bug quando o fizer.}

Atualização:

Depois de pensar um pouco mais sobre o operador Tm , agora acho que isso não deveria ser a raiz do problema.

Ao perceber isso, tentei fazer a conversão com o Ghostscript v8.71 em vez de v9.02. E o que devo dizer? O problema do copy'n'paste não ocorre com a saída v8.71!

Isso significa que há um problema no Ghostscript 9.02 que não estava lá em 8.71. O mais provável é que tenha a ver com as métricas de fontes incorporadas no PDF de saída. Porque os fragmentos de PDF acima citados são os mesmos na saída da v8.71 como na saída da v9.02 ....

Atualização 2:

URL da entrada de bug no bugzilla do Ghostscript:

• link

Atualização 3:

Este bug parece ter sido corrigido enquanto isso. Eu não vejo isso acontecer com as versões do Ghostscript que eu testei novamente com ele: o atual Git (v9.10GIT) nem com o Ghostscript v9.06.

    

Answer 2

Se você digitalizar uma página com texto em um PDF e executar um aplicativo de OCR, o texto será adicionado à página, mas o "modo de renderização de texto" será definido como invisível. Está lá, mas não é renderizado na tela (ou no papel, se impresso). O que você vê ou imprime é a imagem digitalizada original.

Como podemos tornar visível o texto invisível?

Bem, podemos editar o PDF ... O código PDF para definir a renderização de texto para invisível é o seguinte:

3 Tr

Você não pode encontrar esta string (ainda) no from_abbyy.pdf original nem em from_ghostscript.pdf porque partes dos PDFs são compactadas. Então nós os descomprimimos o máximo possível com a ajuda de qpdf :

qpdf \
 --qdf \
   from_abbyy.pdf \
   qdf--from_abbyy.pdf

qpdf \
 --qdf \
   after_ghostscript.pdf \
   qdf--after_ghostscript.pdf

Agora podemos encontrar a string acima facilmente (e há apenas uma ocorrência em cada arquivo).

Vamos mudar isso para um dos modos visíveis de renderização de texto. No geral, podemos escolher entre esses 8 modos de renderização de texto:

 0 -  fill glyph shapes
 1 -  stroke glyph shapes
 2 -  fill, then stroke glyph shapes
 3 -  neither fill nor stroke glyph shapes (invisible)
 4 -  fill and add to path for clipping glyph shapes
 5 -  stroke glyph shapes and add to path for clipping
 6 -  fill, then stroke glyph shapes and add path for clipping
 7 -  add glyph shapes to path for clipping

Se eu usar o modo "preenchimento", o texto do OCR provavelmente não ficará tão bom no topo da imagem de digitalização subjacente. Por isso, prefiro a variante "stroke". Então eu simplesmente mudo a linha acima para ler

 1 Tr

Olhando para este PDF modificado, não gostei, porque a largura de linha padrão é muito grossa para o meu gosto. Além disso, a cor do contorno é preta (padrão); Eu preferiria vermelho para ter um contraste com as formas originalmente escaneadas. Portanto, adiciono algum código à frente dessa linha, que define a largura de linha como um quarto de ponto:

 .25 w

e outros para definir a cor do traçado como vermelho:

 1 0 0 RG

A linha completa agora é:

 .25 w 1 0 0 RG 1 Tr

Isso é tudo.

Note que nossa pequena manipulação danificou o arquivo, porque o seu "TOC" (em termos técnicos: its xref table) não será mais válido. O Acrobat Reader ou o Acrobat Professional ainda assim o abrirá (sem reclamar nem mesmo) e silenciosamente "consertará" a seção xref do arquivo. Outros visualizadores de PDF podem rejeitar o arquivo, mas por enquanto não nos importamos ...

Aqui estão as capturas de tela do resultado: (aprimeiracapturadetelaéampliadaparaalarguradajanela) (a segunda imagem é ampliada para 800%.)

Os contornos vermelhos são o texto digitalizado tornado visível agora, exatamente como queríamos.

Eu realizei o mesmo procedimento descrito acima para os arquivos from_abbyy.pdf e after_ghostscript.pdf . Eu abri os dois resultados em duas instâncias diferentes do Acrobat Reader. Se fizermos com que os dois aumentem o zoom para o mesmo valor e maximizem as duas janelas, será fácil alternar a exibição entre os dois arquivos via [alt]+[tab] . Essa é uma boa maneira de revelar até mesmo as melhores diferenças de renderização entre dois arquivos PDF.

Meu resultado é: não há nem um único pixel diferente entre a entrada do Ghostscript (v9.02) e sua saída para este arquivo. Mas há uma grande diferença se você quiser copiar e colar o texto ...

    

Answer 3

Eu não vejo o problema descrito. Eu abri o arquivo PDF 'depois' com o Acrobat Professional 9.0 eo texto é copiado e colado corretamente.

O Ghostscript interpreta totalmente o arquivo PDF e produz um novo arquivo PDF com base no que foi interpretado, não tem relação com o arquivo original além de registrar a posição do texto.

Devido ao rico conjunto de recursos do PDF, é possível posicionar os caracteres no mesmo local usando vários métodos diferentes. Então, não há nada de errado ou inesperado, por si só, no modo como o GS está produzindo o arquivo PDF.

Dado que o texto pode ser salvo corretamente, é uma questão de heurística do Acrobat decidir se dois caracteres "próximos" são adjacentes ou se têm um espaço entre eles, quando tratados como ASCII consecutivos.

Eu não acredito que o problema possa ser a métrica da fonte incorporada pela simples razão de que a fonte não está embutida :-) A fonte usada é Helvetica, que não está embutida no documento, e então o Acrobat (para mim pelo menos) usa ArialMT. Observe que o arquivo PDF "original" também não contém as fontes.

Eu eventualmente irei olhar o bug reportado, mas não será em breve e eu duvido que exista algo que possamos (ou vamos fazer) sobre isso. Parece-me que esta é uma conseqüência inevitável da heurística. Isso pode ajudar a incorporar as fontes, de modo que, pelo menos, elas sejam consistentes.

    

Answer 4

Do relatório de erros do Ghostscript em:

link

Agora consegui reproduzir o problema, e não é uma regressão do 8.71, é uma progressão (e uma mudança na Adobe).

8.71 enviado com um bug que fazia com que ele escrevesse ToUnicode CMaps inválido. A documentação enganosa e contraditória da Adobe fez com que o CMap fosse escrito como um CMap, quando na verdade ToUnicode CMaps tem suas próprias regras incompatíveis.

ToUnicode CMaps são normalmente usados apenas para pesquisa e cópia / colagem. Enquanto o nome implica que eles são usados para mapear códigos de caracteres para pontos de código Unicode. o ToUnicode CMap no arquivo PDF 8.71 não é usado, porque é inválido, o que nas versões posteriores é válido, e o Acrobat é conhecido por usá-lo.

Parece que no Acrobat Reader até e inclusive 9.2 a existência do Dados ToUnicode não fazem diferença. Em algum momento após 9.2 a busca mecanismo, alterado, e o Acrobat parece usar dois mecanismos diferentes dependendo se um ToUnicode CMap está presente. Eu não tenho acesso a Acrobat Pro após 9.2 e só recentemente instalou o Reader X, não tenho nada entre.

O método 'sem Unicode' funciona em todas as versões do Acrobat, o método 'Unicode' falha nas versões mais recentes.

Mostrei isso pelo espaçamento em branco da referência ao ToUnicode CMap do FontDescriptor. Se necessário, posso disponibilizar os vários arquivos, mas eles são grandes como são descompactados.

Como a busca é um esforço heurístico em PDF, não será possível garantir um resultado. A mudança no comportamento deve-se ao Acrobat, não ao Ghostscript, e a mudança no Ghostscript foi para corrigir um bug real, então uma progressão, não uma regressão.

    

Answer 5

Para verificar se esse problema está conectado ao 'embedded-ness' da fonte ou não, fiz outra conversão no Linux. Eu usei esta linha de comando para que o Ghostscript incorpore as fontes usadas:

gs \
 -o after_ghostscriptonlinux.pdf \
 -sDEVICE=pdfwrite \
 -dPDFSETTINGS=/prepress \
 -sEmbedAllFonts=true \
  from_abbyy.pdf

Ghostscript mostrará esta saída:

GPL Ghostscript SVN PRE-RELEASE 9.02 (2011-02-07)
Copyright (C) 2010 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Processing pages 1 through 1.
Page 1
Loading NimbusSanL-Regu font from %rom%Resource/Font/NimbusSanL-Regu... 2776276 1420923 2081124 778943 3 done.
Loading NimbusSanL-ReguItal font from %rom%Resource/Font/NimbusSanL-ReguItal... 2853416 1529123 2137980 831640 3 done.
Loading NimbusSanL-Bold font from %rom%Resource/Font/NimbusSanL-Bold... 2970748 1643508 2194836 886454 3 done.

O Ghostscript incorporou fontes de uma família de fontes chamada NimbusSanL . Portanto, não mais ArialMT , como foi usado para renderização na tela pelo Acrobat Reader como um substituto para a Helvetica ausente (veja também comentários de user701996 acima). Observe que o Ghostscript irá renomear essa fonte para Helvetica assim que ela for incorporada. Mas isso não é um problema, porque o NimbusSanL foi criado como um clone da Helvetica ...

No entanto, mesmo para este PDF de saída, o copy'n'paste do Acrobat Reader não funcionará bem. Apesar do fato de que o Reader não precisa mais usar o ArialMT para substituir a Helvetica. O Reader agora usa o clone NimbusSanL / Helvetica que é incorporado.

Até agora, estabelecemos esses fatos sobre como copiar e excluir texto do Acrobat Reader ou do Acrobat Professional:

• A saída do Ghostscript v9.02 não funciona bem o suficiente para esse arquivo.
• Esse é o caso se a fonte é incorporada pelo GS ou se não é.

• Esse é o caso do GS no Windows XP e do GS no Linux.

• A saída do Ghostscript v8.71 FUNCIONA bem o suficiente para este arquivo.

• Esse é o caso se a fonte é incorporada pelo GS ou se não é.

• Esse é o caso do GS no Windows XP e do GS no Linux.

• Mesmo para a saída em que o copiar'n'paste está quebrado, Salvar como texto ... faz.

Eu ainda não entendo porque isso deveria ser o caso. Mas parece claramente como uma espécie de (talvez menor) regressão do Ghostscript em seu caminho de v8.71 para 9.02.

Agora, vamos testar outro software de visualização de PDF com os PDFs "críticos":

• O Adobe Reader X dentro do Wine no Linux: o copy'n'paste é o b0rken da mesma forma que o v9.4.4.
• Evince v2.32.2 no Linux: funciona o copy'n'paste.
• PDFXChange Viewer 2.5 (compilação 191) no Windows XP Prof: copiar e colar funciona.
• MuPDF reader 0.8 no Linux: não sei como copiar e colar - mas a 'pesquisa' funciona perfeitamente.
• Encontrado s.th. chamado "PDF Viewer 0.1.7" no Linux: copie e cole trabalhos.
• SumatraPDF v1.5 dentro do Wine no Linux: funciona o copy'n'paste.
• SumatraPDF v1.5.1 no Windows XP: funciona o copy'n'paste.
• FoxitReader 4.3.1.0113 no Windows XP: funciona o copy'n'paste.
• Nitro PDF Reader dentro do Wine no Linux: funciona o copy'n'paste.

Note que ainda existem outras diferenças, mas muito pequenas, entre todos os leitores de PDF "em funcionamento", onde o meu veredicto foi copy'n'paste works . Tal como um traço faltando aqui, ou alguns espaços entre as palavras lá, e outras coisas assim ... Eu não tenho nenhuma explicação atualmente porque isso pode ser, mas provavelmente é a mesma causa porque há uma grande lacuna entre os produtos Adobe (que não tem copy'n'spaste de trabalho para este arquivo) um o one had e "o resto do mundo" do outro.