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

emf term and "set encoding"

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

At present the EMF terminal pays no heed to "set encoding".  This 
means, for example, that if, on Linux, you create a plot file with 
strings encoded in CP1250 and do

set encoding cp1250
set term emf
set output 'foo.emf'
<plot stuff with strings>

You get an EMF file with blanks or funny stuff where the Eastern 
European accented characters should be.

The attached patch fixes this for cp1250, and also contains a 
tentative fix for iso_8859_9, mapping it onto Windows' 
TURKISH_CHARSET.  It's possible that one could map koi8r onto 
RUSSIAN_CHARSET, I'm not sure.  But cp1250 I'm sure about.

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC

Re: utf8 and postscript

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

On Saturday 05 January 2008 20:09, you wrote:
> On Sat, 5 Jan 2008, Ethan A Merritt wrote:
> 
> > On Saturday 05 January 2008 17:45, Allin Cottrell wrote:
> > > But this makes me wonder: if the default alternative to 
> > > "adobeglyphnames" doesn't work with the default postscript font, 
> > > why is adobeglyphnames not the default?
> >
> > If you really need UTF8 my guess is that you are 
> > more likely to use a non-Adobe font...
> 
> It would be great if things worked equally nicely on feeding UTF-8 
> encoded input to the PostScript terminal, but I understand that's 
> not trivial to arrange.

I am agreeable to changing the default to "adobeglyphnames".
We'll see if anyone notices and/or complains.

The UTF8 support is very new and I think it will end up needing 
additional tweaks anyhow.  I am working [slowly] on a modification that
would allow you to specify a separate "mathfont" when you select the
terminal. Characters in Unicode pages 0 and 1 would use the primary font,
characters above that would use the math font instead.  That is useful
because none of the Adobe fonts that I know of contain both the complete
set of European language characters and a useful set of math/physics
symbols.  

You can of course switch fonts explicitly for the special characters,
but that kind of defeats the purpose of using UTF8 text strings.
The alternative right now is to use a single, non-Adobe font that
contains a larger set of characters.  That's where the issue of
non-Adobe glyph names came in.

I am largely fumbling in the dark here.  Before Thomas Henlich came
in with a patch to support UTF8, I didn't even realize it was possible.
Even with Thomas' help I haven't managed to persuade it to use any
CJK font.  As you point out, UTF8 "just works" in the newer formats
like svg and pdf.  So it make not be worth the struggle to get more
than a minimal implementation working in the postscript terminals.

-- 
Ethan A Merritt

Re: utf8 and postscript

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

On Sat, 5 Jan 2008, Ethan A Merritt wrote:

> On Saturday 05 January 2008 17:45, Allin Cottrell wrote:
> > But this makes me wonder: if the default alternative to 
> > "adobeglyphnames" doesn't work with the default postscript font, 
> > why is adobeglyphnames not the default?
> 
> Because most UTF8 fonts are not from Adobe, or at least that was 
> my thinking.  The Adobe fonts have very few non-latin1 
> characters, so if you really need UTF8 my guess is that you are 
> more likely to use a non-Adobe font...

OK, I see your point.  From my point of view, however, the 
attraction of the UTF-8 encoding is not so much that it offers 
access to truly arcane characters (though that is nice in itself) 
but rather that it enables the programmer to disregard differences 
between locales.

With the current pngcairo and pdfcairo terminals one can include 
UTF-8 encoded strings in a plot file (be they plain ASCII, 
Italian, Polish, or whatever) and things will "just work" (given a 
decent font); we don't have to mess with alternate 
iso_8859_whatever's.  This is very nice.

It would be great if things worked equally nicely on feeding UTF-8 
encoded input to the PostScript terminal, but I understand that's 
not trivial to arrange.

