Gutenberg 1.5

15 septembre 2009

PDF et polices de caractères

Depuis l'émergence de la PAO, les polices de caractères ont souvent été sources de tracas pour les imprimeurs et les techniciens prépresse. Si le PDF permet de lever bon nombre d'obstacles à leur bonne utilisation, le format lui-même ne peut pas tout. Si les polices sont absentes du document, l'imprimeur ne peut pas les inventer !

Le format PDF a ceci de particulier qu'il n'a pas besoin de disposer des polices de caractères pour afficher un texte. Les éditeurs de documents PDF peuvent en effet simuler une police de caractères si celle-ci n'est pas chargée dans le système d'exploitation. Cette fonctionnalité, particulièrement utile dans le cadre d'une utilisation bureautique, se révèle dangereuse lors de l'exploitation du PDF comme format d'échange, de manipulation et d'impression dans l'industrie graphique.

Se méfier de la simulation

Dans nos métiers, un document PDF correctement généré doit intégrer les polices de caractères qui ont servi à sa conception. Si les polices sont intégrées au fichier, les logiciels graphiques en charge de son exploitation, à commencer par Adobe Acrobat, vont utiliser ces polices et elles seules pour afficher et imprimer le document. Si ce n'est pas le cas, Adobe Acrobat va réagir différemment selon les réglages de préférence sélectionnés.

En présence de polices non incluses, Adobe Acrobat 9 va, par défaut, les simuler. C'est-à-dire qu'il va les redessiner tant bien que mal à l'écran et lors de l'impression. À l'évidence, ce paramétrage par défaut est à proscrire pour l'industrie graphique.

La case à cocher « Utiliser les polices locales » doit impérativement être cochée dans l'onglet « Affichage » des « Préférences générales » d'Adobe Acrobat 9. Ainsi, s'il ne trouve pas les polices de caractères nécessaires à son exploitation dans le document lui-même, Adobe Acrobat ira les chercher dans le système d'exploitation de l'ordinateur. Et ce n'est qu'en dernière instance, s'il ne les y trouve pas, qu'il va les simuler.

Pour prendre le moins de risques possible quant à la reproduction correcte d'un document PDF, le contrôle de la présence des polices dans le document est donc un impératif. Ce n'est qu'au cas par cas, et avec une extrême prudence, que l'on peut choisir de faire confiance aux polices de son propre système d'exploitation. En aucun cas naturellement on ne doit laisser Adobe Acrobat redessiner lui-même les polices. La non-intégration des polices dans un document PDF est ainsi l'un des rares problèmes qu'avec toute la meilleure volonté du monde un imprimeur ne peut pas régler à la place de son client. S'il ne dispose pas des polices de caractères ayant servi à la mise en page, l'imprimeur ne peut pas les inventer !

Incorporation

L'intégration des polices de caractère dans un document PDF se règle lors de sa génération. Dans Adobe Distiller, il faut cocher la case « Incorporer toutes les polices » de l'onglet « Polices » des « Paramètres Adobe PDF » que l'on utilise (Menu Configuration > Modifier les paramètres Adobe PDF...). Notez que les champs « Toujours incorporer la police» et « Ne jamais incorporer la police » doivent rester vides.

Il existe deux façons d'incorporer les polices prévues dans les spécifications PDF : soit en jeux complets, soit en jeux partiels. En jeux complets, le générateur de PDF (Adobe Distiller par exemple) va placer l'intégralité des fichiers de polices dans le document PDF. En jeux partiels, il va créer un nouvel élément PDF, un sous-ensemble de caractères qu'il nommera de façon unique dans le document, et qui contiendra l'ensemble des glyphes (des caractères) de la police utilisés par le document, mais uniquement ceux-là.

En jeux complets ou en jeux partiels, la présence dans le fichier des caractères de polices utilisés par le document permet son affichage précis et son impression quelque soient les conditions d'exploitation.

Jeux partiels ou jeux complets

L'avantage d'incorporer les polices en jeu complet réside dans le fait de conserver la possibilité de modifier les textes du document à l'aide d'un logiciel spécialisé. Si la police n'est incorporée qu'en jeu partiel, le logiciel ne sera naturellement pas en mesure d'inventer les caractères manquants pour les rajouter au texte du document. Notez cependant que seuls les possesseurs légaux d'une licence de polices de caractères sont habilités à effectuer de telles corrections.

