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>
|