(I also understand that however nicely the handling of encodings 
is set up, the output will contain blanks if the chosen font 
doesn't actually contain the glyphs that are requested.)

Allin Cottrell

Re: utf8 and postscript

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

On Saturday 05 January 2008 17:45, Allin Cottrell wrote:
> Thanks for the hint!  I find that if I take my original UTF-8 
> encoded Polish graph, and put
> 
>   set encoding utf8
>   set term post eps color adobeglyphnames
> 
> at the top, it then works fine.
> 
> But this makes me wonder: if the default alternative to 
> "adobeglyphnames" doesn't work with the default postscript font, 
> why is adobeglyphnames not the default?

Because most UTF8 fonts are not from Adobe, or at least that
was my thinking.  The Adobe fonts have very few non-latin1 characters,
so if you really need UTF8 my guess is that you are more likely to
use a non-Adobe font.  But it's only a guess.   In going over Thomas
Henlich's UTF8 patch, I was focused more on access to UTF8 
greek/symbol/math fonts than on the code pages for non-latin1 European
languages. 

I suppose we could special-case the standard Adobe fontnames
  Helvetica Times-Roman Palatino Courier
but that might be more confusing than treating all fonts equivalently.

Another thought is to make the "{no}adobeglyphnames" be
a sub-option to "fontfile" rather than have it apply to all
fonts.  But I'm not sure that would work internally. 

In any case, I think the next version of the user manual should
have a separate section on fonts.  It is a perennial headache,
and not just for PostScript.

-- 
Ethan A Merritt

Re: utf8 and postscript

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

On Fri, 4 Jan 2008, Ethan Merritt wrote:

> On Friday 04 January 2008 13:48, Allin Cottrell wrote:
> > Sorry, I've lost track: what is the current state of UTF-8 support 
> > in the postscript terminal supposed to be?  I sort of thought that 
> > "set encoding utf8" was working for term post, but it seems not.
> 
> It works here. But you need to use a compatible font file...

But don't we have one by default? (Namely, Helvetica or a clone 
thereof).

> Note that in this [successful UTF-8 encoded] case it was 
> necessary to use the "adobeglyphnames" option.

Thanks for the hint!  I find that if I take my original UTF-8 
encoded Polish graph, and put

  set encoding utf8
  set term post eps color adobeglyphnames

at the top, it then works fine.

But this makes me wonder: if the default alternative to 
"adobeglyphnames" doesn't work with the default postscript font, 
why is adobeglyphnames not the default?

Allin Cottrell

Re: cvs: log cb broken

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

On Saturday 05 January 2008, Petr Mikulik wrote:
> Consequently, there is a bug in 4.3.
> Wasn't it introduced in your patch from 2007-12-18?

I don't think it is at all related. So far as I can determine,
the difference is due to a single line change from back in Aug 2007. 
The following patch would return it to 4.2 behavior.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
--- gnuplot-27aug2007/src/plot2d.c	2007-08-27 12:31:57.000000000 -0800
+++ gnuplot-cvs/src/plot2d.c	2008-01-05 13:41:58.000000000 -0800
@@ -223,7 +223,7 @@
     AXIS_INIT2D(SECOND_Y_AXIS, 1);
     AXIS_INIT2D(T_AXIS, 0);
     AXIS_INIT2D(R_AXIS, 1);
-    AXIS_INIT2D(COLOR_AXIS, 0);
+    AXIS_INIT2D(COLOR_AXIS, 1);
 
     t_axis = (parametric || polar) ? T_AXIS : FIRST_X_AXIS;
 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

However. I do not agree that in the case of image plots the 4.2 behavior is 
correct.  

The plot produced by 4.2 shows a color range in which black indicates a pixel 
value, in this case log(f(x,y)),  less than 0.1.
But these pixel values are not, in fact, less than 0.1.  They are entirely 
undefined because  log(x<0) is undefined.   I think that the correct behavior 
would be to not draw these pixels at all.  This is exactly analogous to your 
previous example of autoscaling    'plot [-10:10] log(x)'.   The y values 
corresponding to x<0  are not shown as zero;  they are not drawn at all.   

I take your point that one case in which pixel values are undefined is the 
case of taking the log of an experimentally measured value near 0 in the 
presence of finite experimental error.   But that is not the general case.  
For example, the matrix data file you posted at the start of this thread 
contained values evenly distributed on both sides of zero.  It was not 
obvious that the values were expected to be all positive.

-- 
Ethan Merritt
(on the road)

Re: cvs: log cb broken

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

