<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>Detailing the issue</title><link rel="stylesheet" type="text/css" href="manual.css"><meta name="generator" content="DocBook XSL Stylesheets V1.76.0"><link rel="home" href="index.html" title="JpGraph Manual"><link rel="up" href="apk.html" title="Appendix K. Why it is not possible to add a SVG backend to JpGraph"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Detailing the issue</th></tr><tr><td width="20%" align="left"> </td><th width="60%" align="center">Appendix K. Why it is not possible to add a SVG backend to JpGraph</th><td width="20%" align="right"> </td></tr></table><hr></div><div class="sect1" title="Detailing the issue"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2655344"></a>Detailing the issue</h2></div></div></div>
<div class="sect2" title="The core problem"><div class="titlepage"><div><div><h3 class="title"><a name="id2655351"></a>The core problem</h3></div></div></div>
<p>It all boils down to one critical issue: </p>
<p>With the current SVG 1.1 (and draft 1.2) standard there is no way to
statically find out the bounding box of an arbitrary text string for later usage
in the SVG script. </p>
<p>This very surprising omission in the SVG standard makes it in principal
impossible to even do such a simple thing as drawing a frame around a text
programatically since there is no easy way to find out the size, in the given
coordinate system, of the string. </p>
<p>Since the actual bounding box is dependent on both font, style, size, etc as
well as the actual SVG viewer text-layout engine implementation this calculation
cannot be done outside the viewer. It must be part of the SVG standard elements. </p>
<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
<p> Now, anyone who are familiar with SVG would jump in here and point out
that this is not entirely correct. For the specific case of a frame around a
text it would be possible to use a filter function as specified by the
standard but that is a special case that just could be used to draw an
effect that looks like a frame around a text (using the objectBoundingBox
property). It is still not possible to find out the bounding box. </p>
<p>The second approach would be to to add some DOM Javascript code in the SVG
script which upon execution of the script could in theory find out the
bounding box and adjust suitable attributes in the script. </p>
</div>
</div>
<div class="sect2" title="Why is this a problem ?"><div class="titlepage"><div><div><h3 class="title"><a name="id2655400"></a>Why is this a problem ?</h3></div></div></div>
<p>There are many places in the library where it is absolutely essential to find
out the bounding box of a text string to adjust the position of other object in
the graph. For example margins for titles, column width in gantt charts and
legends and so on. Without this functionality it will be impossible to add SVG
output without significantly reducing the functionality and in essence create a
new version of the library suitable for this reduced functionality that is
brought upon us by the use of SVG. </p>
</div>
<div class="sect2" title="Possible workarounds"><div class="titlepage"><div><div><h3 class="title"><a name="id2655415"></a>Possible workarounds</h3></div></div></div>
<p>Looking at this from a more positive view instead of explaining why it cannot
be done there are in principal only two workarounds (neither which is a 100%
solution) </p>
<div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem">
<p>Using a single fixed font. Restricting the library to one specific
fixed font would make it possible to calculate the bounding box for the
string. Due to differences in the existing viewers it would be necessary
to have some safety margins built in when doing this calculation.
However this would significantly impact the visual appearance of the
graphs. </p>
</li><li class="listitem">
<p>Using heuristics By establishing some "good enough" heuristics for a
plain font we can try to find a guesstimate of the size of the string.
Unfortunately it is a big difference in length between "iiiii" and
"wwwww" even though they have the same number of characters. So without
fully implementing the same algorithm as some SVG viewer text-layout
engine uses this method cannot guarantee that the text will always fit
without making the box fit the worst case. In addition this method will
have some difficulty in handling rotated text strings. </p>
</li></ol></div>
</div>
<div class="sect2" title="What would be required ?"><div class="titlepage"><div><div><h3 class="title"><a name="id2655446"></a>What would be required ?</h3></div></div></div>
<p>What would be required in the standard to solve this is a new basis element
which could be used to record the bounding box of a particular text string for
later reference. To just give some idea on what is needed some "pseudo-SVG" that
we would need is something along the lines of: </p>
<div class="hl-main"><table class="hl-table" width="100%"><tr><td class="hl-gutter" align="right" valign="top"><pre>1
2
3
4
5
6
7
8
9
10
</pre></td><td class="hl-main" valign="top"><pre><span class="hl-code"><def>
<boundingbox id="bb1"
text="This is a text" style=" />
</def>
<rect x="50+#bb1.x1-10" y="50+#bb1.y1-10"
width="#bb1.width+20"
height="#bb1.height+20" />
<text x="50" y="50" >
<tref xlink:href="#bb1" />
</text></span></pre></td></tr></table></div>
<p>The basic idea is that in the def-section all text strings to later be used in
the script is defined together with the font (and any other formatting
applicable). These text strings are defined in the new SVG element "boundingbox"
which will calculate the bounding box of the given text. These text string is
later referenced in the actual text with a standard tref element. The bounding
box attributes can then be used in the positioning of the text with a "#"
reference based on the id of the new introduced element "boundingbox" The above
script would then draw a text string positioned at (50,50) with a frame around
it with a 10 units margin all around.</p>
</div>
<div class="sect2" title="DOM scripting and GetBBox()"><div class="titlepage"><div><div><h3 class="title"><a name="id2655488"></a>DOM scripting and GetBBox()</h3></div></div></div>
<p>Since we make no claim to be experts in all aspects of the SVG standard (which
is fairly big) it might be possible that there is some way to still solve this
that has eluded us so we would be very interested in getting a second opinion of
these findings. We are aware of the SVG method GetBBox() but this would not work
in the library very well. The reason is that this is not a static function but
requires the context of a DOM script. This would require a substantially rewrite
of the library since there are graphs where every single coordinate would have
to be back-patched in the end (possible in multiple passes - since the
calculation of one bounding box would be needed to adjust another element). </p>
<p>This means that the script would no longer be static but would require the
library to generate "self-modifying" DOM script at the end. The logic of the
library assumes that the bounding box of text can be found out at the place of
creation and then this bounding box can be used to adjust subsequent
coordinates. </p>
<p>So to summarize this we do not feel that the potential back patching of every
single element in the SVG image at the end in a DOM script is a solution.
</p>
</div>
<div class="sect2" title="A final comment"><div class="titlepage"><div><div><h3 class="title"><a name="id2655518"></a>A final comment</h3></div></div></div>
<p>Since we still find it very hard to believe this giant oversight in the
standard we would be happy to receive comments on these conclusions. </p>
</div>
</div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"> </td><td width="20%" align="center"><a accesskey="u" href="apk.html">Up</a></td><td width="40%" align="right"> </td></tr><tr><td width="40%" align="left" valign="top"> </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> </td></tr></table></div></body></html>