Wikipedia:Probleme mit SVGs

Häufig gestellte Fragen 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 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. Ausführliche Erläuterungen zu SVG-Dateien gibt es auch auf der Hilfeseite in den Commons. Allgemeine Fragen zu Inkscape werden auch in der Inkscape-FAQ beantwortet. Neue Antworten können über diesen Link eingetragen werden.

Aktuell: Seit 2016 wird Text in SVG nur sehr bedingt mit richtigem Zeichenabstand dargestellt. Der Bug phab:T36947 besteht schon immer, jedoch nicht so extrem. Eine Lösung (Workaround) ist folgendem Abschnitt zu entnehmen:

→ #Die Abstände von Buchstaben stimmen nicht

Für eine 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.

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.

Wieso gibt es überhaupt Probleme?

SVG-Dateien werden von MediaWiki nicht direkt dargestellt, sondern immer dann, wenn diese auf einer Seite eingebunden werden, in PNG-Dateien umgewandelt. Der Grund dafür war zunächst, dass einige Browser SVG-Dateien nicht direkt anzeigen oder skalieren konnten, allerdings sind die Gründe heutzutage tatsächlich vielschichtiger, siehe phab:SVG client side rendering (T5593). 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

Warum wird meine gewünschte Schrift nicht angezeigt?

Alle 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 (phab:T64987 (Bugzilla:62987)).

Anm.:

