Last modified: 2014-03-09 13:24:34 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 4688 - Allowing tag Image to access SVG layers
Allowing tag Image to access SVG layers
Status: NEW
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
unspecified
PC Windows XP
: Low enhancement with 4 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 55768 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-01-20 12:42 UTC by Nuno Tavares
Modified: 2014-03-09 13:24 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
SVG sieve script, see comment 8 (4.54 KB, text/x-shellscript)
2014-02-21 01:52 UTC, Papou
Details

Description Nuno Tavares 2006-01-20 12:42:46 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
Comment 1 Brion Vibber 2006-01-20 20:50:13 UTC
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?
Comment 2 Guillaume Paumier 2009-12-31 18:26:58 UTC
Noting this as a possible implementation for bug 16052
Comment 3 Happy-melon 2010-03-18 13:55:21 UTC
*** Bug 4689 has been marked as a duplicate of this bug. ***
Comment 4 Bawolff (Brian Wolff) 2013-10-22 00:29:50 UTC
*** Bug 55768 has been marked as a duplicate of this bug. ***
Comment 5 Papou 2013-10-22 12:57:17 UTC
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.
Comment 6 Papou 2013-10-22 18:53:18 UTC
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.
Comment 7 Nikola Smolenski 2013-10-23 01:50:55 UTC
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.
Comment 8 Papou 2014-02-21 01:10:10 UTC
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
Comment 9 Papou 2014-02-21 01:27:02 UTC
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?
Comment 10 Bawolff (Brian Wolff) 2014-02-21 01:43:11 UTC
(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
Comment 11 Papou 2014-02-21 01:52:04 UTC
Created attachment 14641 [details]
SVG sieve script, see comment 8
Comment 12 Bawolff (Brian Wolff) 2014-02-21 06:51:24 UTC
Personally I am opposed to fixing this bug (I think people should just make separate files), but that's just my personal opinion.
Comment 13 Papou 2014-02-21 12:06:20 UTC
>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.
Comment 14 Papou 2014-02-21 12:12:01 UTC
>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?
Comment 15 Bawolff (Brian Wolff) 2014-02-21 13:40:58 UTC
(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 :)
Comment 16 Papou 2014-03-09 13:24:34 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links