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:[EMAIL PROTECTED] Help mailto:[EMAIL PROTECTED] Archive http://lists.ee.ethz.ch/rrd-developers WebAdmin http://lists.ee.ethz.ch/lsg2.cgi
