PDF - textes manquants pour prévisualisation et impression

Bonjour,

Oui je pense que le PDF n'est pas parfait, mais que "comme ça marche sous windows", ton prestataire ne s'est pas posé plus de questions.

Comme le propose cette discussion, as-tu essayé avec okular (l'outil PDF de KDE) ou avec qpdfview ? Peut-être sont-ils capables de rattraper le coup ?

Bonne chance

Bonjour,

Convertir un pdf en ps n'est pas "si crade" puisque de toute façon c'est ce que fera ton logiciel d'impression, mais je comprends qu'éviter cette étape serait plus pratique et plus élégant. La solution de contournement fonctionne car les polices mises en jour, bien qu'absente du PDF, sont sur ton système, ce qui permet (je suppose) à pdf2ps de s'y retrouver.

Je pense que le problème de fond est que ton PDF n'embarque pas les polices personnalisées qu'il implique (or c'est techniquement possible). C'est donc au moment où tu construis ton PDF que tu dois le faire.

Le paquet ttf-mscorefonts-installer permet d'installer les polices Microsoft sur ton système (dans /usr/share/fonts), mais si ton script PHP ne dit pas explicitement qu'il faut les embarquer dans le PDF à générer, il ne le fera visiblement pas pour toi. Il en va bien entendu de même pour toutes les polices impliquées dans ton document.

Il faudrait voir quel paquet PHP tu utilises pour créer ton PDF, mais en admettant que ce soit fpdf, tu peux sans doute t'inspirer de ce tutoriel.

Bonne chance

Bonjour,

Convertir un pdf en ps n'est pas "si crade" puisque de toute façon c'est ce que fera ton logiciel d'impression, mais je comprends qu'éviter cette étape serait plus pratique et plus élégant. La solution de contournement fonctionne car les polices mises en jour, bien qu'absente du PDF, sont sur ton système, ce qui permet (je suppose) à pdf2ps de s'y retrouver.

Je pense que le problème de fond est que ton PDF n'embarque pas les polices personnalisées qu'il implique (or c'est techniquement possible). C'est donc au moment où tu construis ton PDF que tu dois le faire.

Le paquet ttf-mscorefonts-installer permet d'installer les polices Microsoft sur ton système (dans /usr/share/fonts), mais si ton script PHP ne dit pas explicitement qu'il faut les embarquer dans le PDF à générer, il ne le fera visiblement pas pour toi. Il en va bien entendu de même pour toutes les polices impliquées dans ton document.

Vu que sembles utiliser fpdf, tu peux sans doute t'inspirer de ce tutoriel.

Bonne chance

Coucou Mamiemando ;)

Alors je n'ai pas précisé mais ce n'est pas moi qui génère le document, c'est un prestataire qui nous envoie ce document en l'état. J'ai déterminé qu'il les générait à partir de PHP car c'est ce que retourne pdfinfo et mes recherches sur "Producer:       FPDF 1.6"

De là à contacter le prestataire pour lui dire d'embarquer ses polices, je n'y crois pas trop. De plus comme le document est affiché à l'écran avec tout le texte et ce même avant que j'ajoute le paquetage ttf-mscorefonts-installer, je ne pense pas qu'embarquer les polices y change quelque chose.

C'est pour ça que je demande de l'aide, je ne vois vraiment pas ce qui peut coincer, d'autant que le résultat est le même sur 2 machines physiques différentes avec Debian 11 dont l'une a un système fraichement installé.

Pilotes graphique ? Autre ?

Convertir un pdf en ps n'est pas "si crade" puisque de toute façon c'est ce que fera ton logiciel d'impression, mais je comprends qu'éviter cette étape serait plus pratique et plus élégant.

Ah ouais ! Mais mais alors si les applications convertissent de toute manière en PS et vu qu'on peut imprimer directement du PS, ça voudrait dire que le temps pris avant l'impression effective pourrait être optimisé. Je relève car parfois certaines impressions de gros documents prennent vraiment beaucoup de temps alors que la tâche est juste d'imprimer sur une surface A4 et pas sur du A0.

Peux-tu clarifier "l'impression d'un document PDF est incomplète alors que son contenu est correctement affiché à l'écran avant impression" : est-ce une zone de texte dans une même police ou certains caractères ?

As-tu déterminé quel zone de textes (avec quelle police) engendraient des problèmes ?

D'après la sortie de pdffonts, seules les polices Helvetica ne sont pas embarquées.

Peut-être que lancer ton lecteur pdf depuis un terminal puis ouvrir ton document donnera des informations complémentaire sur la cause du problème.

Bonjour,

Si le but est juste d'imprimer le document sous Linux et que certaines polices font défaut, il suffit de les installer.

• Arial
• Cooper Hewitt

Sous Linux les polices se rangent généralement dans /usr/share/fonts mais normalement, tu dois avoir un outil dans ton interface graphique pour ajouter des polices (par exemple font-manager).

Si le but est de rendre le document imprimable, il faut que celui-ci n'implique que des polices sur le système cible. C'est une des raisons pour lesquelles utiliser des polices exotiques est rarement une bonne idée, à moins comme je l'expliquais auparavant de l'embarquer dans le fichier PDF.

Le format PDF est "ouvert" (enfin c'est un peu plus subtil) mais tu peux effectivement le manipuler depuis libreoffice-writer ou avec un programme (par exemple codé en python, avec pdfminer). Une solution pourrait être d'injecter les polices manquantes mais je ne l'ai jamais fait, je pense que c'est faisable, mais je ne sais pas si c'est si facile.

Ce que je ne comprends pas vraiment, c'est comment la conversion vers un fichier PS te permet de contourner le problème. Est-ce que lors de la conversion ps, les polices exotiques sont remplacées par une police par défaut ?

Bonne chance

Si le but est juste d'imprimer le document sous Linux et que certaines polices font défaut, il suffit de les installer.

• Arial
• Cooper Hewitt

J'ai testé d'installer la police Arial mais ça n'a rien changé.

Ce que je ne comprends pas vraiment, c'est comment la conversion vers un fichier PS te permet de contourner le problème. Est-ce que lors de la conversion ps, les polices exotiques sont remplacées par une police par défaut ?

Je rappelle que le PDF s'affiche correctement mais c'est uniquement l'aperçu et l'impression qui posent problème

Le format PDF est "ouvert" (enfin c'est un peu plus subtil) mais tu peux effectivement le manipuler depuis libreoffice-writer ou avec un programme (par exemple codé en python, avec pdfminer).

Alors pas directement avec LibreOffice Writer mais avec Draw et merci pour pdfminer je ne connaissais pas :)

--

Toutefois j'ai trouvé comment activer le mode debug sur evince et j'ai découvert des choses intéressantes :

$ G_MESSAGES_DEBUG=Poppler evince doc.pdf > err_gtk
$ cat err_gtk | cut -d: -f 6 | sort -u
 Command token too long
 font resource is not a dictionary
 Illegal character ')'
 Illegal character '>'
 Illegal character '{'
 Illegal character '}'
 Illegal character <03> in hex string
...
 Illegal character <ff> in hex string
 No font in show
 No font in show/space
 Unknown font tag 'f-3-0'
...
 Unknown font tag 'f-20-0'
 Unknown font tag 'f-21-0'
...
 Unknown font tag 'f-28-0'
 Warning
 xref num 18 not found but needed, try to reconstruct<0a>


$ pdftohtml -fontfullname -hidden -stdout -xml doc.pdf
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd">
...
<pdf2xml producer="poppler" version="20.09.0">
...
<page number="1" position="absolute" top="0" left="0" height="892" width="1262">
	<fontspec id="0" size="10" family="Helvetica-Oblique" color="#000000"/>
<page number="2" position="absolute" top="0" left="0" height="1262" width="892">
...

	<fontspec id="20" size="33" family="GKNUFG+CooperHewitt-Bold" color="#527fac"/>
	<fontspec id="21" size="18" family="GKNUFG+CooperHewitt-Bold" color="#527fac"/>
...
<fontspec id="58" size="13" family="AAAABC+Arial-ItalicMT" color="#000000"/>
...
<text top="99" left="85" width="445" height="33" font="20"><b>BLABLAB</b></text>
<text top="140" left="285" width="43" height="18" font="21"><b>BLABLA</b></text>
...
</page>
</pdf2xml>

=> si quelqu'un a suivi, le debug renvoie des "Unknown font tag" pour les identifiants f-NN-0 où NN est un identifiant et qu'ils correspondraient aux fontspec liée à une police de la sortie XML de pdf2html et dans mon cas correspondraient bien aux problèmes de police remontés plus tôt indiqués par Draw, à savoir CooperHewitt et Arial.

Mais très franchement sans documentation détaillée c'est de la spéculation voire du délire.

Si quelqu'un a plus de connaissance sur le sujet ...

En tout cas pour ma part, je suppose que le problème est du côté du prestataire (même si Windows s'en sort) et s'il se reproduit trop souvent sous Debian 11 XFCE4 je repartirais de cette analyse, sinon autant convertir en PS.

Bonjour,

En réponse à ton dernier message #10.

Malheureusement, je ne pense pas que tu puisses avoir une telle garantie au niveau du lecteur lui-même, car cela dépend de la manière dont est implémenté l'application. C'est un peu comme demander que tous les navigateurs internet se comportent de la même façon, c'est un débat qui a fait couler beaucoup de larmes pendant ces dernières décennies :-)

La promesse du format pdf était de garantir que le comportement à l'impression soit le même pour tout plateforme, mais cela pré-suppose que le fichier soit complet et bien formé, et que le lecteur pdf implémente toute la norme pdf.

• Si le pdf est imparfait, le moteur de l'application va prendre des décisions arbitraires et parvenir (ou pas) à corriger le tir selon son implémentation.
• Si le lecteur pdf est partiellement implémenté, il n'est pas surprenant que certains documents s'ouvrent mal.

On peut regretter qu'evince n'y parvienne pas ce qui mériterait peut être d'être signalé auprès des développeurs concernés (voir cette page).

• Si tu décides de remonter le problème, les développeurs te demanderont sûrement un pdf qui met en évidence le problème, chose que tu peux sans doute leur fournir en anonymisant les parties sensibles du document avec pdfminer.

En résumé :

• Dans un monde parfait, il faudrait :
  • ne générer que des pdf "standalone" afin de garantir que le comportement du lecteur pdf soit toujours celui attendu ;
  • s'assurer qu'on n'utilise que des lecteurs pdf fiables (complètement implémentés et exempts de bogues)
• Dans un monde pratique, tu n'as pas vraiment d'autre choix que de changer de lecteur pdf.
  • okular marche généralement bien pour la lecteur et l'impression. Pour les pdf modifiables, ça dépend j'ai souvenir de mésaventures. Peut-être que qpdfview est meilleur à ce niveau. Malheureusement, tous deux sont construits sur Qt, ce qui engendre l'installation de nombreuses dépendances pour les personnes qui ne sont pas sous KDE.
  • Dans des temps très reculés, j'utilisais acroread (le lecteur développé par Adobe). Étonnamment, il ne semble plus exister pour Linux sur le site officiel, mais il semble toujours possible de l'installer (voir ici).

Bonne chance

Oki merci pour tes conseils :), je vais voir si je peux me permettre de consacrer un peu de temps pour remonter le bug.

En tout cas je déplore le fait qu'il n'y ait pas de projet transversal au niveau des interfaces et que l'approche ne soit pas pensée de manière modulaire pour que, soit on utilise ce que l'équipe de dev nous propose de manière native, soit on choisi nous même ce qui nous convient.

Parce que mine de rien avoir des interfaces et des logiques différentes, oblige l'utilisateur à sans arrêt s'adapter et réapprendre pour des différences souvent mineures.

Je me dis qu'il y a peut être à voir dans les nouveaux standards de programmation (y compris dans les bonnes pratiques) et qu'il y ait une sorte de label de type "projet convivial homogène" qu'on pourrait apposer sur des applications qui s'y conforment et qui sensibiliseraient les devs à rester "User Friendly" dans leur conception.

Je fais une digression, ce n'est pas très clair dans ma tête et certainement moins dans mes écrits, mais j'avais envie de le consigner pour que peut être un jour ça murisse dans l'esprit collectif.