Cowboy's Wiki:Probleme mit SVGs

Aus Cowboy's Wiki
Wechseln zu: Navigation, Suche


Frequently Asked Questions zur SVG-Erstellung für Cowboy's Wiki

Bei der Herstellung von 600X WIKIPEDIA LOGO.svgSVG-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 Cowboy's Wiki:Grafikwerkstatt. Allgemeine Fragen zu Inkscape werden auch in der Inkscape-FAQ beantwortet.

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

Abkürzung: CW:PMS, H:SVG

Lies diesen Abschnitt zuerst

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

  • Mit 600X WIKIPEDIA LOGO.svgInkscape oder 600X WIKIPEDIA LOGO.svgAdobe Illustrator erstellte Dateien sollten vor dem Hochladen immer als „Normales“ (oder „Optimiertes“) SVG abgespeichert werden. Das vermeidet bereits einige kleinere Fehler.
  • Für genauere Prüfung der Anzeige können SVGs mittels diesem Tool getestet werden, welches eine Vorschau eines gerenderten SVGs einer lokalen Datei erstellt und optional Syntaxfehler anzeigt (mehr dazu auf Commons:SVG Check).
  • Dateien sollten mit dem W3C-Validator, einem Testtool u. a. für SVG, geprüft werden und nur bei Fehlerlosigkeit hochgeladen werden.
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, allerdings 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?

SVG-Dateien werden von 600X WIKIPEDIA LOGO.svgMediaWiki nicht direkt angezeigt sondern immer dann, wenn diese auf einer Seite eingebunden werden, in 600X WIKIPEDIA LOGO.svgPNG-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 600X WIKIPEDIA LOGO.svglibrsvg verwendet. Auch der Bildbetrachter Eye of Gnome benutzt librsvg, und wer in der Lage ist, sich dieses unter 600X WIKIPEDIA LOGO.svgLinux verbreitete Programm mit der richtigen librsvg-Version zu installieren, kann damit vor dem Hochladen feststellen, was alles falsch dargestellt wird (mehr dazu auf CW:SVG #Dateien zu Hause testen).

Text

Warum wird meine Lieblingsschrift nicht angezeigt?

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: CW:SVG #Schriftarten in extrahierten Vektordaten.

Zu beachten ist auch, dass die installierten Schriften nicht einheitlich 600X WIKIPEDIA LOGO.svggeglä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. 600X WIKIPEDIA LOGO.svgTimes, 600X WIKIPEDIA LOGO.svgHelvetica und 600X WIKIPEDIA LOGO.svgCourier; 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-Familie) in (meist einfachen) 600X WIKIPEDIA LOGO.svgAnfü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.[1] (Einen Bug-Report scheint es momentan dafür nicht zu geben.)

Warum wird mein Text nicht dargestellt?

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 (Gnome Bug 460904). 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?

Siehe Abschnitt:#Warum wird mein Text nicht dargestellt?

Die Schrift ist an eine andere Position verschoben

Datei:Text-positioning.png
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 angibt (Kerning und Shifting). 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 Cowboy's Wiki-Renderer versteht diese Syntax nicht (Gnome Bug 525023). x und y 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 wieder entfernt werden.

Zur Korrektur bei größeren Quelltext kann auch ein 600X WIKIPEDIA LOGO.svgRegExp-fähiger Texteditor verwendet werden. Wenn die erste Nummernangabe die maßgebliche ist (also nur für zusammenhängenden Text, weit auseinander liegender 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 600X WIKIPEDIA LOGO.svgNotepad++) folgendermaßen aussehen:

