Il PDF ha uno spazio in più in tutte le parole dopo aver eseguito Ghostscript


10

Questo PDF è stato prodotto da Abbyy Finereader 10:

http://ebooks.zeitr.org/from_abbyy.pdf

Puoi copiare e incollare la prima frase e ottenere questo (ottimo) risultato del testo:

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

Dopo qualche elaborazione con Ghostscript 9.02 (Windows a 64 bit) ottengo questo file:

http://ebooks.zeitr.org/after_ghostscript.pdf

Ora la prima frase sembra strana: c'è uno spazio extra prima dell'ultimo carattere di ogni parola.

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

Questo ha il principale effetto negativo che non è possibile cercare parole intere in Acrobat Reader. Posso riprodurre l'effetto con il seguente set di parametri minimo per Ghostscript:

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

Qualche idea?


@Erwin Jurschitza: ti dispiacerebbe mantenere il link del tuo file from_abbyy.pdf per un po ', in modo che possa essere recuperato anche dopo pochi mesi?
Kurt Pfeifle,

@pipitas: nessun problema, è su Amazon S3.

Risposte:


8

Ho trovato questo un problema interessante e ho dato un'occhiata più da vicino ...

Innanzitutto, ho utilizzato lo qpdfstrumento da riga di comando per decomprimere i flussi di dati PDF in modo da poter vedere meglio i codici sorgente di entrambi i file:

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

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

Osservando una delle prime occorrenze in cui viene inserito uno spazio aggiuntivo (è la stringa originale "Bund Deutscher Gymnastik-Schulleiter" che si trasforma in "Bun d Deutsche r GymnastikSchulleiter" ), trovo i seguenti frammenti PDF:

In 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

In 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

Per darti un'idea di cosa significano gli operatori grafici PDF qui usati, ecco un breve elenco:

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

Come puoi vedere, Ghostscript ha sostituito l' operatore Tm( matrice di testo ) originale con uno Td( sposta il punto corrente del testo ) e ne ha aggiunto uno in più 2.16501 0 Td... Non so perché. Invierò una segnalazione di bug a bugzilla di Ghostscript [*] e vedrò se sono interessati a risolverlo.

Si noti tuttavia che questo problema non si verifica se utilizzo Linux Acrobat Reader 9.4.2 e utilizzo l'azione di menu "File -> Salva come testo ..." . In questo caso, non ci sono spazi aggiuntivi (ma alcune interruzioni di riga in più). Anche su Linux, il testo non è correttamente ricercabile e mostra anche gli spazi extra quando si fa copia e incolla ....


[*] Aggiornerò qui con il numero di bug quando l'ho fatto.


Aggiornare:

Dopo aver riflettuto un po 'di più sull'operatore sostituito Tm, ora penso che questo non dovrebbe essere la radice del problema.

Quando me ne sono reso conto, ho provato a fare la conversione con Ghostscript v8.71 invece di v9.02. E cosa dovrei dire? Il problema copy'n'paste non si verifica con l'output v8.71!

Ciò significa: c'è un problema in Ghostscript 9.02 che non era presente in 8.71. Molto probabilmente ha a che fare con le metriche dei caratteri incorporate nel PDF di output. Poiché i frammenti PDF sopra citati sono gli stessi nell'output v8.71 dell'output v9.02 ....

Aggiornamento 2:

URL della voce del bug nel bugzilla di Ghostscript:

Aggiornamento 3:

Questo bug sembra essere stato corretto nel frattempo. Non vedo che accada con le versioni di Ghostscript con cui l'ho ancora testato con: Git corrente (v9.10GIT) né con Ghostscript v9.06.


@pipitas: grazie mille per aver analizzato questo!

5

Se si esegue la scansione di una pagina con testo in un PDF e si esegue un'applicazione OCR su di essa, il testo verrà aggiunto alla pagina, ma la "modalità di rendering del testo" è impostata su invisibile. È lì, ma non viene visualizzato sullo schermo (o sulla carta se stampato). Quello che vedi o stampa è l'immagine digitalizzata originale.

Come possiamo rendere visibile il testo invisibile?

Bene, possiamo modificare il PDF ... Il codice PDF per impostare il rendering del testo su invisibile è questo:

3 Tr

Non puoi trovare questa stringa (ancora) nell'originale from_abbyy.pdf né in from_ghostscript.pdf perché parti dei PDF sono compresse. Quindi li decomprimiamo il più possibile con l'aiuto di qpdf:

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

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

Ora possiamo trovare facilmente la stringa sopra (e c'è solo un'occorrenza in ciascun file).

Passiamo a una delle modalità visibili di rendering del testo. Nel complesso, possiamo scegliere tra queste 8 modalità di rendering del testo:

 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 uso la modalità "riempimento", il testo dell'OCR probabilmente non apparirà così buono sull'immagine di scansione sottostante. Pertanto preferisco la variante "corsa". Quindi cambio semplicemente sopra la riga per leggere

 1 Tr

