Wikipedia:Probleme mit SVGs
|
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. |
Lies diesen Abschnitt zuerst
- Mit Inkscape oder Adobe 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.
- die meisten XML- und CSS- Attribute direkt im Root-Element
<SVG>nicht mehr interpretiert, siehe Bugzilla:31122
Wieso gibt es überhaupt Probleme?
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. 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 Wikipedia:WikiProjekt SVG#Dateien zu Hause testen).
Warum wird mein Füllmuster nicht angezeigt?
Der Renderer ist leider nicht in der Lage, alle Füllmuster wiederzugeben. Es bleibt nichts übrig, als sie von Hand zu zeichnen. Tip: 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.
Text
Warum wird meine Lieblingsschrift nicht angezeigt?
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 WikiProjekt_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, Helvetica und Courier; Aktualität ohne Gewähr). Siehe auch Abschnitt: „#Die Abstände von Buchstaben stimmen nicht“
Als weitere Ursache kommmt die fehlende Interpretation des Schriftnamens (Font-Familie) 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.[1] (Einen Bug-Report scheint es momentan dafür nicht zu geben.)
Warum wird mein Text nicht dargestellt?
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 (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 umgebrochen werden.
Auf SVG-Dateiebene werden in diesem Fall die ab SVG-Version V1.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 externen 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 schwarze Balken angezeigt?
→ Siehe Abschnitt: „#Warum wird mein Text nicht dargestellt?“
Die Schrift ist an eine andere Position verschoben
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 Wikipedia-Renderer versteht diese Syntax nicht (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 RegExp-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 Notepad++) folgendermaßen aussehen:
( [xy]="[-0-9.]*) [-0-9. ]*"
→ Ersetzung: \1"
Des Weiteren werden Verschachtelungen, bzw. wechselnde Verwendung des <tspan>-tags nicht interpretiert (Bugzilla:17174).
Die Abstände von Buchstaben stimmen nicht
Der Wikipedia-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.
Der Effekt ist umso ausgeprägter, je kleiner die Schrift ursprünglich definiert wurde. Damit lässt sich auch ein Gegenmittel angeben: Statt
<text font-size="5px">Beispieltext</text>
erzeugt die spätere Verkleinerung einer ursprünglich großen Textdarstellung
<g transform="scale(0.25)"><text font-size="20px">Beispieltext</text>
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.
Des Weiteren muss die Schriftgröße mit einer absoluten Einheit[2] versehen werden, mit Ausnahme von px (Bug 337979 und Bugzilla:13494, sollte eigentlich längst gefixt sein). Fix mittels RegExp z. B.:
(font-size:[0-9.]*);
→ Ersetzung: \1px;
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 14 jedoch nicht (Bugzilla 371787[4]).
Hoch- und tiefgesteller Text
Die Grundlinienverschiebung (baseline-shift) Superscript and Subscript wird vom Renderer nicht unterstützt.(Bugzilla:5792) Alternativ kann jedoch einfach die Buchstaben-Unterschneidung (Vertikaler Versatz)Translation verwendet werden.
Equivalent verhält es sich mit der Schriftdehnung, die selbst von modernen Browser nicht komplett unterstützt wird, jedoch einfach durch eine Stretch-/Objekt-Transformation (scale) ersetzt werden kann.
An Pfad ausgerichteter Text
Das entspr. Element <textPath> wird derzeit nicht unterstützt.(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 jedes einzelnen Textzeichens (z. B. mit Adobe Illustrator automatisch möglich). Sofern der Textpfad keine Gerade ist, da Text ansonsten auch ganz normal über das Attribut transform positioniert werden kann.
Warum hat mein Bild durch den Pfad weiße Streifen?
Auch wenn zwei Pfad-Knoten genau an der selben Stelle sind, erscheint beim Renderer eine Spalte (jedoch auch in manchen aktuellen Browsern, Bugzilla:19224). Hier gibt es in Inkscape eine Funktion ‹Pfad›–‹Vereinigung› (Strg++), welche die übereinanderliegenden Knoten zu einem Knoten vereint. Selbst wenn sich zwei Objekte scheinbar weit überlappen, kann dieser Effekt auftreten, sobald der Bereich in der Skalierung 1 px unterschreitet.
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, das die Datei korrekt angezeigt wird. Folgende Fehlerquellen sind möglich (vermutlich keine vollständige Liste):
- Das eingebundene Bitmap ist eine JPEG-Datei. Der Renderer kann aber nur PNG-Dateien darstellen.
- 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 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:
|
Kann ich die Darstellung mit CSS steuern?
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 CSS 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 (März 2011) bei drei von sechs Tests (Punkt 3., 4. und 6. 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 Benutzer: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 | 50 Pixel | 52 Pixel | 80 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.
Anmerkung: Der Fehler tritt vor allem bei einem niedrigem Wert auf (wenn im Ergebnis unter einem Pixel, Bug 605875)
Pfad-Objekte werden abstrakt oder verschoben dargestellt
 |
 |
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 (Bug 620565, 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
WikiMedia: Librsvg development funding (engl.)
![[1]](https://upload.wikimedia.org/wikipedia/commons/thumb/2/2c/MediaWiki_SVG_fonts.svg/2000px-){kind=link}
Einzelnachweise
- ↑ W3C Recommendation (07 June 2011): Font family: the ‘font-family’ property (CSS 2.1) Specification – Fonts
- ↑ Flowing text and graphics, W3 SVG1.2 Draft
- ↑ W3C SVG Text: Spacing properties - letter-spacing
- ↑ SVG in Firefox: Element implementation status