[reportlab-users] External hyperlinks in SVG output

[Peter]

On Thu, Jan 29, 2009 at 4:38 PM, Andy Robinson <andy at reportlab.com> wrote:

> There are two parts to this.  First, the shapes hierarchy in

> reportlab/graphics would need some extra properties so that

> a shape could have link properties.  This is straightforward for

> manually constructed shapes, but ...


The list of properties for HTML like output is potentially quite long,
see http://www.w3.org/TR/REC-html40/struct/links.html - and would be
different for SVG, PDF, ... output.  The core two for me are the HREF
or URL, and the TITLE (usually rendered as a tooltip).  Another
interesting one in HTML is the TARGET (useful if you want to have the
link open in another window), although for SVG is appear they prefer
the new SHOW attribute).  There are also things like mouse over, on
click etc.

What can a PDF (or PS) hyperlink do, or what attributes can is have?
There is the link URL itself, but is that it?

If we added a dictionary (or object) to the basic shape objects
(called "link" or "hyperlink" or whatever) then the user could put as
many attributes into the dictionary as they liked.  The different
render backends would each look at a different subset of these
entries.  This would be extendible, but for the end user could require
different properties to be set depending on the intended output file
format.  I also feel this dictionary approach would be a departure
form current ReportLab style.  For example, font properties are not
bundled together but are held as multiple properties (fontface,
fontsize, ...).

Therefore, perhaps we should instead implement just a handful of core
link properties.  e.g. "href_url" as a string, "href_tooltip" as a
string, and perhaps "href_new_window" as a boolean (an HTML image map
back end would use target="_blank", an SVG or XML backend might use
show="new", while for a PDF this has probably has no real meaning and
would be ignored).  This could be extended gradually if other
attributes were deemed sufficiently important.


> Secondly, each renderer would need to do the right thing.

> I can see this would be really easy with SVG.

>

> If you're willing to do a little work on this and contribute

> patches for core and SVG back end, we'd be happy to help out and

> maybe do the same in PDF in step with it.


I've been experimenting with an HTML image map renderer, inspired by
Dirk Datzert's approach (see July 2003 email linked to earlier) but
with additional support for polygons.  It occurs to me that even
strings with links could be dealt with here by generating a link
region from their bounding box.  Other basic ReportLab shapes include
the ellipse which is not support by an HTML image map, so a crude
polygon approximation may be required for completeness.  However, for
the moment, my biggest unsolved problem is dealing with group
transformations - I expect looking more closely at the existing render
backends will help here.

Trying to extend renderSVG to cope with links is on my to do list -
but it would help to have an idea of how you would prefer to store the
extra attributes within the basic shapes (discussed above).

Thanks,

Peter