Incorporer les polices en jeux partiels permet naturellement d'obtenir des fichiers PDF moins lourds. Mais il est un autre intérêt à cette façon de procéder : en jeux partiels, chaque ensemble de polices possède un nom qui lui est propre. En jeu complet, l'ensemble de caractères inclus dans le fichier PDF porte le nom de la police. Or deux polices de caractères différentes peuvent porter le même nom. Cela ne poserait jamais aucun problème si les fichiers PDF étaient toujours exploités individuellement, mais ce n'est pas toujours le cas en prépresse. Lorsque l'on demande par exemple à un logiciel d'imposition d'amalgamer les pages de deux documents PDF distincts, on court le risque que ces deux documents contiennent des jeux complets de polices, portant le même nom, mais n'étant pas rigoureusement identiques. En effet, le nom ne suffit pas à identifier de façon unique une police. Dans ce cas, lorsque le logiciel d'imposition effectue la consolidation des polices (c'est-à-dire qu'il sélectionne les fichiers de police à conserver et qu'il élimine les doublons), il subsiste un risque pour que le rendu de certaines pages, incorporées dans le PDF imposé, ne soit pas conforme à celui des originaux. Des logiciels, tels que Callas pdfToolbox 4 et pdfToolbox Server, règlent le problème en ajoutant un préfixe au nom des polices incorporées rendant celui-ci unique, mais alourdissant ainsi le poids du PDF imposé puisque les doublons sont alors incorporés.

Lorsque l'on crée un PDF en incorporant les polices en jeux partiels, on a le choix dans Adobe Distiller de limiter la création de jeux partiels en deçà d'un certain pourcentage de glyphes (caractères) d'une police réellement utilisé dans le document. Par exemple, si moins de 30 % des glyphes d'une police sont réellement utilisés dans le document, alors Adobe Distiller incorporera cette police en jeu partiel. En revanche, les polices dont plus de 30 % des glyphes sont exploités dans le document seront incorporées en jeu complet. Cela permet d'incorporer les polices spécifiques telles que les dingbats en jeux partiels, tandis que les polices rédactionnelles le seront en jeux complets.

Les exceptions

Notez que lorsqu’Adobe Distiller rencontre des polices dont le codage lui semble exotique (typiquement toutes les polices qui ne se conforment pas stictement au codage Adobe), il les intègre systématiquement en jeux partiels.

De plus, les polices dites composites, c'est-à-dire codées sur 2 octets au lieu d'un seul et répondant en général au codage Unicode, doivent être incorporées en jeux partiels. Dans le cas contraire, les logiciels risquent de ne pas les interpréter correctement. C'est pourquoi Adobe Distiller crée systématiquement des jeux partiels pour ce type de polices, même si on le programme pour n'incorporer les polices qu'en jeux complets. Ces jeux partiels d'un type particulier comportent cependant tous les glyphes contenus dans la table Unicode du langage utilisé par le document.

Selon leur type (TrueType, PostScript Type 1, OpenType...), les polices sont intégrées différemment dans un fichier PDF. Les polices modernes au format OpenType sont des polices composites (codées sur deux octets) générées sur une base soit PostScript soit TrueType. Les spécifications PDF 1.3, sur lesquelles sont encore fondées les normes internationales d'échange de fichiers PDF, n'acceptent l'intégration des polices OpenType que sous leur forme PostScript ou TrueType. Il faut donc se garder de cocher la case à cocher « Incorporer les polices OpenType » de l'onglet « Polices » des « Paramètres Adobe PDF » d'Adobe Distiller. Il s'agit là d'une bien mauvaise traduction. Si cette case est décochée, les polices OpenType seront bien intégrées (si toutefois la case à cocher « Incorporer toutes les polices » est elle bien cochée), mais elles le seront sous la forme de polices PostScript ou TrueType et seront donc correctement interprétées par les logiciels de prépresse et les RIPs.

Enfin, certaines polices TrueType disposent d'une fonctionnalité interdisant leur incorporation. Les logiciels respectueux des droits d'auteur, comme Adobe Distiller, refuseront donc logiquement d'incorporer de telles polices.

08 juin 2009

Les zones de pages PDF

Les zones de pages PDF (ou page boundaries en anglais) fournissent des informations indispensables aux logiciels de traitement prépresse et d'impression des pages PDF. Leur bonne configuration est un impératif pour rendre un document PDF exploitable en industrie graphique.

Les informations de zone de page précisent les bornes (boundaries) selon lesquelles un document PDF doit être affiché, manipulé et imprimé par les différents logiciels. Les spécifications PDF étant rédigées et publiées en anglais, seules les appellations des zones de page dans cette langue sont normalisées. Leur traduction en français dépend du logiciel utilisé. Pour les désigner, nous employons ici, le nom des clefs de leur code PDF, en précisant les traductions françaises les plus couramment employées.

Les cinq boîtes PDF
Initialement, les zones de page PDF étaient au nombre de deux :

• MediaBox (zone de support ou zone de média) ;
• CropBox (zone de cadrage ou de recadrage).

Avec le PDF 1.3 sont apparues trois nouvelles zones pour répondre aux exigences du prépresse :

• TrimBox (zone de rogne ou de rognage) ;
• BleedBox (zone de fond perdu) ;
• ArtBox (zone d'image).

Ces informations de zone de page sont des rectangles, précisées dans le code PDF par les coordonnées x et y de leurs coins inférieur gauche et supérieur droit par rapport au point Zéro du document.
Le point Zéro d'un document PDF est toujours (comme en PostScript) placé en bas et à gauche de la page PDF.

Il ne faut pas s'imaginer les zones de pages PDF comme des rectangles « contenant » les éléments de la page. Le contenu du document PDF existe indépendamment du contenant. Si le contenant (la zone de page) n'est pas explicité, le contenu ne va pas pour autant se répandre dans le disque dur de l'ordinateur... Mais en revanche, il ne sera pas exploitable par les logiciels.
N'imaginez pas non plus un document PDF comme une image composée d'un nombre fini de pixels. Quant on rogne une image, dans Photoshop par exemple, on lui soustrait des pixels. Après sauvegarde de l'image rognée, ceux-ci sont définitivement perdus. Rien de tel en PDF. Un élément peut être « hors cadre » et ne pas se voir ni s'imprimer, il n'en existe pas moins. Si on élargit les dimensions du cadre, cet élément réapparaîtra.

La MediaBox
C'est la seule zone obligatoirement présente et renseignée dans un document PDF. Toutes les autres zones sont optionnelles, mais, si elles existent, elles doivent forcément s'inscrire dans la MediaBox. En théorie le point de départ de la MediaBox doit correspondre au point Zéro de la page. Mais ce n'est pas toujours le cas. En effet, on l'a vu, il est possible de modifier après coup les dimensions de la MediaBox tout comme celles des autres zones de page. Pour réduire la MediaBox, il est possible de définir ces coordonnées de départ positivement ou négativement vis-à-vis du point Zéro du document. Dans ces conditions le « point Zéro » de la MediaBox sera distinct du point Zéro du document lui-même.
Le format PDF n'est pas exclusivement destiné à l'impression. C'est pourquoi les spécifications PDF parlent de zone de média ou zone de support, MediaBox, plutôt que de format du papier.
Pour l'imprimeur ou le technicien prépresse, c'est cependant à ce format du papier que la MediaBox ressemble le plus. En dehors du format du papier..., rien ne s'imprime. Même si la plaque offset contient des zones imprimables en dehors de ce format, ces zones ne risquent pas de se reporter sur le papier, sauf à en changer les dimensions...
Il en va de même en PDF avec la MediaBox. Il s'agit de la zone exploitable la plus vaste du document PDF. Tout élément PDF situé en dehors de la MediaBox ne sera pas exploitable. Encore une fois, cela ne veut pas dire qu'il n'existe pas. L'élément redevient exploitable (en bien ou en mal) si l’on élargit les dimensions de la MediaBox. Pour réduire le poids effectif d'un document PDF, il ne suffit donc pas de réduire les dimensions de la MediaBox, encore faut-il supprimer les éléments PDF situés à l'extérieur de cette zone.

La CropBox
La CropBox (ou zone de cadrage) est optionnelle dans les spécifications PDF. Elle ne peut pas être de plus grandes dimensions que la MediaBox. Elle détermine la partie de la page qui s'affiche à l'écran et, par défaut, la zone d'impression. Par défaut, mais pas toujours, loin de là ! Les pilotes d'impression des RIPs des CTP utilisent la MediaBox comme zone d'impression. Ceux des copieurs des reprographes en revanche utilisent bien la CropBox pour déterminer la zone à imprimer.
Si elle n'est pas renseignée, les logiciels utilisent par défaut les dimensions de la MediaBox pour renseigner la CropBox.

La TrimBox
La TrimBox (ou zone de rogne) est, elle aussi, optionnelle dans les spécifications PDF. Mais pour autant elle est fondamentale pour tous les imprimeurs. C'est elle qui détermine les dimensions du produit fini. C'est de fait la zone délimitée par les repères de coupe, celle qui va servir de base aux logiciels d'imposition. Si elle n'est pas renseignée, elle prend par défaut les dimensions de la CropBox.

La BleedBox
La BleedBox (ou zone de fond perdu), optionnelle encore, désigne la partie de la page qui doit être considérée par les logiciels d'imposition et d'impression comme contenant (éventuellement) des fonds perdus. Typiquement le contenu situé entre cette zone et la TrimBox doit être rogné par les logiciels d'imposition quand il tombe dans un pli et laissé tel quel quand il tombe en débord. La BleedBox prend aussi par défaut les valeurs de la CropBox.

L'ArtBox
L'ArtBox (ou zone d'image), optionnelle dans les spécifications PDF, détermine la zone de la page dont le contenu doit être pris en compte par les logiciels. Typiquement c'est la zone que doivent prendre en compte par défaut les logiciels de mise en page lorsqu'ils importent une page PDF pour en positionner le contenu.

Les impératifs du prépresse
Sans définition précise des zones de page PDF, les logiciels de prépresse ne peuvent pas traiter correctement les fichiers. C'est pourquoi les normes internationales d'échange de documents PDF dans l'industrie graphique sont plus contraignantes. Le PDF/X-1a impose la présence des zones suivantes :

• MediaBox (zone de support) ;
• TrimBox ou ArtBox (zone de rogne ou zone d'image, mais pas les deux, préférez la TrimBox) ;
• BleedBox (zone de fond perdu, optionnelle, mais conseillée) ;
• La CropBox (zone de recadrage) est optionnelle, mais si elle existe ses dimensions doivent contenir celle de la TrimBox ou de l’ArtBox.

Dire que la définition de ces zones est obligatoire ne veut pas dire que leurs dimensions soient obligatoirement distinctes. On peut concevoir un fichier correct dont la BleedBox serait de mêmes dimensions que la MediaBox, ou encore que la TrimBox dans le cas d'un document sans fond perdu.
À ce sujet, la présence d'une zone de fond perdu (BleedBox) ne veut aucunement dire qu'il existe de la matière dans ces fonds perdus. On peut penser à définir une BleedBox distincte de la TrimBox, mais oublier d'étendre la matière dans le fichier au-delà des limites fixées par les traits de coupe. Le cas échéant, ces deux aspects du respect des fonds perdus sont donc à contrôler distinctement.

01 juin 2009

PDF/X-1a:2003

Zoom sur la principale norme internationale d'échange de fichiers PDF sans visibilité, actuellement en vigueur dans l'industrie graphique.

Publié sous la référence ISO 15930-3:2003, le PDF/X1a:2003 édicte les règles minimales à respecter pour s'assurer de la prévisibilité de l'impression d'un document PDF. Il s'agit d'une norme à vocation universelle. Elle vise à s'assurer de l'imprimabilité des fichiers PDF et non pas de la qualité in fine du produit imprimé. (Lire à ce sujet l'article Normes PDF, PDF/X, PDF/X Plus...).
L’ISO 15930-3:2003 s'assure d'une part que le document PDF ne contiendra pas de données susceptibles de perturber le fonctionnement des logiciels en charge de son traitement, et d'autre part que l'imprimeur disposera, sans aucune ambiguïté, de toutes les informations nécessaires à sa bonne interprétation. Le respect de part et d'autre de l'ISO PDF/X1a:2003 constitue la première étape, obligée, à l'automatisation des traitements prépresse.

Contrôle
L'idée directrice qui sous-tend cette norme est le contrôle à chaque étape de la production. La norme n'est d'aucunes utilités si l'on en vérifie pas le respect tout au long de la chaîne de fabrication. La norme PDF/X-1a:2003 édicte les différents points à contrôler dans un fichier PDF, rien de plus, rien de moins.

Le fait qu'un créateur de PDF produise un fichier aux normes n'affranchit aucunement l'imprimeur de le contrôler. Au contraire, en stipulant que son fichier respecte les spécifications du PDF/X-1a:2003, le créateur informe l'imprimeur des règles communes selon lesquelles ce dernier doit en vérifier la conformité. En d'autres termes le respect de la norme ISO 15930-3:2003 – PDF/X1a:2003 oblige le créateur de PDF comme l'imprimeur. Si le premier doit respecter les prescriptions de la norme, l'imprimeur de son côté s'engage à en tenir compte.

PDF 1.4
Comme son nom l'indique, le PDF/X-1a:2003 fut publié en 2003. Il a succédé au PDF/X-1a:2001. Ce dernier était basé sur les spécifications PDF 1.3. Le PDF/X-1a:2003 est quant à lui basé sur les spécifications PDF 1.4. Il interdit cependant l'usage de la principale innovation de ces dernières : un fichier PDF/X-1a:2003 ne doit pas contenir d'informations de transparence. En revanche, le PDF 1.4 autorise la présence de métadonnées. Un avantage jugé suffisamment utile en soi par le comité technique de l'ISO pour justifier l'évolution de la norme. Les spécifications PDF ultérieures au PDF 1.4 sont proscrites par PDF/X1a:2003.

CMJN & tons directs
Le PDF/X-1a n'autorise que les échanges de fichiers PDF en CMJN ou CMJN & tons directs. Tous les autres modes colorimétriques (RVB, LAB...) sont proscrits. Si un imprimeur souhaite recevoir des fichiers RVB et procéder lui-même à leur séparation, il doit réclamer des fichiers aux normes PDF/X-3.
À l'inverse, dans l'ordre actuel des choses, un créateur de PDF, qui ne connaît pas son imprimeur, doit s'abstenir de fournir des fichiers en couleurs autres qu'en CMJN ou CMJN & tons directs. Pour le PDF/X-1a, les fichiers en une seule couleur (Noir, par exemple) sont considérés comme relevant d'un sous ensemble du mode CMJN & tons directs.

Identification
Un document PDF 1.4 commence toujours par l'information de version PDF notée « %PDF-1.4 ».
Un document à la norme PDF/X-1a n'échappe pas à cette règle, mais il doit comporter deux balises supplémentaires « GTS_PDFXVersion » et « GTS_PDFXConformance » renseignées toutes les deux de la valeur « PDF/X-1a:2003 ».

Ce qui est interdit
Le PDF/X-1a:2003 restreint l'usage de fonctionnalités pourtant disponibles dans les spécifications PDF 1.4. Il s'agit le plus souvent de fonctionnalités incompatibles en l'état avec l'impression PostScript (voir à ce sujet l'article Du PostScript au PDF), ou d'informations porteuses d'ambiguïtés quant à la bonne interprétation des données.

Sont interdits :

• les pages préséparées (les PDF doivent être impérativement en couleur composite) ;
• les compressions LZW ;
• les protections par mots de passe ou cryptage ;
• les transparences ;
• l'incorporation de fragment PostScript (PS Xobjects) ;
• les courbes de transfert ;
• les images alternatives définies comme imprimables par défaut ;
• les annotations à l'intérieur des zones de pages TrimBox (Zone de rogne) et BleedBox (Zone de fond perdu) ;
• les actions et JavaScript (code exécutable) ;
• les commentaires OPI ;
• les informations de trame ;
• les profils ICC sources, associés aux couleurs des images ou des éléments vectoriels.

Ce qui est obligatoire
Les données essentielles à la bonne interprétation des fichiers par les logiciels de prépresse doivent être impérativement présentes dans les PDF/X-1a, ainsi que les informations utiles à l'automatisation de la production. De plus, les fichiers doivent contenir toutes les informations précisant à l'imprimeur les intentions de leur créateur. Là encore, l'idée maîtresse est de lever toutes ambiguïtés.

Sont obligatoires :

• l'incorporation des polices de caractères soit en jeux complets, soit en jeux partiels ;
• les spécifications des zones de pages :
  
  • MediaBox (Zone de support, comme dans tous PDF 1.4) ;
  • TrimBox ou ArtBox (Zone de rogne ou Zone d'image, mais pas les deux, préférez la TrimBox) ;
  • BleedBox (Zone de fond perdu, optionnelle, mais conseillée) ;
  • la CropBox (Zone de recadrage) est optionnelle, mais si elle existe elle ne doit pas être de dimensions inférieures à la TrimBox ou à la ArtBox.

• La date de création et de modification du document ;
• Le titre du document ;
• La balise d'identification unique du document, calculée à la création et à chaque modification du PDF ;
• La balise de trapping indiquant si le PDF a fait l'objet ou non d'un travail de grossi-maigri (recouvrement des bords des réserves) :
  
  • si cette balise est réglée sur false (faux) le PDF n'a pas fait l'objet de trapping et celui-ci est à la discrétion de l'imprimeur.
  • Si elle est réglée sur true (vrai), le PDF a déjà fait l'objet d'un travail de trapping ou le créateur souhaite que l'imprimeur s'en abstienne ;
  • Le PDF/X-1a interdit que cette balise soit réglée sur unknown (inconnu).

PDF/X-1a:2003 et colorimétrie
Les fichiers à la norme PDF/X-1a:2003 sont obligatoirement en modes CMJN ou CMJN & tons directs.
Les couleurs ne sont définies que par les valeurs de point de trame de leurs composantes, exprimées en pourcentage. Aucun profil ICC SOURCE ne doit leur être associé.
Par contre, l'imprimeur doit savoir pour quelles conditions d'impression le fichier a été préparé. Typiquement dans quel espace de couleur le graphiste a simulé le rendu de l'impression sur son moniteur calibré.
Ces conditions d'impression sont communiquées à l'imprimeur sous forme de balises spécifiques regroupées dans une partie du code appelé OutputIntent (intention de sortie).

L'OutputIntent contient l'une ou l'autre des balises suivantes :

• OutputConditionIdentifier
  Il s'agit de l'identification des conditions d'impression enregistrée dans un registre spécifié. Le registre doit être annoncé dans la clef «RegistryName». L'ICC (International color consortium) publie sur son site www.color.org un tel registre de condition d'impression. Typiquement en Europe, utilisez l'identifiant Fogra 39, basé sur l'ISO 12647-2. (Voir à ce sujet l'article ISO 12647-2, Fogra, et colorimétrie.).

• DestOutputProfile
  Si les conditions d'impression ne sont pas enregistrées dans un registre disponible, elles doivent être communiquées sous la forme d'un profil ICC DE SORTIE. (À ne pas confondre avec un profil SOURCE, attaché à une couleur particulière). Notez que l'on peut à la fois renseigner la balise OutputConditionIdentifier en Fogra 39 et noter le profil de sortie ISO Coated V2 dans la balise DestOutputProfile.

• OutputCondition
  Informe en clair des conditions d'impression pour lesquelles le PDF a été créé. Cette clef doit être renseignée de façon lisible par un être humain.

19 mai 2009

Normes PDF, PDF/X, PDF/X Plus...

Des outils au service de la communication entre professionnels de l'industrie graphique. Rien de magique, que du pro !

L'échange de fichiers PDF dans l'industrie graphique a fait l'objet d'une série de normes éditées par l'ISO (Organisme international de normalisation) et regroupées dans le document ISO 15930. Développées par le comité technique en charge des technologies graphiques ISO/TC130, elles définissent différents standards appelés PDF/X. Les PDF/X ne sont donc pas des formats particuliers mais de simples ensembles de spécifications ayant valeur normative.

PDF/X
La famille PDF/X se décompose en trois sous-ensembles : PDF/X-1,  PDF/X-2,  PDF/X-3.
Seuls les PDF/X-1 et  PDF/X-3 fixent les termes des échanges de fichiers « sans visibilité », c'est-à-dire sans possibilités d'échanger des informations supplémentaires entre émetteurs et destinataires du PDF.
Les PDF/X-2 autorisent en effet l'utilisation de spécifications PDF, inopérantes si l'on ne s'est pas au préalable accordé sur la façon de les exploiter  — par exemple des informations OPI (Open Prépresse Interface).
Initialement, le PDFX-1 autorisait lui aussi les informations OPI. C'est pourquoi cette norme a fait l'objet d'un sous-ensemble dit PDF/X-1a qui prohibe leur usage, rendant possibles les échanges sans visibilité.
Au fur et à mesure que la technologie évolue, les normes se précisent. Aussi fait-on suivre leur référence par le millésime de sa publication. Le PDF/X-1a est ainsi aujourd'hui décliné en deux versions : PDF/X-1a:2001 et  PDF/X-1a:2003.

Échange sans visibilité
En ce qui concerne les échanges de fichiers PDF sans visibilité, les normes actuelles sont le PDF/X-1a:2003 et le  PDF/X-3:2003, faisant respectivement l'objet des parties 4 et 6 de l'ISO 15930.
Le standard PDF/X-1a:2003 fixe les termes des échanges de fichiers PDF dont les couleurs sont définies en CMJN et tons directs. C'est-à-dire dans des espaces de couleurs dépendants du dispositif d'impression. C'est le standard le plus employé actuellement.
Le standard PDF/X-3:2003 autorise l'échange de données contenant d'autres espaces colorimétriques que le CMJN (RVB, Niveaux de gris...), à condition que chacun d'eux soit précisé par son profil ICC. Il tente ainsi de normaliser les échanges de fichiers contenant des données colorimétriques indépendantes du dispositif d'impression. Peu utilisé aujourd'hui, il n'est pas sûr qu'il le soit plus demain, l'histoire le dira.

Normes universelles
Ces normes ISO 15930 sont à vocation universelle. Contrairement aux normes 12647, elles ne distinguent pas les différentes technologies d'impression (offset feuilles, rotative, sérigraphie...). Un fichier PDF/X-1a peut aussi bien être destiné à l'impression en offset sur papier couché que sur papier journal.
D'une part, les spécifications PDF/X se contentent d'interdire les éléments, possiblement inclus dans des documents PDF, qui sont incompatibles avec leur impression professionnelle. D'autre part, elles édictent les informations indispensables à la bonne interprétation des fichiers par les imprimeurs et qui doivent à ce titre y figurer impérativement. Les métadonnées multimédias (son, vidéo...) sont par exemple proscrites, tandis que les polices de caractères doivent impérativement être intégrées aux fichiers.
En revanche, toujours à titre d'exemple, aucune résolution minimale n'est spécifiée pour les images contenues dans un document PDF/X.

PDF/X Plus
Considérant, à juste titre, que ces normes PDF/X n'étaient pas assez précises pour s'assurer d'une qualité d'impression minimale des fichiers PDF échangés, le Gent PDF Workgroup (GWG) publie des spécifications techniques supplémentaires. Il s'agit de fait de restrictions, applicables aux normes PDF/X, qui diffèrent selon les segments de marché et/ou les procédés d'impression adressés. Ces ensembles de spécifications sont souvent appelés PDF/X Plus, sans que cette dénomination n'ait de lien formalisé avec l'ISO.

Le Gent PDF Workgroup est, comme son nom l'indique, un groupe de travail entre professionnels de l'industrie graphique préconisant l'utilisation du format PDF en prépresse. À l'initiative de la société Enfocus, éditeur d'un des premiers outils pour contrôler et normaliser les fichiers PDF, le GWG a eu le mérite de standardiser les multiples points de contrôle qualitatif du format PDF. Ainsi, différents logiciels peuvent se transmettre des informations de contrôle cohérentes dans et entre les divers flux de production prépresse.

Le GWG segmente ses spécifications entre les marchés suivants :

• Annonceurs (publicité) dans les magazines ;
• Annonceurs (publicité) dans les journaux ;
• Offset feuille ;
• Offset rotative ;
• Héliogravure ;
• Packaging.

Chacun de ces segments est lui-même subdivisé en deux versions : l'une pour l'impression finale en quadrichromie (CMJN), l'autre pour l'impression CMJN + tons directs.

PDF certifié
Les normes ISO PDF/X n'obligent en aucune façon l'émetteur du document à « prouver » que son document respecte bien telle ou telle norme. Elles spécifient seulement qu'une balise (éventuellement modifiable à l'aide d'un simple traitement de texte) doit être ajoutée au fichier PDF pour préciser quelle norme devrait être respectée.
Le Gent PDF Workgroup souhaite aller plus avant dans la sécurité des échanges de documents PDF.
À cette fin, il publie des spécifications pour l'inclusion de la preuve du contrôle dans le fichier PDF lui-même. Ce que l'on appelle en prépresse la certification PDF.
Initialement, seuls les outils de contrôle de la société Enfocus (la gamme PitStop) disposaient d'une technologie de certification. C'est d'ailleurs ce qui a fait pour partie leur succès. Afin de faciliter la standardisation de la façon dont les fichiers PDF doivent être certifiés, Enfocus a rendu publique, en 2008 sa technologie de certification Certified PDF. L'éditeur autorise ainsi tous les développeurs qui le souhaitent à incorporer cette technologie dans leurs propres logiciels. Enfocus conserve cependant l'intégralité des droits de propriété intellectuelle sur Certified PDF.

Certification ou sécurisation ?
La certification PDF n'est autre que le marquage et l'inclusion du rapport de contrôle dans le fichier PDF lui-même. Il s'agit d'un moyen de communication supplémentaire entre l'émetteur et le receveur de fichiers PDF. En aucun cas d'un outil de sécurisation absolue du format PDF.
Un PDF parfaitement sécurisé perdrait tous les avantages du PDF en prépresse : éditabilité, légèreté, souplesse d'utilisation, etc. La sécurisation PDF est donc un mythe, un fantasme. Ce que l'on peut sécuriser n'est pas le format lui-même, mais le processus de production dans son ensemble. Les normes ISO PDF/X et les spécifications du GWG, correctement respectées et contrôlées à chaque étape de la chaîne de production, à l'aide d'outils performants et par un personnel compétent, sont bien en mesure de garantir la fiabilité du procès de production. Il s'agit là d'une logique industrielle à mettre en œuvre, ce qui n'a rien à voir avec la magie d'un format ou d'un outil si perfectionné est-il.

17 mai 2009

Du PostScript au PDF

Adobe annonce ces jours-ci la première version opérationnelle de PDF Print Engine, sa technologie de RIP entièrement PDF. Une occasion pour nous de revenir sur les rapports ambigus qu'entretiennent le PDF et le PostScript.

Né en filiation directe d'avec le langage PostScript, le format PDF, pas plus que son parent, ne fut conçu initialement pour répondre aux besoins des arts graphiques. Quand Adobe lance le PDF, il y a une quinzaine d'années, c'est à destination des marchés de la bureautique et de la gestion documentaire. On allait enfin pouvoir s'affranchir de la paperasse et s'échanger des documents de travail sans avoir à les imprimer. Ce n'est que dans un second temps que l'industrie graphique s'est emparée du PDF et en a fait son format de prédilection pour la circulation de fichiers et les opérations de prépresse.
Le PostScript lui-même, dans les années 80, a connu un parcours identique. Il ne s'agissait au début que d'imprimer un texte ou un tableur sur une imprimante de bureau. De cette histoire, il nous reste les contraintes.

Mais qu'est-ce que le PostScript ?
Contrairement au PDF, le PostScript n'est pas un format, mais un langage de commande numérique. Un langage destiné à piloter à distance une imprimante ou tout autre système d'impression. Une imprimante, quelle qu'elle soit, n'est jamais qu'une mécanique à qui l'on doit indiquer les parties de la feuille de papier qu'elle doit recouvrir d'encre. Pour ce faire, la surface imprimante (la feuille de papier) est divisée en un nombre fini de colonnes (verticales) et de rangées (horizontale) qui définissent une grille (une matrice) de points. Le fonctionnement d'un système d'impression est toujours, en définitive, matriciel.
Or l'organisation interne des logiciels de traitement de texte, de calcul ou de mise en page n'est pas matricielle, mais « vectorielle ». Dans ces applications, la page à imprimer n'est pas pensée comme une grille de points, mais comme une suite d'informations balisées. Le PostScript est un langage pour communiquer avec un dispositif d'impression, accessible (sous quelques contraintes) à tout logiciel tournant sous un système d'exploitation courant. Une imprimante PostScript n'est en fait qu'une mécanique pilotée par un ordinateur très spécialisé, le RIP (pour Raster Image Processor). La fonction de ce dernier n'est autre que de comprendre (interpréter) les commandes vectorielles codées en PostScript et les transformer en informations matricielles, seules exploitables par l'imprimante.
Le PostScript n'est pas le seul langage de ce type à avoir été développé. Il existe des imprimantes non PostScript. L'énorme avantage de ce dernier pour l'industrie graphique est d'être un standard. Si un constructeur veut mettre sur le marché un système d'impression à destination des professionnels de l'industrie graphique, il le conçoit obligatoirement comme étant compatible PostScript. L'affaire est entendue depuis plus de vingt ans... Adobe a gagné la bataille technique et commerciale (peut-être l'une plus que l'autre...) au cours des années 80. Au point que le mot PostScript est presque devenu synonyme de PAO (Publication assistée par ordinateur), au moins pour la génération qui a assisté à l'émergence de celle-ci.

Actualité du PostScript
On le verra, le PostScript est loin d'être exempt de défaut au regard des exigences de l'impression professionnelle. Ses lacunes et autres limites tendent à être dépassées par l'utilisation du PDF. Alors, pourquoi parler PostScript, 15 ans après la naissance de celui-là ? Simplement parce que, jusqu'à présent, aucun RIP n'interprétait directement le format PDF. Pour imprimer un document graphique de qualité professionnelle, la conversion ultime du PDF en PostScript est encore un impératif à l'heure où ces lignes sont écrites. La mise à disposition annoncée par Adobe de la technologie d'impression directe en PDF, « PDF Print Engine », va changer la donne. Mais le temps que le parc machine des imprimeurs soit entièrement renouvelé, l'eau va couler sous les ponts. Sans être prophète, on peut s'attendre dans l'imprimerie à ce que le PostScript impose sa loi au PDF pendant encore une petite dizaine d'années...

Les limites du PostScript
Développé il y a presque 30 ans pour des besoins de bureautique, le PostScript traine derrière lui les faiblesses de son âge. Une page décrite en PostScript pèse lourd. Elle est difficilement éditable. Pour l'afficher à l'écran, il faut la ripper. Pour y effectuer des modifications, il faut être un as du prépresse. Pour décrire correctement une page en PostScript, il faut connaître précisément les caractéristiques du système qui va l'imprimer. (Le PostScript est dépendant du dispositif d'impression). Mais surtout, le PostScript est peu prévisible. Un comble pour nos métiers où prévoir ce que l'on va imprimer est le moindre de nos impératifs.
Nous l'avons dit, le PostScript n'est pas un format, mais un langage de commande. Qui dit langage dit syntaxe. Or en PostScript, comme dans les langages humains, il y a plusieurs façons d'exprimer la même information. Il n'existe pas une, mais des milliers de façons différentes pour décrire une même page en PostScript. A contrario, il n'existe pas non plus une seule et unique façon de comprendre une page exprimée en PostScript. Dit autrement, deux RIP PostScript ne vont pas forcément interpréter de la même manière l'information qui leur est adressée. Cerise sur le gâteau : le RIP doit bien souvent effectuer lui-même des calculs (opérations en boucle) pour positionner et déterminer l'aspect des divers éléments de la page. Qui dit calcul dit risque d'erreur. Les fameuses erreurs PostScript sont bien souvent des opérations en boucle que le RIP n'a pas réussies à résoudre.
Il découle de tout cela que ni les logiciels, ni les imprimantes ne sont égaux au regard du PostScript. Il existe des logiciels (ou des pilotes PostScript) qui « parlent » le PostScript mieux que d'autres. Le succès d'un logiciel comme Quark XPress à la fin des années 80 fut dû pour beaucoup au fait qu'il écrivait lui-même son PostScript et qu'il le faisait bien. Utilisant une syntaxe claire et ne faisant pas appel à des opérations en boucle superflues, les informations qu'il envoyait au RIP avaient plus de chances d'être correctement interprétées que celles émises par... d'autres logiciels. Il existe également des RIP meilleurs que d'autres, qui interpréteront au mieux des informations complexes. L'idéal étant naturellement de produire une syntaxe PostScript châtiée à destination d'un RIP de qualité.

PDF à la rescousse !
La bonne fortune du PDF dans l'industrie graphique vient essentiellement de sa capacité à dépasser certaines limites du PostScript. S'agissant d'un format, il est avant tout plus prévisible. Les opérations en boucle du PostScript, nécessaires à la bonne compréhension de la page, ont été calculées lors de la distillation du PDF. Idem pour la syntaxe qui est cadrée par les spécifications du PDF. Utilisant des algorithmes de compression des données, les fichiers PDF pèsent infiniment moins lourd que les PostScript. Ils restent éditables, s'affichent correctement et sont indépendants du dispositif d'impression. Tout pour plaire ? Voir. La faiblesse du PDF réside dans sa force. Il s'agit d'un format aux multiples ressources dont la grande majorité n'a aucune utilité pour les arts graphiques. Un fichier PDF peut par exemple contenir de la vidéo. Ce qui ne saurait laisser indifférent un RIP bien né... Dans l'industrie graphique, il n'est aujourd'hui de bon PDF que des PDF compatibles... PostScript. Et c'est bien cette compatibilité qui détermine les normes internationales d'échange des fichiers et les contrôles indispensables à une utilisation sereine du PDF en prépresse.