gnuplot development

On Mon, 2 Nov 2009, Allin Cottrell wrote:

> It seems there is something not quite right with font-handling
> under the pngcairo terminal on Windows...
>
> The issue is that the extremities of text get clipped in some
> contexts. This is with CVS gnuplot built for win32 with
> pango/cairo support.

Sorry, I should have mentioned: I'm currently using pango 1.26.0
and cairo 1.8.8.  But the problem doesn't seem to be sensitive
to the versions of these DLLs -- I saw the same with pango 1.24.5.

Allin Cottrell

Hello

I have a cvs version of the gnuplot in which the pngpango terminal is available.
However, I myself does not use bitmap based terminal
(In case of bitmap graph is required, I always use eps term and translate eps to png or jpeg).

Please show me a script to relveal your problem.

I'll try to test on my cvs version of gnuplot.

Or you can try it by yourself, using my distribution of cvs versions of gnuplot at 

http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/ 

Regards

Tatsuro

--- Allin Cottrell wrote:

> 
> It seems there is something not quite right with font-handling
> under the pngcairo terminal on Windows.  I suspect the problem
> lies somewhere in the pango/cairo stack for Windows but I thought
> I'd start here in case anyone has any ideas.
> 
> The issue is that the extremities of text get clipped in some
> contexts. This is with CVS gnuplot built for win32 with
> pango/cairo support.  I haven't seen this using pngcairo on Linux.
> 
> I suppose the first thing is to see if others can replicate the
> problem.  I've put a simple test file and four examples of PNG
> output (v8.png uses the verdana font at 8 points and v9 uses
> verdana at 9 points; the others use the default font for
> pngcairo).  These PNGs show bits of the letter 'Q' being clipped,
> plus, in some cases, bits of the x-axis numerals missing.
> 
> Do others see this?
> 
> -- 
> Allin Cottrell
> Department of Economics
> Wake Forest University
> 
> 
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> gnuplot-beta mailing list
> gnuplot-beta@...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 


--------------------------------------
GyaO! - Anime, Dramas, Movies, and Music videos [FREE]
http://pr.mail.yahoo.co.jp/gyao/

On Tue, 3 Nov 2009, Tatsuro MATSUOKA wrote:

> I have a cvs version of the gnuplot in which the pngpango
> terminal is available. However, I myself does not use bitmap
> based terminal (In case of bitmap graph is required, I always
> use eps term and translate eps to png or jpeg).
>
> Please show me a script to relveal your problem.
> I'll try to test on my cvs version of gnuplot.

Thank you.  There's a gnuplot script (along with examples of PNG
output) at

http://www.wfu.edu/~cottrell/gptest/

(The script is pngtest.plt)

> Or you can try it by yourself, using my distribution of cvs
> versions of gnuplot at
>
> http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/

Thanks again, I'll see if I can test with your build.

My feeling is that the pngcairo terminal is basically much
preferable to the libgd-based png terminal, so it is worth
ensuring that pngcairo output is as good as it can be.

Allin Cottrell

On Monday 02 November 2009 13:34:38 Tatsuro MATSUOKA wrote:
> Hello
> 
> I have a cvs version of the gnuplot in which the pngpango terminal is available.
> However, 
> 
> Or you can try it by yourself, using my distribution of cvs versions of gnuplot at 
> 
> http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/ 

I have tried your recent version (31 October) under linux+wine.
I find that it has a strange problem with all fonts.  
The font in the image is extremely large, maybe 100 times (?) larger than requested.
This makes it impossible to check for the specific problem that 
Allin refers to.

Of course, the problem I see may be an artifact of testing under linux + wine,
rather than MSWin.  Does it behave properly under MSWin?

	cheers,

		Ethan



