gnuplot-beta — Developers and beta testers of new gnuplot code

Re: gp_cairo.c patch for win32

[Allin C. <cot...@wf...>]

On Thu, 5 Nov 2009, Ethan Merritt wrote:

> On Thursday 05 November 2009 12:21:24 Ethan Merritt wrote:
> >  #if PANGO_VERSION_MAJOR > 1 || PANGO_VERSION_MINOR >= 22
> >    context = pango_font_map_create_context(fontmap);
> >  #else
> >    context = pango_cairo_font_map_create_context(fontmap);
> >  #endif
> >
>
> Sigh.  That doesn't work either:
>
> wxterminal/gp_cairo.c: In function ‘gp_cairo_create_layout’:
> wxterminal/gp_cairo.c:708: warning: passing argument 1 of ‘pango_cairo_font_map_create_context’ from incompatible pointer type

Urgh.  That function wants a pointer to PangoCairoFontMap, not to
PangoFontMap.

> We need a better handle on what versions and configurations this
> alternate code works on.

Yes, I can work on that if you like.  What's the pango version on
your system, BTW?

Allin Cottrell

Re: gp_cairo.c patch for win32

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

On Thursday 05 November 2009 12:21:24 Ethan Merritt wrote:
>  #if PANGO_VERSION_MAJOR > 1 || PANGO_VERSION_MINOR >= 22
>    context = pango_font_map_create_context(fontmap);
>  #else
>    context = pango_cairo_font_map_create_context(fontmap);
>  #endif
> 

Sigh.  That doesn't work either:

wxterminal/gp_cairo.c: In function ‘gp_cairo_create_layout’:
wxterminal/gp_cairo.c:708: warning: passing argument 1 of ‘pango_cairo_font_map_create_context’ from incompatible pointer type


We need a better handle on what versions and configurations this
alternate code works on.


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: gp_cairo.c patch for win32

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

On Thursday 05 November 2009 11:39:19 Allin Cottrell wrote:
> Ah, in the pango docs it says that this is new since pango
> version 1.22.  Maybe conditionalize the relevant line as:
> 
> #if PANGO_VERSION_MAJOR == 1 && PANGO_VERSION_MINOR < 22
>   context = pango_cairo_font_map_create_context(fontmap);
> #else
>   context = pango_font_map_create_context(fontmap);
> #endif
>
> (The first formulation above is now "deprecated".)

Nope. Doesn't help:

p_cairo.o: In function `gp_cairo_create_layout':
/home/merritt/cvs/gnuplot-cvs/src/wxterminal/gp_cairo.c:708: undefined reference to `pango_font_map_create_context'
collect2: ld returned 1 exit status
make[1]: *** [gnuplot] Error 1
make[1]: Leaving directory `/home/merritt/cvs/gnuplot-cvs/src'
make: *** [all-recursive] Error 1

I think it's not picking up the right header, so it doesn't have values
for PANGO_VERSION_* at all.

How about if we turn that around, and see if this works for you

 #if PANGO_VERSION_MAJOR > 1 || PANGO_VERSION_MINOR >= 22
   context = pango_font_map_create_context(fontmap);
 #else
   context = pango_cairo_font_map_create_context(fontmap);
 #endif



-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: gp_cairo.c patch for win32

[Allin C. <cot...@wf...>]

On Thu, 5 Nov 2009, Ethan Merritt wrote:

> On Thursday 05 November 2009 10:57:59 Allin Cottrell wrote:
> > Attached: request that pango/cairo use its FreeType + fontconfig
> > backend when operating on MS Windows.
> >
> > Note: the patch doesn't seem to do any harm on Linux, but perhaps
> > should be made conditional on compilation for Windows.
>
> Doesn't build for me under linux:
>
> wxterminal/gp_cairo.c: In function ‘gp_cairo_create_layout’:
> wxterminal/gp_cairo.c:705: warning: \
implicit declaration of function ‘pango_font_map_create_context’

Ah, in the pango docs it says that this is new since pango
version 1.22.  Maybe conditionalize the relevant line as:

#if PANGO_VERSION_MAJOR == 1 && PANGO_VERSION_MINOR < 22
  context = pango_cairo_font_map_create_context(fontmap);
#else
  context = pango_font_map_create_context(fontmap);
#endif

(The first forulation above is now "deprecated".)

Allin Cottrell

Re: gp_cairo.c patch for win32

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

On Thursday 05 November 2009 10:57:59 Allin Cottrell wrote:
> Attached: request that pango/cairo use its FreeType + fontconfig
> backend when operating on MS Windows.
> 
> Note: the patch doesn't seem to do any harm on Linux, but perhaps
> should be made conditional on compilation for Windows.

Doesn't build for me under linux:

wxterminal/gp_cairo.c: In function ‘gp_cairo_create_layout’:
wxterminal/gp_cairo.c:705: warning: implicit declaration of function ‘pango_font_map_create_context’
wxterminal/gp_cairo.c:705: warning: assignment makes pointer from integer without a cast
gp_cairo.o: In function `gp_cairo_create_layout':
/home/merritt/cvs/gnuplot-cvs/src/wxterminal/gp_cairo.c:705: undefined reference to `pango_font_map_create_context'
collect2: ld returned 1 exit status
make[1]: *** [gnuplot] Error 1
make[1]: Leaving directory `/home/merritt/cvs/gnuplot-cvs/src'
make: *** [all-recursive] Error 1

