Allowing tag Image to access SVG layers
OpenPublic

Description

Author: nunotavares

Description:
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


Version: unspecified
Severity: enhancement
OS: Windows XP
Platform: PC

bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz4688.
bzimport created this task.Via LegacyJan 20 2006, 12:42 PM
brion added a comment.Via ConduitJan 20 2006, 8:50 PM

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?

gpaumier added a comment.Via ConduitDec 31 2009, 6:26 PM

Noting this as a possible implementation for bug 16052

bzimport added a comment.Via ConduitMar 18 2010, 1:55 PM

happy.melon.wiki wrote:

*** Bug 4689 has been marked as a duplicate of this bug. ***

Bawolff added a comment.Via ConduitOct 22 2013, 12:29 AM
  • Bug 55768 has been marked as a duplicate of this bug. ***
A_Pirard added a comment.Via ConduitOct 22 2013, 12:57 PM

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.

A_Pirard added a comment.Via ConduitOct 22 2013, 6:53 PM

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.

Nikola_Smolenski added a comment.Via ConduitOct 23 2013, 1:50 AM

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.

A_Pirard added a comment.Via ConduitFeb 21 2014, 1:10 AM

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

A_Pirard added a comment.Via ConduitFeb 21 2014, 1:27 AM

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?

Bawolff added a comment.Via ConduitFeb 21 2014, 1:43 AM

(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

A_Pirard added a comment.Via ConduitFeb 21 2014, 1:52 AM

SVG sieve script, see comment 8

Attached: svg-sieve

Bawolff added a comment.Via ConduitFeb 21 2014, 6:51 AM

Personally I am opposed to fixing this bug (I think people should just make separate files), but that's just my personal opinion.

A_Pirard added a comment.Via ConduitFeb 21 2014, 12:06 PM

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.

A_Pirard added a comment.Via ConduitFeb 21 2014, 12:12 PM

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?

Bawolff added a comment.Via ConduitFeb 21 2014, 1:40 PM

(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 :)

A_Pirard added a comment.Via ConduitMar 9 2014, 1:24 PM

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.

Gilles added a project: Multimedia.Via WebNov 24 2014, 3:33 PM
Perhelion added a subscriber: Perhelion.Via WebDec 23 2014, 2:59 PM

Add Comment