Page MenuHomePhabricator

Allowing tag Image to access SVG layers
Closed, DeclinedPublic

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

Details

Reference
bz4688

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 9:03 PM
bzimport set Reference to bz4688.
bzimport added a subscriber: Unknown Object (MLST).

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

happy.melon.wiki wrote:

*** 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

SVG sieve script, see comment 8

Attached:

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.

I would close this issue as won't fix.

There is nothing in the SVG spec about having a master SVG file with selectively displayed layers, so the issue is out of scope. Say MW did have the capability to display layers of an SVG file. Now some soul copies that SVG file from Commons to his website. His website will not have the functionality to select layers. Commons is not meant to be specific to wikis.

Some editors have already implemented such layer selection by abusing systemLanguage attributes with made up langtags. It is a bad practice, and it will not work off wiki. It also turns out that it has subtle problems on wiki because hyphenated langtags do not work (e.g. lang=ru-x-layer1).

There are world maps on Commons that use CSS to color countries. They are used by copying the map and then editing the CSS style block to highlight particular countries. Yes, it creates a new (and large) SVG file, but the information is embedded in the file rather than in some arcane MW layers argument. And how flexible can a MW layers argument be? A map may display an infection rate by country, so it might want to paint the New Zealand layer light gray and the US layer black. You can do that with CSS, but you would need to grow more syntactic sugar cane to do that with external MW arguments. The big downside of using CSS hacks on WMF is the static world map must be copied into each file rather than just linked.

If MW allowed linking to external SVG files, then this issue would be moot. Linking would avoid copying, and such linking would work off wiki. But linking has its own problems.

This issue can be characterized as please load SVG file X with CSS file Y. Or it could be load SVG file X after running it through XSLT file Z.

Selectable layer SVG files have dubious value, are not part of the SVG specification, and should not be part of MW.

Declining per T6688#91020 and last comment.