> Regards
> 
> Tatsuro
> 
> --- Allin Cottrell wrote:
> 
> > 
> > It seems there is something not quite right with font-handling
> > under the pngcairo terminal on Windows.  I suspect the problem
> > lies somewhere in the pango/cairo stack for Windows but I thought
> > I'd start here in case anyone has any ideas.
> > 
> > The issue is that the extremities of text get clipped in some
> > contexts. This is with CVS gnuplot built for win32 with
> > pango/cairo support.  I haven't seen this using pngcairo on Linux.
> > 
> > I suppose the first thing is to see if others can replicate the
> > problem.  I've put a simple test file and four examples of PNG
> > output (v8.png uses the verdana font at 8 points and v9 uses
> > verdana at 9 points; the others use the default font for
> > pngcairo).  These PNGs show bits of the letter 'Q' being clipped,
> > plus, in some cases, bits of the x-axis numerals missing.
> > 
> > Do others see this?
> > 
> > -- 
> > Allin Cottrell
> > Department of Economics
> > Wake Forest University
> > 

-- 
Ethan A Merritt

On Mon, 2 Nov 2009, Allin Cottrell wrote:

[about a problem with pngcairo on MS Windows]

> I suppose the first thing is to see if others can replicate the
> problem.  I've put a simple test file and four examples of PNG
> output (v8.png uses the verdana font at 8 points and v9 uses
> verdana at 9 points; the others use the default font for
> pngcairo).

Sorry, too hasty: I've "put" these, but where?  Here's where:

http://www.wfu.edu/~cottrell/gptest/

Allin Cottrell

Hello Allin Cottrell and Ethan Merritt

> I have a cvs version of the gnuplot in which the pngpango
> terminal is available. However, I myself does not use bitmap
> based terminal (In case of bitmap graph is required, I always
> use eps term and translate eps to png or jpeg).
>
> Please show me a script to relveal your problem.
> I'll try to test on my cvs version of gnuplot.

Thank you.  There's a gnuplot script (along with examples of PNG
output) at

http://www.wfu.edu/~cottrell/gptest/

I have tested for both gnuplot built on MinGW and Cygwin-1.7.
I understand what you would like to say to see the differnce in both png files.


http://www.geocities.jp/tmgpltwin/Files/Files.html

0024 deffont2TMwin.png, 14,992 bytes, 2009-11-03
0025 deffont2TMcyg.png, 13,197 bytes, 2009-11-03

deffont2TMwin.png is similar to  deffont2.png on your web.

For a png file produced by the gnuplot for cygwin-1.7 looks fine.

As you pointed out, this problem is intrisic to pngcairo on at least MinGW.
I do not know how gnuplot built by MSVC will give results.

For pdfcairo, pdf outputs are fine for both gnuplot on MinGW and on Cygwin-1.7

0026 deffont2TMwin.pdf, 6,762 bytes, 2009-11-03
0027 deffont2TMcyg.pdf, 8,641 bytes, 2009-11-03



*********
Ethan wrote:

***********
> http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/ 

I have tried your recent version (31 October) under linux+wine.
I find that it has a strange problem with all fonts.  
The font in the image is extremely large, maybe 100 times (?) larger than requested.
This makes it impossible to check for the specific problem that 
Allin refers to.

Of course, the problem I see may be an artifact of testing under linux + wine,
rather than MSWin.  Does it behave properly under MSWin?
************
It would be a little bit bigger than that expected as shown deffont2TMwin.png in the above but not 100
times on windows XP Home sp3.

Regards

Tatsuro



--------------------------------------
GyaO! - Anime, Dramas, Movies, and Music videos [FREE]
http://pr.mail.yahoo.co.jp/gyao/

On Tue, 3 Nov 2009, Tatsuro MATSUOKA wrote:

> Hello Allin Cottrell and Ethan Merritt
>
> I have tested for both gnuplot built on MinGW and Cygwin-1.7.
> I understand what you would like to say to see the differnce in
> both png files.
>
> http://www.geocities.jp/tmgpltwin/Files/Files.html
>
> 0024 deffont2TMwin.png, 14,992 bytes, 2009-11-03
> 0025 deffont2TMcyg.png, 13,197 bytes, 2009-11-03

Thanks for making these.

> deffont2TMwin.png is similar to  deffont2.png on your web.

Yes, missing pixels at the bottom of the title.

> For a png file produced by the gnuplot for cygwin-1.7 looks fine.

Hmm, that's interesting.

> As you pointed out, this problem is intrisic to pngcairo on at least MinGW.
> I do not know how gnuplot built by MSVC will give results.
>
> For pdfcairo, pdf outputs are fine for both gnuplot on MinGW and
> on Cygwin-1.7

