Que change-t-il en passant du SVG au PDF ? viewBox, unités et logique des polices

Le SVG est un format graphique web : souple, redimensionnable, s'adaptant à l'écran. Le PDF est un format de page : fixe, physique, lié à l'impression. Bien qu'ils partagent le même modèle de dessin vectoriel, cette différence de philosophie produit des conséquences concrètes lors de la conversion. Dans cet article, nous expliquons ces différences et pourquoi certains SVG se convertissent en PDF à des dimensions inattendues.

Deux conceptions différentes de la « page »

Dans un PDF, la page est physique. Chaque objet page possède une MediaBox, un rectangle fixe exprimé en points. Une page A4 fait 595 × 842 points, toujours, partout. Le contenu est placé directement dans ce système de coordonnées. La notion d'« adapter à l'écran » n'existe pas — la visionneuse zoome, mais la page elle-même ne change pas.

En SVG, la « page » est relative. Un SVG n'a pas de taille intrinsèque ; le contenu est défini dans un système de coordonnées et ce système peut être mis à l'échelle de n'importe quelle zone d'affichage. Le même fichier SVG peut s'afficher sur 100 pixels de large à un endroit et sur 1000 à un autre, et les deux sont corrects.

Cette différence de philosophie impose une décision lors de la conversion : quelle échelle utiliser pour placer un graphique souple sur une page fixe ?

Le viewBox : le système de coordonnées du SVG

L'attribut viewBox prend quatre nombres :

<svg viewBox="0 0 595 842">

Ce sont, dans l'ordre : minX, minY, largeur, hauteur. Leur sens : « mon contenu est défini dans une zone de 595 unités de large et 842 de haut, à partir du point (0,0) ».

Toutes les coordonnées internes sont exprimées dans ce système. Si un rectangle indique x="100" y="200", c'est dans les coordonnées du viewBox.

Le viewBox n'est pas une mesure physique. Il ne fait que définir le système de coordonnées interne. Ce sont width et height qui déterminent la place réelle qu'occupera ce système.

width/height : la taille d'affichage

<svg width="210mm" height="297mm" viewBox="0 0 595 842">

Dans ce fichier, le contenu est défini dans un système de coordonnées de 595 × 842 unités, et ce système est mis à l'échelle d'une zone de 210 × 297 mm. Une unité utilisateur vaut donc environ 0,353 mm — ce qui correspond exactement à 1 point (1/72 de pouce = 0,3528 mm).

Imaginez maintenant le même contenu avec un width différent :

<svg width="105mm" height="148.5mm" viewBox="0 0 595 842">

Le contenu est identique, mais il est affiché à mi-échelle — au format A5.

L'ambiguïté des unités : la source de problème la plus fréquente

Le problème commence lorsque width et height sont écrits sans unité :

<svg width="595" height="842" viewBox="0 0 595 842">

Cela laisse sans réponse la question « 595 quoi ? ». Deux interprétations existent, avec 33 % d'écart entre elles :

| Interprétation | 1 unité | 595 unités | |---|---|---| | Convention PDF/impression : le point | 1/72 de pouce | 210 mm (largeur A4) | | Convention web/CSS : le pixel | 1/96 de pouce | 157 mm |

Les convertisseurs utilisent généralement l'interprétation en points et donnent le bon résultat. Mais dans les SVG issus du web (produits par une bibliothèque graphique, enregistrés par un outil de navigateur), les valeurs peuvent avoir été produites en supposant des pixels, et le PDF obtenu est alors plus grand que prévu.

Pire encore, quand width/height sont totalement absents :

<svg viewBox="0 0 800 600">

Dans ce cas, le convertisseur devine entièrement. Certains considèrent les valeurs du viewBox comme des points, d'autres les adaptent à une taille de page par défaut, d'autres supposent des pixels CSS.

La solution est simple : avant de convertir le SVG en PDF, ouvrez le fichier dans un éditeur de texte et écrivez les valeurs width et height avec une unité physique :

<svg width="210mm" height="297mm" viewBox="0 0 595 842">

Cette seule modification élimine totalement l'ambiguïté.

preserveAspectRatio : que se passe-t-il en cas de rapports incompatibles

Si le rapport du viewBox ne correspond pas à celui de width/height, c'est l'attribut preserveAspectRatio qui détermine ce qui se passe. Sa valeur par défaut est xMidYMid meet : le contenu est ajusté à la zone en conservant son rapport et centré, laissant des espaces là où il en reste.

La valeur slice fait l'inverse : la zone est entièrement remplie et les parties qui débordent sont rognées.

Dans une conversion PDF, cela se traduit par des marges vides inattendues ou du contenu tronqué. En cas d'incompatibilité, égaliser les rapports du viewBox et de width/height est la solution la plus propre.

Les polices : une différence de philosophie fondamentale

C'est la distinction pratique la plus importante entre les deux formats.

Le PDF intègre les polices. La raison d'être du format est que le document s'affiche partout de la même façon. Le seul moyen de le garantir est de placer dans le fichier les données de tracé des polices utilisées. La police que vous voyez en ouvrant un PDF est celle que le fichier transporte lui-même.