Guardando questo PDF modificato, non mi piace, perché la larghezza di linea predefinita è troppo spessa per i miei gusti. Inoltre, il colore del tratto del contorno è nero (impostazione predefinita); Preferirei il rosso per avere un contrasto con le forme originariamente scansionate. Pertanto aggiungo un po 'di codice all'inizio di questa riga che imposta la larghezza della linea su un quarto di punto:

 .25 w

e alcuni altri per impostare il colore del tratto su rosso:

 1 0 0 RG

La riga completa ora è la seguente:

 .25 w 1 0 0 RG 1 Tr

È tutto.

Nota che la nostra piccola manipolazione ha danneggiato il file, perché il suo "TOC" (in termini tecnici: la sua xreftabella) ora non sarà più valido. Acrobat Reader o Acrobat Professional lo apriranno comunque (senza lamentarsi nemmeno) e "ripareranno" silenziosamente la sezione xrif del file. Altri visualizzatori di PDF potrebbero rifiutare il file, ma per ora non ci interessa ...

Ecco alcuni screenshot del risultato: ingrandito alla larghezza della finestra (Il primo screenshot viene ingrandito alla larghezza della finestra.) ingrandito all'800% (Il secondo screenshot viene ingrandito all'800%.)

I contorni rossi sono il testo digitalizzato reso visibile ora, proprio come lo volevamo.

Ho condotto la stessa procedura descritta sopra per entrambi i file from_abbyy.pdf e after_ghostscript.pdf . Ho aperto entrambi i risultati in 2 diverse istanze di Acrobat Reader. Se eseguiamo entrambi lo zoom sullo stesso valore e massimizziamo entrambe le finestre, è facile alternare la vista tra i due file tramite [alt]+[tab]. Questo è un buon modo per rivelare anche le migliori differenze di rendering tra due file PDF.

Il mio risultato è: non c'è nemmeno un singolo pixel diverso tra l'input di Ghostscript (v9.02) e il suo output per questo file. Ma c'è una bella differenza se vuoi copiare il testo ...


1

Non vedo il problema descritto. Ho aperto il file PDF "after" con Acrobat Professional 9.0 e il testo viene copiato e incollato correttamente.

Ghostscript interpreta completamente il file PDF e produce un nuovo file PDF basato su ciò che ha interpretato, non ha alcuna relazione con il file originale se non che registra la posizione del testo.

Grazie al ricco set di funzionalità di PDF è possibile posizionare i caratteri nello stesso posto utilizzando più metodi diversi. Quindi non c'è nulla di sbagliato o inaspettato di per sé nel modo in cui GS sta producendo il file PDF.

Dato che il testo può essere salvato correttamente, si tratta dell'euristica di Acrobat che decide se due caratteri "vicini" sono adiacenti o hanno uno spazio tra, quando vengono gestiti come ASCII consecutivi.

Non credo che il problema possa essere la metrica del carattere incorporato per la semplice ragione che il carattere non è incorporato :-) Il carattere utilizzato è Helvetica, che non è incorporato nel documento, e quindi Acrobat (almeno per me) usa ArialMT. Si noti che anche il file PDF "originale" non contiene i caratteri.

Alla fine esaminerò il bug segnalato, ma non sarà presto e dubito che ci sia qualcosa che possiamo (o fare) fare al riguardo. Mi sembra che questa sia una conseguenza inevitabile dell'euristica. Si potrebbe contribuire a incorporare i caratteri, però, in modo che almeno sarebbero coerenti.


@ user701996: Interessante - nessun problema con Acrobat Pro 9.0? Il mio Acrobat Reader X (10.0.1, Windows) presenta il problema.

@ user701996: ho aperto il file in Acrobat Professional 9.4.4. Copia e incolla del file after- file non funziona. Salva come testo ... tuttavia funziona ....
Kurt Pfeifle,

@ user701996: anche se il carattere non è incorporato, lo sono le metriche dei caratteri . Hmmm, a meno che il carattere non sia uno dei "Base 14" .... Quindi potresti avere ragione in questo caso. Darò un'occhiata più da vicino.
Kurt Pfeifle,

@ user701996: Sembri una delle persone di Ghostscript. Tu sei?
Kurt Pfeifle,

1

Dal rapporto sui bug di Ghostscript all'indirizzo:

http://bugs.ghostscript.com/show_bug.cgi?id=692206


Sono stato ora in grado di riprodurre il problema, e non è una regressione da 8.71, è una progressione (e una modifica di Adobe).

8.71 fornito con un bug che ha causato la scrittura di CMaps ToUnicode non validi. La documentazione fuorviante e contraddittoria di Adobe ha portato alla stesura della CMap come CMap, quando in realtà le CMap ToUnicode hanno regole proprie, incompatibili.

