J'essaie de convertir des fichiers PDF normaux en PDF / A avec cette ligne de commande:
GPL Ghostscript 9.26: UTF16BE text string detected in DOCINFO cannot be represented in XMP for PDF/A1, reverting to normal PDF output
Cependant, je reçois le message
gs -dPDFA -dBATCH -dNOPAUSE -sProcessColorModel=DeviceCMYK -sDEVICE=pdfwrite -sPDFACompatibilityPolicy=1 -sOutputFile=output.pdf input.pdf
an gs revient au PDF normal.
Apparemment, le message provient de ce fragment de code de gs, mais là on lit que le message ne peut apparaître que lorsque pdev-> PDFACompatibilityPolicy == 0 . Je crois comprendre que le paramètre -sPDFACompatibilityPolicy = 1 dans la ligne de commande a pour but d'empêcher cela.
Q: Pourquoi gs se comporte-t-il comme si la politique souhaitée était 0 au lieu de 1? Existe-t-il un autre moyen de définir la règle sur 1?
De plus, tout comme cela me rend curieux:
Q: Y a-t-il un moyen de voir ce que sorte de DOCINFO étrange il est à l'origine du problème d'origine ou pour l'empêcher en premier lieu? En utilisant Acrobat Reader, je ne vois rien de "suspect" dans le fichier. Si cela aide: Le fichier input.pdf est généré sur Windows à partir de Word (et j'ai essayé même avec le paramètre UseISO19005-1, qui devrait produire PDF / A pour commencer, mais le problème se produit quand même).
3 Réponses :
Vous avez mis -sPDFACompatibilityPolicy = 1 . Cela, j'en ai peur, est incorrect. Ghostscript a deux types de commutateurs -s qui traitent des valeurs de chaîne, et -d qui traite des valeurs numériques et de nom (les noms en PostScript commencent par '/'). < / p>
Vous avez attribué une valeur de chaîne de «1» au paramètre PDFACompatbilityPolicy, qui (en interne) attend une valeur numérique. Pour des raisons liées au fait que ces valeurs doivent être accessibles à partir de l'environnement PostScript, nous ne pouvons pas signaler la confusion de type comme une erreur. À la place, nous laissons le contrôle réel à sa valeur par défaut de 0.
Si vous définissez à la place -dPDFACompatibilityPolicy = 1 , je pense que vous verrez le comportement que vous attendez.
Quant à voir les données, sans regarder le fichier PDF, je ne peux pas le dire. Cependant, si vous vous arrêtez dans le débogueur à ce stade et regardez p-> data, vous pourrez voir quelles sont les données. Si vous regardez paires + i au lieu de paires + i + 1 , vous pourrez voir la clé qui est associée à la valeur du pdfmark DOCINFO.
Vous ne pourrez rien voir de «suspect» en regardant le fichier dans Acrobat, car Acrobat traduira l'UTF16BE en tout ce dont votre système a besoin pour afficher le texte correctement. Il se peut même que ce soit de l'ASCII, vous pouvez toujours le représenter en UTF16.
Si vous ouvrez le fichier dans un éditeur de texte, vous pouvez être en mesure de voir la chaîne appropriée (notez que la nomenclature dans Ghostscript est en octal, donc c'est 0xFE 0xFF en hexadécimal), à condition que ce ne soit pas dans un flux d'objets compressé.
Sur place! Je dois maintenant trouver un moyen de traiter les centaines de découvertes Google qui utilisent en toute confiance -s < / code> (dont j'ai tiré ma ligne). (Et d'après les exemples de lignes trouvés, cela semblait si convaincant, comme si la signification sous-jacente était -dNAME pour définir un indicateur et -sNAME = VAL pour définir une valeur)
En examinant la source du dernier ghostscript (9.50), il semble que les valeurs de PDFACompatibilityPolicy dans ce cas (voir devices / vector / gdevpdfm.c autour de la ligne 1951) le comportement contenant l'erreur en tant que tel:
Donc, dans mon cas, tout a été résolu simplement en paramétrant
-dPDFACompatibilityPolicy=3
Ghostscript ne se plaint pas, n'interrompt pas la sortie PDF / A, fait ne pas ignorer le PDFINFO, et, plus important encore, le vérificateur veraPDF vérifie toujours que le PDF est parfaitement correct.
Je ne fais pas de commentaire sur la laideur de cette solution, mais elle fonctionne tout simplement très bien. Puisque toutes les autres instructions de commutateur supposent simplement la politique de compatibilité 0 si quelque chose au-dessus de 2 est passé, ce "raccourci" semble être un bogue involontaire, mais très utile.
Veuillez considérer ma réponse, j'ai publié stackoverflow.com/a/65699796/6864538
La réponse d'exa n'est pas tout à fait correcte. Ghostscript continuera sa sortie mais le pdf résultant ne sera pas conforme au validateur veraPDF.
En ce moment, je suis occupé à essayer de faire fonctionner ghostscript donc j'obtiens un pdf de facture zugferd valide. Par conséquent, le PDF doit être un fichier PDF / A-3 (a, b ou u) valide.
Problème avec la réponse
Si vous venez de utilisez -dPDFACompatibilityPolicy = 3 verPDF ne validera pas le PDF.
Au lieu de cela, vous devriez corriger le fichier avec le bon encodage.
Dans mon cas, le pdf ressemblait à ceci :
Comment le résoudre:
Créez un nouveau fichier (exemple "pdfmarks") avec ce contenu:
[ /Title (Foo Title) /Author (Foo Bar) /Subject (Foo Bar Subject) /Keywords () /ModDate (D:20061204092842) /CreationDate (D:20061204092842) /Creator (Foo Bar) /Producer (Foo Bar) /DOCINFO pdfmark
(Il n'y a pas de crochets finaux ']')
Exécutez gs comme ceci :
Windows:
"C: \ Program Files \ gs \ gs9.53.3 \ bin \ gswin64c.exe" -dSAFER -dBATCH -dNOPAUSE -sDEVICE = pdfwrite -sOutputFile = / chemin / vers / output.pdf / chemin / vers / entrée. pdf / chemin / vers / pdfmarks
Linux:
gs -dSAFER -dBATCH -dNOPAUSE -sDEVICE = pdfwrite -sOutputFile = / path / to / output.pdf /path/to/input.pdf / path / to / pdfmarks
Vous pouvez soit inclure vos affaires, soit appeler gs une deuxième fois.
J'espère que je pourrais vous les gars un peu plus avec ça.
Cela a l'air génial! Existe-t-il un moyen simple de l'automatiser? (Le pdf que j'obtiens provient de Latex) De plus, comment utiliser les caractères UTF-8 dans le fichier pdfmarks? (est-il compatible utf?)
Vous voulez un script Linux exécutant ces commandes? Je peux fournir cela.