Yes, I agree, no problem with PDF output.

I have an idea of what might help pngcairo/mingw, but I need to do
some testing on Windows to make sure I know what I'm taking about.

Allin Cottrell

Ethan Merritt a écrit :
> On Monday 02 November 2009 13:34:38 Tatsuro MATSUOKA wrote:
>   
>> Hello
>>
>> I have a cvs version of the gnuplot in which the pngpango terminal is available.
>> However, 
>>
>> Or you can try it by yourself, using my distribution of cvs versions of gnuplot at 
>>
>> http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/ 
>>     
>
> I have tried your recent version (31 October) under linux+wine.
> I find that it has a strange problem with all fonts.  
> The font in the image is extremely large, maybe 100 times (?) larger than requested.
> This makes it impossible to check for the specific problem that 
> Allin refers to.
>
> Of course, the problem I see may be an artifact of testing under linux + wine,
> rather than MSWin.  Does it behave properly under MSWin?
>
> 	cheers,
>
> 		Ethan
>
>
>
>   
Hi Ethan,

The "very large font" issue comes from Wine only, and is fixed in recent 
releases. The stable 1.0 Wine release is affected by this bug though. 
See http://bugs.winehq.org/show_bug.cgi?id=14688 for example.

Best regards,

Timothée

On Mon, 2 Nov 2009, Allin Cottrell wrote:

> I have an idea of what might help pngcairo/mingw, but I need to do
> some testing on Windows to make sure I know what I'm taking about.

s/taking/talking.  But anyway, I think I have one piece of the
puzzle.

In src/wxterminal/gp_cairo.c, in the function gp_cairo_draw_text,
at lines 749 to 752, we originally had:

 vert_just = ((double)ink_rect.height/2 +(double)ink_rect.y) /
             PANGO_SCALE;

where "ink_rect" is filled out via pango_layout_get_extents().
I presume this is code that Timothee wrote (?).

In March 2009 Ethan disabled this line and substituted

 vert_just = avg_vchar/2;

with the comment 'Adjusting the vertical position for every
character fragment leads to uneven baselines.  Better to adjust to
the "average" character height.'

I just did two builds of current CVS gnuplot for win32 -- one "as
is" (A) and one in which I reverted the March 2009 change in
respect of "vert_just" (B) -- and ran the following script on
Vista for each build:

<script>
set term pngcairo font "verdana,8"
set output 'test8.png'
set title 'Qyg0a'
set ylabel 'Qyg0a'
set xrange [0:300.8]
plot x title 'Qyg0a8'

set term pngcairo font "verdana,9"
set output 'test9.png'
plot x title 'Qyg0a9'
</script>

Results:

8-point font: Using build A the title at top has missing pixels
from the bottom of 'Q', 'y' and 'g'; using build B the title is
rendered without missing pixels. The ylabel (rotated) has pixels
missing from the 'Q' in the output from both builds.

9-point font: Using build A both the title and the ylabel have
pixels missing from the bottom of the letters that extend below
(or, for the rotated yabel, to the right of) the baseline.  This
is fixed using build B.

I have put the PNG output files (test8a.png, test9a.png from build
A; test8b.png, test9b.png from build B) in

http://www.wfu.edu/~cottrell/gptest/

I find that the differences are seen most easily by opening both
test8a.png and test8b.png (or test9a and test9b) in xv, and
toggling between them.

Allin Cottrell

On Tuesday 03 November 2009 09:39:33 Allin Cottrell wrote:
> 
> On Mon, 2 Nov 2009, Allin Cottrell wrote:

> I think I have one piece of the puzzle.

I'm not convinced.  I suspect that the change you see may be an
artifact of shifting the character position by 1 or 2 pixels.
See comments below.

More importantly...
I have begun to wonder if the involvment of cairo may be a red herring.  
The problem may be more general than that.
Have a look at Bug report

1918293  	 "Copy to Clipboard" on MS-Win32 clip "tails" of p,g,q and y

https://sourceforge.net/tracker/?func=detail&aid=1918293&group_id=2055&atid=102055

Could this be the same problem, but involving the
windows terminal rather than the cairo terminal?  
Could it be that the real problem is with the font itself?  
Or with some very low level Windows font rendering code that is shared by
cairo and by the windows terminal?


