Wikipedia:Probleme mit SVGs

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche


Frequently Asked Questions zur SVG-Erstellung für die Wikipedia

Bei der Herstellung von SVG-Dateien gibt es einige wiederkehrende Probleme. Diese rühren meist daher, dass zur Anzeige die SVG-Dateien meist umgewandelt werden. Einige der Probleme und deren Lösungen sind im folgenden dargestellt.

Hast du eine Frage zu SVG-Grafiken, die hier noch nicht aufgeführt ist, wende dich an das WikiProjekt SVG oder an die Wikipedia:Grafikwerkstatt. Allgemeine Fragen zu Inkscape werden auch in der Inkscape-FAQ beantwortet.

Neue Antworten können über diesen Link eingetragen werden.

Abkürzung: WP:PMS

Lies diesen Abschnitt zuerst[Bearbeiten]

Diese Seite baut auf dem Informationsstand der allgemeinen Hinweise für SVG-Autoren auf und setzt diesen als problembezogene Erweiterung voraus.

Diamond-caution.svg
Kennzeichnen: Jede SVG-Datei die auf Wikimedia Commons hochgeladen wird, sollte zeigen:
  • Wie sie erstellt wurde: benutze Vorlagen wie {{Inkscape}}, {{Adobe}}, {{HandSVG}} oder was auch immer.
    Mit Inkscape oder Adobe Illustrator erstellte Dateien sollten vor dem Hochladen ggf. als „Normales“ (oder „Optimiertes“) SVG abgespeichert werden (das vermeidet bereits einige kleinere Fehler).
  • Ob sie W3C-valid oder -invalid ist: setze den entsprechenden Parameter für die Vorlage, z. B. {{Inkscape|v}}.
    Dazu sollte die Datei mit dem W3C-Validator (einem Testtool u. a. für SVG) geprüft werden.
Für genauere Prüfung der Anzeige und der Validität kann die SVG vor dem Hochladen mit SVG Check getestet werden (mehr dazu auf Commons:SVG Check).
Wenn du dir nicht sicher bist (SVG Check deckt z. B. nicht alle Schriften und Auflösungen ab) und zuerst sehen willst wie libRSVG die Datei tatsächlich rendern wird, laden sie unter Datei:Test.svg hoch.
i Info: Mit der Aktualisierung vom 24.10.2012 (Serverupdate auf Ubuntu 12.04) wurden die Server, die für die Erstellung der Thumbnails zuständig sind (Imagescaler), mit dem entsprechend aktualisierten Programm libRSVG (2.36) umgestellt. Auf der einen Seite sollten damit so manche Fehler behoben sein, auf der anderen Seite kann es auch zu neuen Fehlern kommen. Daher ist die Liste ggf. zu aktualisieren (wikitech-Mailingliste: New Imagescaler disto/packages) Anm.: Evtl. entfernte Bugs können in der Version vom 24.10.2012 eingesehen werden.

Wieso gibt es überhaupt Probleme?[Bearbeiten]

