Was ändert sich beim Wechsel von SVG zu PDF? viewBox, Einheiten und Schriftlogik

SVG ist ein Webgrafikformat: flexibel, skalierbar, an den Bildschirm anpassbar. PDF ist dagegen ein Seitenformat: fest, physisch, an den Druck gebunden. Auch wenn beide dasselbe Vektorzeichenmodell teilen, hat dieser Unterschied in der Grundhaltung konkrete Folgen für die Umwandlung. In diesem Beitrag erklären wir diese Unterschiede und warum manche SVGs in unerwarteten Größen nach PDF gewandelt werden.

Zwei verschiedene Auffassungen von "Seite"

In PDF ist die Seite physisch. Jedes Seitenobjekt hat eine MediaBox, und diese ist ein festes Rechteck in Punkt. Eine A4-Seite misst 595 × 842 Punkt, immer und überall. Der Inhalt wird unmittelbar in dieses Koordinatensystem gesetzt. Ein Konzept "an den Bildschirm anpassen" gibt es nicht – der Betrachter zoomt, doch die Seite selbst ändert sich nicht.

In SVG ist die "Seite" relativ. Ein SVG hat keine natürliche Größe; der Inhalt ist in einem Koordinatensystem definiert, und dieses System lässt sich auf jede beliebige Anzeigefläche skalieren. Dieselbe SVG-Datei kann an einer Stelle 100 Pixel und an einer anderen 1000 Pixel breit dargestellt werden, und beides ist richtig.

Dieser Unterschied in der Grundhaltung erzwingt bei der Umwandlung eine Entscheidung: Welcher Maßstab wird verwendet, wenn eine flexible Grafik auf eine feste Seite gesetzt wird?

viewBox: das Koordinatensystem von SVG

Das Attribut viewBox nimmt vier Zahlen entgegen:

<svg viewBox="0 0 595 842">

Der Reihe nach: minX, minY, Breite, Höhe. Die Bedeutung: "Mein Inhalt ist in einer Fläche definiert, die am Punkt (0,0) beginnt und 595 Einheiten breit sowie 842 Einheiten hoch ist."

Alle inneren Koordinaten werden in diesem System ausgedrückt. Steht bei einem Rechteck x="100" y="200", so gilt das in viewBox-Koordinaten.

Die viewBox ist kein physisches Maß. Sie definiert nur das innere Koordinatensystem. Wie viel Platz dieses System tatsächlich einnimmt, bestimmen width und height.

width/height: die Anzeigegröße

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

In dieser Datei ist der Inhalt in einem Koordinatensystem von 595 × 842 Einheiten definiert, und dieses System wird auf eine Fläche von 210 × 297 mm skaliert. Eine Benutzereinheit entspricht damit etwa 0,353 mm – und das ist genau ein Punkt (1/72 Zoll = 0,3528 mm).

Denken Sie sich nun denselben Inhalt mit einer anderen width:

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

Der Inhalt ist derselbe, wird aber in halbem Maßstab dargestellt – im Format A5.

Uneindeutige Einheiten: die häufigste Problemquelle

Das Problem beginnt, wenn width und height ohne Einheit geschrieben werden:

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

Das lässt die Frage "595 was?" unbeantwortet. Es gibt zwei Auslegungen, und zwischen ihnen liegen 33 % Unterschied:

| Auslegung | 1 Einheit | 595 Einheiten | |---|---|---| | Konvention von PDF/Druck: Punkt | 1/72 Zoll | 210 mm (A4-Breite) | | Konvention von Web/CSS: Pixel | 1/96 Zoll | 157 mm |

Konverter verwenden meist die Punkt-Auslegung und liefern damit das richtige Ergebnis. Doch bei SVGs aus dem Webumfeld (von einer Diagrammbibliothek erzeugt, von einem Browserwerkzeug gespeichert) können Werte stecken, die unter der Pixelannahme entstanden sind – und dann fällt das entstehende PDF größer aus als erwartet.