( [xy]="[-0-9.]*) [-0-9. ]*"
Ersetzung: \1"

Die Abstände von Buchstaben stimmen nicht

Alle Textschnipsel sollten gleich dargestellt werden

Der Cowboy's Wiki-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 600X WIKIPEDIA LOGO.svgUnterschneidung definiert ist. 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.

Eine besondere Variante ist, im Text-Element <tspan /> mit vorgestelltem Leerzeichen einzufügen. Eventuell wird auch die Position des Textes verschoben. Dies kann mit dx und dy innerhalb von <tspan /> korrigiert werden. In anderen Anzeigeprogrammen hat diese eigenwillige Variante keine Auswirkung.

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 600X WIKIPEDIA LOGO.svgLigaturen aus den Schriftdateien nicht berücksichtigen.

Als weitere Ursache kommen ebenfalls die x-, y-Positionsangaben für Textzeichen in Frage (z. B. beim PDF-Import), siehe obigen Abschnitt: „#Die Schrift ist an eine andere Position verschoben“.

Bei unerwarteten Größen, siehe obigen Abschnitt: „#Warum wird meine Lieblingsschrift nicht angezeigt?

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

Hoch- und tiefgesteller Text

Text-Shifting mittels dy

Die CSS-Grundlinienverschiebung (baseline-shift) Superscript and Subscript wird vom Renderer nicht unterstützt.(Bugzilla:5792 und Gnome Bug 340047) (Jedoch selbst von aktuellen Browsern wie Firefox 21 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 Single-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

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

Als Workaround bietet sich an den Text selbst in Pfade umzuwandeln (was jedoch die bekannten Nachteile mit sich bringt), mögliche Alternative ist eine Ausrichtung der einzelnen Textzeichen (z. B. mit Adobe Illustrator automatisch möglich). Ist der Textpfad eine Gerade, kann der Text auch ganz normal über das Attribut transform positioniert werden kann.

Warum hat mein Bild durch den Pfad feine Linien?

Auch wenn zwei Pfad-Knoten genau an der selben Stelle sind, erscheint beim Renderer (in bestimmten Auflösungen) eine Spalte (hairline, jedoch auch in manchen aktuellen Browsern, [Bugzilla:?]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?

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.

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

Das liegt in der Regel nicht an einem SVG-Fehler, sondern an 600X WIKIPEDIA LOGO.svgPNG-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:

Datei:Svg-png-ff-IE.png
links Firefox 2.0.0.13, rechts IE 6.0
Green copyright.svg

Kann ich die Darstellung mit CSS steuern?

Systematischer Test verschiedener CSS-Methoden.

Während der Eintrag von style-Eigenschaften in Objekte und Gruppen natürlich der zentrale Mechanismus für die Darstellung von SVGs ist, ist die Verwendung von eingebetteten 600X WIKIPEDIA LOGO.svgCSS am Beginn des Dokuments ein wahres Glücksspiel. Welche Mechanismen vom Renderer unterstützt werden, lässt sich eigentlich nur durch Ausprobieren feststellen.

Bei fehlerfreier Funktion der Rendering-Software sollten in der Abbildung rechts sechs rote Kreise, sechs blaue Quadrate und die Texte bei Punkt 5 und optional bei Punkt 6 in Fettschrift erscheinen. Die bei Wikimedia eingesetzte Rendering-Software scheitert derzeit (September 2013) bei zwei von sechs Tests (Punkt 3. und 4. wird nicht korrekt in der PNG-Grafik dargestellt).

Wie kann ich die Hintergrundfarbe setzen?

SVGs verfügen weder über einen Hintergrund noch über Hintergrundfarbe als Eigenschaft der Grafik. Ein farbiger, nicht-transparenter Hintergrund wird daher bei SVGs durch ein farbiges Rechteck in Größe der Grafik erreicht.

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

Ein verkleinertes Vorschaubild sieht ganz anders aus als das Originalbild

Der Renderer (Rendering-Software) 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

Korrekt
0 fehlend

Als reguläre Abkürzung können optional bei numerischen Koordinaten (coordinate values) von Pfaden (<path d="<path-data>") 600X WIKIPEDIA LOGO.svgführende Nullen (leading zeroes) vor der 600X WIKIPEDIA LOGO.svgDezimalkommastelle („.“ decimal point) weggelassen werden, was keinen Verstoß gegen einen Standard darstellt und normalerweise kein Problem bereitet (siehe auch 600X WIKIPEDIA LOGO.svgsignifikante 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 600X WIKIPEDIA LOGO.svgStream Editor):

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

Siehe auch

WikiMedia WikiMedia: Librsvg development funding (engl.)

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

Einzelnachweise

  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