> This is new to me, and does not seem to agree with the documentation:
> 
> help autoscale
>     When autoscaling, the axis range is automatically computed and the dependent
>     axis (y for a `plot` and z for `splot`) is scaled to include the range of the
>     function or data being plotted.
> 
> You are saying that for log scales, only the range of the data greater than
> some positive value epsilon is to be scaled?

Yes, it has always worked like that. Hitting "l" for log scale, for any plot 
or splot with at least few positive points, gnuplot produces a reasonable 
drawing.

> I can see how this makes sense for functions, but it strikes me as being
> incorrect for actual data.

Why? Negative values are e.g. electronic noise. The user is not interested 
in, but want to see the image in log scale of intensities.

> Anyhow, I don't quite understand what the equivalent result would be for
> plots "with image".  In the example you give below for log scale on y, only
> points with f(x) > 0 are displayed on the plot.  Would the equivalent for
> "with image" be that individual pixels are only drawn if the value of f(x,y)
> is positive?   That is not what version 4.2 does.
> 
> And what would be the assignment of colors?  Would you limit the colors
> used in the bar to the color range corresponding to positive Z values?
> That would be the logical equivalent of drawing only the positive region
> on y in the example below.  But that is not what 4.2 does.

It should work in 4.3 as 4.2 works: the cb min is 0.1 (the smallest positive 
data point value if "set autoscale fix"), and colors of smaller values are 
drawn same as those corresponding to this minimum.

It works everywhere like this for the cb axis. Try for example this:

	splot x*x-y*y*2 with pm3d
	set log cb
	replot

and the colors below the limit are black.
If you want to mask out some rectangles, then you need
	set log z; replot

Consequently, there is a bug in 4.3. 
Wasn't it introduced in your patch from 2007-12-18?
 
---
PM

Re: cvs: log cb broken

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

> > Gnuplot has been always excellent in handling negative ranges in log scales.
> > For example,
> >
> >	gnuplot> set xrange [-10:10]; set log y; plot 1/x
> 
> I don't understand your example. The y axis range is auto-calculated
> (correctly, it seems) as 0.1 to 1. There is no negative log range 
> there, and the negative y-values associated with the x=[-10:0] range 
> are ignored. If you try something like:
> 
> 	gnuplot> set xrange [-10:10]; set yrange [-1:1]; set log y; plot 1/x;
> 
> You will, as expected, get the error "y range must be greater than 0 for
> log scale." This seems to be the case in 4.2 as well.

OK, I should have written "Gnuplot has been always excellent in autoscaling 
log axis ranges."

---
PM

Re: cvs: log cb broken

[Tait <gnu...@t4...>]

Petr Mikulik <mikulik_physics.muni.cz> said (on 2008/01/04):
> No, the error message is not correct, it should autoscale the cb-value to a
> lower positive value, as it does in the same case for "with image" for
> logged y or z axes. There must have been some change in cvs which broke this
> for "matrix with image".
>
> Gnuplot has been always excellent in handling negative ranges in log scales.
> For example,
>
>	gnuplot> set xrange [-10:10]; set log y; plot 1/x

I don't understand your example. The y axis range is auto-calculated
(correctly, it seems) as 0.1 to 1. There is no negative log range 
there, and the negative y-values associated with the x=[-10:0] range 
are ignored. If you try something like:

	gnuplot> set xrange [-10:10]; set yrange [-1:1]; set log y; plot 1/x;

You will, as expected, get the error "y range must be greater than 0 for
log scale." This seems to be the case in 4.2 as well.

Tait

Re: utf8 and postscript

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

On Friday 04 January 2008 13:48, Allin Cottrell wrote:
> Sorry, I've lost track: what is the current state of UTF-8 support=20
> in the postscript terminal supposed to be?  I sort of thought that=20
> "set encoding utf8" was working for term post, but it seems not.

It works here.
But you need to use a compatible font file.

> I tried a plot containing Polish text with accented characters,=20
> l-slash, and such. =20
>=20
> With the source file in UTF-8, and with the "term post eps" line=20
> preceded by "set encoding utf8", no joy: the accented characters=20
> were missing in the output.