Noch schlimmer ist es, wenn width/height ganz fehlen:

<svg viewBox="0 0 800 600">

In diesem Fall rät der Konverter vollständig. Manche rechnen die viewBox-Werte als Punkt, manche passen den Inhalt an eine Standardseitengröße an, manche nehmen CSS-Pixel an.

Die Lösung ist einfach: Öffnen Sie die Datei vor der Umwandlung nach PDF in einem Texteditor und schreiben Sie die Werte von width und height mit einer physischen Einheit:

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

Diese eine Änderung beseitigt die Mehrdeutigkeit vollständig.

preserveAspectRatio: was bei abweichenden Verhältnissen geschieht

Weichen das Verhältnis der viewBox und das von width/height voneinander ab, bestimmt das Attribut preserveAspectRatio, was geschieht. Der Standardwert lautet xMidYMid meet: Der Inhalt wird unter Wahrung seines Verhältnisses in die Fläche eingepasst und zentriert, an den übrigen Stellen bleibt Freiraum.

Der Wert slice bewirkt das Gegenteil: Die Fläche wird vollständig gefüllt, überstehende Teile werden abgeschnitten.

Bei der PDF-Umwandlung zeigt sich das als unerwartete leere Ränder auf der Seite oder als abgeschnittener Inhalt. Besteht eine Abweichung, ist es die sauberste Lösung, die Verhältnisse von viewBox und width/height anzugleichen.

Schriften: der grundlegende Unterschied in der Haltung

Das ist die wichtigste praktische Unterscheidung zwischen beiden Formaten.

PDF bettet Schriften ein. Der Daseinsgrund des Formats ist, dass ein Dokument überall gleich aussieht. Der einzige Weg, das zu garantieren, besteht darin, die Zeichendaten der verwendeten Schriften in die Datei zu legen. Die Schrift, die Sie beim Öffnen eines PDFs sehen, ist die Schrift, die die Datei selbst mitbringt.

SVG bettet meist nicht ein. Es schreibt font-family="Roboto" und erwartet, dass diese Schrift in der Anzeigeumgebung vorhanden ist. Im Web wird das durch das Laden einer Schriftdatei per CSS @font-face gelöst – doch diese Information kann im CSS der Seite und nicht in der SVG-Datei selbst stehen.

Was bei der Umwandlung geschieht, hängt davon ab, ob der Konverter auf diese Schrift zugreifen kann:

• Kann er es: Die Schrift wird in das PDF eingebettet, und der Text bleibt echter Text. Markierbar, durchsuchbar, zugänglich.
• Kann er es nicht: Es wird auf eine ähnliche Schrift zurückgegriffen. Die Zeichenbreiten ändern sich, die Ausrichtung verrutscht, lange Zeilen können überlaufen oder kürzer werden.

Das Heimtückische am zweiten Fall ist, dass das Ergebnis falsch, aber plausibel aussieht. Auf den ersten Blick bemerken Sie es nicht; erst im Vergleich mit dem Original sehen Sie, dass die Ausrichtungen verrutscht sind.

Die sichere Lösung: die Texte im erzeugenden Programm in Pfade (Outlines) umwandeln. Jeder Buchstabe wird zu einer Vektorform, die Schriftabhängigkeit entfällt vollständig. Der Preis ist, dass der Text nicht mehr markierbar und durchsuchbar ist.

Farbe: kein Weg aus RGB heraus

SVG ist von Natur aus RGB-basiert. Sie schreiben fill="#3366CC" oder fill="rgb(51,102,204)". Ein Konzept CMYK gibt es nicht.

PDF unterstützt dagegen CMYK, Schmuckfarben und ICC-Farbprofile – weil es für den Druck entworfen wurde.

