Ce PDF a été produit par Abbyy Finereader 10:

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

Vous pouvez copier et coller la première phrase et obtenir ce (très bon) résultat texte:

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.

Après un traitement avec Ghostscript 9.02 (Windows 64 bits), j'obtiens ce fichier:

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

Maintenant, la première phrase semble étrange - il y a un espace supplémentaire avant le dernier caractère de chaque mot.

Der »Bun d Deutsche r GymnastikSchulleiter« wurd eam 20. Novembre 1955 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.

Cela a le principal effet négatif que vous ne pouvez pas rechercher des mots entiers dans Acrobat Reader. Je peux reproduire l'effet avec le jeu de paramètres minimal suivant pour Ghostscript:

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

Des idées?

J'ai trouvé cela un problème intéressant et j'ai regardé de plus près ...

Tout d'abord, j'ai utilisé l' qpdfoutil de ligne de commande pour décompresser les flux de données PDF afin de mieux voir les codes source des deux fichiers:

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

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

En regardant l'une des premières occurrences où un espace supplémentaire est inséré (c'est la chaîne d'origine "Bund Deutscher Gymnastik-Schulleiter" qui se transforme en "Bun d Deutsche r GymnastikSchulleiter" ), je trouve les extraits PDF suivants:

En 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

En 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

Pour vous donner une petite idée de ce que les opérateurs graphiques PDF utilisés ici signifient, voici une courte liste:

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

Comme vous pouvez le voir, Ghostscript a remplacé l' opérateur d' origine Tm( matrice de texte ) par un Td( déplacer le texte du point courant ), et il en a également ajouté un supplémentaire 2.16501 0 Td... Je ne sais pas pourquoi. Je soumettrai un rapport de bug au bugzilla de Ghostscript [*] et je verrai s'ils sont intéressés à le résoudre.

Notez cependant que ce problème ne se produit pas si j'utilise Linux Acrobat Reader 9.4.2 et que j'utilise l'action de menu "Fichier -> Enregistrer en tant que texte ..." . Dans ce cas, il n'y a pas d'espaces supplémentaires (mais quelques sauts de ligne supplémentaires). Sous Linux également, le texte ne peut pas être recherché correctement, et montre également les espaces supplémentaires lors de la copie et du collage ....