I attach the output from the following sequence of commands

  set encoding utf8
  set term post eps fontfile '/home/local/share/ttfonts/verdana.ttf' font '=
Verdana' adobeglyphnames
  set output 'agn.eps'
  set title "=C5=81=C5=82=C5=83=C5=84=C5=85=C5=86=C5=87=C5=88=C5=A0=C5=A1=
=C5=A2=C5=A3=C5=B8=C5=B9=C7=BA=C7=BB=C7=BC=C7=BD=C7=BE=C7=BF"
  plot sin(x)

Note that in this case it was necessary to use the "adobeglyphnames" option.
It is very annoying, but you probably have to try both with and without this
option for each font.  I don't know of any way to query the font externally
to ask what convention it uses for glyph names.

=46urthermore, because the aglfn.txt contains glyph names for ~1000 charact=
ers,
the resulting glyph table at the head of your output file is rather large.
If you were doing this routinely, you'd might want to create a tailored
file containing only the subset of glyphs you expect to need.

=46or more information, please see the file  unicode_maps.README
distributed in the .../term/PostScript/  directory and installed in=20
/usr/local/share/gnuplot/4.3/PostScript/=20

Anyhow, yes it works. But we haven't yet made it trivially easy to use.


=2D-=20
Ethan A Merritt

utf8 and postscript

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

Sorry, I've lost track: what is the current state of UTF-8 support 
in the postscript terminal supposed to be?  I sort of thought that 
"set encoding utf8" was working for term post, but it seems not.

I tried a plot containing Polish text with accented characters, 
l-slash, and such.  

With the source file in UTF-8, and with the "term post eps" line 
preceded by "set encoding utf8", no joy: the accented characters 
were missing in the output.

With the source recoded to Latin-2, and the "term post eps" line 
preceded by "set encoding iso_8859_2", fine: the accented 
characters come through OK.

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC

Re: cvs: log cb broken

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

On Friday 04 January 2008 03:42, Petr Mikulik wrote:
> > >   "bug_logcb.gp", line 4: color axis has cb coord of -10; must be above 0 
> > >   for log scale!
> > > 
> > > plot 'matrix.dat' matrix with image
> > >
> > > What has broken in cvs?
> > 
> > But the error message is correct.  
> > The cb values go negative and therefore log scale cannot work.
> > 
> > I see that 4.2 does draw something, but I don't understand 
> > what it is drawing.  I'd say that 4.2 fails to detect the
> > error, while CVS is doing the right thing by reporting it.
> 
> No, the error message is not correct, it should autoscale the cb-value to a 
> lower positive value, as it does in the same case for "with image" for 
> logged y or z axes. There must have been some change in cvs which broke this 
> for "matrix with image".
> 
> Gnuplot has been always excellent in handling negative ranges in log scales. 

This is new to me, and does not seem to agree with the documentation:

help autoscale
    When autoscaling, the axis range is automatically computed and the dependent
    axis (y for a `plot` and z for `splot`) is scaled to include the range of the
    function or data being plotted.

You are saying that for log scales, only the range of the data greater than
some positive value epsilon is to be scaled?

I can see how this makes sense for functions, but it strikes me as being
incorrect for actual data.

Anyhow, I don't quite understand what the equivalent result would be for
plots "with image".  In the example you give below for log scale on y, only
points with f(x) > 0 are displayed on the plot.  Would the equivalent for
"with image" be that individual pixels are only drawn if the value of f(x,y)
is positive?   That is not what version 4.2 does.

And what would be the assignment of colors?  Would you limit the colors
used in the bar to the color range corresponding to positive Z values?
That would be the logical equivalent of drawing only the positive region
on y in the example below.  But that is not what 4.2 does.

> For example,
> 
> 	gnuplot> set xrange [-10:10]; set log y; plot 1/x


Anyhow, I don't have any immediate guesses as to what changed between
4.2 and current cvs.

-- 
Ethan A Merritt

Re: 2D Histogram

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

On Tuesday 01 January 2008 11:47, Justace Clutter wrote:
> I was trying to see if there was a way to get a 2D histogram in gnuplot.  

It is unclear what you mean by a "2D histogram".
Could you please provide a URL for an example of such a plot?

