https://bugzilla.wikimedia.org/show_bug.cgi?id=58920
--- Comment #4 from Bawolff (Brian Wolff) <[email protected]> --- (In reply to C. Scott Ananian from comment #3) > bawolff: yes, the confusion about 'system in question' is part of the > problem here. In a client/server system where some duties (for example, > image thumbnailing) are sometimes done on the client (for example, scaling > driven by the height/width attributes on an <img> tag) Well in the mediawiki context, img width/height attribute is to prevent rendering re-layouts. Its not used for scaling. But I get what you're saying about the term "system" being extremely ambiguously, and I agree. > > Concretely, parsoid would like to emit an <img> tag with the SVG in question > and allow the browser to do the scaling --- and language conversion, > presumably. The current way that 'systemLanguage' is designed and > implemented does not allow that. Mediawiki *must* render all SVGs into > bitmaps server side because we are implementing a behavior at odds with the > SVG spec (since we are using "wiki language" and an explicit "lang option" > override, not the "user's operating system's language") and at odds with > browser behavior (since no browsers appear to implement systemLanguage at > all). Well its at odds with the browser behaviour, the svg spec says: "Evaluates to "true" if one of the languages indicated by user preferences exactly equals one of the languages given in the value of this parameter, or if one of the languages indicated by user preferences exactly equals a prefix of one of the languages given in the value of this parameter such that the first tag character following the prefix is "-"." So if we were blindly following the spec, we would use the language in Special:Preferences. Nowhere in the spec do I see it say operating system language. This is hardly the only place where librsvg is going to be at odds with browser behaviour. The interpretation of the spec MediaWiki currently uses is much more useful to our users (imo) than the alternative. If parsoid really wants to serve raw svgs to the users (Which would be problematic for other reasons given how large in terms of file size some of them are at commons), it could always just blacklist svgs with systemLang in them (surely you're going to need to be scaling some other image formats - djvus, tiffs, pdfs, xcfs, jpegs with a rotation set, etc). It could even inject js into the svg to change its structure appropriately (although that would be hacky beyond hacky). -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
