Bug 45783 - [PATCH] HTML imagemap support
Summary: [PATCH] HTML imagemap support
Status: NEW
Alias: None
Product: Batik - Now in Jira
Classification: Unclassified
Component: SVG Rasterizer (show other bugs)
Version: 1.8
Hardware: All All
: P2 enhancement
Target Milestone: ---
Assignee: Batik Developer's Mailing list
Keywords: PatchAvailable
Depends on:
Reported: 2008-09-11 10:45 UTC by Stefan Bund
Modified: 2009-01-26 08:59 UTC (History)
3 users (show)

Patch against trunk revision 694374 (14.12 KB, patch)
2008-09-11 10:45 UTC, Stefan Bund
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Bund 2008-09-11 10:45:40 UTC
Created attachment 22559 [details]
Patch against trunk revision 694374

This patch implements HTML imagemap support. It is based on an implementation by Thomas Knodt from 2002.

This implementation does correctly support transformations. Thanks to thomas.deweese@kodak.com for very important tips on how batik works. Without his help, this patch would not have been possible.

This patch adds an ImageMapTranscoder and extends the svgrasterizer application to map the 'text/xml' output format to this transcoder.
Comment 1 Helder Magalhães 2008-11-17 02:40:46 UTC
This sounds like a really cool feature to include into Batik! ;-)

According to what I have understood, it could be used to convert a static SVG containing links into a raster image (PNG/JPEG) plus an image map. It could be used to ease the pain of supporting existing (HTML-based) browser implementations until all browsers properly can handle SVG in a more interoperable way (lack of IE support and some minor incoherence within existing implementations such as Firefox, Opera and Webkit).

If there are any plans for integrating this into the framework, I'd be glad to help with further testing. :-)
Comment 2 Helder Magalhães 2009-01-26 08:59:17 UTC
Comment on attachment 22559 [details]
Patch against trunk revision 694374

>+    public static final String IMGMAP_STR = "text/xml";

Should this be "text/html"? Original is more XHTML oriented, proposed is HTML compatible [1]. A recent FAQ [2] points out to "application/xml" or "application/xhtml+xml" for XHTML...

>+    public static final String IMGMAP_EXTENSION = ".xml";

Same for ".html" or ".xhtml", if the HTML compatibility argumentation above makes sense...

>+        mimeTypeMap.put("text/xml", DestinationType.IMGMAP);

See above.

>+ * @author <a href="mailto:[EMAIL PROTECTED]";>Torsten Knodt</a>

This "[EMAIL PROTECTED]" suggests this was copied from a mailing list Web frontend (Nabble or such). Probably it would make sense to use the real email address in the final patch version or use some other kind of protection (person at domain dot suffix).

>+    private final String XHTML_URI = "http://www.w3.org/1999/xhtml";;
>+    private final String XHTML_SYSID = "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";;

Typos: semicolon twice.

>+        // FIXME: ID/ name attribute must be added to map element to make output valid

Few comments like this one... Is this really a problem?

>+        // We could also use xlink:title, but I think svg:desc is better.

It might make sense to use a combination of both. An accessibility page (see "Assumptions" section [3]) describes the expected behavior.

>+        // Here svg:title should be used instead of svg:desc, I think. Perhaps xlink:title would also be an idea.

See above.

>+			throw new TranscoderException ("Line segment not allowed at begin of path");

For simplification or by any known limitation? Couldn't this line segment simply be part of the "coords" attribute?

>+			throw new TranscoderException ("Move segment only allowed at begin of path");

I guess this could be added a TODO item as I quickly thought of a possible workaround: for each "move to" path command, an additional shape needed to be produced. I'm not sure if this is a good idea though (much more mark up being generated, while throwing an exception makes sure the user is aware of this limitation. Does this make sense to address?

Finally, I'm not sure if anything relevant could or should be made in order to make the output HTML5-compliant [4]... ;-)

Thanks for sharing, I hope this can be further reviewed/updated so this neat feature can make it to the trunk. :-)


 Helder Magalhães

[1] http://www.w3.org/TR/xhtml-media-types/
[2] http://wiki.whatwg.org/wiki/HTML_vs._XHTML#MIME_Types
[3] http://www.w3.org/Graphics/SVG/IG/wiki/Accessibility_Activity#Title_As_Tooltip
[4] http://www.w3.org/TR/html5/the-canvas.html#shape