Le SVG ne les intègre généralement pas. Il écrit font-family="Roboto" et s'attend à ce que cette police soit présente dans l'environnement d'affichage. Sur le web, cela se règle par le chargement d'un fichier de police via @font-face en CSS — mais cette information peut se trouver dans le CSS de la page, pas dans le fichier SVG lui-même.

Ce qui se passe à la conversion dépend de la capacité du convertisseur à accéder à cette police :

• S'il y accède : la police est intégrée au PDF, le texte reste du véritable texte. Sélectionnable, consultable, accessible.
• S'il n'y accède pas : le système bascule sur une police approchante. Les chasses de caractères changent, l'alignement se décale, les longues lignes peuvent déborder ou raccourcir.

Le côté sournois du second cas est que le résultat paraît faux mais plausible. Vous ne le remarquez pas au premier regard ; c'est en le plaçant côte à côte avec l'original que vous voyez les alignements décalés.

Solution définitive : convertir les textes en courbes (outline/path) dans le logiciel qui produit le SVG. Chaque caractère devient une forme vectorielle, la dépendance aux polices tombe à zéro. Le prix à payer : le texte n'est plus ni sélectionnable ni consultable.

La couleur : pas de sortie du RVB

Le SVG est nativement en RVB. Vous écrivez fill="#3366CC" ou fill="rgb(51,102,204)". La notion de CMJN n'existe pas.

Le PDF, lui, prend en charge le CMJN, les tons directs et les profils colorimétriques ICC — puisqu'il a été conçu pour l'impression.

Lors d'une conversion de SVG en PDF, les couleurs sont transportées en RVB. Ce n'est pas un problème pour un usage écran, mais c'est une lacune pour un fichier destiné à l'imprimerie : l'imprimeur demande du CMJN et, s'il reçoit un fichier RVB, il effectue lui-même la conversion, avec un résultat pouvant différer de ce que vous voyiez. Les verts vifs, les orangés et les noirs riches ressortent particulièrement de façon inattendue.

Si le travail d'impression est sérieux, il faut convertir en CMJN dans un logiciel de design après la conversion.

Filtres et rastérisation

L'élément <filter> du SVG offre des effets puissants : flou gaussien, ombre portée, matrice de couleurs, éclairage, turbulence.

Le modèle de transparence et d'effets du PDF est différent et la plupart de ces filtres n'ont pas d'équivalent direct.

Le convertisseur a deux options :

1. Utiliser une approximation. C'est possible pour la simple transparence alpha et certains modes de fusion.

2. Rastériser cette zone. La zone filtrée est rendue en image et placée en pixels dans le PDF.

La seconde donne un résultat visuellement correct mais fait perdre la netteté vectorielle. Quand vous zoomez dans le PDF, cette zone se pixellise. À l'impression, elle apparaît comme une zone en basse résolution.

C'est pourquoi, sur les SVG destinés à l'impression, il est plus sûr d'éviter les filtres et d'imiter les ombres et les flous en vectoriel.

Tout ce qui est dynamique est figé

Le SVG est une technologie web, et cela a des conséquences :

| En SVG | En PDF | |---|---| | Animation SMIL | La première image ou l'état initial | | Animation / transition CSS | Figée | | Styles :hover | Non appliqués, l'état normal subsiste | | Contenu généré en JavaScript | Transporté si le convertisseur lit le DOM, non s'il lit le fichier | | <foreignObject> (HTML intégré) | Généralement perdu | | Fichier CSS externe | Peut ne pas être appliqué |

Les deux dernières lignes sont importantes : si votre SVG dépend d'un fichier CSS externe ou de JavaScript, le fichier est incomplet à lui seul. Avant de convertir, il faut intégrer les styles dans le SVG (attributs style en ligne ou bloc <style>).

Ce que l'on y gagne

La conversion n'est pas que perte ; le PDF apporte aussi des choses :

• L'intégration des polices : le fichier se suffit désormais à lui-même.
• Le multipage : plusieurs SVG peuvent être réunis dans un seul document.
• Le contrôle de l'impression : taille de page, orientation et marges sont définies.
• Les propriétés de document : métadonnées, signets et signature numérique deviennent possibles.
• L'ouverture universelle : le fichier se comporte comme attendu sur tous les appareils.

En résumé

Le SVG travaille dans un système de coordonnées souple et relatif ; le PDF repose sur une logique de page fixe et physique. La plupart des problèmes de conversion naissent de cette différence : lorsque l'unité de width/height n'est pas précisée, la taille de page relève de la devinette (l'ambiguïté entre point et pixel crée 33 % d'écart), les polices n'étant pas intégrées au SVG, le résultat dépend de l'accès du convertisseur à celles-ci, les couleurs ne peuvent pas sortir du RVB, et les filtres complexes entraînent une rastérisation qui fait perdre la netteté vectorielle. Tous ces problèmes peuvent être réglés en amont : écrivez des unités physiques, convertissez les textes en courbes, évitez les filtres, et si le fichier part à l'impression, planifiez la conversion colorimétrique comme une étape distincte.