SVG-Dateien werden von MediaWiki nicht direkt angezeigt sondern immer dann, wenn diese auf einer Seite eingebunden werden, in PNG-Dateien umgewandelt. Der Grund dafür ist, dass einige Browser SVG-Dateien nicht direkt anzeigen und einige sie nicht skalieren können. Für das SVG-Rendering wird eine angepasste und beschränkte, zuweilen fehlerbehaftete Version der Programmbibliothek libRSVG verwendet (die ursprünglich nur für Icons vorgesehen war). Auch der Bildbetrachter Eye of Gnome benutzt libRSVG, und wer in der Lage ist, sich dieses unter Linux verbreitete Programm mit der richtigen libRSVG-Version zu installieren, kann damit vor dem Hochladen feststellen, was alles falsch dargestellt wird (mehr dazu auf WP:SVG #Dateien zu Hause testen).

Text[Bearbeiten]

Warum wird meine gewünschte Schrift nicht angezeigt?[Bearbeiten]

Einige installierte Schriften

Für den Renderer ist es wichtig, dass die Schriften, die er anzeigen soll, auch auf dem Server installiert sind. Eine Liste der für Wikimedia-Seiten verwendbaren Schriften findet sich unter meta:SVG fonts.

Das direkte Einbetten von Schriftdefinitionen als SVG-Fonts kann der Renderer leider ebenfalls nicht verarbeiten. Wer unbedingt andere Schriften darstellen will, dem bleibt nichts anderes übrig, als sie in Pfade umzuwandeln. Siehe dazu auch: WP:SVG #Schriftarten in extrahierten Vektordaten.

Zu beachten ist auch, dass die installierten Schriften nicht einheitlich geglättet und skaliert werden. Die Unterschiede treten vor allem bei kleinen Größen in Erscheinung. Teilweise kommt es bei Verkleinerung zu Überlappungen. Falls das passiert, kann man die Abstände erhöhen oder eine andere Schriftart nehmen. Eine Veranschaulichung der Unterschiede bietet diese Grafik, vor allem in der Vergrößerung[1] sind die schlecht skalierbaren Fonts zu erkennen (nicht zu empfehlen sind z. B. Times und Courier; Aktualität ohne Gewähr). Siehe auch Abschnitt: „#Die Abstände von Buchstaben stimmen nicht

Als weitere Ursache kommt die fehlende Interpretation des Schriftnamens („font-family“) in (meist einfachen) Anführungszeichen in Frage, welche eigentlich (bei Namen mit Leerzeichen, Ziffern oder Satzzeichen außer Bindestrich, sowie möglicher Weise gleichen Wert reservierter Schlüsselwörter) vom W3C generell empfohlen werden (Bugzilla:62987).[1]

Anm.:

  • LibRSVG unterstützt nicht die CSS 2 „shorthand font“-Eigenschaft (Bugzilla:41425).
  • Inkscape V.0.48 unterstützt keine „Fallback-Fonts“, so dass die SVG-Datei nach dem Speichern in einem Text-Editor manuell aktualisiert werden muss.

Warum wird mein Text nicht dargestellt?[Bearbeiten]

Schlechtes SVG mit Textrahmen
Korrektes SVG ohne Textrahmen

Man darf keine Textrahmen (in Inkscape „Fließtext“ / „Flowing text“ genannt) verwenden, sondern „nur“ einfache Texte, die man in Inkscape mit einem einfachen Klick setzt und sofort lostippt (Bugzilla:41424). Wenn man dagegen einen Rahmen aufzieht und Text dort einfügt, erhält man als Ergebnis statt des Textes schwarze Flächen oder der Text erscheint gar nicht. Fließtextfelder machen, wie der Name bereits andeutet, automatisch Zeilenumbrüche, wenn eine Zeile nicht in den vordefinierten Rahmen passt. In normalen Textfeldern können Zeilen mit der Eingabetaste umbrochen werden.

Auf SVG-Dateiebene werden in diesem Fall die ab SVG-Version 1.2 vorgesehenen englisch Flowing-Text-And-Graphics[2] Elemente in der Form wie folgt abgelegt:

  <flowRoot
     ...>
   ...
  </flowRoot>

Insbesondere bei leeren Textfeldern kann es passieren, dass diese Elemente von Inkscape in Folge nicht mehr einfach ausgewählt und gelöscht werden können. Zum Konvertieren eines Flowing-Textfeldes in ein normales Textfeld, gehe ins „Text“-Menü und wähle „Convert to Text“. Wenn dies immer noch nicht funktioniert, ist es in diesen Fällen am einfachsten, den integrierten XML-Editor (Shift-Ctrl-X) (oder einem Texteditor) zu öffnen und alle (hier verwaisten) flowRoot-Elemente zu löschen.

Ebenfalls an einem Pfad ausgerichteter Text wird unter Umständen (z. B. mit entspr. Editor wie Inkscape) in flow-Elemente gesetzt. → Siehe hierzu: „#An Pfad ausgerichteter Text

Warum werden (anstatt Text, schwarze) Balken angezeigt?[Bearbeiten]

Siehe Abschnitt: „#Warum wird mein Text nicht dargestellt?

Die Schrift ist an eine andere Position verschoben[Bearbeiten]

Korrekt einzeln positionierte Buchstaben
Falsche Darstellung: nur die Unterlänge des „g“ ragt oben links in das Bild hinein

Im SVG-Standard ist es möglich, jeden Buchstaben innerhalb einer Zeichenkette einzeln zu positionieren, indem man für jeden eine x- und y-Position als Liste angibt (Kerning und Shifting, diese Art der Positionierung geschieht meist beim PDF-Import). Das sieht dann etwa so aus:

  <text
     x="50 70 90 110"
     y="50 52 48 46"
     style="font-size:24px;font-family:Sans-serif">efgh</text>

Der MediaWiki-Renderer versteht diese Syntax nicht (das gleiche gilt für die entsprechenden relativen Attribute dx und dy, Bugzilla:33245). Die Koordinaten-Attribute x / y (bzw. dx / dy) dürfen jeweils nur einen Wert enthalten, sonst werden sie angezeigt, als ob beide Werte gleich Null sein. (Das hat zur Folge, dass bei y=0 die Zeichen oberhalb des Bildrandes erscheinen und abgeschnitten werden.)

Unter Inkscape kann diese entsprechende „Text-Manipulation“ mit der Funktion: ‹Text› – ‹Manuelle Unterschneidung entfernen› einfach egalisiert werden.

Zur Korrektur bei größeren Quelltext bietet sich auch ein RegExp-fähiger Texteditor an. Wenn die erste Nummernangabe die maßgebliche ist (also nur für zusammenhängenden Text, weit auseinanderliegender Text müsste entweder händisch neu positioniert oder im Texteditor per zwischengefügter <tspan's getrennt werden), könnte der Suchausdruck (z. B. bei Notepad++) folgendermaßen aussehen: ( [xy]="[-0-9.]*) [-0-9. ]*"Ersetzung: \1"

Die Abstände von Buchstaben stimmen nicht[Bearbeiten]

Alle Textschnipsel sollten gleich dargestellt werden

Der MediaWiki-Renderer macht manchmal Fehler bei der Berechnung von Buchstabenabständen. Dabei sind besonders solche Buchstabenfolgen betroffen, bei denen in der zu Grunde liegenden Schrift eine Unterschneidung definiert ist (Bugzilla:34947). Der Effekt ist umso ausgeprägter, je kleiner die Schrift definiert wurde.

Der Effekt kann verhindert werden, wenn vor dem <text>-Element Grafikelemente wie <rect> und <line> aufgerufen werden.[Beispiel?]

Eine besondere Variante ist, im Text-Element <tspan> mit vorgestelltem Leerzeichen einzufügen.[Beispiel?] Eventuell wird auch die Position des Textes verschoben. Dies kann mit dx und dy innerhalb von <tspan> korrigiert werden.

Ein weiteres Gegenmittel ist, statt

<text font-size="5px">Beispieltext</text>

erzeugt die spätere Verkleinerung einer ursprünglich großen Textdarstellung

<g transform="scale(0.2)"><text font-size="25px">Beispieltext</text></g>

eine deutlich verbesserte Platzierung der einzelnen Glyphen.

Lädt man die nebenstehende Testgrafik direkt in einem Browser, der SVG darstellen kann, kann man übrigens gut sehen, dass viele Browser die Unterschneidungsdefinitionen und Ligaturen aus den Schriftdateien nicht berücksichtigen.

Als weitere bizarre Ursache kommen (jegliche Art von per transform) stark herunterskalierter Grafik-Objekten in Frage, die im Quellcode vor dem Text liegen (Bugzilla:63703). Der Effekt ist umso ausgeprägter, je kleiner das Objekt skaliert wurde.

Anmerkung: Die Eigenschaft ‘letter-spacing[3] wird unterstützt, von manchen modernen Browsern wie Firefox jedoch nicht (Bugzilla 371787[4]).

Hoch- und tiefgesteller Text[Bearbeiten]

Text-Shifting mittels dy

Die CSS-Grundlinienverschiebung (baseline-shift) Superscript and Subscript wird vom Renderer nicht unterstützt.(Bugzilla:5792) (Jedoch selbst von aktuellen Browsern wie Firefox Mozilla Bug 308338 und IE11 msdn.microsoft nicht) Alternativ kann jedoch einfach die SVG-Buchstaben-Unterschneidung mittels vertikalem Versatz durch die Attribute y (gleich y-Koordinate in der translation Angabe) oder (relativ) dy verwendet werden. (Inkscape hat hier volle Unterstützung. Normaler Weise können diese eine Liste von Werten enthalten, der Renderer unterstützt jedoch nur einen Einzel-Wert, siehe #Die Schrift ist an eine andere Position verschoben.)

<svg xmlns="http://www.w3.org/2000/svg" width="350" height="160">
  <text y="60" x="20" style="font-size:24px;font-family:sans-serif">
    <tspan>Normaler Text<tspan style="font-size:65%;baseline-shift:sub">tiefgestellter Text</tspan></tspan>
  </text>
  <text y="120" x="20" style="font-size:24px;font-family:sans-serif">
    <tspan>Normaler Text<tspan dy="5.15" style="font-size:65%;">tiefgestellter Text</tspan></tspan>
  </text>
</svg>

Hier wurde style="baseline-shift:sub" durch einen simplen vertikalen (relativen) Versatz (dy="5.15") ersetzt.[5]

Equivalent verhält es sich mit der Schriftdehnung (font-stretch), die selbst von modernen Browser nicht komplett unterstützt wird, jedoch durch den Workaround der Stretch-/Objekt-Transformation (scale) ersetzt werden kann.

An Pfad ausgerichteter Text[Bearbeiten]

Das entspr. Element <textPath> wird derzeit nicht unterstützt (Bugzilla:9420).

Als Workaround bietet sich eine Ausrichtung der einzelnen Textzeichen an (z. B. mit Adobe Illustrator automatisch möglich), oder wenn der Textpfad eine Gerade ist, kann der Text auch normal über das Attribut transform positioniert/rotiert werden. Als letztes aber adäquates Mittel bietet sich an den Text selbst in Pfade umzuwandeln (was jedoch eine Reihe von Nachteilen mit sich bringt).

Warum hat mein Bild durch den Pfad feine Linien?[Bearbeiten]

Auch wenn zwei Pfad-Knoten genau an derselben Stelle sind, erscheint beim Renderer (in bestimmten Auflösungen) eine Spalte (hairline, jedoch auch in manchen aktuellen Browsern Bugzilla:18936). Hier gibt es in Inkscape eine Funktion ‹Pfad›–‹Vereinigung› (Strg++), welche die übereinanderliegenden Knoten zu einem Knoten vereint. Selbst wenn sich zwei Objekte überlappen, kann dieser Effekt auftreten, sobald der Bereich in der skalierten Renderung 1px unterschreitet.

Die Quadrate sind eigentlich ganz aneinander.
Selbes Bild 2px größer

Warum wird meine SVG nicht angezeigt?[Bearbeiten]

Vermutlich hast du den Verweis auf eine Bitmapgrafik in der SVG vergessen. Solche mag der Renderer gar nicht, sie müssen unbedingt entfernt werden, d. h. nicht nur unsichtbar sein. Wenn du also eine Pixelgrafik nachzeichnest oder als Referenz nutzt, denke immer daran, diese vor dem Hochladen aus der SVG zu löschen.

Ich habe eine Bitmapgrafik direkt eingebunden, aber es funktioniert trotzdem nicht[Bearbeiten]

Einbinden heißt im Unterschied zu Verweisen (siehe vorherige Frage), dass der Code für die Bitmapgrafik direkt in der SVG-Datei abgespeichert wird. Leider ist auch das keine Garantie dafür, dass die Datei korrekt angezeigt wird. Folgende Fehlerquellen sind möglich (vermutlich keine vollständige Liste):

  1. Das eingebundene Bitmap ist eine JPEG-Datei. Der Renderer kann aber nur PNG-Dateien darstellen.
  2. Nur für Grafiken, die mit Inkscape erstellt wurden: Wenn man das Verhältnis von Höhe zu Breite eines Bitmaps ändert, speichert Inkscape das auf eine Art und Weise, die nicht standardkonform ist. Andere Renderer, die korrekt arbeiten, zeigen deshalb möglicherweise das unverzerrte Bild. Um das Auftreten eines Fehlers zu vermeiden, sollte man auf das Bitmap nach dem Einbetten als allererstes den Befehl Objekt → Gruppieren anwenden, und nur diese Gruppe verschieben und skalieren.

Warum werden Transparenzen der SVG als weißer Hintergrund dargestellt?[Bearbeiten]

Das liegt in der Regel nicht an einem SVG-Fehler, sondern an PNG-Renderfehlern deines Browsers. Der Microsoft Internet Explorer kann bis einschließlich der Version 6 Transparenzen in PNG-Dateien nicht richtig darstellen.

Folgendes Beispiel zeigt ein SVG-Bild (c-Symbol), das teilweise transparent ist, vor einem grünen Hintergrund. Das SVG wird als PNG ausgeliefert. Die unterschiedliche Darstellung in IE und Firefox sind auf dem Bild rechts zu sehen:

links Firefox 2.0.0.13, rechts IE 6.0
Green copyright.svg

Kann ich die Darstellung mit CSS steuern?[Bearbeiten]

Systematischer Test verschiedener CSS-Methoden

Während der Eintrag von style-Eigenschaften in Objekte und Gruppen ein zentraler Mechanismus für die Darstellung von SVGs ist, ist die Verwendung von eingebetteten CSS am Beginn des Dokuments mit Vorsicht zu genießen. So unterstützt der MediaWiki-Renderer u.a. keine CSS Kind-Selektoren (child selectorBugzilla:41423).

Bei fehlerfreier Funktion des Renderers sollten in der Abbildung rechts alle Beispiele gleich aussehen (also sechs rote Kreise, sechs blaue Quadrate und der Text im gleichen Stil).

[Ggf. sind hier weitere Beispiele notwendig, da das Bsp. nur einen Bug zeigt]

Wie kann ich die Hintergrundfarbe setzen?[Bearbeiten]

SVGs verfügen weder über einen Hintergrund noch über Hintergrundfarbe als Eigenschaft der Grafik (im Gegensatz zu CSS in HTML, das Gleiche gilt für Text). Ein farbiger, nicht-transparenter Hintergrund wird daher bei SVGs durch ein farbiges Rechteck in Größe der Grafik erreicht.

<rect width="100%" height="100%" fill="#A8F"/>

Anmerkung: Mit Hilfe des Online-Tools „in[k]firmary(von Benutzer:Connum) lässt sich unter anderem optional, automatisch eine Hintergrundfarbe festlegen.

Ein verkleinertes Vorschaubild sieht ganz anders aus als das Originalbild[Bearbeiten]

Der Renderer hat Schwierigkeiten, skalierte Vorschaubilder zu produzieren, wenn Filterfunktionen verwendet werden, wie z. B. bei bestimmten Weichzeichnern. So kann z. B. die Breite und Position von GaussianBlur-Filtern (feGaussianBlur) mit der Größe des PNG-Vorschaubildes deutlich variieren, oder bei kleinen Thumbnails wird die Filterfunktion gar nicht mehr ausgeführt. Beispielsweise ist in nachfolgender Galerie fünfmal die gleiche SVG-Datei dargestellt, mit jeweils einer unterschiedlichen Renderingauflösung. Bei fehlerhaftem Rendering wird erst ab der Auflösung von 50 Pixel oder mehr die Abbildung korrekt dargestellt.

46 Pixel 48 Pixel 60 Pixel 80 Pixel 100 Pixel
Audacity Logo.svg Audacity Logo.svg Audacity Logo.svg Audacity Logo.svg Audacity Logo.svg

Insgesamt sollte der Einsatz von Filterfunktionen sehr vorsichtig erfolgen. Dabei sollte auch immer bedacht werden, dass bei der direkten Anzeige von SVGs im Browser noch weitere Fehler auftauchen können, da nicht alle diese überhaupt darstellen können.

Anmerkung: Der Fehler tritt vor allem bei einem niedrigem Wert auf (wenn im Ergebnis unter einem Pixel, Gnome Bug 605875)

Pfad-Objekte werden abstrakt oder verschoben dargestellt[Bearbeiten]

Als reguläre Abkürzung können optional bei numerischen Koordinaten (coordinate values) von Pfaden (<path d="<path-data>") führende Nullen (leading zeroes) vor der Dezimalkommastelle („.“ decimal point) weggelassen werden, was keinen Verstoß gegen einen Standard darstellt und normalerweise kein Problem bereitet (siehe auch signifikante Stellen), jedoch von libRSVG nicht interpretiert und gerendert werden kann (Gnome Bug 620565, Gnome Bug 620923 ). Abhilfe kann hier das Speichern mit einer im entsprechenden Programm möglichen Option zur (Abwärts-)Kompatibilität sein. Falls nicht, ist ein Fix mittels RegExp möglich (Bsp. hier mit Unix Stream Editor):

sed 's/\([ -]\)\([.][0-9]\)/\10\2/g'

Siehe auch[Bearbeiten]

WikiMedia WikiMedia: Librsvg development funding (engl.)

Meta-Wiki: SVG image support – MetaWiki (engl. historical information)

Einzelnachweise[Bearbeiten]

  1. W3C Recommendation (07 June 2011): Font family: the ‘font-family’ property (CSS 2.1) Specification – Fonts
  2. Flowing text and graphics, W3 SVG1.2 Draft
  3. W3C SVG Text: Spacing properties – letter-spacing
  4. SVG in Firefox: Element implementation status
  5. Die 5.15 Pixel im Beispiel ergeben sich gerundet durch die Rechnung Schrifthöhe * 33 %, d.h. 24 px * 65 % * 33 % = 5.148 px