Page MenuHomePhabricator

Find a way to parse SVG files to render wikilinks
Open, LowPublic

Description

Hello,

When doing a map as vector graphics, it is very interesting to make this map
interactive by putting wikilinks pointing to the dedicated articles. You can
take a look at the two following examples:

This methode using CSS has many drawbacks:

  • Everytime you resize the image frame, all the links have to be changed by hand.
  • Everytime you change the SVG file and this change includes a resize, all the

links have to be changed by hand.

  • This method is very boring and takes a looooooong time.

It would be _really_ practical to have some extension that would parse an SVG
file looking for text with wikisyntax. Thus, links could be added directly in
the SVG file. This would really improve the map features of MediaWiki:

  • Images could be resized without making the position of the links obsolete
  • The links could be placed directly in Inkscape, thus making it much more

practical to place them

  • All maps could be made interactive

Version: unspecified
Severity: enhancement
URL: http://fr.wikipedia.org/wiki/Mod%C3%A8le:Carte_des_ch%C3%A2teaux_cathares

Details

Reference
bz7849

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 9:24 PM
bzimport set Reference to bz7849.
bzimport added a subscriber: Unknown Object (MLST).
gpaumier created this task.Nov 9 2006, 8:07 AM

ayg wrote:

This should be part of the ImageMap extension, maybe? Since SVGs are rendered
to PNG, of course, you'll have to generate an HTML <map> element with all the
correct positions when you render the thumbnail.

michaeldaly wrote:

I'm a rank beginner wrt SVG but I know <imagemap> quite well. There are a couple of things to watch for in the proposal and I propose ways to deal with this.

1 - SVGs can contain a lot of elements and not all will be needed in an imagemap. While some users might create a nice SVG, in general an SVG could swamp imagemap if it contained too many bits.
2 - Placing links directly in the SVG makes the SVG unusable in other contexts. In other words, if the SVG of a map of a city that links to real estate info would not be useful as a map of tourism - a second version would be required. The links should not be in the SVG.

For that reason, I would not recommend having the SVG "drive" the imagemap. Rather, make sure the imagemap and the user specify the elements in the SVG that are to be used and map those to links. I would propose that a new keyword be added to imagemap that allows this. For example:

Add a keyword "group" with the following syntax:

group group-id link-definition

Example:
<imagemap>
image nycboroughs.svg|300px|center
default [[New Your City Tourist Information]]
group manhattan [[Manhattan Tourist Information]]
group bronx [[The Bronx Tourist Information]]
...
</imagemap>

Within nycboroughs.svg, you'd have a group like:
<g id="manhattan">

<rect x="50px" y="75px" width="80px" height="240px" />

</g>

Thus <imagemap> can find group-id "manhattan", get the contained rectangle and generate the appropriate area html:
<area href="index.php/Manhattan_Tourist_Information" shape=rect
coords="50, 75, 130, 315" alt="Manhattan Tourist Information"
title="Manhattan Tourist Information">

Obvious problems (and in this an expert on SVG may offer help):

  • This requires that the SVG creation software generate appropriate data - one shape per group for the relevant area. I don't know whether this is under the control of the user in a typical software package (like Inkscape).
  • For reusability of the SVG, there should be an easy method of finding the appropriate group names contained in the SVG.

I offer this as a starting point...

michaeldaly wrote:

On further consideration, the requirement for one area per group is not necessary. If more than one area is provided (e.g. union of two polygons that may or may not be contiguous) to define one image region, using both of those areas in the imagemap will be easy to deal with. If two <area> HTML lines are created with the same link, it provides the same functionality.

In fact, using <g>roup as a level of identifying the information for a single link seems that it will allow for a lot of complex image regions to be handled correctly. HTML Image maps do not have a problem with overlap, so if all areas within a group are rendered separately as an area, it should work fine.

If two distinct groups have overlapping regions, then it should still work, since IIRC, HTML rules on overlap in image maps are consistent with SVG's on rendering - the last definition takes precedence over the earlier ones. This means no clipping calculations need be done to produce the correct image map areas.

gpaumier removed a subscriber: gpaumier.Jul 18 2018, 6:02 PM