Nous vous proposons aujourd’hui de revenir sur le Tech Monday de la semaine passée sur les polices OpenType SVG et PDF.
Nous avons continué nos tests, en incluant notamment QuarkXpress, et nous avons eu l’opportunité de présenter nos travaux dans le cadre des meetings du Ghent Workgroup. Nous allons résumer ici nos nouvelles trouvailles ainsi que les résultats des experts du Ghent Workgroup dont nous faisons partie.
QuarkXPress 2018 s’en sort plutôt bien (mais plus de texte vivant)
Après avoir testé la suite Adobe CC 2019, nous avons poursuivi nos tests en évaluant QuarkXPress 2018, qui, au passage, était la première application professionnelle de montage de pages prenant en charge les polices OpenType SVG. Vous pouvez d’ailleurs consulter cette vidéo (en anglais) de Matthias Günther, Head of Desktop Publishing chez Quark.
Quark communique beaucoup à propos de ces nouvelles polices, mais que donne l’utilisation de ces polices au sein de QuarkXPress 2018 et la conversion en PDF des fichiers les utilisant ?
Et bien, à la fois l’export en PDF/X-1a et en PDF/X-4 fonctionnent parfaitement, les fichiers PDF générés à ces formats étant conformes aux normes.
En fait, QuarkXPress ne convertit pas la fonte OpenType SVG en Type 3 (comme tente de le faire la suite Adobe CC – hors PDF/X-1a), mais extrait le contenu de chaque glyphe pour en faire un object vectoriel dans le fichier PDF. Il n’y a donc plus de texte vivant, mais les objets contenus dans les glyphes sont des contenus de page (page content).
En ce qui concerne le PDF/X-4, soit ces objets sont convertis en CMJN, soit gardés en RVB (en fonction des choix dans le profil d’export). Dans le cas des objets RVB, ils sont taggés ICC (en l’occurence le profil Quark Generic RVB), ce qui est parfaitement conforme à la norme PDF/X-4:2010.
Pour le PDF/X1-a, chaque bloc de texte est converti en image haute résolution, en CMJN.
Alors, évidemment, le fichier PDF est correctement géré, mais le fait de ne plus contenir de texte vivant reste tout de même contrariant. Autant pour une police Emoji, on pourra se passer du texte lui-même, autant pour une police « lisible », il serait nécessaire de pouvoir en extraire le texte, ne serait-ce que pour l’accessibilité.
Retour sur les discussions menées lors du Ghent Workgroup
Suite aux discussions menées lors de la réunion Process Control, il apparaît que :
- les polices OpenType SVG sont incorporées dans le fichier PDF en Type 3 (sauf le caractère « espace » en Type 1)
- lors de la conversion en Type 3, les applications Adobe comportent un bug et les ressources de la police Type 3 sont stockées incorrectement dans le PDF
- le texte vivant (en Type 3) est en RVB, mais n’est pas taggé ICC, ce qui est contraire à la norme PDF/X-4
- pour les deux raisons ci-dessus, le preflight en PDF/X-4 échoue, avec, entre autres, l’erreur « Missing XObjects » (car les ressources ne sont pas stockées au bon endroit)
Avons-nous besoin d’un contrôle spécifique pour les fontes en Type 3 incorrectes ?
Du fait que le preflight échoue actuellement, nous avons décidé qu’il n’y a pas besoin de contrôle supplémentaire. Cela, d’autant plus que les fontes Type 3 correctement créées sont correctement gérées et que les exclure pourrait poser problème, un certain nombre de sociétés ayant créé une police Type 3 pour leur logo par exemple.
Prochaines versions des applications Adobe CC, Enfocus PitStop & callas pdfToolbox
Grâce à nos travaux, il est apparu qu’il est nécessaire de faire évoluer les outils existants afin de résoudre les bugs existants d’une part, mais aussi d’offrir de nouvelles fonctions pour gérer les problèmes rencontrés.
Adobe a reconnu un bug dans l’écriture des polices au format Type 3 dans le PDF et travaille à le régler dans une prochaine version du Creative Cloud.
Callas va proposer des nouvelles fonctions pour gérer les fontes Type 3, correctes et incorrectes (conversion de couleur & extraction du contenu des glyphes – selon un mode proche de l’aplatissement des champs de formulaire ?).
Enfocus travaille également sur des améliorations de PitStop.
Recommandation du Ghent Workgroup
Au regard des points évoqués ci-dessus, à ce jour, le Ghent Workgroup recommande de ne pas utiliser de fontes OpenType SVG pour des contextes de Print.
Informations additionnelles
Merci à Olaf Drümmer (callas software) et Leonard Rosenthol (Adobe) !
Bien que la majorité des fontes OpenType SVG sont RGB, ce n’est pas une condition obligatoire. Dans le principe, une fonte OpenType SVG peut être de n’importe quelle couleur (ou combinaison de couleurs) – elle peut donc parfaitement être monochrome. Il existe également des polices qui utilisent les couleurs autour d’elles (graphic state) ; de ce fait, il est tout à fait envisageable d’avoir une police OpenType SVG dont le mode colorimétrique est CMJN, voire en ton(s) direct(s) !
Il est à noter que les polices de Type 3 (qui contiennent en fait du code PostScript pour le dessin de chaque glyphe) font partie du format PDF (depuis sa version 1.0 !!) et sont supportés par les normes PDF/X.
En conclusion
Nous n’avons pas fini de parler de ce sujet, et nous reviendrons régulièrement sur les évolutions de ce nouveau format de polices de caractères.
Suite à nos tests et aux échanges que nous avons eu lors de nos meetings du Ghent Workgroup, il apparaît maintenant que la partie la plus compliquée de l’utilisation de ces polices en PDF provient de leur conversion d’OpenType SVG vers Type 3 (une conversion est forcément obligatoire, le format OpenType SVG ne faisant pas partie de la spécification PDF). Bien que le format Type 3 soit géré par la spécification PDF, les outils PDF sont encore assez incomplets pour la gestion de ces fontes, et nous attendons les nouvelles versions de ces outils pour voir s’ils nous apportent les fonctions nécessaires.
Pour l’instant, nous ne pouvons que vous inciter à vous tenir à l’écart de l’OpenType SVG pour le Print, mais la vérité d’aujourd’hui n’est peut-être pas celle de demain !
Un commentaire