Le PDF et le SVG utilisent-ils le même modèle de dessin ?

En grande partie, oui. Tous deux reposent sur un modèle d'imagerie issu du PostScript : les chemins (path) sont définis par des segments de droite et des courbes de Bézier, le remplissage et le contour sont des opérations distinctes, les chemins de rognage délimitent la zone. Cette communauté explique pourquoi la conversion de PDF en SVG est si directe — la plupart des instructions ont un équivalent exact.

Pourquoi les systèmes de coordonnées des deux formats sont-ils inversés ?

Le PDF, venant de la tradition de l'imprimerie, place l'origine au coin inférieur gauche de la page et l'axe y croît vers le haut — comme le repère cartésien des cours de mathématiques. Le SVG, venant de la tradition de l'écran, place l'origine en haut à gauche et l'axe y croît vers le bas. Les convertisseurs compensent cette différence par une matrice de transformation : en tant qu'utilisateur, vous ne le remarquez pas.

Peut-on utiliser une police intégrée en SVG ?

Oui, de deux façons : référencer un fichier de police externe avec la règle CSS @font-face, ou intégrer la police en base64 dans le SVG. La seconde rend le fichier totalement autonome mais en augmente sérieusement la taille — une famille de polices peut peser plusieurs centaines de kilo-octets. Par ailleurs, les licences de police n'autorisent pas toujours l'intégration.

Pourquoi le SVG n'est-il pas retenu pour les travaux d'imprimerie ?

Pour trois raisons : le SVG travaille nativement en RVB et ne prend pas en charge le CMJN, les notions de prépresse comme le fond perdu et les traits de coupe n'y sont pas définies, et il n'y a pas de gestion des profils colorimétriques (ICC). Les imprimeurs exigent ces trois éléments. Le PDF, et en particulier ses sous-profils PDF/X, a été conçu pour ces besoins.

Qu'est-ce que le SVG ? Pourquoi ressemble-t-il tant au PDF et où divergent-ils ?

La conversion de PDF en SVG est l'une des plus « directes » qui soient entre formats — car les deux appartiennent en réalité à la même famille. Dans cet article, nous examinons leurs racines communes, les points où ils coïncident exactement et ceux où ils divergent.

L'ancêtre commun : le modèle d'imagerie PostScript

Les deux formats reposent sur un modèle d'imagerie issu du langage de description de page PostScript, développé par Adobe dans les années 1980. Les idées fondamentales de ce modèle sont les suivantes :

La notion de chemin (path). Les formes se composent de chemins définis par des segments de droite et des courbes de Bézier. Un chemin peut être ouvert ou fermé ; il peut être rempli, contouré ou utilisé comme zone de rognage.