> In src/wxterminal/gp_cairo.c, in the function gp_cairo_draw_text,
> at lines 749 to 752, we originally had:
> 
>  vert_just = ((double)ink_rect.height/2 +(double)ink_rect.y) /
>              PANGO_SCALE;
> 
> where "ink_rect" is filled out via pango_layout_get_extents().
> I presume this is code that Timothee wrote (?).
> 
> In March 2009 Ethan disabled this line and substituted
> 
>  vert_just = avg_vchar/2;
> 
> with the comment 'Adjusting the vertical position for every
> character fragment leads to uneven baselines.  Better to adjust to
> the "average" character height.'

So?   vert_just is just an offset in gnuplot's coordinate space.
It affects the pixel coordinate pair (x,y) where we request that
the text be rendered, but it does not alter anything I can see
about how that text is requested.  I am wondering whether the bug
in the underlying cairo/pango library comes down to a question
of whether the x coordinate integer value is even or odd.
 
> [snip script] 

> I have put the PNG output files (test8a.png, test9a.png from build
> A; test8b.png, test9b.png from build B) in
> 
> http://www.wfu.edu/~cottrell/gptest/
> 
> I find that the differences are seen most easily by opening both
> test8a.png and test8b.png (or test9a and test9b) in xv, and
> toggling between them.

But both of those renderings are different from the output of the same 
script run under linux. Here are blow-ups of the character rendering in 
your 9a/9b examples and the output of the same script + font request 
run on linux. 

  http://skuld.bmsc.washington.edu/~merritt/gnuplot/cairobug/windows_9a.png
  http://skuld.bmsc.washington.edu/~merritt/gnuplot/cairobug/windows_9b.png
  http://skuld.bmsc.washington.edu/~merritt/gnuplot/cairobug/linux_9.png

One immediately obvious difference is antialiasing -- the windows
versions are not using it.  

A less obvious difference is that in both windows output images the character
position (at least that of the "Q") is shifted to the right and down by 
1 or 2 pixels relative to the linux output.  I am suspicious that this pixel 
shift may be the real problem.  It smells of an off-by-one error in some
copy operation.

-- 
Ethan A Merritt

On Tue, 3 Nov 2009, Ethan Merritt wrote:

> On Tuesday 03 November 2009 09:39:33 Allin Cottrell wrote:
> >
> > On Mon, 2 Nov 2009, Allin Cottrell wrote:
>
> > I think I have one piece of the puzzle.
>
> I'm not convinced.  I suspect that the change you see may be an
> artifact of shifting the character position by 1 or 2 pixels.
> See comments below.
>
> More importantly...
> I have begun to wonder if the involvment of cairo may be a red herring.
> The problem may be more general than that.
> Have a look at Bug report
>
> 1918293  	 "Copy to Clipboard" on MS-Win32 clip "tails" of p,g,q and y
>
> https://sourceforge.net/tracker/?func=detail&aid=1918293&group_id=2055&atid=102055
>
> Could this be the same problem, but involving the
> windows terminal rather than the cairo terminal?
> Could it be that the real problem is with the font itself?
> Or with some very low level Windows font rendering code that is shared by
> cairo and by the windows terminal?

Yes, this could be.  I understand that pango uses FreeType for
font-handling on Linux, but uses "native" win32 font-handling on
MS Windows.  Maybe the difference lies there.  If so, I have no
idea if the bug lies in the underlying win32 font routines or in
pango's interface to them.

(As a guess, I'd be surprised if there's an outright bug in
Windows font-handling, since this seems to be a point of pride in
an OS that's otherwise cr*p, but I can well believe that the
documentation for these routines is obscure or misleading.)

Allin Cottrell

On Tuesday 03 November 2009 15:06:14 Allin Cottrell wrote:
> 
> Yes, this could be.  I understand that pango uses FreeType for
> font-handling on Linux, but uses "native" win32 font-handling on
> MS Windows.  Maybe the difference lies there.  If so, I have no
> idea if the bug lies in the underlying win32 font routines or in
> pango's interface to them.

This seems directly relevant, if not very hopeful:

  http://old.nabble.com/Font-Quality-Windows-Vista64-td21729133.html