Gnuplot has a plot mode for what *it* calls 2D histograms,
  http://gnuplot.sourceforge.net/demo_4.3/histograms.html
but I guess you have something else in mind.

The closest 3D equivalent, should that be what you are looking for,
is

   set hidden3d
   splot 'data' using 1:2:3 with impulses linewidth <something_big>

> I am  
> running the CVS version of gnuplot.  I did some looking but got back 
> basically nothing.  Can anybody provide some suggestions.  Thanks.

-- 
Ethan A Merritt

Re: cvs: log cb broken

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

> >   "bug_logcb.gp", line 4: color axis has cb coord of -10; must be above 0 
> >   for log scale!
> > 
> > plot 'matrix.dat' matrix with image
> >
> > What has broken in cvs?
> 
> But the error message is correct.  
> The cb values go negative and therefore log scale cannot work.
> 
> I see that 4.2 does draw something, but I don't understand 
> what it is drawing.  I'd say that 4.2 fails to detect the
> error, while CVS is doing the right thing by reporting it.

No, the error message is not correct, it should autoscale the cb-value to a 
lower positive value, as it does in the same case for "with image" for 
logged y or z axes. There must have been some change in cvs which broke this 
for "matrix with image".

Gnuplot has been always excellent in handling negative ranges in log scales. 
For example,

	gnuplot> set xrange [-10:10]; set log y; plot 1/x

---
PM

Re: gnuplot for PDA

[<HBB...@t-...>]

Petr Mikulik wrote:
> A colleague has sent me the following link for gnuplot for PDA:
> 
> 	http://www.rainer-keuchel.de/wince/gnuplot-ce.html
> 
> Could someone compile a newer version of gnuplot?

Hardly.  It's quite far from being a matter of just compiling the thing. 
  The producer of the above version obviously hacked the source quite a 
lot, and doesn't seem to provide source code on his site.  I'm afraid 
that technically, that's a Copyright violation.

Re: cvs: log cb broken

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

On Thursday 03 January 2008 04:18, Petr Mikulik wrote:
> There is a difference between gnuplot 4.2.2 and cvs; 4.2.2 works OK for log 
> cb axis, while cvs gives this error:
> 
>   "bug_logcb.gp", line 4: color axis has cb coord of -10; must be above 0 
>   for log scale!
> 
> What has broken in cvs?

But the error message is correct.  
The cb values go negative and therefore log scale cannot work.

I see that 4.2 does draw something, but I don't understand 
what it is drawing.  I'd say that 4.2 fails to detect the
error, while CVS is doing the right thing by reporting it.

 
> 
> Script:
> 
> plot 'matrix.dat' matrix with image
> 
> set log cb
> replot
> 
> File matrix.dat:
> 2 4 6 8
> 1 2 3 4
> 0 1 2 3
> -2 -1 1 2
> -4 -3 -2 -1
> -6 -5 -4 -3
> 
> ---
> PM

-- 
Ethan A Merritt

cvs: log cb broken

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

There is a difference between gnuplot 4.2.2 and cvs; 4.2.2 works OK for log 
cb axis, while cvs gives this error:

  "bug_logcb.gp", line 4: color axis has cb coord of -10; must be above 0 
  for log scale!

What has broken in cvs?


Script:

plot 'matrix.dat' matrix with image

set log cb
replot

File matrix.dat:
2 4 6 8
1 2 3 4
0 1 2 3
-2 -1 1 2
-4 -3 -2 -1
-6 -5 -4 -3

---
PM

gnuplot for PDA

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

A colleague has sent me the following link for gnuplot for PDA:

	http://www.rainer-keuchel.de/wince/gnuplot-ce.html

Could someone compile a newer version of gnuplot?

---
PM

updates to links

[Tim H. <tim...@un...>]

Hello,

I found that the links page is not up-to-date. Below is a list of errors 
/ changes. When possible I gave new links.

Regards,
Tim