• LibRSVG unterstützt nicht die CSS 2 „shorthand font“-Eigenschaft (phab:T43425 (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?

Schlechtes SVG mit Textrahmen

Korrektes SVG ohne Textrahmen

Dafür können mehrere Ursachen in Frage kommen: In Inkscape darf man keine Textrahmen („Fließtext“ / „Flowing text“ genannt) verwenden, sondern „nur“ einfache Texte, die man in Inkscape mit einem einfachen Klick setzt und sofort lostippt (phab:T43424 (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 in SVG-Version 1.2 vorgesehenen englisch Flowing-Text-And-Graphics (die nur ein Vorschlag und nie ein Standard waren) 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 „In normalen Text umwandeln“ (Convert to Text) bzw. „Fließtext aufheben“. 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“

Des Weiteren wird die Text-Eigenschaft text-size im Bezug auf relative Angaben smaller/larger nicht unterstützt (phab:T88833).

Als weitere Ursache kommt eine „Manuelle Unterschneidung“ in Frage, siehe Abschnitt: „#Warum ist mein Text verschoben (verschwunden)?“

Warum ist mein Text verschoben (verschwunden)?

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, phab:T35245 (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 wären. (Das hat zur Folge, dass bei y="0" die Zeichen oberhalb des Bildrandes erscheinen und abgeschnitten werden, oder unter Umständen ganz verschwinden, siehe weiteres Bsp.)

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., ]*" ⇒ \1"

Als weitere – aber eher seltene – Ursache (evtl. in Verbindung mit ChemDraw) kommt ein Verhalten bei horizontal ausgerichteten Text (middle/end) mit tspan-Elementen in Frage. Diese (bis auf das Letzte) dürfen keine absoluten x-Werte enthalten, da ansonsten das text-anchor-Attribut ignoriert wird (phab:T97233 – wahrscheinlich gilt das Gleiche für vertikal ausgerichteten Text).

Die Abstände von Buchstaben stimmen nicht

Gemeldet in Phabricator
Task T36947 Open

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 (phab:T36947 (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>

eine größere Schriftgröße zu setzen, bei (individuell) gleichzeitiger Verkleinerung der Textdarstellung

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

erzeugt eine deutlich verbesserte Platzierung der einzelnen Glyphen. Optimal scheint hier ein Wert >72px (siehe Grafik rechts).

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 (phab:T65703 (Bugzilla:63703)). Der Effekt ist umso ausgeprägter, je kleiner das Objekt skaliert wurde.
• Für einen ähnlichen Effekt können auch die als Liste gesetzten x-, y-Positionsangaben für Textzeichen in Frage kommen, siehe obigen Abschnitt: „#Die Schrift ist an eine andere Position verschoben“.
• Zudem hat sich gezeigt, dass tspan-Elemente mit einem Zeilenumbruch im XML-Code den Bug abmildern.^[r] Also ist es nicht ratsam diese Einrückung in betr. SVG (mit einem Cleaner o.dgl.) zu entfernen.
• Bei unerwarteten Größen, siehe obigen Abschnitt: „#Warum wird meine Lieblingsschrift nicht angezeigt?“

Anm.: Die Eigenschaft ‘letter-spacing’ wird unterstützt, von manchen modernen Browsern wie Firefox jedoch nicht (Mozilla Bug 371787).

Hoch- und tiefgesteller Text

• Inkscape-Icons
• 
• 

Text-Shifting mittels dy

Die aus HTML und CSS bekannte Grundlinienverschiebung (baseline-shift) Superscript and Subscript wird vom Renderer und ebenfalls von aktuellen Browsern wie Firefox und Internet Explorer 11 nicht unterstützt. Alternativ gibt es jedoch in SVG die zugrundeliegende Buchstaben-Unterschneidung mittels vertikalem Versatz über die Text-Attribute y oder relativ dy. Inkscape hat hier ebenfalls GUI-Unterstützung mittels .

<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">
    Normaler Text<tspan style="font-size:65%; baseline-shift:sub">tiefgestellter Text</tspan>
  </text>
  <text y="120" x="20" style="font-size:24px; font-family:sans-serif">
    Normaler Text<tspan dy="5" style="font-size:65%">tiefgestellter Text</tspan>
  </text>
</svg>

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

(Anm.: Normalerweise können diese Koordinaten-Attribute eine Liste von Werten enthalten, der Renderer unterstützt jedoch nur einen Einzel-Wert, siehe #Warum ist mein Text verschoben (verschwunden)?.)

An Pfad ausgerichteter Text

• 
  textPath
• 
  Workaround Text in Pfadflächen konvertiert
• 
  Workaround mit geraden gedrehten Text

Das entspr. Element <textPath> wird derzeit nicht unterstützt (phab:T11420 (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?

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 phab:T20936 (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 gänzlich aneinander.

Selbes Bild 1px größer.

Anm.: Der Bug scheint nach einem Update abgeschwächt worden zu sein, so dass dieser nur etwas bei ungeraden Auflösungen auftritt.

Warum wird meine SVG nicht angezeigt?

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

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.

Kann ich die Darstellung mit CSS steuern?

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 selector – phab:T43423 (Bugzilla: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 angebracht, da das Bsp. im Endeffekt nur einen Bug zeigt]

Anm.: Seit libRSVG 2.36 muss das style-Element eine type="text/css" Notation enthalten, entgegen der ausdrücklich als „optional“ gegebenen Empfehlung des W3C (phab:T68672).

Wie kann ich die Hintergrundfarbe setzen?

SVG verfügt 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 SVG durch ein farbiges Rechteck in Größe der Grafik erreicht.

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

Anm.: 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 (semi-fixed)

Der Renderer hat Schwierigkeiten, skalierte Vorschaubilder zu produzieren, wenn Filter-Funktionen 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

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.

Anm.: Der Fehler tritt vor allem bei einem niedrigem Wert auf (wenn im Ergebnis unter einem Pixel, Gnome Bug 605875, bearbeitet in libRSVG 2.40.9, Update des MediaWiki-Renderers notwendig [2])

Warum wird mein Füllmuster nicht richtig angezeigt?

Der Renderer ist leider nur bedingt in der Lage Füllmuster, folgend Pattern genannt, korrekt wiederzugeben (vor allem in der Skalierung, phab:T20463).

Tipps als Alternative: Erzeuge nur ein einziges „Urmuster“, dann vervielfache es durch Klonen, bis es die ganze Fläche des zu musternden Objektes überdeckt. Dann verwende die Silhouette des Objektes als Ausschneidepfad.

Als weiterer Workaround für Fortgeschrittene: bietet sich folgende Möglichkeit an, wenn man das Pattern nochmal in ein weiteres Pattern setzt (ein einfaches Viereck reicht) hat man meistens das gewünschte Resultat (Erfahrungen können hier auf der Diskussionsseite gerne weitergegeben werden).

Falls Pattern bei mehrfacher Verwendung (des gleichen Pattern) gänzlich verschwunden sind, ist eine mögliche Ursache eine Unordnung der Definition (defs-Element). Das bedeutet, dass der Editor intern Clone der verwendeten Pattern erstellt (nur mit geänderten Positionen) und diese womöglich im Dokumenten-Baum vor dem Original gesetzt wurden (was nicht schön ist, aber auch keinen Verstoß darstellt). Diesen Umstand kann der MediaWiki-Renderer nicht verarbeiten, daher ist der Fix, einfach die Clone im Dokument nach dem Original zu setzen. Beispiel-Datei:Grundriss Burg Hageneck.svg (no bug-report yet found)

stroke-dasharray

phab:T32033: Die Datei: EKG-Reto 001.svg zeigt ein Füllmuster mit stroke-dasharray fälschlich als volle Linien (etwas weniger, je größer die Vorschaugröße).

• 
  EKG-Reto 001.svg benutzt Leerzeichen als Trennzeichen (nicht unterstützt)
• 
  EKG-Reto 001 BugSolved.svg verwendet Komma als Separator (Workaround)

RegExp-Ersetzung (mit nur 2 Werten):

• stroke-dasharray="(\d*\.?\d*) (\d*\.?\d*)" ⇒ stroke-dasharray="\1,\2"

Animation

SVG-Animationen werden vom Wiki-Renderer nicht unterstüzt, jedoch können sie mit einem Direktlink für Browser zugänglich gemacht werden.

Beispiele: commons:Category:Animated SVG

Behobene Bugs

Marker (fixed)

Für Diagramme (Skizzen, Graphen und Flowchart artige) werden häufig wiederkehrende sogenannte Markierungssymbole wie Pfeile mittels marker-Element verwendet. Der MediaWiki-Renderer versteht diese ganz gut. Allerdings mit Ausnahme des mittigen Marker, dem sog. marker-mid in Verbindung mit orient="auto". Hier kann es zum völligen Abbruch des Renderns weiterer Elemente der Grafik kommen (phab:T117530).

Pfeile (Markierungen) sind verdreht (fixed)

Fehlerhafte Version in der Versionsgeschichte

Hier gibt es eine uneindeutige Besonderheit bei sogenannten kubischen Bezierkurven (bezier curves) auf. Wenn diese „unvollständig“ sind (auch bei „fast“ geraden Linien siehe Bsp.), werden diese nicht nach der Pfadrichtung ausgerichtet (sondern verbleiben in ihrer „Normalposition“).

Grund ist der, dass bei kubischen Bezierkurven der letzte Koordinatenpunkt (Endpunkt) sich anscheinend vom Vorletzten unterscheiden muss um eine Richtung (für den Marker) feststellen zu können. Nun könnte man einfach per Texteditor den Koordinatenpunkt ändern, allerdings ist es wohl leichter diesen über einen GUI-Editor (bei Inkscape über F2) neu zu setzen. Erkennbar ist dies daran, dass beim betreffenden Endknotenpunkt der Bogen-Anfasser (control point) fehlt, daher kann dieser einfach mittels gedrückter Shift-Taste (und Maus) gesetzt werden. (Daher kann der Bug auch aufgehoben, wenn man einen spiegel-/punkt-symmetrischen Pfad dreht/spiegelt und einen gespiegelten Marker verwendet ohne die Pfaddaten wirklich verändert zu haben.)

Als weitere Ursache können eng aneinanderliegende Knotenpunkte (daher nicht offensichtliche) in Frage kommen.

Anm.:

Der Bug ist ab librsvg-2.40.10 gefixt (GNOME Bug #476507) Die Tatsache, dass Firefox und Inkscape solchen Code (auf eine Weise) interpretieren, lässt jedoch den Umstand einer ungenauen W3C-Spezifikation und Konformität offen.

Aktuell tritt dieses Verhalten immernoch im Chrome (65) auf.

Info

 Info: Mit der Aktualisierung vom 24. Oktober 2012 (Serverupdate auf Ubuntu 12.04) wurden die Server, die für die Erstellung der Vorschaubilder 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. Oktober 2012 eingesehen werden.

Siehe auch

Commons: Help:SVG/de – ausführliche deutschsprachige Einführung in SVG

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

Einzelnachweise

.