On Sun, May 01, 2005 at 12:25:25 +0200, Tobias Oetiker wrote:
> > I also read a post in the archives about floating point arguments to
> > LINEx (rrd_graph_helper.c). What is prefered, strtod() or some changes
> > to the sscanf() (say, checking the return value along with removing c1 and
> > c2 and instead checking line[*eaten+...] == ':')? Or are there reasons
> > to keep it LINE1, LINE2 or LINE3 only?
> 
> 1.2.1 will accept float arguments
Thanks for fixing this, as well as the other issues.
I have a suggestion for the new LINEx-code though: Currently it
accepts whatever sscanf( "%lf" ) accepts, which is a bit too liberal.
For example, "LINEinf" appears to eat memory like crazy.

See attachment linewidth.patch for a suggested change. I used isnan()
and isinf() since those should be the most compatible ones. Allowing
width = 0 is probably a good thing (error message and code disagreed
in previous version), even though it doesn't make much sense for PNG
it has a special meaning for EPS (thinnest possible line).

> not for the graphics as fahr as I know. 
OK, maybe a future version of libart will allow non-anti-aliased
graphics.

> The fonts on the other hand could be drawn
> non antialiased if freetype was called appropriately ... I will be
> glad to accept a patch wich adds an appropriate option to rrdgraph
I've attached a patch that adds --no-antialiasing/-B. It's my first
non-trival patch to rrdtool, so I might have screwed something up. In
particular, I saw no solution except adding an extra argument to the
gfx_*text*-functions. Perhaps they should use a single
textoptions-struct (specifying font, size, tabwidth and so on) to make
future patches cleaner?

As it is now, it also adds a "int no_antialiasing" to gfx_node_t,
perhaps using a "int flags" would be better, but I wasn't sure if
inheriting the extra_flags #defines from rrd_graph would be OK.

In rrd_gfx.c, gfx_save_png(), I think:
   font_alpha = *(bit->bitmap.buffer + iy * bit->bitmap.width + ix);
should be changed to 
   font_alpha = *(bit->bitmap.buffer + iy * bit->bitmap.pitch + ix);
(However, this change is not included in the patch.)

The patch doesn't update the documentation, I wasn't sure how to do
that (is .pod the source for both .txt and .html?). I'm not sure about
the option name either, perhaps it ought to reflect the fact that it
only disables anti-aliasing for the text?

Finally, I should also say that using freetype's (patent-free)
"auto-hinting" created readable but extremely ugly output for me.
Should the documentation to --no-antialiasing mention that enabling
freetype's bytecode interpreter (if allowed by ones jurisdiction)
makes the output look better? (Of course, this applies to anti-aliased
output as well, but smoothing makes it less apparent.)

Please test the patch it and see if it works!


-- Attached file removed by Ecartis and put at URL below --
-- Type: text/plain
-- Size: 509 bytes
-- URL : http://lists.ee.ethz.ch/p/linewidth.patch


-- Attached file removed by Ecartis and put at URL below --
-- Type: text/plain
-- Size: 13k (13876 bytes)
-- URL : http://lists.ee.ethz.ch/p/noantialiasing.patch


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