front-ends
[N/A] Xgfe
[link changed] gnuplot-mode.el 
http://cars9.uchicago.edu/~ravel/software/gnuplot-mode.html
[changed] Kile
from: 
http://changelogs.ubuntu.com/changelogs/pool/universe/k/kile/kile_1.8.1-3.2ubuntu1/changelog
"Kile no longer comes with a Gnuplot front end; this is now maintained
separately by Pascal Brachet at http://www.xm1math.net/qgfe/."
[N/A] Tcl/Tk interface
[link changed] unignuplot http://unicalculus.sourceforge.net/
[N/A] fltk
[N/A] vim mode

programming interfaces
[link changed] ANSI C  http://ndevilla.free.fr/gnuplot/
[N/A] C (by Ed Breen)
[N/A] Lisp

programming interfaces - bidirectional
ALL OK

software that uses gnuplot
[N/A] Mifit
[link changed] statist   http://statist.wald.intevation.org/  or 
http://wald.intevation.org/projects/statist/

2D Histogram

[Justace C. <jus...@gm...>]

I was trying to see if there was a way to get a 2D histogram in gnuplot.  I am 
running the CVS version of gnuplot.  I did some looking but got back 
basically nothing.  Can anybody provide some suggestions.  Thanks.

Justace

Re: pngcairo: suggestion for additional option

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

On Fri, 28 Dec 2007, Ethan A Merritt wrote:

> Allin:
> 
> I attach a revised version of your patch.
> The changes are:
> - Export pre-calculated values for TERM_XMIN etc taken from the axis
>   structures
> - Initialize term->tscale to 1.0 for all terminals that do not provide
>   an explicit value
> - Initialize term->tscale for SVG terminal
> 
> Please give it a look-over.  

This looks good to me.  It works fine for the various PNG plots 
that I've checked.

> Also please help me figure out which other terminals need an 
> explicit scale, and whether the exported variables need to be of 
> type double rather than integer. For instance, I think "post 
> eps" needs a scale factor of 20, but PostScript coordinates are 
> not limited to integers.  A test plot gave
>         TERM_XMIN = 546
>         TERM_XMAX = 6990
>         TERM_YMIN = 280
>         TERM_YMAX = 4872
> and dividing back by 20 will give non-integral values.  I am also worried
> that to actually use these values we would also need to have the offset
> of the coordinate origin relative to the origin of the PostScript page.
> On the other hand, the necessary information is already in the output
> PostScript file, so perhaps it is not necessary to export it as a user
> variable inside gnuplot.  What do you think?

I see what you mean about PostScript.  I find that TERM_XMIN et al 
agree with a readback from the mouse in gv, if I divide by 20 
(that is, 2*PS_SC) and add the coordinates of the bottom left of 
the bounding box -- that is, (50,50).  I also see that division by 
the scale factor of 20 yields non-integral values, but I'd think 
that for practical purposes having these measurements to the 
nearest PostScript point would probably be sufficient.

As for the translation of the bounding box: yes, it's quite easily 
readable from the PostScript file.  I'm not sure whether a user 
would want/expect the measurements net or gross of the PostScript 
translation; I think it might be enough to state somewhere that
they are net.

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC

Re: pngcairo: suggestion for additional option

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

Allin:

I attach a revised version of your patch.
The changes are:
- Export pre-calculated values for TERM_XMIN etc taken from the axis
  structures
- Initialize term->tscale to 1.0 for all terminals that do not provide
  an explicit value
- Initialize term->tscale for SVG terminal

Please give it a look-over.  Also please help me figure out which other
terminals need an explicit scale, and whether the exported variables need
to be of type double rather than integer. For instance, I think "post eps"
needs a scale factor of 20, but PostScript coordinates are not limited to
integers.  A test plot gave
        TERM_XMIN = 546
        TERM_XMAX = 6990
        TERM_YMIN = 280
        TERM_YMAX = 4872
and dividing back by 20 will give non-integral values.  I am also worried
that to actually use these values we would also need to have the offset
of the coordinate origin relative to the origin of the PostScript page.
On the other hand, the necessary information is already in the output
PostScript file, so perhaps it is not necessary to export it as a user
variable inside gnuplot.  What do you think?


-- 
Ethan A Merritt

Re: pngcairo: suggestion for additional option

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

Ethan first wrote:

> I like the idea, but unfortunately this code isn't working. If 
> you look closely, you will find that the y coordinates being 
> reported by this code are off by 17 pixels in the default 
> 640x480 ouput from either 'set term png' or 'set term 
> pngcairo'...

I demurred, and Ethan clarified thus:

> The problem is in the convention that defines y.  If I create a 
> plot using
>    set term pngcairo
>    set output 'cairo.png'
>    plot sin(x)/x
>    show var all
> I get 
>         TERM_XMIN = 64
>         TERM_XMAX = 615
>         TERM_YMIN = 37
>         TERM_YMAX = 460
> If I now open up cairo.png in GIMP or ImageMagick, I get y pixel
> readouts:
> 	bottom of plot	443             (= 480 - 37)
> 	top of plot      20		(= 480 - 460)
> Notice that the convention is that Y=0 at the top of the image.
> The problem comes if one tries to interpret the bounds [37:460]
> as refering to the offset in pixels from the bottom of the image.
> If you do that, then the values are off by 17 pixels.

True, but surely all that's needed is some indication in the 
documentation of the proposed new variables, that gnuplot takes 
Y=0 to be at the bottom of the image.  

IMO there's no point in trying to second-guess what use people 
might want to make of these dimensions.  Anyone wanting to use 
them on X11 will know that Y=0 is at the top in that context, and 
can easily adjust accordingly.  

Allin Cottrell

Re: pngcairo: suggestion for additional option

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

On Wednesday 26 December 2007 14:11, Allin Cottrell wrote:
> On Tue, 25 Dec 2007, Ethan A Merritt wrote:
> 
> > On Wednesday 19 December 2007 08:16, Allin Cottrell wrote:
> > > I'm attaching a new .tgz file with 3 small patches, to 
> > > term/cairo.trm, src/eval.c and src/term_api.h.  Jointly these 
> > > implement the writing of plot pixel bounds, with a possible scale 
> > > factor, using a new scalar variable rather than a new function 
> > > pointer.
> > 
> > I like the idea, but unfortunately this code isn't working.
> > If you look closely, you will find that the y coordinates being
> > reported by this code are off by 17 pixels in the default 640x480
> > ouput from either 'set term png' or 'set term pngcairo'...
> 
> Hmm, could you explain how you're coming to that judgment?  

I read out mouse coordinates using either display (ImageMagick) or GIMP
while displaying the png image output by gnuplot.  The true pixel coord
of the lower border of the plot area is 

> The way I'm testing this is (in my program, gretl) is by 
> displaying the PNG (at present, produced by the pngcairo term) in 
> a GTK window, with a mouse-over feedback mechanism that prints the 
> data coordinates.  

If you write your own mouse read-out then of course you can
apply whatever mapping you want.
 
> Anyway, I find that the readback is perfectly accurate: the data 
> coordinates seem right and they kick out just at the very edge of 
> the plot.  I've tried this with plots of 640x480 and 680x400.

Sure, I'm not questioning the accuracy.  The problem is in the
convention that defines y.  If I create a plot using
   set term pngcairo
   set output 'cairo.png'
   plot sin(x)/x
   show var all
I get 
        TERM_XMIN = 64
        TERM_XMAX = 615
        TERM_YMIN = 37
        TERM_YMAX = 460
If I now open up cairo.png in GIMP or ImageMagick, I get y pixel
readouts:
	bottom of plot	443             (= 480 - 37)
	top of plot      20		(= 480 - 460)
Notice that the convention is that Y=0 at the top of the image.
The problem comes if one tries to interpret the bounds [37:460]
as refering to the offset in pixels from the bottom of the image.
If you do that, then the values are off by 17 pixels.

Maybe that's OK.  But it puts the burden on the program that
eventually interprets pixel coords to know what convention is being
used.   The messier case is for PostScript, where so far as I can see
there is no obvious place to pick up the coordinates of the origin of
the plot relative to the origin of the page.


	best regards,

		Ethan



 
