Re: png: selecting builtin font impossible?

[Manfred S. <man...@gm...>]

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


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