Avez-vous entendu parlé des polices de caractères OpenType SVG ?
Ces nouvelles fontes, plutôt dédiées au web, contiennent des glyphes en couleur (en mode RVB) et ne sont pas monochromes, comme traditionnellement. Elles sont maintenant supportées dans la suite Adobe CC 2019 (c’était déjà le cas pour Illustrator en CC 2018) et Adobe en propose deux dans la suite, Emoji One et Trajan Color (vous pourrez en trouver d’autres sur le web également).
Que se passe-t-il quand je génère un fichier PDF à partir d’un document contenant ces fontes ?
En exportant un fichier InDesign ou Illustrator en PDF, le résultat dépend de mon choix de joboptions. En exportant en PDF, sans standard particulier, le texte reste vivant, mais la police est incorporée en Type 3 ou un mix de Type 1 et Type 3. Si mon joboptions ne contient pas de conversion de couleur, le texte n’est pas converti dans un autre mode colorimétrique. C’est également le cas si j’opte pour une conversion en PDF/X-4:2010. Par contre, si je choisi de convertir mon fichier source en PDF/X-1a:2001, mon texte sera vectorisé et converti en CMJN.
Le résultat en PDF/X-1a:2001
Le texte est vectorisé, et on ne notera pas de problème particulier, si ce n’est que le texte n’est plus éditable évidemment. Enfin, pas de problème, cela dépendra de votre logiciel source ! Si InDesign ne pose pas de souci, Illustrator n’a pas correctement vectorisé la Trajan Color, et l’effet de relief est absent par endroits sur les caractères…
Occupons-nous maintenant d’un fichier PDF ayant conservé les polices de caractères (pas de PDF/X1-a:2001)
Un mix de Type 1 et Type 3 ?
Effectivement, la Trajan Color sera convertie sous forme de deux polices distinctes, le glyphe correspondant à l’espace étant en Type 1 et le reste de la fonte en Type 3 !
Mais de quelle couleur est ma police ?
Quand bien même la fonte est en couleur (RVB), les inspecteurs des différents logiciels testés (Acrobat, Enfocus PitStop Pro, callas pdfToolbox) estiment que la police est en 100% K.
Mais puis-je alors convertir ma police en CMJN ?
La réponse est claire… NON !
Eh oui, en fonction des logiciels, les comportements seront différents, mais il sera bien impossible d’obtenir un résultat correct.
Pour PitStop Pro, il n’y a rien à convertir (bien sûr, puisque le texte est 100% noir…)…
…mais une tentative de conversion en PDF/X-1a:2001 sera impossible, car le fichier contient du RVB !
pdfToolbox est plus extrême, il fera la tentative de conversion… mais le résultat est étonnant… l’aspect de la police est complètement détruit !
Tentons donc de vectoriser la fonte pour contourner ces problèmes…
Vectorisons-donc notre police pour permettre la conversion de couleur et la validation en PDF/X-1a:2001.
Ah, mais non, PitStop Pro ne nous autorise pas la vectorisation (ce qui est normal, la police étant en Type 3, le contenu de chaque glyphe n’est pas connu – en effet, une Type 3 peut contenir n’importe quoi, ce qui est clairement le cas ici, convenons-en 😉
Bien, tentons alors pdfToolbox… Pas mieux, le logiciel génère une erreur à la vectorisation… non sans avoir détruit la police au passage !
Mais, que faire alors ?
Hélas, pour l’instant, point trop de solutions.
Nous ne pouvons que vous inciter à vectoriser ces polices directement dans votre logiciel source (attention, vérifiez bien le résultat après vectorisation, cf. le problème évoqué plus haut avec Illustrator), et pourtant, nous ne sommes de loin pas des adeptes de la vectorisation des polices !
L’utilisation du format PDF/X-1a:2001 est aussi une option à envisager, même si, là encore, nous sommes plutôt enclins à utiliser du PDF/X-4:2010 si possible.
Nous pourrions espérer qu’Adobe, au lieu de générer sans avertissement un fichier PDF depuis ses applications auteur, présente un écran d’avertissement lors de la génération du PDF.
Nous allons porter ce sujet cette semaine aux réunions du Ghent Workgroup, dans l’espoir de pouvoir lancer une initiative du groupe pour mettre en place des contrôles (et des corrections ?) pour améliorer la situation actuelle. Restez connectés, nous en reparlerons ici-même !
Vous avez rencontré ces soucis ? Vous avez une expérience à nous faire partager ? Vous souhaitez échanger sur le sujet ? Laissez un commentaire !
Chose particulière, la police Apple Color Emoji ne passe pas en Pdf x-4 mais bien en Pdf X-1. On n’a pas fini de rire avec tout ça.
Il est à noter que la police Apple Color Emoji n’est pas une police OpenType SVG, mais une police TrueType (pour être tout à fait exact, c’est une True Type Font Collection – .ttc et non pas .ttf).
Alors que les glyphs sont vectoriels dans une police SVG, ici, nous avons une police où chaque glyph est une image.
Cette police est également très déconseillée pour le Print, notamment si elle est utilisée dans des grands corps, car le résultat sera très pixellisé.
Pourquoi nous avons un résultat différent entre le résultat PDF/X1-a:2001 & PDF/X-4:2010 ?
En PDF/X-4, la police est incorporée en Type 3 (donc avec un problème similaire avec l’article ici, sauf que les glyphs sont des images RVB au lieu de vecteurs RVB), en PDF/X-1a, il n’y a plus de texte et l’ensemble du texte est rastérisé en image.
Bonjour,
merci pour ces infos. Et si on déclenche un applatissement des transparences ? Quel serait le résultat ?
L’aplatissement des transparences est à déconseiller si on fait un PDF/X-4:2010, car la colorimétrie sera alors figée, et les éléments pourront être découpés (résultat classique d’un aplatissement).
Dans le cas d’un PDF/X-1a:2001, l’aplatissement sera de toute façon lancé au besoin, donc rien de plus à faire.
Si nous parlons d’utiliser l’aplatissement des transparences pour vectoriser le texte, c’est une méthode à proscrire absolument (nous y reviendrons sans doute dans un prochain Tech Monday), et de toute façon, ce ne serait pas nécessaire en sortie en PDF/X-1a:2001 puisque le contenu de la police est automatiquement extrait (on peut dire vectorisé par abus de langage) et qu’il n’y aura plus de texte dans le PDF.
Dans notre nouvel article de cette semaine, nous voyons que le problème est essentiellement dû au fait que les logiciels Adobe comportent un bug dans la conversion de l’OpenType SVG vers un format Type 3 (dans le PDF). Grâce à nos travaux, et avec l’aide de nos confrères du Ghent Workgroup, les choses vont changer (pour Adobe et les éditeurs de plug-ins PDF), et nous pouvons espérer que la situation s’améliore dans un futur proche. Nous surveillons cela de près et nous vous tiendrons au courant de l’évolution de ces technologies ici même sur ce blog.
Me suis lancé dans la création de Colorfont SVG avec Fontself Maker (pour l’impression – le gars qui aime sortir de sa zone de confort ;o). Passionnant mais mauvaise surprise effectivement à l’impression. Oui, il faut bien penser à tout vectoriser dans Illustrator (dans lequel je n’ai pas rencontré de problèmes – mais conversion de couleur de RVB à CMJN, je n’aime pas les chiffres pas rond, les noirs non quadri,, le noir dans les couleurs). Donc un surcroit de travail, mais c’est malgré tout interessant quand on a créé sa propre font.
Vous serez fouetté en place publique ! 😄
Merci pour le retour, vous avez vécu en live les problèmes abordés.
Nous restons sur la position du Ghent workgroup, développée dans notre deuxième article sur le sujet : https://www.agilestreams.io/opentype-svg-pdf-print-pourquoi-il-vaut-mieux-attendre/
Pour l’instant, il est fortement déconseillé d’utiliser de telles fontes en production pour l’impression.
Adobe a officiellement reconnu un bug de leur côté et a annoncé qu’il serait résolu rapidement. Enfocus et callas ont pris position pour offrir des fonctionnalités additionnelles dans leurs prochaines versions de PItStop et pdfToolbox.
Position officielle de callas, par l’intermédiaire de son CEO, Olaf Drümmer, dans notre post en langue anglaise :
https://www.agilestreams.io/en/opentype-svg-pdf-the-new-printers-nightmare/#comment-22
Merci Damiens pour ce retour d’expérience. Suite à nos échanges lors du Ghent Work Group, nous sommes convaincus que ces polices seront tôt ou tard bien assimilées sur l’ensemble de la chaîne. Mais oui faut souffrir pour être joli aujourd’hui 😉