gnuplot-beta

png: selecting builtin font impossible?

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

Ethan,

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?

Thanks,
Manfred


-- 
Jetzt 1 Monat kostenlos! GMX FreeDSL - Telefonanschluss + DSL 
für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a

Re: png: selecting builtin font impossible?

[Petr M. <mi...@ph...>]

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

I see this also ... trying

	GDFONTPATH=. gnuplot
or
	GDFONTPATH=/dev/null gnuplot

I get:

gnuplot> set term png tiny; show term; set out '0tiny.png'; test
   terminal type is png nocrop tiny size 640,480
Could not find/open font when opening font "arial", using internal 
non-scalable font

However, the output for tiny, small, giant, ... is correct.

---
PM

Re: png: selecting builtin font impossible?

[Ethan M. <merritt@u.washington.edu>]

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?

Font problems are the most common cause for complaint or requested
support with regard to the png terminal.  Neither enhanced text nor
internationalization work with the built-in fonts.  The rationale
for the change you point to was to make it as hard as possible to
end up with the built-in fonts.  I consider them as only a last
resort to be used in desperation.

Having said that, I would think you could defeat the search for
arial.ttf by clearing the GDFONTPATH environmental variable.
And you can certainly set the default font to something other than
arial.  For example, if you want a mono-spaced font you could set
GNUPLOT_DEFAULT_GDFONT to Courier (postscript font)
or couri (ttf equivalent).

-- 
Ethan A Merritt

Re: png: selecting builtin font impossible?

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

> 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.
   Otherwise I would use vector output (i.e. ps-terminal) and
   convert the resulting vector plot into png. This way I would
   get homogeneous "blurring".
   So for me the question is really 
   "Why would you ever want to NOT to?" (for a pixel terminal).

3) For 90 degree rotated text, font quality for non-builtin
   fonts is really bad. I can send examples if you like.

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.

> Font problems are the most common cause for complaint or requested
> support with regard to the png terminal.  Neither enhanced text nor
> internationalization work with the built-in fonts.  The rationale
> for the change you point to was to make it as hard as possible to
> end up with the built-in fonts.  I consider them as only a last
> resort to be used in desperation.
> 

Hmm, setting the default is one thing. Taking away the choice is
another thing. 

Cheers,
Manfred



> Having said that, I would think you could defeat the search for
> arial.ttf by clearing the GDFONTPATH environmental variable.
> And you can certainly set the default font to something other than
> arial.  For example, if you want a mono-spaced font you could set
> GNUPLOT_DEFAULT_GDFONT to Courier (postscript font)
> or couri (ttf equivalent).
> 
> -- 
> Ethan A Merritt

-- 
Jetzt 1 Monat kostenlos! GMX FreeDSL - Telefonanschluss + DSL 
für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a

Re: png: selecting builtin font impossible?

[Ethan M. <merritt@u.washington.edu>]

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?

>    Otherwise I would use vector output (i.e. ps-terminal) and
>    convert the resulting vector plot into png. This way I would
>    get homogeneous "blurring".
>    So for me the question is really 
>    "Why would you ever want to NOT to?" (for a pixel terminal).

It sounds to me that you might have a font problem external to
gnuplot per se, but I don't know what it might be.

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

> > Font problems are the most common cause for complaint or requested
> > support with regard to the png terminal.  Neither enhanced text nor
> > internationalization work with the built-in fonts.  The rationale
> > for the change you point to was to make it as hard as possible to
> > end up with the built-in fonts.  I consider them as only a last
> > resort to be used in desperation.
> > 
> 
> Hmm, setting the default is one thing. Taking away the choice is
> another thing. 

If you always want to use the gd built-in fonts, then it seems to
make sense to simply remove GDFONTPATH from the environment in 
which your web applications run.



 
> Cheers,
> Manfred
> 
> 
> 
> > Having said that, I would think you could defeat the search for
> > arial.ttf by clearing the GDFONTPATH environmental variable.
> > And you can certainly set the default font to something other than
> > arial.  For example, if you want a mono-spaced font you could set
> > GNUPLOT_DEFAULT_GDFONT to Courier (postscript font)
> > or couri (ttf equivalent).
> > 
> > -- 
> > Ethan A Merritt



-- 
Ethan A Merritt

Re: png: selecting builtin font impossible?

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

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


> >    Otherwise I would use vector output (i.e. ps-terminal) and
> >    convert the resulting vector plot into png. This way I would
> >    get homogeneous "blurring".
> >    So for me the question is really 
> >    "Why would you ever want to NOT to?" (for a pixel terminal).
> 
> It sounds to me that you might have a font problem external to
> gnuplot per se, but I don't know what it might be.
> 
> > 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. The upper strings are done with "set label" in combination
with "splot", the lower ones are plotted with "set label" in a 
"plot" plot. The upper labels seem to be of higher quality than
the lower ones, somehow.
Please ignore the bad text alignment in the plots, just look at the
characters themself.


