Benutzer Diskussion:Hk kng/svgdirect.js

Erläuterungen

Es wird immer mal wieder gefordert, Wikipedia solle doch bitte SVG-Dateien direkt ausliefern, statt sie auf dem Server zu rendern und als PNG auszuliefern. Dieser Skript ist der Versuch, dieses Verhalten durch Nachladen der SVG-Daten zu emulieren. Damit ergibt sich automatisch, dass er nur für solche Browser geeignet ist, die mit diesem Dateiformat auch umgehen können - sei es generisch oder mittels eines Plugins.

Nicht jeder Browser/Plugin unterstützt SVG gleich gut. Und damit starten die Probleme nur.

Das Inkscape-Problem

Die meisten SVGs für Wikipedia werden mit Inkscape erstellt. Dieses Programm beschreibt die Größe einer Seite durch die width- und height-Attribute, lässt jedoch das viewBox-Attribut weg. Das macht für die direkte Darstellung erhebliche Probleme, denn nur mit diesem Attribut erhält der Browser die notwendigen Information, um die Darstellung skalieren zu können. Nehmen wir an, es sollte das SVG-Logo, original 638 mal 638 groß, als kleines Icon von 60px mal 60px dargestellt werden.

Normalerweise würde man SVGs einfach als Objekt (ersatzweise <embed> für alte Netscape-Browser) einbinden:

<object data="http://upload.wikimedia.org/wikipedia/commons/a/ac/SVG-Logo2.svg" type="image/svg+xml"
      width="180" height="150">
  <embed src="http://upload.wikimedia.org/wikipedia/commons/a/ac/SVG-Logo2.svg" type="image/svg+xml"
        width="180" height="150" />
</object>

Da aber die Datei keine viewBox definiert hat, wird dieser Code kein kleines Thumbnail zeigen, sondern einfach die linke obere Ecke in Originalgröße, je nach Browser mit Scrollbars.

Die SVG-Datei muss also manipuliert werden, damit eine verkleinerte Anzeige erreicht wird.

Das Same Origin-Problem

Das Manipulieren von SVG-Dateien sollte clientseitig eigentlich über das Document Object Model relativ einfach sein. Wäre da nicht die Wikipedia-Serverkonfiguration: Deutsche WP-Seiten kommen von der Domain de.wikipedia.org, die Bild-Dateien aber von upload.wikimedia.org. Und entprechend der Same Origin Policy sperren Browser den Zugriff auf die DOM, wenn Skript und Zieldatei nicht von derselben Domain kommen. Die SVG-Datei kann so nicht manipuliert werden.

Lösung: ein Wrapper

Die Problemlösung besteht darin, SVG-Funktionalität inline auf der Webseite zur Verfügung zu stellen. Der Skript fügt also folgenden Code direkt in jede WP-Seite ein:

<svg:svg xmlns:svg="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
      width="60px" height="60px" viewBox = "0 0 638 638" version="1.1">
  <svg:image x="0" y="0" width="100%" height="100%"
        xlink:href="http://upload.wikimedia.org/wikipedia/commons/a/ac/SVG-Logo2.svg"/>
</svg:svg>

Die originale SVG-Datei wird dabei von einem <svg:image>-Element referenziert, ohne zu versuchen, es zu manipulieren.

Das Firefox-Problem

Wie oben angemerkt, nicht jede Browserimplementierung ist gleich gut. Firefox hat ein Problem: Mit ihm verarbeitet <svg:image> nur Rasterbilder, aber keine SVG-Dateien. Dies wird seit vier Jahren kritisiert, der entsprechende Bug-Report ist aber immer noch nicht bearbeitet: [1]. Deswegen muss für diesen Browser eine Extra-Umdrehung hinzugefügt werden: ein <xhtml:object> in einem <svg:foreignObject> in einem <svg:svg>...

<svg:svg xmlns:svg="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
      width="60px" height="60px" viewBox = "0 0 638 638" version="1.1">
    <svg:foreignObject x="0" y="0" width="638" height="638">
         <xhtml:object xmlns:xhtml="http://www.w3.org/1999/xhtml"
                data="http://upload.wikimedia.org/wikipedia/commons/a/ac/SVG-Logo2.svg"
                type="image/svg+xml" width="638" height="638"/>
    </svg:foreignObject>
</svg:svg>

Da dies ein Verfahren ist, dass für andere Browser misslingt, ist es nur für die Gecko-Engine eingebaut.

Kommentare erwünscht

Habt ihr Lust, den Skript auszuprobieren? Hinterlasst eure Erfahrungs- und Fehlerberichte hier! --Hk kng 18:13, 9. Feb. 2009 (CET)

Trying out your script

Hi Hk kng,

Sorry for my lack of German. Thanks for the link to your script, I've tried it out a little now and it works OK sofar. I'm still looking at the source trying to see exactly what each part of it is doing, I see you've even accounted for ASV in IE.

I have just one question about it's functionality. I've been using my own little crude UserJavascript for this functionality and the method I used is quite different. Obviously my script is not cross-browser as it's purely for personal use, but I'm just interested to know whether there's any advantage to doing it either way. My script is very small and simplistic:

(function(){
var svgs=document.evaluate('//img[substring-after(@src,".svg.")="png"]',document,null,6,null);
for(var i=0,ii=svgs.snapshotLength;i<ii;++i){
  var parts=svgs.snapshotItem(i).getAttribute('src').split('/thumb/')[1].split('.svg');
  svgs.snapshotItem(i).setAttribute('src','http://upload.wikimedia.org/wikipedia/commons/'+parts[0]+'.svg');
}})();

but it works for me and I prefer the effect as it retains the "Right-click -> Open Image" functionality. I'll keep looking at your script, I'm sure I can learn something as you seem to know more about this than I. _ɹəəpıɔnı 17:58, 17. Mai 2009 (CEST)

Oh wouldn't things be easy this way...unfortunately the use of the <img> tag is a problem for some browsers. Mozilla has now been mulling over for four(!) years whether they should implement it or not. I havn't looked it up but I would expect ASV also not to work, since there is no file type declaration that would indicate the plugin should be loaded. So, for now, I am generally working through an inline-SVG as a wrapper.

I am working on resolving the link issue. --Hk kng 20:58, 17. Mai 2009 (CEST)

Oh, this I know (as I said it's not a cross-browser method), but the only reason I mentioned it was that I notice you have if ( is_gecko ) { and if ( is_ie ) { sections so I thought you were accounting for different methods. Other than that, I'm still working my way through it, educational.

Interestingly enough, on that Firefox bug, I think things are looking up. After all this time, it's been seeing a lot of activity lately _ɹəəpıɔnı 23:19, 17. Mai 2009 (CEST)

FYI, declarative animation is also unsupported with the method used, but works with <img>. Here is an example as a test case. _ɹəəpıɔnı 07:31, 18. Mai 2009 (CEST)