ToUnicode CMaps viene normalmente utilizzato solo per la ricerca e la copia / incolla. Come suggerisce il nome, vengono utilizzati per mappare i codici carattere ai punti codice Unicode. ToUnicode CMap nel file PDF 8.71 non viene utilizzato, poiché non è valido, quello nelle versioni successive è valido e Acrobat è noto per usarlo.

Sembra che in Acrobat Reader fino al 9.2 compreso, l'esistenza dei dati ToUnicode non faccia alcuna differenza. Ad un certo punto dopo 9.2 il meccanismo di ricerca è cambiato e Acrobat sembra utilizzare due meccanismi diversi a seconda della presenza di un CMap ToUnicode. Non ho accesso ad Acrobat Pro dopo la 9.2 e solo Reader X è stato installato di recente, non ho nulla in mezzo.

Il metodo "no Unicode" funziona su tutte le versioni di Acrobat, il metodo "Unicode" non funziona su versioni più recenti.

L'ho mostrato spaziando in bianco il riferimento a ToUnicode CMap da FontDescriptor. Se necessario, posso rendere disponibili i vari file, ma sono grandi in quanto vengono decompressi.

Poiché la ricerca è uno sforzo euristico in PDF, non sarà possibile garantire un risultato. Il cambiamento nel comportamento è dovuto ad Acrobat, non a Ghostscript, e il cambiamento in Ghostscript è stato quello di correggere un vero bug, quindi una progressione, non una regressione.


0

Per verificare se questo problema è collegato o meno al carattere "incorporato" del font, ho fatto un'altra conversione su Linux. Ho usato questa linea di comando per far sì che Ghostscript incorporasse i caratteri usati:

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

Ghostscript mostrerà questo output:

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.

Ghostscript ha incorporato caratteri di una famiglia di caratteri chiamata NimbusSanL . Quindi non più ArialMT , come è stato utilizzato per il rendering sullo schermo da Acrobat Reader come sostituto della Helvetica mancante (vedere anche i commenti dell'utente701996 sopra). Nota che Ghostscript rinominerà quel font in Helvetica non appena sarà incorporato. Ma questo non è un problema, perché NimbusSanL è stato creato come un clone di Helvetica ...

Tuttavia, anche per questo PDF di output, copy'n'paste da Acrobat Reader non funzionerà bene. Nonostante il fatto che Reader non debba più utilizzare ArialMT per sostituire Helvetica. Reader ora utilizza il clone NimbusSanL / Helvetica incorporato.

Finora abbiamo stabilito questi fatti sulla copia e l'annullamento del testo da Acrobat Reader o Acrobat Professional:

  • L'output di Ghostscript v9.02 non funziona abbastanza bene per questo file.
  • Questo è il caso se il carattere è incorporato da GS o se non lo è.
  • Questo è il caso di GS su Windows XP e GS su Linux.

  • L'output di Ghostscript v8.71 FUNZIONA abbastanza bene per questo file.

  • Questo è il caso se il carattere è incorporato da GS o se non lo è.
  • Questo è il caso di GS su Windows XP e GS su Linux.

  • Anche per l'uscita in cui Copy'n'Paste è rotto, Salva come testo ... fa.

Ancora non capisco perché questo dovrebbe essere il caso. Ma sembra chiaramente una sorta di regressione (forse minore) di Ghostscript sulla sua strada dalla v8.71 al 9.02.

Ora proviamo altri software di visualizzazione PDF con i PDF "critici":

  • Adobe Reader X in Wine su Linux: copy'n'paste è b0rken come nella v9.4.4.
  • Evince v2.32.2 su Linux: funziona copy'n'paste.
  • PDFXChange Viewer 2.5 (build 191) su Windows XP Prof: copy'n'paste funziona.
  • Lettore MuPDF 0.8 su Linux: non so come copiare e incollare, ma la 'ricerca' funziona perfettamente.
  • Trovato il s.th. chiamato "PDF Viewer 0.1.7" su Linux: copy'n'paste funziona.
  • SumatraPDF v1.5 all'interno di Wine su Linux: funziona il copy'n'paste.
  • SumatraPDF v1.5.1 su Windows XP: copy'n'paste funziona.
  • FoxitReader 4.3.1.0113 su Windows XP: copy'n'paste funziona.
  • Nitro PDF Reader in Wine su Linux: funziona il copy'n'paste.

Nota, ci sono ancora altre, ma differenze minime tra tutti i lettori PDF "funzionanti" in cui il mio verdetto è stato il copia e incolla . Come un trattino mancante qui, o alcuni spazi raddoppiati tra le parole lì, e altre cose del genere ... Al momento non ho alcuna spiegazione del perché questo possa essere, ma probabilmente è la stessa causa principale perché c'è il grande divario tra i prodotti Adobe (che non ha una copia funzionante per questo file) uno l'uno e "il resto del mondo" sull'altro.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.