Bei der Umwandlung von SVG nach PDF werden die Farben als RGB übernommen. Für den Bildschirmeinsatz ist das kein Problem, für eine Datei, die in den Druck geht, jedoch ein Mangel: Die Druckerei verlangt CMYK, und erhält sie eine RGB-Datei, nimmt sie die Umwandlung selbst vor – das Ergebnis kann sich von dem unterscheiden, was Sie gesehen haben. Besonders kräftige Grüntöne, Orangetöne und satte Schwarztöne fallen unerwartet aus.

Steht ein ernsthafter Druckauftrag an, muss nach der Umwandlung in einem Gestaltungsprogramm nach CMYK gewandelt werden.

Filter und Rasterung

Das SVG-Element <filter> bietet mächtige Effekte: Gaußschen Weichzeichner, Schatten, Farbmatrix, Beleuchtung, Turbulenz.

Das Transparenz- und Effektmodell von PDF ist anders, und die meisten dieser Filter haben keine unmittelbare Entsprechung.

Der Konverter hat zwei Möglichkeiten:

1. Eine annähernde Entsprechung verwenden. Bei einfacher Alphatransparenz und einigen Mischmodi ist das möglich.

2. Diesen Bereich rastern. Die gefilterte Fläche wird in ein Bild gerendert und als Pixel ins PDF gesetzt.

Die zweite Variante liefert das optisch richtige Ergebnis, lässt aber die Vektorschärfe verloren gehen. Zoomen Sie im PDF hinein, wird dieser Bereich pixelig. Im Druck erscheint er als Fläche mit niedriger Auflösung.

Deshalb ist es bei SVGs, die in den Druck gehen, sicherer, auf Filter zu verzichten und Schatten- sowie Weichzeichnungseffekte als Vektoren nachzubilden.

Alles Dynamische wird festgeschrieben

SVG ist eine Webtechnologie, und das hat Folgen:

| In SVG | Im PDF | |---|---| | SMIL-Animation | Das erste Einzelbild oder der Ausgangszustand | | CSS-Animation / -Übergang | Wird festgeschrieben | | :hover-Stile | Werden nicht angewendet, der Normalzustand bleibt | | Per JavaScript erzeugter Inhalt | Wird übernommen, wenn der Konverter das DOM liest; nicht, wenn er die Datei liest | | <foreignObject> (eingebettetes HTML) | Geht meist verloren | | Externe CSS-Datei | Wird womöglich nicht angewendet |

Die letzten beiden Punkte sind wichtig: Hängt Ihr SVG von einer externen CSS-Datei oder von JavaScript ab, ist die Datei für sich genommen unvollständig. Vor der Umwandlung müssen die Stile in das SVG eingebettet werden (als Inline-style-Attribute oder als <style>-Block).

Was gewonnen wird

Bei der Umwandlung verlieren Sie nicht nur; PDF bringt auch etwas mit:

• Schrifteinbettung: Die Datei ist nun in sich vollständig.
• Mehrere Seiten: Mehrere SVGs lassen sich in einem Dokument sammeln.
• Druckkontrolle: Seitengröße, Ausrichtung und Ränder sind definiert.
• Dokumenteigenschaften: Metadaten, Lesezeichen und digitale Signaturen werden möglich.
• Universelle Öffenbarkeit: Es verhält sich auf jedem Gerät erwartungsgemäß.

Zusammengefasst

SVG arbeitet in einem flexiblen, relativen Koordinatensystem; PDF beruht auf einer festen, physischen Seitenlogik. Die meisten Probleme bei der Umwandlung entspringen diesem Unterschied: Fehlt bei width/height die Einheit, bleibt die Seitengröße dem Raten überlassen (die Unterscheidung Punkt oder Pixel macht 33 % aus), Schriften sind in SVG nicht eingebettet und hängen daher vom Zugriff des Konverters ab, Farben kommen nicht aus RGB heraus, und komplexe Filter führen zur Rasterung und damit zum Verlust der Vektorschärfe. All diese Probleme lassen sich vorab lösen: physische Einheiten angeben, Texte in Pfade umwandeln, auf Filter verzichten und bei geplantem Druck die Farbumwandlung als eigenen Schritt einplanen.