And this may be relevant also (not sure)

  http://lists.cairographics.org/archives/cairo/2008-January/012647.html

Also it seems there are relevant known problems on the Cairo project
TODO list.

  http://cairographics.org/todo/

Might it be worth forwarding this whole problem to a cairo developer list?


-- 
Ethan A Merritt

Hello

--- Allin Cottrell wrote:
> > For a png file produced by the gnuplot for cygwin-1.7 looks fine.
> 
> Hmm, that's interesting.
> 

I have googled about GTK+ on Cygwin. It uses X windows on cygwin so that it is natural that pngcairo
terminal on Cygwin-1.7 behaves the same as that on true Unix distribution.

****************
BTW, cairo based terminal can be constructed only on Cygwin 1.7 without building the cairo and pango
related libraries by users.  This is because the cairo and pango libraries distributed on Cygwin-1.5
are old and the cairo and pango related libraries has been updated to the newer one only on
Cygwin-1.7.

I am distributing cvs Verina gnuplot on Cygwin at

http://www.tatsuromatsuoka.com/gnuplot/Eng/cygbin/

>From I have started disturbing Cygwin-1.7 version, the number of the page counter rapidly began to
increase.  That's very interacting for me.

Regards

Tatsuro
 

--------------------------------------
GyaO! - Anime, Dramas, Movies, and Music videos [FREE]
http://pr.mail.yahoo.co.jp/gyao/

On Wed, 4 Nov 2009, Tatsuro MATSUOKA wrote:

> --- Allin Cottrell wrote:
> > > For a png file produced by the gnuplot for cygwin-1.7 looks fine.
> >
> > Hmm, that's interesting.
>
> I have googled about GTK+ on Cygwin. It uses X windows on cygwin
> so that it is natural that pngcairo terminal on Cygwin-1.7
> behaves the same as that on true Unix distribution.

Ah, I was thinking that might be the case; thank you for
confirming this.

Allin Cottrell

On Tue, 3 Nov 2009, Ethan Merritt wrote:

> On Tuesday 03 November 2009 15:06:14 Allin Cottrell wrote:
> >
> > Yes, this could be.  I understand that pango uses FreeType for
> > font-handling on Linux, but uses "native" win32 font-handling on
> > MS Windows.  Maybe the difference lies there.  If so, I have no
> > idea if the bug lies in the underlying win32 font routines or in
> > pango's interface to them.
>
> This seems directly relevant, if not very hopeful:
>
>   http://old.nabble.com/Font-Quality-Windows-Vista64-td21729133.html

Agreed.

> And this may be relevant also (not sure)
>
>   http://lists.cairographics.org/archives/cairo/2008-January/012647.html

Hmm, not sure either.

> Also it seems there are relevant known problems on the Cairo project
> TODO list...
>
> Might it be worth forwarding this whole problem to a cairo
> developer list?

Yes, that seems a good idea to me.  On the face of it, we're
hitting a problem in the pango/cairo win32 backend.

Allin Cottrell

On Tue, 3 Nov 2009, Ethan Merritt wrote:

> This seems directly relevant, if not very hopeful:
>
>   http://old.nabble.com/Font-Quality-Windows-Vista64-td21729133.html

Actually quite hopeful!  I have made a build of gnuplot for win32
in which I take Behdad Esfahbod's hint (in his message of 3
January); that is, I use pango_cairo_font_map_new_for_font_type
to force use of the pangocairo-fc backend ("fc" = FreeType plus
fontconfig) rather than the pangocairo-win32 one.

This will work only if the Windows system has pango built with
support for FreeType and fontconfig, and those libraries are
available.  But that should be the default, when using the win32
DLLs from http://www.gtk.org/download-windows.html . (And failing
this, gnuplot should fall back to using the win32 font backend.)

I have generated new test PNGs (on MS Vista) that have no problem
with missing extremities of fonts:

http://www.wfu.edu/~cottrell/gptest/test8-fc.png
http://www.wfu.edu/~cottrell/gptest/test9-fc.png

And in this build I undid the reversion of Ethan's small change to
the code in gp_cairo.c, in relation to "vert_just" (i.e. changed
that back to the way it is in CVS).

I'll clean up my patch to gp_cairo.c and send it in shortly.

Allin Cottrell