> > 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%
For the attached snipplets, the size differences are much bigger.


> > > Font problems are the most common cause for complaint or requested
> > > support with regard to the png terminal.  Neither enhanced text nor
> > > internationalization work with the built-in fonts.  The rationale
> > > for the change you point to was to make it as hard as possible to
> > > end up with the built-in fonts.  I consider them as only a last
> > > resort to be used in desperation.
> > > 
> > 
> > Hmm, setting the default is one thing. Taking away the choice is
> > another thing. 
> 
> If you always want to use the gd built-in fonts, then it seems to
> make sense to simply remove GDFONTPATH from the environment in 
> which your web applications run.
>


Yes, this works for me.


Thanks,
Manfred


> 
> 
>  
> > Cheers,
> > Manfred
> > 
> > 
> > 
> > > Having said that, I would think you could defeat the search for
> > > arial.ttf by clearing the GDFONTPATH environmental variable.
> > > And you can certainly set the default font to something other than
> > > arial.  For example, if you want a mono-spaced font you could set
> > > GNUPLOT_DEFAULT_GDFONT to Courier (postscript font)
> > > or couri (ttf equivalent).
> > > 
> > > -- 
> > > Ethan A Merritt
> 
> 
> 
> -- 
> Ethan A Merritt

-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01

Re: png: selecting builtin font impossible?

[Ethan M. <merritt@u.washington.edu>]

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.

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

-- 
Ethan A Merritt

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

Re: png: selecting builtin font impossible?

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

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

Re: png: selecting builtin font impossible?

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

<snip>

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

Baa, I missed a hunk of this commit, here it is:

--- term_api.h	2008/07/09 16:39:50	1.74
+++ term_api.h	2008/09/16 05:35:25	1.75
@@ -1,5 +1,5 @@
 /*
- * $Id: term_api.h,v 1.74 2008/07/09 16:39:50 mikulik Exp $
+ * $Id: term_api.h,v 1.75 2008/09/16 05:35:25 sfeam Exp $
  */
 
 /* GNUPLOT - term_api.h */
@@ -59,9 +59,10 @@
 #define LT_DEFAULT    (-7)
 
 /* Constant value passed to (term->text_angle)(ang) to generate vertical
- * text. Current implementation has ang equal to rotation in degrees.
+ * text corresponding to old keyword "rotate", which produced the equivalent
+ * of "rotate by 90 right-justified".
  */
-#define TEXT_VERTICAL (90)
+#define TEXT_VERTICAL (-270)
 
 
 /* Type definitions */



Before 20080916, I get angle=90, TEXT_VERTICAL=90 for
the vertical label in my example and therefore we get into the
first case: x += t->v_char;

After this date, I get angle=0, TEXT_VERTICAL=-270, and
we fall into case 3: y -= t->v_char;


I will stop tracing this issue now, I hope someone can
pursue this some further.


Cheers,
Manfred

<snip>

-- 
Jetzt 1 Monat kostenlos! GMX FreeDSL - Telefonanschluss + DSL 
für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a

Re: png: selecting builtin font impossible?

[Ethan A M. <merritt@u.washington.edu>]

On Monday 23 February 2009, Manfred Schwarb wrote:
> 
> 
> 
> Before 20080916, I get angle=90, TEXT_VERTICAL=90 for
> the vertical label in my example and therefore we get into the
> first case: x += t->v_char;
> 
> After this date, I get angle=0, TEXT_VERTICAL=-270, and
> we fall into case 3: y -= t->v_char;

What terminal are you using, that seems to think an angle of
-270 is different from an angle of 90?   The ones I have tested
here do not seem to have any problem with it.
 
> I will stop tracing this issue now, I hope someone can
> pursue this some further.

We'll need a simple script that demonstrates the bug,
and a note on which terminal type is affected.

-- 
Ethan A Merritt

Re: png: selecting builtin font impossible?

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

> On Monday 23 February 2009, Manfred Schwarb wrote:
> > 
> > 
> > 
> > Before 20080916, I get angle=90, TEXT_VERTICAL=90 for
> > the vertical label in my example and therefore we get into the
> > first case: x += t->v_char;
> > 
> > After this date, I get angle=0, TEXT_VERTICAL=-270, and
> > we fall into case 3: y -= t->v_char;
> 
> What terminal are you using, that seems to think an angle of
> -270 is different from an angle of 90?   The ones I have tested
> here do not seem to have any problem with it.
>  
> > I will stop tracing this issue now, I hope someone can
> > pursue this some further.
> 
> We'll need a simple script that demonstrates the bug,
> and a note on which terminal type is affected.
> 

Is the script I have added to an earlier email enough, or do you
want me to reduce it some more?

