Last modified: 2014-03-09 13:24:34 UTC
Since MediaWiki now renders SVG directly, it would be nice to permit choosing wich layers to render. Look, for instance, at [1] and [2]. The first is just a translation from the second. That could be done by means of specific layers (perhaps the names could be normalized). Example: [[Image:whatever.svg|layers=map,lang_en|...]] , for the second one [[Image:whatever.svg|layers=map,lang_no|...]] , for the first one. This issue has infinite uses. We at pt: have an SVG map where we store everything, from rivers to municipalities. We could choose on the fly which ones to render. Obviously, the parameter format should be discussed - as to whether we should choose which ones to show or the ones to hide. [1] http://commons.wikimedia.org/wiki/Image:Iberia_1031_%28norsk%29.jpg [2] http://commons.wikimedia.org/wiki/Image:Taifas.gif
Can this be accomplished with a simple XML transformation before shipping it out to be rendered, or will it require a more pliable interface with a rendering engine?
Noting this as a possible implementation for bug 16052
*** Bug 4689 has been marked as a duplicate of this bug. ***
*** Bug 55768 has been marked as a duplicate of this bug. ***
This is an exerpt from bug 55768 which concurs with this one. SVG layers can contain texts for different languages, the above rivers and municipalities, layers to compose different types of keyboards. The layers to display for a particular case could be specified with File:filename|layers=layer1, layer2,...,layerN I made an experiment that is NOT the way it should be done but that shows the general idea. I used a fun SVG made with inkscape and containing language text layers as described above. <g inkscape:groupmode="layer" id="g3001" inkscape:label="language=en" style="display:none" sodipodi:insensitive="true"> <text ... <g inkscape:groupmode="layer" id="g3002" inkscape:label="language=fr" style="display:none" sodipodi:insensitive="true"> <text ... <g inkscape:groupmode="layer" id="g3004" inkscape:label="language=ru" style="display:none" sodipodi:insensitive="true"> <text ... ... Then I ran the following command with $svglan being the wanted language parameter svglan=ru perl -pe "undef $/; s/(\"layer\".*?language=$svglan.*?display:)none/\1inline/sg" source.svg | rsvg-convert > displayed.png Et voilà, rsvg converts only the turned on "display:inline" layers and the result was a PNG in the chosen language. In short, the SVG renderer receives parameters that turn various layers on based on their names or some ID. I have drawn keyboard layouts SVGs for Wikipedia and a similar problem raises. For example, a Russian keyboard is nothing more than a QWERTY keyboard with Cyrillic "stickers". Same for Greek. Same for the additions that Unix makes. Etc.
We've got two options: File:filename|lang=XX in bug 16052, to make a language visible, hopefully File:filename|layer_name=layer1, layer2,...,layerN in bug 4688, to make visible anything that the author wants to As bug 4688 says, the second case covers, in addition to language text, a host of very interesting possibilities like selecting feature visibility like rivers and/or municipalities etc. in a map, or to select other components of a drawing. Look at https://commons.wikimedia.org/wiki/File:Belgian_Linux_keyboard.svg and see how, by removing the Linux layer you get a plain Belgian keyboard layout, and you can add more layers to select keyboard types like Russian and Greek. On the other hand, the first case is a language-only method incompatible with the other one. We could hardly use it together with choosing the features. I browsed the SwitchElement document ... SVG contains a ‘switch’ element along with attributes ‘requiredFeatures’, ‘requiredExtensions’ and ‘systemLanguage’ to provide an ability to specify alternate viewing depending on the capabilities of a given user agent or the user's language. If I understand it well, 1) switch is not supported by any editor and it can even clash with them 2) the switch concept is not made to cover user's choices of layers but to adapt to the environment, of which language happens to be a wiki concern 3) An author who, quite naturally, uses one layer per language will of course turn visibility off for all but one layer (else the SVG text is unreadable). I am not sure that processing the SVG by switch will make the hidden layer visible. In that case, I very STRONGLY think that a TRIVIAL filter that removes from the SVG file the groups that do not meet the criteria passed as parameters and that turns visibility on for the others is MUCH MUCH more interesting than switch. By "criteria" I mean that if we wanted to support editors that do not support group labels, we could also use a test of the group ID and that if it would be useful to identify the language of a group with systemLanguage, we could do it too. I have shown a hack of a similar filter in bug 4688. With a filter we get immediate support of editors, language and features. In fact, we get exactly what everybody wants. That filtering should best be within rsvg, it is not but it may be an option to add it there now or later when a filter such as written in Perl or Python will have been demonstrated.
There is one more possible syntax: [[File:filename.svg/language=xx]]. This might be easier to implement since it could repurpose the mechanism now used to display PDF/DJV pages.
I have written svg-sieve a script that does what bug 4688 suggests, select which layers to display, and by extension, bug 16052, select messages in a particular language. Principle: If a top level SVG group is tagged with a label contained in a matchlist, its visibility is enforced (< g style="display:) and the group is copied as is to standard output (flush), together with non grouped code. Else, the group is removed from the stream (purge). The script is extensible (open ended) to other tags to identify the layers. Full code and examples to play with @ http://www.papou.byethost9.com/notes/svg-sieve/ See comments in the source. Brussels-municipalities.svg is the source file, made with Inkscape, and the other svgs are generated samples. Please note in the unimpressive source svg the warning message indicating that the image is not final. svg-sieve -d all to test the inline example with debug. svg-sieve -d ma -l Ixelles,language=ru,names=ru Brussels-municipalities.svg > Brussels-Ixelles-ru.svg add -d mi to discover the layers. A patch exercising svg-sieve from wiki syntax would allow running it on a test basis. I am presently busy elsewhere, but I would try to run back asap if interest raises. What about this bug title? Allowing selecting SVG layers with Image parameters, including multilanguage
I use the option: Automatically add me to the CC list of bugs I change: Always. but I did not receive the post I just wrote. Why do they prevent archiving one's own posts? If I don't want a post I received, I just erase it, no fuss. But how can I archive posts I don't receive? What's the game?
(In reply to Papou from comment #9) > I use the option: Automatically add me to the CC list of bugs I change: > Always. > but I did not receive the post I just wrote. > > Why do they prevent archiving one's own posts? > If I don't want a post I received, I just erase it, no fuss. > But how can I archive posts I don't receive? > What's the game? In email prefs tab, near the bottom uncheck "The change was made by me" Normally its assumed email for notification, not archiving, and you already know about your own posts
Created attachment 14641 [details] SVG sieve script, see comment 8
Personally I am opposed to fixing this bug (I think people should just make separate files), but that's just my personal opinion.
>In email prefs tab, near the bottom uncheck "The change was made by me" Oops. OK. Thanks. >Normally its assumed email for notification, not archiving, and you already know about your own posts An e-mail copy is handy to be forwarded to someone.
>Personally I am opposed to fixing this bug (I think people should just make separate files), but that's just my personal opinion. Supposing the very realistic display in Wikipedia of a world map in which 200 countries are highlighted one by one in the 50 languages one by one. That makes 10 000 SVG files. And as the languages in the world are over 5000, counting a potential 500 for the main ones would make the figure 100 000. Are you volunteering?
(In reply to Papou from comment #14) > >Personally I am opposed to fixing this bug (I think people should just make separate files), but that's just my personal opinion. > > Supposing the very realistic display in Wikipedia of a world map in which > 200 countries are highlighted one by one in the 50 languages one by one. > That makes 10 000 SVG files. > And as the languages in the world are over 5000, counting a potential 500 > for the main ones would make the figure 100 000. I'm not opposed to having the language option that can be specified (Which is already supported) My concerns with this proposal are: *It seems hackish (That's just a gut feeling, so perhaps not a fair criticism) *It would be hard to adequately expose to the user which layers options are available. The [[File:..]] syntax might then become very mysterious. (This is probably my main worry) *There's possibly some issues with scalability related to how we store files. (However that's an implementation detail, so perhaps not a fair criticism of this bug as an "idea") > > Are you volunteering? Luckily they could use your script on the client side to generate the neccesary files :)
I'm afraid your message is unclear. > I'm not opposed to having the language option that can be specified (Which is already supported) I don't understand. Where is the documentation of that language option? > My concerns with this proposal are: > *It seems hackish (That's just a gut feeling, so perhaps not a fair criticism) What is hackish? - if it's the bug request, you'd better say it before someone uses his time to please you (all) - if it's the (open ended) way it's implemented, you'd better say how you would have done it > *It would be hard to adequately expose to the user which layers options are available. The [[File:..]] syntax might then become very mysterious. (This is probably my main worry) What simpler method do you devise to display a selection of named layers than to give the list of their names? Of course, even if docs disappeared in this era, the layers live best with an explanation (which can be in layers). > *There's possibly some issues with scalability related to how we store files. (However that's an implementation detail, so perhaps not a fair criticism of this bug as an "idea") I see some issues to discuss but not that. What is mysterious is why people repeatedly discuss language support in a project about layers selection support. Even is that layer support also covers languages and it's mentioned, subject closed. It's like repeatedly speaking of Cobol in a Fortran project. Both languages coexist and users choose what they find the most appropriate. Layers support has a wider scope than and includes languages. That's all. But if you really want to prompt my opinion, what I find a hack is the <switch>-element. It's a sub-product of an "if IE8 vs NS" like feature to adapt SVG code to some environment. Consequently it uses the LANG env variable of the GUI for the language of the data. And hence it needs an "env LANG=" kludge to work correctly. That would produce error messages in the language of the data. Neat. It cannot support more than one language at a time. Plus, not regarding design, there is no editor support for it. I don't want to discuss this any more. The user should be informed of the alternative and he would choose. > Luckily they could use your script on the client side to generate the neccesary files :) Brilliant idea ;-) I'm going to write a script to upload 10 000 map files. And I'll run it every time some detail changes in the map.
