123 lines
10 KiB
HTML
123 lines
10 KiB
HTML
|
<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>
|