Le modèle du peintre (painter's model). Les dessins sont appliqués dans l'ordre et ce qui est dessiné après recouvre ce qui l'a été avant. Comme poser de la peinture sur une toile.

L'état graphique (graphics state). Les réglages comme la couleur, l'épaisseur de trait ou la matrice de transformation sont conservés dans une pile d'états ; ils peuvent être sauvegardés et restaurés.

Les matrices de transformation. La mise à l'échelle, le décalage, la rotation et l'inclinaison s'expriment par des matrices de transformation affines à six éléments.

Grâce à cette communauté, la plupart des instructions de dessin du PDF ont un équivalent direct en SVG :

| Instruction PDF | Équivalent SVG | |---|---| | m (moveto) | M (path data) | | l (lineto) | L | | c (curveto) | C (Bézier cubique) | | re (rectangle) | <rect> ou path | | f (fill) | Attribut fill | | S (stroke) | Attribut stroke | | W n (clip) | <clipPath> | | cm (transformation) | Attribut transform | | q/Q (sauver/restaurer l'état) | Groupe <g> |

Le travail du convertisseur consiste essentiellement à établir cette correspondance. C'est pourquoi la conversion PDF→SVG est bien plus fiable que, par exemple, la conversion PDF→Word ; cette dernière exige des estimations de mise en forme, là où l'on a ici le plus souvent une traduction directe.

Première divergence : le système de coordonnées

Le PDF vient de la tradition de l'imprimerie. L'origine se situe au coin inférieur gauche de la page et l'axe y croît vers le haut. C'est identique au repère cartésien des cours de mathématiques, et c'est naturel pour raisonner en dimensions de papier.

Le SVG vient de la tradition de l'écran. L'origine est en haut à gauche et l'axe y croît vers le bas. C'est l'approche standard en informatique graphique.

Les convertisseurs règlent cela par une matrice de transformation : ils inversent tout le contenu sur l'axe y et le décalent de la hauteur de page. En tant qu'utilisateur, vous ne le remarquez pas, mais en ouvrant le fichier SVG comme du texte, vous pouvez voir sur l'élément racine une transformation de ce type :

transform="matrix(1,0,0,-1,0,842)"

Cela signifie « inverse l'axe y et décale de 842 unités vers le bas » — 842 étant la hauteur d'une page A4 en points.

Deuxième divergence : les unités

Le PDF utilise le point : 1 point = 1/72 de pouce. Une page A4 fait 595 × 842 points. Cette unité est la norme dans le monde de l'impression.

Le SVG définit des unités utilisateur via l'attribut viewBox et n'est lié à aucune mesure physique. Les attributs width et height permettent d'indiquer des unités comme le pixel, le millimètre ou le pouce, mais ce n'est pas obligatoire.

Lors de la conversion, les valeurs en points du PDF sont généralement reprises directement comme unités utilisateur SVG. Le résultat préserve les proportions de la page, mais l'information de taille physique peut devenir floue. Si vous préparez un SVG destiné à l'impression, il faut indiquer explicitement width et height en millimètres.

Troisième divergence : les polices

C'est la différence pratique la plus importante entre les deux formats.

Le PDF intègre les polices. Un PDF peut transporter (et transporte généralement) les données de tracé des polices qu'il utilise. Cela garantit que le fichier s'affiche partout à l'identique — c'est la raison d'être du format.

Le SVG ne les intègre généralement pas. Un fichier SVG standard indique font-family="Arial" et s'attend à ce que cette police soit présente sur le système du lecteur. Si elle ne l'est pas, le navigateur bascule sur une police approchante.

Conséquence : quand vous transférez le texte d'un PDF vers du SVG en tant que texte, la police d'origine peut être absente chez le lecteur. Les chasses de caractères changent, les lignes débordent ou raccourcissent, l'alignement se casse. C'est quasi certain pour les documents utilisant des polices institutionnelles ou commerciales.

Trois solutions existent :

1. Convertir le texte en courbes. Chaque caractère devient un <path>. L'apparence est garantie mais le texte n'en est plus un — il n'est ni sélectionnable, ni consultable, ni lisible par un lecteur d'écran, et le fichier grossit nettement.

2. Intégrer la police. Vous pouvez placer les données de police encodées en base64 dans le SVG via @font-face. L'apparence et l'accessibilité sont toutes deux préservées, mais le fichier grossit et la licence de la police peut ne pas l'autoriser.

3. Se rabattre sur une police web sûre. Si une police répandue est employée (Arial, Times New Roman), le risque est faible.

En pratique, on privilégie les courbes pour les logos et les travaux graphiques, et l'intégration ou le texte pour les contenus riches en texte.

Quatrième divergence : l'espace colorimétrique

Le PDF prend nativement en charge le CMJN. Conçu pour l'impression, il permet de définir les couleurs par leurs composantes cyan-magenta-jaune-noir. Il permet aussi de définir des tons directs (encres séparées comme le Pantone) et des profils colorimétriques ICC.

Le SVG est fondé sur le RVB. La notion de CMJN n'existe pas. Vous écrivez fill="#RRGGBB" ou fill="rgb(r,v,b)".

Lors de la conversion, les valeurs CMJN sont converties en RVB, et c'est une conversion avec perte. Les deux espaces colorimétriques n'ont pas le même gamut (l'étendue de couleurs qu'ils couvrent) ; certaines couleurs CMJN n'ont pas d'équivalent RVB exact. Les écarts les plus marqués s'observent sur les rouges foncés, les bleus marine, les orangés et les noirs riches.

Si vos couleurs institutionnelles doivent correspondre exactement, il faudra corriger à la main les valeurs de couleur du SVG après conversion, d'après les valeurs RVB de votre charte.

Cinquième divergence : transparence et effets

Le modèle de transparence du PDF est très évolué : transparence alpha, modes de fusion (produit, superposition, incrustation...), masques doux (soft mask), groupes de transparence.

Le SVG dispose lui aussi d'une prise en charge de la transparence (opacity, fill-opacity, <mask>, <filter>) mais les modèles ne coïncident pas exactement. Certains modes de fusion du PDF n'ont pas d'équivalent direct en SVG, et certaines structures de masques doux sont traitées différemment.

Résultat : sur les fichiers de design comportant des effets de transparence évolués, des écarts visuels peuvent apparaître après conversion. Avec une simple transparence alpha, aucun problème ne se pose.

Sixième divergence : structure et finalité

Le PDF est multipage et c'est un format de document. Arbre des pages, signets, champs de formulaire, annotations, métadonnées, signature numérique — tout cela relève de la notion de document.

Le SVG est « monopage » et c'est un format graphique. La notion de pages multiples n'existe pas. Il n'a pas de propriétés documentaires comme les signets, les champs de formulaire ou les annotations.

Tout cela se perd à la conversion :

| Fonctionnalité PDF | En SVG | |---|---| | Structure de pages | Un fichier par page | | Signets | Perdus | | Champs de formulaire | L'apparence subsiste, la fonction disparaît | | Annotations | Généralement perdues | | Hyperliens | Certains convertisseurs les transportent en <a> | | Métadonnées | Perdues | | Calques (OCG) | Généralement aplatis | | Signature numérique | Perdue |

En contrepartie, le SVG possède des capacités absentes du PDF : mise en forme par CSS, interactivité en JavaScript, animation SMIL ou CSS, accès programmatique via le DOM.

Pourquoi les imprimeurs ne veulent pas de SVG

À cause de trois manques :

Pas de CMJN. La presse travaille en CMJN ; un fichier RVB crée une incertitude de gestion des couleurs.

Pas de fond perdu ni de traits de coupe. Le PDF dispose des boîtes BleedBox et TrimBox ; le SVG ne définit pas de telle notion.

Pas de gestion des profils colorimétriques. Les profils ICC ne peuvent pas être intégrés.

C'est pourquoi les imprimeurs demandent du PDF, et en particulier ses sous-profils PDF/X. Le SVG a été conçu pour le web et l'écran, le PDF pour l'impression et le partage de documents.

En résumé

Le PDF et le SVG sont deux formats vectoriels issus du même modèle d'imagerie PostScript, et leurs instructions de dessin se correspondent largement une à une — ce qui explique la fiabilité de la conversion. Les points où ils divergent ont en revanche des conséquences pratiques : leurs systèmes de coordonnées sont inversés (le convertisseur compense), le PDF intègre les polices là où le SVG ne le fait généralement pas (d'où la décision texte ou courbes), le PDF prend en charge le CMJN quand le SVG est fondé sur le RVB (dérive des couleurs), et le PDF est un format de document quand le SVG est un format graphique monopage (signets, formulaires et structure multipage sont perdus). Le bon choix de format dépend de la destination : le SVG pour le web et le design, le PDF pour l'impression et le partage de documents.