Terminal: as I stated, pngcairo is OK, I see this effect only
with libgd ("set term png"). I did not test any other terminals.


Manfred



> -- 
> Ethan A Merritt

-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01

Re: png: selecting builtin font impossible?

[Ethan M. <merritt@u.washington.edu>]

On Monday 23 February 2009 08:38:40 Manfred Schwarb wrote:
> 
> > On Monday 23 February 2009, Manfred Schwarb wrote:
> > > 
> > > 
> > > 
> > > Before 20080916, I get angle=90, TEXT_VERTICAL=90 for
> > > the vertical label in my example and therefore we get into the
> > > first case: x += t->v_char;
> > > 
> > > After this date, I get angle=0, TEXT_VERTICAL=-270, and
> > > we fall into case 3: y -= t->v_char;
> > 
> > What terminal are you using, that seems to think an angle of
> > -270 is different from an angle of 90?   The ones I have tested
> > here do not seem to have any problem with it.
> >  
> > > I will stop tracing this issue now, I hope someone can
> > > pursue this some further.
> > 
> > We'll need a simple script that demonstrates the bug,
> > and a note on which terminal type is affected.
> > 
> 
> Is the script I have added to an earlier email enough, or do you
> want me to reduce it some more?
> 
> Terminal: as I stated, pngcairo is OK, I see this effect only
> with libgd ("set term png"). I did not test any other terminals.

OK, considering only the png terminal (gd.trm) it seems there may
be a bug in some versions of libgd that causes the text alignment
to behave badly if the angular setting is outside the range 
-180 < angle < 180.

The following patch may improve things:

--- gnuplot/term/gd.trm 2008-12-01 11:33:06.000000000 -0800
+++ gnuplot-cvs/term/gd.trm     2009-02-23 13:38:40.000000000 -0800
@@ -1672,6 +1677,8 @@ PNG_put_text(unsigned int x, unsigned in
 TERM_PUBLIC int
 PNG_text_angle(int ang)
 {
+    while (ang < -180) ang += 360;
+    while (ang >  180) ang -= 360;
     png_state.angle = ang;
     return TRUE;
 }

Please let me know if that fixes your problem or not.


-- 
Ethan A Merritt

Re: png: selecting builtin font impossible?

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

-------- Original-Nachricht --------
> Datum: Mon, 23 Feb 2009 13:48:11 -0800
> Von: Ethan Merritt <merritt@u.washington.edu>
> An: "Manfred Schwarb" <man...@gm...>
> CC: gnu...@li...
> Betreff: Re: png: selecting builtin font impossible?

> On Monday 23 February 2009 08:38:40 Manfred Schwarb wrote:
> > 
> > > On Monday 23 February 2009, Manfred Schwarb wrote:
> > > > 
> > > > 
> > > > 
> > > > Before 20080916, I get angle=90, TEXT_VERTICAL=90 for
> > > > the vertical label in my example and therefore we get into the
> > > > first case: x += t->v_char;
> > > > 
> > > > After this date, I get angle=0, TEXT_VERTICAL=-270, and
> > > > we fall into case 3: y -= t->v_char;
> > > 
> > > What terminal are you using, that seems to think an angle of
> > > -270 is different from an angle of 90?   The ones I have tested
> > > here do not seem to have any problem with it.
> > >  
> > > > I will stop tracing this issue now, I hope someone can
> > > > pursue this some further.
> > > 
> > > We'll need a simple script that demonstrates the bug,
> > > and a note on which terminal type is affected.
> > > 
> > 
> > Is the script I have added to an earlier email enough, or do you
> > want me to reduce it some more?
> > 
> > Terminal: as I stated, pngcairo is OK, I see this effect only
> > with libgd ("set term png"). I did not test any other terminals.
> 
> OK, considering only the png terminal (gd.trm) it seems there may
> be a bug in some versions of libgd that causes the text alignment
> to behave badly if the angular setting is outside the range 
> -180 < angle < 180.
> 
> The following patch may improve things:
> 
> --- gnuplot/term/gd.trm 2008-12-01 11:33:06.000000000 -0800
> +++ gnuplot-cvs/term/gd.trm     2009-02-23 13:38:40.000000000 -0800
> @@ -1672,6 +1677,8 @@ PNG_put_text(unsigned int x, unsigned in
>  TERM_PUBLIC int
>  PNG_text_angle(int ang)
>  {
> +    while (ang < -180) ang += 360;
> +    while (ang >  180) ang -= 360;
>      png_state.angle = ang;
>      return TRUE;
>  }
> 
> Please let me know if that fixes your problem or not.


Yes, this fixes it.

Thanks,
Manfred

> 
> 
> -- 
> Ethan A Merritt

-- 
Computer Bild Tarifsieger! GMX FreeDSL - Telefonanschluss + DSL
für nur 17,95 ¿/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a