OK, ich bin mir noch nicht ganz sicher, welche der beiden Darstellungen korrekt ist, aber ich vermute, dass dies die von den Webbrowsern angezeigte ist, da ich in meinem Beispiel in Inkscape und Eye of GNOME (siehe unten).
Ich habe den Grund dafür herausgefunden, wie ich auf dieses Problem aufmerksam wurde: Die SVG-Datei, die ich mit Inkscape geöffnet hatte, hatte eine <linearGradient>
mit den Attributen gradientUnits="userSpaceOnUse"
und x2="1"
(genau wie in meinem Beispiel). Beim Speichern als "optimiertes SVG" hat Inkscape das x2="1"
Attribut "wegoptimiert", weil es dies als äquivalent interpretierte. Dies x2="100%"
ist die Standardeinstellung für das x2
Attribut, wie vom SVG-Standard angegeben, und könnte daher weggelassen werden. Jedoch Inkscapes Interpretation, x2="100%"
⇔ x2="1"
ist (wahrscheinlich) falsch - das ist Inkscape Bug # 1153706 .
In meiner Forschung zu diesem Thema, habe ich verschiedene Unstimmigkeiten über angetroffen, wie verschiedene Software verarbeitet gradientUnits="userSpaceOnUse"
in Kombination mit dem Gradientenvektor Attributen x1
, x2
, y1
und y2
. Im Folgenden sind Fehlerberichte aufgeführt, die entweder bereits vorhanden waren oder die ich aufgrund meiner Ergebnisse eingereicht habe:
- Inkscape - Fehler # 1153706: "gradientUnits userSpaceOnUse mit falschem Viewport"
- scour - Fehler # 66: "Steigung auf Beschneidungspfad bei Optimierung mit Scour verloren"
- Librsvg (wird von GNOME-Software wie Eye of GNOME oder GIMP verwendet) - Fehler Nr. 778187: "SVG: Eigenschaft x2 auf Gradienten, die falsch mit gradientUnits =" userSpaceOnUse "behandelt werden."
- ImageMagick - "gradientUnits =" userSpaceOnUse "falsch gerendert" (ImageMagick scheint nicht einmal einen echten Bug-Tracker zu haben ...)