So yes, we'll have to wrap it in a conditional.
Or maybe we should test for the presence of pango_font_map_create_context()
in the ./configure script?


-- 
Ethan A Merritt

gp_cairo.c patch for win32

[Allin C. <cot...@wf...>]

Attached: request that pango/cairo use its FreeType + fontconfig
backend when operating on MS Windows.

Note: the patch doesn't seem to do any harm on Linux, but perhaps
should be made conditional on compilation for Windows.

-- 
Allin Cottrell
Department of Economics
Wake Forest University

Re: pngcairo performance on Windows

[Allin C. <cot...@wf...>]

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

Re: pngcairo performance on Windows

[Allin C. <cot...@wf...>]

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

Re: pngcairo performance on Windows

[Allin C. <cot...@wf...>]

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

Re: pngcairo performance on Windows

[Tatsuro M. <tma...@ya...>]

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/

Re: pngcairo performance on Windows

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

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

Re: pngcairo performance on Windows

[Allin C. <cot...@wf...>]

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

Re: pngcairo performance on Windows

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

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

Re: pngcairo performance on Windows

[Allin C. <cot...@wf...>]

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

Re: exposing cairo context from gnuplot

[Richard H. <ric...@st...>]

On Mon, 2009-11-02 at 21:36 +0100, Johan wrote:
> Hi,
> 
> I did not try it but it seems to be easy:
> http://old.nabble.com/embedding-gnuplot-x-window-into-gtk-app-ts11670440.html#a11670440

Hi Johan,

My reading of the method described in this post is when you wish to
delegate rendering responsibility for a particular X context to Gnuplot.

My original query on exposing Cairo context is similar, but to be best
of my knowledge unsupported: delegate rendering responsibility for a
particular Cairo context to Gnuplot.

The posts you've found are helpful since they suggest to me a potential
implementation, i.e. 
First create a cairo context within your program then pass the context
id to Gnuplot 'set terminal cairo context ID'

best regards,
Richard
-- 
Scanned by iCritical.

Re: pngcairo performance on Windows

[Timothée L. <tim...@lp...>]

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

Re: pngcairo performance on Windows

[Allin C. <cot...@wf...>]

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

Re: pngcairo performance on Windows

[Tatsuro M. <tma...@ya...>]

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/

Re: pngcairo performance on Windows

[Allin C. <cot...@wf...>]

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

Re: pngcairo performance on Windows

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

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

Re: pngcairo performance on Windows

[Allin C. <cot...@wf...>]

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

Re: pngcairo performance on Windows

[Tatsuro M. <tma...@ya...>]

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
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 


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

Re: exposing cairo context from gnuplot

[Johan <jo...@wo...>]

Hi,

I did not try it but it seems to be easy:
http://old.nabble.com/embedding-gnuplot-x-window-into-gtk-app-ts11670440.html#a11670440

cheers

Re: exposing cairo context from gnuplot

[johan47 <jo...@wo...>]

Hi,
I did not try it but it seems to be easy:
http://old.nabble.com/embedding-gnuplot-x-window-into-gtk-app-ts11670440.html#a11670440
cheers
-- 
View this message in context: http://old.nabble.com/exposing-cairo-context-from-gnuplot-tp25331048p26157820.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Re: exposing cairo context from gnuplot

[johan47 <jo...@wo...>]

Hi,

I did not try it but it seems to be easy:
http://old.nabble.com/embedding-gnuplot-x-window-into-gtk-app-ts11670440.html#a11670440

cheers
-- 
View this message in context: http://old.nabble.com/exposing-cairo-context-from-gnuplot-tp25331048p26157815.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.