> Here's the function I'm using to compute the data coordinates, 
> given integer x and y as reported by GTK from the mouse pointer,
> relative to the window holding the PNG:
> 
> static void get_data_xy (png_plot *plot, int x, int y, 
> 			 double *data_x, double *data_y)
> {
>     double dx, dy;
> 
>     *data_x = plot->xmin + ((double) x - plot->pixel_xmin) / 
> 	(plot->pixel_xmax - plot->pixel_xmin) * 
>         (plot->xmax - plot->xmin);
> 
>     *data_y = ymax - ((double) y - plot->pixel_ymin) / 
> 	(plot->pixel_ymax - plot->pixel_ymin) * 
>         (plot->ymax - plot->ymin);
> }
> 
> where the relevant members of the my png_plot structure have the 
> following relationships with gnuplot variables (as read from an 
> auxiliary test file produced using gnuplot's print command):
> 
> plot->pixel_xmin <- TERM_XMIN
> plot->pixel_xmax <- TERM_XMAX
> plot->pixel_ymin <- plot->pixel_height - TERM_YMIN
> plot->pixel_ymax <- plot->pixel_height - TERM_YMAX
> 
> plot->xmin <- GPVAL_X_MIN
> plot->xmax <- GPVAL_X_MAX
> plot->ymin <- GPVAL_Y_MIN
> plot->ymax <- GPVAL_Y_MAX
> 
> plot->pixel_height is, e.g. 480 for a 640x480 PNG, as you might 
> expect!
> 
> Allin Cottrell
> 
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

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

Re: pngcairo: suggestion for additional option

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

On Tue, 25 Dec 2007, Ethan A Merritt wrote:

> On Wednesday 19 December 2007 08:16, Allin Cottrell wrote:
> > I'm attaching a new .tgz file with 3 small patches, to 
> > term/cairo.trm, src/eval.c and src/term_api.h.  Jointly these 
> > implement the writing of plot pixel bounds, with a possible scale 
> > factor, using a new scalar variable rather than a new function 
> > pointer.
> 
> I like the idea, but unfortunately this code isn't working.
> If you look closely, you will find that the y coordinates being
> reported by this code are off by 17 pixels in the default 640x480
> ouput from either 'set term png' or 'set term pngcairo'...

Hmm, could you explain how you're coming to that judgment?  

The way I'm testing this is (in my program, gretl) is by 
displaying the PNG (at present, produced by the pngcairo term) in 
a GTK window, with a mouse-over feedback mechanism that prints the 
data coordinates.  

This is similar to the mechanism in gnuplot itself (e.g. for the 
X11 or wxt terminals), except that in my version the coordinates 
readback goes blank if you move the pointer outside of the 
actual plot area (which incidentally enables you to see easily if 
that area is correctly registered).

Anyway, I find that the readback is perfectly accurate: the data 
coordinates seem right and they kick out just at the very edge of 
the plot.  I've tried this with plots of 640x480 and 680x400.

Here's the function I'm using to compute the data coordinates, 
given integer x and y as reported by GTK from the mouse pointer,
relative to the window holding the PNG:

static void get_data_xy (png_plot *plot, int x, int y, 
			 double *data_x, double *data_y)
{
    double dx, dy;

    *data_x = plot->xmin + ((double) x - plot->pixel_xmin) / 
	(plot->pixel_xmax - plot->pixel_xmin) * 
        (plot->xmax - plot->xmin);

    *data_y = ymax - ((double) y - plot->pixel_ymin) / 
	(plot->pixel_ymax - plot->pixel_ymin) * 
        (plot->ymax - plot->ymin);
}

where the relevant members of the my png_plot structure have the 
following relationships with gnuplot variables (as read from an 
auxiliary test file produced using gnuplot's print command):

plot->pixel_xmin <- TERM_XMIN
plot->pixel_xmax <- TERM_XMAX
plot->pixel_ymin <- plot->pixel_height - TERM_YMIN
plot->pixel_ymax <- plot->pixel_height - TERM_YMAX

plot->xmin <- GPVAL_X_MIN
plot->xmax <- GPVAL_X_MAX
plot->ymin <- GPVAL_Y_MIN
plot->ymax <- GPVAL_Y_MAX

plot->pixel_height is, e.g. 480 for a 640x480 PNG, as you might 
expect!

Allin Cottrell