^{[*] Je mettrai à jour ici avec le numéro de bogue quand je l'aurai fait.}

Mise à jour:

Après avoir réfléchi un peu plus sur l' Tmopérateur remplacé , je pense maintenant que cela ne devrait pas être à l'origine du problème.

En réalisant cela, j'ai essayé de faire la conversion avec Ghostscript v8.71 au lieu de v9.02. Et que dois-je dire? Le problème de copier-coller ne se produit pas avec la sortie v8.71!

Cela signifie: il y a un problème dans Ghostscript 9.02 qui n'était pas là dans 8.71. Cela a probablement à voir avec les mesures de police intégrées dans le PDF de sortie. Parce que les extraits PDF cités ci-dessus sont les mêmes dans la sortie v8.71 que dans la sortie v9.02 ....

Mise à jour 2:

URL de l'entrée du bogue dans le bugzilla de Ghostscript:

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

Mise à jour 3:

Ce bug semble avoir été corrigé entre-temps. Je ne vois pas cela se produire avec les versions de Ghostscript avec lesquelles je l'ai à nouveau testé: Git actuel (v9.10GIT) ni avec Ghostscript v9.06.

Si vous numérisez une page contenant du texte dans un PDF et exécutez une application OCR dessus, le texte sera ajouté à la page, mais le "mode de rendu du texte" est défini sur invisible. Il est là, mais il n'est pas rendu à l'écran (ou sur papier s'il est imprimé). Ce que vous voyez ou imprimez est l'image numérisée d'origine.

Comment rendre visible le texte invisible?

Eh bien, nous pouvons éditer le PDF ... Le code PDF pour définir le rendu du texte sur invisible est le suivant:

3 Tr

Vous ne trouvez pas (encore) cette chaîne dans l'original from_abbyy.pdf ni dans from_ghostscript.pdf car certaines parties des PDF sont compressées. Nous les décompressons donc autant que possible à l'aide de qpdf:

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

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

Maintenant, nous pouvons trouver la chaîne ci-dessus facilement (et il n'y a qu'une seule occurrence dans chaque fichier).

Passons à l'un des modes visibles de rendu de texte. Dans l'ensemble, nous pouvons choisir parmi ces 8 modes de rendu de texte:

 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

Si j'utilise le mode "remplissage", le texte de l'OCR ne sera probablement pas aussi bon au-dessus de l'image de numérisation sous-jacente. Je préfère donc la variante "course". Donc je change simplement la ligne ci-dessus pour lire

 1 Tr

En regardant ce PDF modifié, je ne l'aime pas, car la largeur de ligne par défaut est trop épaisse à mon goût. De plus, la couleur du contour est noire (par défaut); Je préfère le rouge pour avoir un contraste avec les formes numérisées à l'origine. Par conséquent, j'ajoute du code au début de cette ligne qui définit la largeur de ligne au quart de point:

 .25 w

et un autre pour définir la couleur du trait sur le rouge:

 1 0 0 RG

La ligne complète se lit maintenant:

 .25 w 1 0 0 RG 1 Tr

C'est tout.

A noter que notre petite manipulation a endommagé le fichier, car sa "TOC" (en termes techniques: sa xreftable) ne sera plus valide. Acrobat Reader ou Acrobat Professional l'ouvrira néanmoins (sans se plaindre même) et "réparera" silencieusement la section xréf du fichier. D'autres lecteurs PDF peuvent rejeter le fichier, mais pour l'instant, cela nous est égal ...

Voici des captures d'écran du résultat: (La première capture d'écran est agrandie sur la largeur de la fenêtre.) (La deuxième capture d'écran est agrandie à 800%.)

Les contours rouges sont le texte numérisé rendu visible maintenant, comme nous le voulions.

J'ai effectué la même procédure que celle décrite ci-dessus pour les deux fichiers from_abbyy.pdf et after_ghostscript.pdf . J'ai ouvert les deux résultats dans 2 instances différentes d'Acrobat Reader. Si nous les faisons zoomer sur la même valeur et maximiser les deux fenêtres, il est facile de basculer la vue entre les deux fichiers via [alt]+[tab]. C'est un bon moyen de révéler même les différences de rendu les plus fines entre deux fichiers PDF.

Mon résultat est: il n'y a même pas un seul pixel différent entre l'entrée de Ghostscript (v9.02) et sa sortie pour ce fichier. Mais il y a toute une différence si vous voulez copier-coller du texte ...

Je ne vois pas le problème décrit. J'ai ouvert le fichier PDF «après» avec Acrobat Professional 9.0 et le texte est copié et collé correctement.

Ghostscript interprète entièrement le fichier PDF et produit un nouveau fichier PDF en fonction de ce qu'il a interprété, il n'a aucune relation avec le fichier d'origine autre qu'il enregistre la position du texte.

En raison du riche ensemble de fonctionnalités de PDF, il est possible d'avoir des caractères positionnés au même endroit en utilisant plusieurs méthodes différentes. Il n'y a donc rien de mal ou d'inattendu en soi dans la façon dont GS produit le fichier PDF.

Étant donné que le texte peut être enregistré correctement, il s'agit de l'heuristique Acrobat de décider si oui ou non deux caractères «voisins» sont adjacents ou ont un espace entre eux, lorsqu'ils sont traités comme ASCII consécutifs.

Je ne crois pas que le problème puisse être les métriques de police incorporée pour la simple raison que la police n'est pas incorporée :-) La police utilisée est Helvetica, qui n'est pas incorporée dans le document, et donc Acrobat (pour moi au moins) utilise ArialMT. Notez que le fichier PDF «original» ne contient pas non plus les polices.

Je vais finalement regarder le bug signalé, mais ce ne sera pas pour bientôt et je doute qu'il y ait tout ce que nous pouvons (ou ferons) à ce sujet. Il me semble que c'est une conséquence inévitable de l'heuristique. Cependant, il pourrait être utile d'incorporer les polices, afin qu'elles soient au moins cohérentes.

Du rapport de bogue Ghostscript à:

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

J'ai maintenant pu reproduire le problème, et ce n'est pas une régression à partir de 8.71, c'est une progression (et un changement Adobe).

8.71 livré avec un bogue qui provoquait l'écriture de CMaps ToUnicode invalides. La documentation Adobe trompeuse et contradictoire a conduit à l'écriture de la CMap en tant que CMap, alors qu'en fait, les CMaps ToUnicode ont leurs propres règles, incompatibles.

ToUnicode CMaps est normalement utilisé uniquement pour la recherche et le copier / coller. Comme leur nom l'indique, ils sont utilisés pour mapper les codes de caractères aux points de code Unicode. Le ToUnicode CMap dans le fichier PDF 8.71 n'est pas utilisé, car il n'est pas valide, celui des versions ultérieures est valide et Acrobat est connu pour l'utiliser.

Il semble que dans Acrobat Reader jusqu'à 9.2 inclus, l'existence des données ToUnicode ne fait aucune différence. À un certain point après 9.2, le mécanisme de recherche a changé et Acrobat semble utiliser deux mécanismes différents selon la présence ou non d'un CMap ToUnicode. Je n'ai pas accès à Acrobat Pro après 9.2 et seulement récemment installé Reader X, je n'ai rien entre les deux.

La méthode «no Unicode» fonctionne sur toutes les versions d'Acrobat, la méthode «Unicode» échoue sur les versions plus récentes.

J'ai montré cela en espaçant les blancs la référence au ToUnicode CMap du FontDescriptor. Si nécessaire, je peux rendre les différents fichiers disponibles, mais ils sont volumineux car ils sont décompressés.

La recherche étant un effort heuristique en PDF, il ne sera pas possible de garantir un résultat. Le changement de comportement est dû à Acrobat, pas à Ghostscript, et le changement dans Ghostscript devait corriger un vrai bug, donc une progression, pas une régression.

Afin de vérifier si ce problème est lié à l '«embarquement» de la police ou non, j'ai effectué une autre conversion, sous Linux. J'ai utilisé cette ligne de commande pour que Ghostscript intègre les polices utilisées:

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

Ghostscript affichera cette sortie:

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 a incorporé des polices d'une famille de polices nommée NimbusSanL . Donc, plus ArialMT , comme cela a été utilisé pour le rendu à l'écran par Acrobat Reader en remplacement de Helvetica manquant (voir également les commentaires de l'utilisateur 701996 ci-dessus). Notez que Ghostscript renommera cette police en Helvetica dès qu'elle sera intégrée. Mais ce n'est pas un problème, car NimbusSanL a été créé comme un clone d'Helvetica ...

Cependant, même pour ce PDF de sortie, le copier-coller d'Acrobat Reader ne fonctionnera pas bien. Malgré le fait que Reader n'a plus besoin d'utiliser ArialMT pour remplacer Helvetica. Reader utilise désormais le clone NimbusSanL / Helvetica intégré.

Jusqu'à présent, nous avons établi ces faits à propos de la copie de texte à partir d'Acrobat Reader ou d'Acrobat Professional:

• Sortie de Ghostscript v9.02 ne fonctionne pas assez bien pour ce fichier.
• C'est le cas, que la police soit intégrée par GS ou non.

• C'est le cas pour GS sous Windows XP ainsi que GS sous Linux.

• La sortie de Ghostscript v8.71 fonctionne assez bien pour ce fichier.

• C'est le cas, que la police soit intégrée par GS ou non.

• C'est le cas pour GS sous Windows XP ainsi que GS sous Linux.

• Même pour une sortie où le copier-coller est cassé, Enregistrer comme texte ... le fait.

Je ne comprends toujours pas pourquoi cela devrait être le cas. Mais cela ressemble clairement à une sorte de régression (peut-être mineure) de Ghostscript sur son chemin de la v8.71 à la 9.02.

Essayons maintenant d'autres logiciels de visualisation PDF avec les fichiers PDF «critiques»:

• Adobe Reader X dans Wine sous Linux: le copier-coller est b0rken de la même manière qu'avec la v9.4.4.
• Evince v2.32.2 sous Linux: le copier-coller fonctionne.
• PDFXChange Viewer 2.5 (build 191) sur Windows XP Prof: le copier-coller fonctionne.
• Lecteur MuPDF 0.8 sur Linux: ne savez pas copier-coller - mais la «recherche» fonctionne parfaitement.
• Trouvé s.th. appelé "PDF Viewer 0.1.7" sous Linux: le copier-coller fonctionne.
• SumatraPDF v1.5 dans Wine sous Linux: le copier-coller fonctionne.
• SumatraPDF v1.5.1 sur Windows XP: le copier-coller fonctionne.
• FoxitReader 4.3.1.0113 sous Windows XP: le copier-coller fonctionne.
• Nitro PDF Reader dans Wine sous Linux: le copier-coller fonctionne.

Remarque, il existe encore d'autres différences, mais très mineures, entre tous les lecteurs PDF «de travail» où mon verdict était copier-coller . Comme un tiret manquant ici, ou des espaces doublés entre les mots là-bas, et d'autres choses de ce genre ... Je n'ai aucune explication actuellement pourquoi cela peut être, mais c'est probablement la même cause profonde pourquoi il y a un grand écart entre les produits Adobe (qui n'ont pas de copier / coller de travail pour ce fichier) l'un et l'autre "le reste du monde".