[rrd-developers] Re: [patch] stringwidth patch for SVG etc.

[Peter Speck]

On mandag, april 1, 2002, at 08:44 , Tobias Oetiker wrote:

> Well, I have no problem adding the canvas object pointer to the
> textwidth call ... but this shows an issue we might have, in the
> sense that we should know what output format we are going to create
> when the canvas is created ... this is sad, because I was hoping to
> end up with something where the decision on how the output is going
> to look like will be decided upon calling the output function ...

This requires fonts to be static, e.g. the same for all output types. As 
high-quality fonts are possible more encumbered by copyrights than 
music, that's not possible: high-level formats like SVG/EPS/PDF 
'prefers' to use the standard 14 postscript fonts (which Adobe/Linotype 
has copyrighted) to avoid having to include them in the file, and bitmap 
formats like to have the fonts included with rrdtool to avoid being 
dependent on installed fonts on the host / local X-server / whatever.

> but then again, as we have to know the space used up by text while
> placing the legend elements, this may not be possible anyway ...

This would require gfx_* to step up one level in abstraction and 
implement a simple html box model, so the output function can (re)layout 
legends etc for the actual font used.
If we assume legends are always placed on a single line, the box model 
could be reduced to that gfx nodes could have a relative coordinate 
(from last node) instead of always absolute. Then, with use of 
'vertical-filler' nodes, the legends are absolute placed by the output 
function.

> so how about adding modifying the canvas create call to also take
> the output format as an option, require the text width call to
> have a canvas pointer and have the output generation function use
> the information from the canvas to determine what sort of output it
> should generate ?
>
> could you modify your patch accordingly ?

yes. I'll send a patch for that. If I read a little more into "the 
output format as an option", this includes moving (if_en imgformat, 
fl_en fontlib, int interlaced) so canvas_t includes all image format 
options. Just like image_desc_t it is created virgin, the attributes are 
set while parsing the options, instead of parsing all the info to 
gfx_new_canvas.

I can include the dashed-line option in that patch too.

I'm done implementing the eps driver. Using a path for creating the 
black box around the legends color creates a very minor artifact due to 
how postscript draws paths. The reason is that ending a path at the same 
point as it starts is not the same as closing the path. So I would 
suggest something like gfx_close_path which takes care of that. Some 
implementations might just treat gfx_close_path as adding the first 
point as an extra point if they don't have the concept of closed paths.

----
  - Peter Speck


--
Unsubscribe mailto:rrd-developers-request at list.ee.ethz.ch?subject=unsubscribe
Help        mailto:rrd-developers-request at list.ee.ethz.ch?subject=help
Archive     http://www.ee.ethz.ch/~slist/rrd-developers
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi