Menu
▾
▴
Re: png: selecting builtin font impossible?
|
From: Manfred S. <man...@gm...> - 2009-02-22 22:31:57
|
Am Freitag, den 20.02.2009, 23:05 +0100 schrieb Manfred Schwarb: > Am Donnerstag, den 19.02.2009, 13:08 -0800 schrieb Ethan Merritt: > > On Thursday 19 February 2009 03:52:38 Manfred Schwarb wrote: > > > > On Wednesday 18 February 2009 09:41:44 Manfred Schwarb wrote: > > > > > > > > > > > On Wednesday 18 February 2009 05:13:09 Manfred Schwarb wrote: > > > > > > > > > > > > > > your change in term/png.trm of > > > > > > > "revision 1.130, Thu Nov 20 06:14:41 2008 UTC" set "arial" as the > > > > > > > font default. > > > > > > > > > > > > > > Now, I can't select the builtin fonts any more. > > > > > > > I tried > > > > > > > "set term png small" > > > > > > > "set term png small font small" > > > > > > > "set term png font small" > > > > > > > > > > > > > > but I always get Arial as the selected font. > > > > > > > How to select the builtin fonts? > > > > > > > > > > > > Why would you ever want to? > > > > > > > > > > > > > > > > > > > > > 1) Because I want to be able to shoot myself into the foot? > > > > > > > > > > 2) Because I don't want blurred text in an otherwise unblurred > > > > > plot? I really want terminal-font quality in a pixel plot. > > > > > > > > So why not set the font to whatever you are using in your terminal? > > > > > > > > > > How to do? You can only select Truetype fonts. > > > > That is not correct. libgd is not limited to TrueType fonts. > > The font handling is done via freetype2, which handles quite a > > variety of font formats: > > http://freetype.sourceforge.net/freetype2/ > > > > > E.g. I'd like to set the > > > font to the "6x13" terminal font, and something like > > > "set term png font '6x13'" does not work, as expected. > > > > On my machine such fonts are installed under the names "Terminal [Bitstream]" > > and "Terminal [DEC]". Font installation and naming varies widely, so > > beyond that I cannot help much. > > OK, it seems libgd supports TTF and Type1 fonts, but not unscalable > pixel fonts. > > > > > > > > > 3) For 90 degree rotated text, font quality for non-builtin > > > > > fonts is really bad. > > > > > > > > That makes no sense to me at all. The font rendering in libgd > > > > is identical in the two cases. All that the rotation changes is the > > > > order in which text pixels are copied across onto the image canvas. > > > > 90-rotated text should be pixel-for-pixel identical to unrotated text. > > > > If it isn't, this sounds like a bug that should be filed against libgd > > > > rather than against gnuplot. > > > > > > > > > I can send examples if you like. > > > > > > > > Please do. Please also provide the script that generated them, > > > > and the version number of libgd against which gnuplot is linked. > > > > Probably a good idea to send them to the libgd list also. > > > > > > > > > > I suspect it is a generic issue (or perhaps I simply expect too much > > > from font rendering machines). I tested with pngcairo, and I got the > > > same artefact. It's like there is a too coarse or skewed color gradient > > > when rendering the characters, I don't know. > > > > > > libgd and libcairo are reasonably new, I guess (2.0.36 and 1.4.10). > > > > > > I will attach some plot snipplets to this email, for builtin, ttf > > > and cairo. > > > > But you did not attach the generating script. > > It seems clear to me from inspection of the "bad" ttf rotated text that > > the rotation angle is not truly 90. Without seeing the command that > > generated this text, I cannot say why that would happen. > > > > It is true that when you rotate text to an arbitrary angle, then the > > characters become somewhat distorted. Then again, with the builtin fonts > > you cannot rotate text to arbitrary angles at all. > > > > > I figured there are 2 separate issues: > > 1) bad rendering which optically results skewed color gradients: > This is purely my own fault, as the thing is a multiplot and > with each additional "plot" command all label commands were > executed, which resulted in multiple overlaying labels. > And the labels seem to be additive in the color space, with the > obvious result. > I.e. I simply forgot to add some "unset label" commands after the > "plot" command. > Hmmm, actually an implicit "unset label" after every plot command > would be more intuitive. And it is probably almost mandatory > to "unset label" after an plot command, at least I don't see > at the moment any usage of these already plotted labels after the > "plot" command. > > > 2) As you correctly noted, the strings are somewhat slanted. This only > happens with libgd, in cairo mode things are OK. And this issue > is something different from issue 1). > Interestingly this seems to happen only with recent gnuplot versions. > I found a gnuplot 4.3 version of December 2007 on my disk, and this > version does correct rendering, although it uses the very same > shared libraries (i.e. same libgd.so) as the recent cvs-versions > which show this strange slanting. > The slanting only occurs in vertical orientation, horizontal strings > are always OK. > > I will try to investigate this a bit further over the weekend, but at > the moment I'm a bit clueless. > > A script which shows this issue (probably it could be reduced even > more): > > set encoding iso_8859_1 > > #set term pngcairo font 'arial,12' size 900,960 > #set term png truecolor small size 900,960 > set term png truecolor font 'arial,12' size 900,960 > set out "demo.png" > > set multiplot > set label "DEMO" at screen 0.5,0.98 center font "large" > set lmargin screen 0.1 > set rmargin screen (1.0-0.1) > set tmargin screen (1.0-0.0708333-0.234375-0.0791667*4.0) > set bmargin screen (1.0-0.0708333-0.234375-0.0791667*5.0) > > yoff=(1.0-0.0708333-0.234375-0.0791667*4.5) > set label "Atmosphärenquerschnitt [hPa]" at screen > (0.1-6.0*0.0133333),yoff \ > center rotate textcolor lt -1 > plot [0:180][-15:10] sin(x) notitle with lines lc rgb "#A0A0A0" > > unset multiplot > set output > > I did some binary search, an I got 20080915 good 20080916 bad the offending patch is: --- term.c 2008/09/07 04:13:02 1.179 +++ term.c 2008/09/16 05:35:25 1.180 @@ -1,5 +1,5 @@ #ifndef lint -static char *RCSid() { return RCSid("$Id: term.c,v 1.179 2008/09/07 04:13:02 sfeam Exp $"); } +static char *RCSid() { return RCSid("$Id: term.c,v 1.180 2008/09/16 05:35:25 sfeam Exp $"); } #endif /* GNUPLOT - term.c */ @@ -995,9 +995,9 @@ (*t->put_text) (x - fix, y, text); } } - if (angle == TEXT_VERTICAL) + if (angle == 90 || angle == TEXT_VERTICAL) x += t->v_char; - else if (-angle == TEXT_VERTICAL) + else if (angle == -90 || angle == -TEXT_VERTICAL) x -= t->v_char; else y -= t->v_char; Cheers, Manfred > Cheers, > Manfred > > > > > > > 4) If you want to produce light-weight plots for e.g. web applications > > > > > (i.e. the fewer bytes the better) you really want to avoid > > > > > such truetype fonts. > > > > > > > > Possibly. But I am curious about the weight of that argument. > > > > Can you provide some numbers that demonstrate a significant difference > > > > in the output file sizes? If I compare the output of a 'typical' plot > > > > from the demo set using "verdana,9" as compared to the "medium" built-in > > > > font, I get a difference of about 400 bytes out of 8000. I would gladly > > > > pay that price, because to my eyes the built-in font is both ugly and > > > > harder to read. You have said that your eyes disagree, and I believe you. > > > > On the other hand, if you are exporting your plots to the rest of the > > > > world then the question is what does a typical viewer think about it? > > > > I realize that discussion of font preferences can degenerate into > > > > intractable differences of opinion, but you must be aware that many > > > > people prefer anti-aliased text. > > > > > > > > > > Size: in a plot with moderate amount of labels, I get: > > > ttf -> builtin: -15% > > > ttf -> cairo: +40% > > > > The cairo output is a from completely different driver, and a completely > > different text processing system. You can compare it if you like, but > > it is not really relevant to the choice of fonts for the png driver. > > > > > For the attached snipplets, the size differences are much bigger. > > > > The fonts, and the image size itself, are larger for your ttf.png example > > than for your builtin.png example. If you color more pixels, then yes the > > image size is larger. But to blame a larger and heavier font for coloring > > more pixels is, I think, a bit disingenuous. On top of that, it is evident > > that the rotation angle in the ttf example is not exactly 90, which > > distorts the characters and causes additional rows of pixels to be colored. > > > > Here is what I get: > > set term png font "courbd,9" > > set output 'rav_courbd.png' > > load 'running_avg.dem' > > ## unsetenv GDFONTPATH > > set term png medium > > set output 'rav_builtin.png' > > load 'running_avg.dem' > > > > chauvet [21] ls -l *.png > > -rw-rw-r-- 1 merritt merritt 7022 2009-02-19 12:43 rav_builtin.png > > -rw-rw-r-- 1 merritt merritt 7496 2009-02-19 12:52 rav_courbd.png > > > > So for fonts that are roughly the same style, size, and weight, > > I get a difference of about 475/7500 = 6% difference in image size. > > > > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta |
