gnuplot-beta

pngcairo: suggestion for additional option

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

I'll float this by the list first and submit a tracker item if 
there's any support.

I would find it very useful to get a readback from gnuplot on the 
internal dimensions of a PNG file -- that is, the pixel bounds of 
the data area and also the data minima and maxima.  This is for 
generating an interactive display (much like the mousable wxt 
terminal display, but with additional features).

I may be missing something, but I don't think there's any way of 
doing this at present.

The attached patch adds a boolean "boundsfile" option to pngcairo.  
If this is activated, and if output is going to a named file, the 
driver also writes out a small auxiliary file containing the data 
mentioned above.  The aux file has the same name as the PNG file 
plus the suffix ".bounds".

For example, if you do:

set term pngcairo bounds
set output 'test.png'
plot sin(x)

you get test.png as usual, but also a file named test.png.bounds
with content

xleft=89 xright=620 ybot=37 ytop=460
xmin=-10 xmax=10 ymin=-1 ymax=1

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

Re: pngcairo: suggestion for additional option

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

On Wednesday 21 November 2007 09:13, Allin Cottrell wrote:
> I'll float this by the list first and submit a tracker item if 
> there's any support.
> 
> I would find it very useful to get a readback from gnuplot on the 
> internal dimensions of a PNG file -- that is, the pixel bounds of 
> the data area and also the data minima and maxima.  This is for 
> generating an interactive display (much like the mousable wxt 
> terminal display, but with additional features).

I don't think I quite understand what you are aiming for.

My first take was that you were suggesting that pngcairo is missing
the "crop" option of the libgd-based png terminal.
In general the gnuplot core routines will not know this information.
Consider the case of "plot with labels", where the label is rendered
(by cairo/pango in this case) as a scaled glyph.
What pixels are touched in drawing that glyph?  Gnuplot doesn't know.
It would have to be provided by the support library.
 
> The attached patch adds a boolean "boundsfile" option to pngcairo.  
...
> you get test.png as usual, but also a file named test.png.bounds
> with content
> 
> xleft=89 xright=620 ybot=37 ytop=460
> xmin=-10 xmax=10 ymin=-1 ymax=1

But then I backtracked and thought maybe you are asking for output of
the    [terminal coordinate] <--> [plot coordinate]
mapping that is used by the mousing code.  Is that the idea?
See for example the term->text() driver entry point for x11.trm
(X11_text).  That is exactly what it does.

I thought there was an ancient patchset that implemented this for
the libgd-based terminals by placing the information in a comment
record inside the image file proper. That might make more sense,
and as with the current x11 driver it would become a normal part of
the term->text() processing.  No special command-line options needed.
Unfortunately I can't seem to find that patchset on SourceForge any
more.  Also I don't know if cairo provides a mechanism to add 
arbitrary comment records to a PNG file.

Finally, let me note that one of my biggest long term wish-list items
is to have gnuplot emit similar information for use with SVG plots
embedded in a web page.  The idea is to implement full browser-side
mousing/zooming capabilities for each embedded plot using jscript or
the equivalent.  See for example the pages at:
	http://sitn.ne.ch/

-- 
Ethan A Merritt

Re: pngcairo: suggestion for additional option

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

On Wed, 21 Nov 2007, Ethan Merritt wrote:

> On Wednesday 21 November 2007 09:13, Allin Cottrell wrote:
> > I'll float this by the list first and submit a tracker item if 
> > there's any support.
> > 
> > I would find it very useful to get a readback from gnuplot on the 
> > internal dimensions of a PNG file -- that is, the pixel bounds of 
> > the data area and also the data minima and maxima.  This is for 
> > generating an interactive display (much like the mousable wxt 
> > terminal display, but with additional features).
> 
> I don't think I quite understand what you are aiming for.
> 
> My first take was that you were suggesting that pngcairo is 
> missing the "crop" option of the libgd-based png terminal.

Sorry if I wasn't clear but no, that's not it.

> But then I backtracked and thought maybe you are asking for output of
> the    [terminal coordinate] <--> [plot coordinate]
> mapping that is used by the mousing code.  Is that the idea?

Yes.

> I thought there was an ancient patchset that implemented this for
> the libgd-based terminals by placing the information in a comment
> record inside the image file proper. 

I wrote a patch to do that at one time and canvassed it on this 
list.

> That might make more sense...

In principle, yes.  But neither libgd nor cairo (AFAIK) offers a 
means of doing this.  My patch was an ugly hack in that it 
imported a modified chunk of the libgd code into gd.trm; that's 
the only way I could get a handle on the comment fields.

I tried submitting a patch for libgd to add an API for writing to 
the comments fields in a PNG but that wasn't accepted.  I don't 
know if one would have any better luck offering a patch for cairo.

Hence my notion of falling back on an auxiliary file. Not all that 
pretty but it works (and obviously could be implemented for other 
terminals too).  One nice thing about this approach is that the 
reader doesn't have to link to libpdf (or carry out fiddly 
do-it-yourself binary reading) to get the info; it's right there 
in plain text.

> Finally, let me note that one of my biggest long term wish-list items
> is to have gnuplot emit similar information for use with SVG plots
> embedded in a web page.

Yes, that would be nice.

Allin Cottrell

Re: pngcairo: suggestion for additional option

[<pl...@pi...>]

On Wed, 21 Nov 2007 20:03:52 +0100, Ethan Merritt  
<merritt@u.washington.edu> wrote:

> Finally, let me note that one of my biggest long term wish-list items
> is to have gnuplot emit similar information for use with SVG plots
> embedded in a web page.  The idea is to implement full browser-side
> mousing/zooming capabilities for each embedded plot using jscript or
> the equivalent.  See for example the pages at:
> 	http://sitn.ne.ch/
>

Hi,

that sounds very interesting, the DOM inspector in Firefox seems to be  
able to walk the xml structure so I guess there's a means of  
accessing/modifying content with javaScript.

   One thing I've often wanted on working with SVG is a means to get a  
readable file at the end of a plot command without having to unset  
terminal to write out the xml terminators and close the file. Unless this  
is done the file seems to be unparsable to any readers I've tried.

For example , if I output to jpeg or png, I get a readable file after the  
plot command. With svg I dont.

Would it make sense to have gnuplot terminate the unmatched tags until a  
further command is given in either of the following cases:

1/ end of .gnu file input from load "filename" . If svg terminal is still  
open , close unmatched tags.
2/ interactive use after plot command close tags while awaiting further  
input.

The added tags would have to be stipped off again on adding further  
content.

What I'd like to get to is periodic replotting of volatile data whilst  
independantly refreshing / reloading the SVG output in the viewer,  
typically a web browser on a timed or manual refresh.

Especially in debugging it would be nice to avoid:  unset terminal ; set  
terminal svg; replot; unset terminal .... loops.

If I've just missed a trick, sorry for the noise.

regards, Peter.

Re: pngcairo: suggestion for additional option

[<pl...@pi...>]

On Wed, 21 Nov 2007 23:40:35 +0100, Hans-Bernhard Bröker  
<HBB...@t-...> wrote:

> pl...@pi... wrote:
>
>>    One thing I've often wanted on working with SVG is a means to get a   
>> readable file at the end of a plot command without having to unset   
>> terminal to write out the xml terminators and close the file.
>
> Unsetting the terminal is completely unnecessary.  You will have to  
> close the plot though, i.e. "unset output".

I beg you pardon, I was meaning unset output not unset terminal. This does  
not affect crux of what I was suggesting. It is the need to close the file  
for it to become parsable, that remains the same.

> gnuplot cannot  possibly write the closing tags if you didn't tell it  
> you're done with writing to the file.

Well it could _possibly_ write the closing tags temporarily as I suggested  
and remove them later if/when further output occured. Maybe you did not  
read that part of my post.

>
>> For example , if I output to jpeg or png, I get a readable file after  
>> the  plot command. With svg I dont.
>
> The reason for the difference is that JPEG only allows one page per  
> file, SVG allows as many as you wish.

Yes precisely, that's why it may be useful to produce intermidiate svg  
output in a readable state.

>
>> Would it make sense to have gnuplot terminate the unmatched tags until  
>> a  further command is given in either of the following cases:
>>  1/ end of .gnu file input from load "filename" . If svg terminal is  
>> still  open , close unmatched tags.
>
> Absolutely no.  Not all loaded scripts end the output file.

Again, you've misread the main point of my post that this should be  
reversible.
If three lines of closing tags were needed these simply get chopped off  
again and output continues.

>
>> 2/ interactive use after plot command close tags while awaiting  
>> further  input.
>
> Absolutely no, for basically the same reason.
>

Absolutely possible , for basically the same reason.

It may be helpful if you reread the parts of my previous post that you  
chose not to quote, before replying.

regards, Peter.

Re: pngcairo: suggestion for additional option

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

Allin Cottrell wrote:
> I'll float this by the list first and submit a tracker item if 
> there's any support.

No need to.  There's been an item open for ages about this.  Its poster 
wanted the info to set up clickable an <IMG> map for GIFs on web page, 
but the real feature request is the same as yours.

More abstractly speaking, what these requests are about is a very rough 
approximation of on aspect of mouse interaction: coordinate mapping back 
to data values for static bitmap terminal drivers.

Version 4.2.2 has quite a lot of this already your finger tips, by way 
of gnuplot-defined variables GPVAL_X_MIN etc.  Adding GRAPH_XLEFT etc. 
shouldn't pose a major problem.

Re: pngcairo: suggestion for additional option

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

pl...@pi... wrote:

>    One thing I've often wanted on working with SVG is a means to get a  
> readable file at the end of a plot command without having to unset  
> terminal to write out the xml terminators and close the file.

Unsetting the terminal is completely unnecessary.  You will have to 
close the plot though, i.e. "unset output".  gnuplot cannot  possibly 
write the closing tags if you didn't tell it you're done with writing to 
the file.

> For example , if I output to jpeg or png, I get a readable file after the  
> plot command. With svg I dont.

The reason for the difference is that JPEG only allows one page per 
file, SVG allows as many as you wish.

> Would it make sense to have gnuplot terminate the unmatched tags until a  
> further command is given in either of the following cases:
> 
> 1/ end of .gnu file input from load "filename" . If svg terminal is still  
> open , close unmatched tags.

Absolutely no.  Not all loaded scripts end the output file.

> 2/ interactive use after plot command close tags while awaiting further  
> input.

Absolutely no, for basically the same reason.

Re: pngcairo: suggestion for additional option

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

On Wed, 21 Nov 2007, Hans-Bernhard Bröker wrote:

> Allin Cottrell wrote:
> > I'll float this by the list first and submit a tracker item if there's any
> > support.
> 
> No need to.  There's been an item open for ages about this...

OK, but then nothing has happened about this.  I'm now proposing 
what seems to me a minimalistic solution that shouldn't disturb 
the existing codebase.

> More abstractly speaking, what these requests are about is a 
> very rough approximation of on aspect of mouse interaction: 
> coordinate mapping back to data values for static bitmap 
> terminal drivers.

Why would it be a "very rough approximation", if you know the 
pixel bounds of the actual plot area in the bitmap graphic, and 
the data bounds of the plot?  Pixels are discrete, of course, but 
the approximation should be pretty good if we have hundreds of 
pixels in both dimensions.

> Version 4.2.2 has quite a lot of this already your finger tips, 
> by way of gnuplot-defined variables GPVAL_X_MIN etc.  Adding 
> GRAPH_XLEFT etc. shouldn't pose a major problem.

Sorry, I don't really understand.  There's no difficulty at all 
calculating/retrieving this information inside gnuplot.  The issue 
is how to make it available to the outside world -- that is, to 
another program that has called gnuplot to make a plot file, and 
wants to know some internal properties of the file.

Allin Cottrell

Re: pngcairo: suggestion for additional option

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

On Wednesday 21 November 2007 16:01, Allin Cottrell wrote:
> 
> > Version 4.2.2 has quite a lot of this already your finger tips, 
> > by way of gnuplot-defined variables GPVAL_X_MIN etc.  Adding 
> > GRAPH_XLEFT etc. shouldn't pose a major problem.
> 
> Sorry, I don't really understand.  There's no difficulty at all 
> calculating/retrieving this information inside gnuplot.  The issue 
> is how to make it available to the outside world -- that is, to 
> another program that has called gnuplot to make a plot file, and 
> wants to know some internal properties of the file.

I believe the suggestion was that one could achieve this by the
following lines:

  set print "plot_coords.dat"
  print "x limits: ", GPVAL_X_MIN, GPVAL_X_MAX
  print "x2 limits: ", GPVAL_X2_MIN, GPVAL_X2_MAX
  print "y limits: ", GPVAL_Y_MIN, GPVAL_Y_MAX
  print "y2 limits: ", GPVAL_Y2_MIN, GPVAL_Y2_MAX
  print "graph limits: ", GPVAL_GRAPH_XMIN, GPVAL_GRAPH_XMAX
  ... and so on

In other words, no need for a special terminal option.
The existing print mechanism would allow flexibility as to
file format and exactly what information is saved.

-- 
Ethan A Merritt

Re: pngcairo: suggestion for additional option

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

On Wed, 21 Nov 2007, Ethan Merritt wrote:

> On Wednesday 21 November 2007 16:01, Allin Cottrell wrote:
> > 
> > > Version 4.2.2 has quite a lot of this already your finger tips, 
> > > by way of gnuplot-defined variables GPVAL_X_MIN etc.  Adding 
> > > GRAPH_XLEFT etc. shouldn't pose a major problem.
> > 
> > Sorry, I don't really understand.  There's no difficulty at all 
> > calculating/retrieving this information inside gnuplot.  The issue 
> > is how to make it available to the outside world -- that is, to 
> > another program that has called gnuplot to make a plot file, and 
> > wants to know some internal properties of the file.
> 
> I believe the suggestion was that one could achieve this by the
> following lines:
> 
>   set print "plot_coords.dat"
>   print "x limits: ", GPVAL_X_MIN, GPVAL_X_MAX
>   print "x2 limits: ", GPVAL_X2_MIN, GPVAL_X2_MAX
>   print "y limits: ", GPVAL_Y_MIN, GPVAL_Y_MAX
>   print "y2 limits: ", GPVAL_Y2_MIN, GPVAL_Y2_MAX
>   print "graph limits: ", GPVAL_GRAPH_XMIN, GPVAL_GRAPH_XMAX
>   ... and so on

where GPVAL_GRAPH_XMIN and friends are still to be added?

OK, this looks promising.  

Allin Cottrell

Re: pngcairo: suggestion for additional option

[<tim...@lp...>]

pl...@pi... a écrit :
> On Wed, 21 Nov 2007 23:40:35 +0100, Hans-Bernhard Bröker  
> <HBB...@t-...> wrote:
>
>   
>> gnuplot cannot  possibly write the closing tags if you didn't tell it  
>> you're done with writing to the file.
>>     
>
> Well it could _possibly_ write the closing tags temporarily as I suggested  
> and remove them later if/when further output occured. Maybe you did not  
> read that part of my post.
>
>   
I like this idea very much. This kind of "lazy file closing" would be a 
good time saver.

Best regards,

Timothée

Re: pngcairo: suggestion for additional option

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

On Wednesday 21 November 2007 23:33, Timoth=C3=A9e Lecomte wrote:
> pl...@pi... a =C3=A9crit :
> > On Wed, 21 Nov 2007 23:40:35 +0100, Hans-Bernhard Br=C3=B6ker =20
> > <HBB...@t-...> wrote:
> >  =20
> >> gnuplot cannot  possibly write the closing tags if you didn't tell it =
=20
> >> you're done with writing to the file.=20
> >
> > Well it could _possibly_ write the closing tags temporarily as I sugges=
ted =20
> > and remove them later if/when further output occured. Maybe you did not=
 =20
> > read that part of my post.
> >  =20
> I like this idea very much. This kind of "lazy file closing" would be a=20
> good time saver.

That would prevent using a pipe for output.  I do not use the TeX
terminals normally, so I don't know if piped output is relevant to these.
Certainly it is a very common case for png, svg, and postscript (eps).


=2D-=20
Ethan A Merritt

Re: pngcairo: suggestion for additional option

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

On Wed, 21 Nov 2007, Ethan Merritt wrote:

(about extracting bounds information from gnuplot, e.g. for a PNG 
file)

> I believe the suggestion was that one could achieve this by the
> following lines:
> 
>   set print "plot_coords.dat"
>   print "x limits: ", GPVAL_X_MIN, GPVAL_X_MAX
>   print "x2 limits: ", GPVAL_X2_MIN, GPVAL_X2_MAX
>   print "y limits: ", GPVAL_Y_MIN, GPVAL_Y_MAX
>   print "y2 limits: ", GPVAL_Y2_MIN, GPVAL_Y2_MAX
>   print "graph limits: ", GPVAL_GRAPH_XMIN, GPVAL_GRAPH_XMAX
>   ... and so on

I'm attaching a small patch to eval.c that implements 
GPVAL_GRAPH_XMIN, GPVAL_GRAPH_XMAX, GPVAL_GRAPH_YMIN and 
GPVAL_GRAPH_YMAX. In the context of bitmapped output, these values 
should represent the pixel coordinates of the actual graph area.

Those more familiar than I with the gnuplot architecture will no 
doubt be able to see if there's a better way of doing this.

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

Re: pngcairo: suggestion for additional option

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

On Thursday 22 November 2007 08:19, Allin Cottrell wrote:
> 
> I'm attaching a small patch to eval.c that implements 
> GPVAL_GRAPH_XMIN, GPVAL_GRAPH_XMAX, GPVAL_GRAPH_YMIN and 
> GPVAL_GRAPH_YMAX. In the context of bitmapped output, these values 
> should represent the pixel coordinates of the actual graph area.
> 
> Those more familiar than I with the gnuplot architecture will no 
> doubt be able to see if there's a better way of doing this.

>--- eval.c.orig	2007-11-22 10:16:05.000000000 -0500
>+++ eval.c	2007-11-22 11:05:46.000000000 -0500
>@@ -733,6 +733,39 @@
>     Gstring(&v->udv_value, gp_strdup(stringvalue));
> }
> 
>+static void update_plot_bounds (void)
>+{
>+    int xl = plot_bounds.xleft;
>+    int xr = plot_bounds.xright;
>+    int yb = plot_bounds.ybot;
>+    int yt = plot_bounds.ytop;

I think that has to be 

    unsigned int xl, xr, yb, yt;
    struct position bottom_left = {graph, graph, graph, 0., 0., 0.};
    struct position upper_right = {graph, graph, graph, 1., 1., 1.};

    map_position(&bottom_left, &xl, &yb, "");
    map_position(&upper_right, &xr, &yt, "");

>+    if (term != NULL && !strcmp(term->name, "pngcairo")) {
>+        /* convert to pixels */
>+	xl /= 20;
>+	xr /= 20;
>+	yb /= 20;
>+	yt /= 20;

Where did the magic number 20 come from?
If we need terminal-specific code in core routines, this approach isn't
going to work.  We would have to export addition information from the
terminals, probably from term->text().  But I'm not sure we need this at all.

-- 
Ethan A Merritt

Re: pngcairo: suggestion for additional option

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

On Thu, 22 Nov 2007, Ethan A Merritt wrote:

> On Thursday 22 November 2007 08:19, Allin Cottrell wrote:
> > 
> > I'm attaching a small patch to eval.c that implements 
> > GPVAL_GRAPH_XMIN, GPVAL_GRAPH_XMAX, GPVAL_GRAPH_YMIN and 
> > GPVAL_GRAPH_YMAX. In the context of bitmapped output, these values 
> > should represent the pixel coordinates of the actual graph area.
> > 
> > Those more familiar than I with the gnuplot architecture will no 
> > doubt be able to see if there's a better way of doing this.
> 
> >--- eval.c.orig	2007-11-22 10:16:05.000000000 -0500
> >+++ eval.c	2007-11-22 11:05:46.000000000 -0500
> >@@ -733,6 +733,39 @@
> >     Gstring(&v->udv_value, gp_strdup(stringvalue));
> > }
> > 
> >+static void update_plot_bounds (void)
> >+{
> >+    int xl = plot_bounds.xleft;
> >+    int xr = plot_bounds.xright;
> >+    int yb = plot_bounds.ybot;
> >+    int yt = plot_bounds.ytop;
> 
> I think that has to be 
> 
>     unsigned int xl, xr, yb, yt;
>     struct position bottom_left = {graph, graph, graph, 0., 0., 0.};
>     struct position upper_right = {graph, graph, graph, 1., 1., 1.};
> 
>     map_position(&bottom_left, &xl, &yb, "");
>     map_position(&upper_right, &xr, &yt, "");

OK, I'll take your word for that!

> >+    if (term != NULL && !strcmp(term->name, "pngcairo")) {
> >+        /* convert to pixels */
> >+	xl /= 20;
> >+	xr /= 20;
> >+	yb /= 20;
> >+	yt /= 20;
> 
> Where did the magic number 20 come from?

The cairo code seems to deal in units of 1/20 of a pixel.  Note 
that in mouse.c we have, e.g.:

  mv_mouse_x = term->xmax / 20;

However, if something like the above assignment to 
GPVAL_GRAPH_XMIN et al is acceptable, I'd be happy even if no 
conversion to pixels is done -- that is, if the numbers are just 
whatever comes out of map_position().

Allin Cottrell

Re: pngcairo: suggestion for additional option

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

On Fri, 23 Nov 2007, Allin Cottrell wrote:

> On Thu, 22 Nov 2007, Ethan A Merritt wrote:

> > Where did the magic number 20 come from?
> 
> The cairo code seems to deal in units of 1/20 of a pixel...

Found the source:

gp_cairo.h: #define GP_CAIRO_SCALE 20

See also plot->oversampling_scale in gp_cairo.c.

Allin Cottrell

Re: pngcairo: suggestion for additional option

[<pl...@pi...>]

On Sat, 24 Nov 2007 01:24:09 +0100, Allin Cottrell <cot...@wf...>  
wrote:

> On Fri, 23 Nov 2007, Allin Cottrell wrote:
>
>> On Thu, 22 Nov 2007, Ethan A Merritt wrote:
>
>> > Where did the magic number 20 come from?
>>
>> The cairo code seems to deal in units of 1/20 of a pixel...
>
> Found the source:
>
> gp_cairo.h: #define GP_CAIRO_SCALE 20
>
> See also plot->oversampling_scale in gp_cairo.c.
>
> Allin Cottrell
>

So you should probalby be using the named const not a number.

Nice work.

Peter.

Re: pngcairo: suggestion for additional option

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

On Friday 23 November 2007 16:56, pl...@pi... wrote:
> On Sat, 24 Nov 2007 01:24:09 +0100, Allin Cottrell <cot...@wf...>  
> wrote:
> >
> > gp_cairo.h: #define GP_CAIRO_SCALE 20
> >
> 
> So you should probalby be using the named const not a number.

No core routine should be peering into the code of individual terminal
drivers, nor making terminal-specific decisions.  If it is necessary to 
get additional information from the terminal, it should either be
returned by one of the terminal entry routines term->foo()  or be
exported directly in the terminal table analogous to term->xmax and
term-ymax.

But please also think of alternative ways to accomplish this.
For instance, instead of setting these GPVAL_GRAPH_XMIN values from a
core routine, how about the driver setting them as part of the
term->text() processing?  In that case we might want to start up a 
new series of exported variable names.  We already have GPVAL_*, MOUSE_*,
and FIT_*.  These could be TERM_* or AXISCALE_* or something like that.


-- 
Ethan A Merritt

Re: pngcairo: suggestion for additional option

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

On Fri, 23 Nov 2007, Ethan A Merritt wrote:

> On Friday 23 November 2007 16:56, pl...@pi... wrote:
> > On Sat, 24 Nov 2007 01:24:09 +0100, Allin Cottrell <cot...@wf...>  
> > wrote:
> > >
> > > gp_cairo.h: #define GP_CAIRO_SCALE 20
> > >
> > 
> > So you should probalby be using the named const not a number.
> 
> No core routine should be peering into the code of individual 
> terminal drivers, nor making terminal-specific decisions.

Granted.  I'm attaching a set of 3 small patches that, I hope, 
jointly do the job in a reasonably elegant way.

1) term_api.h is modified to add another term->foo function, 
namely term_scale, which (if applicable) retrieves a 
terminal-specific scale factor such as the oversampling_scale
in pngcairo.

2) cairo.trm (pngcairo variant) is modified to provide that 
function, which simply returns the oversampling scale.

3) eval.c is modified as per my previous suggestion, as amended by 
you.  That is, update_gpval_variables(), for context = 1, is 
augmented to call the new function update_plot_bounds(), which 
defines the 4 variables TERM_XMIN, TERM_XMAX, TERM_YMIN and 
TERM_YMAX.  The initial values to fill out these variables come 
via the map_position() function.  We then test to see if the 
current term offers a term_scale function, and if so we use this 
to modify the values before recording them.

This way every terminal writes entries for TERM_XMIN et al, with 
the option for the maintainer of the terminal to add a scale 
factor function if that makes sense (e.g. to convert to pixels).

You suggested this sort of thing might be done on a per-terminal 
basis via the term->text function.  I thought about that, but it 
would seem to create a potential problem.  Suppose I plot using 
(say) pngcairo and the TERM_* values are set.  Then I plot again 
using some other terminal, and these values are not touched.  Now 
I'm going to get stale state information from the TERM_* 
variables.

Also, the basic bounds calculation can easily be done in the core, 
hence avoiding needless duplication of code at the terminal level.

Allin Cottrell

Re: pngcairo: suggestion for additional option

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

On Saturday 24 November 2007 11:29, Allin Cottrell wrote:
> I'm attaching a set of 3 small patches that, I hope, 
> jointly do the job in a reasonably elegant way.
> 
> 1) term_api.h is modified to add another term->foo function, 
> namely term_scale, which (if applicable) retrieves a 
> terminal-specific scale factor such as the oversampling_scale
> in pngcairo.
> 
> 2) cairo.trm (pngcairo variant) is modified to provide that 
> function, which simply returns the oversampling scale.

Thinking out loud...

Is there an advantage to having this be a function call, rather than
simply exporting the scale itself in TERM_TABLE?  

Would we ever need separate scales for X and Y?

What about auxilliary information like the mouse coordinate format?
This is a sore point in the current X11 implementation. You can 
continue to mouse an old plot even after gnuplot itself has exited,
but the format used for mouse coordinates falls back to a generic
one rather than the user-specified one.

What if someone wanted mouse feedback from the colorbar?
We don't do that now, but as long as we're looking into expanded
capabilities, why not?


> 3) eval.c is modified as per my previous suggestion, as amended by 
> you.  That is, update_gpval_variables(), for context = 1, is 
> augmented to call the new function update_plot_bounds(), which 
> defines the 4 variables TERM_XMIN, TERM_XMAX, TERM_YMIN and 
> TERM_YMAX.  The initial values to fill out these variables come 
> via the map_position() function.  We then test to see if the 
> current term offers a term_scale function, and if so we use this 
> to modify the values before recording them.

I have not yet had a chance to look at your patchset.
Too busy reviewing character encoding fix-ups :-)

> You suggested this sort of thing might be done on a per-terminal 
> basis via the term->text function.  I thought about that, but it 
> would seem to create a potential problem.  Suppose I plot using 
> (say) pngcairo and the TERM_* values are set.  Then I plot again 
> using some other terminal, and these values are not touched.  Now 
> I'm going to get stale state information from the TERM_*  variables.

But that will _always_ be the case, no matter where you put the code.
The TERM_* variables, and for that matter the GPVAL_* variables,
are only valid immediately after a plot command.  As soon as you 
change anything with a "set ..." command, the values become stale.

> Also, the basic bounds calculation can easily be done in the core, 
> hence avoiding needless duplication of code at the terminal level.

Yes, but...
Some terminals will want their own routines anyhow. In particular,
x11 has its own format and output path for this information.  

There is another possible mechanism for this case, one parallel to
that used for term->arrow(). Any driver that wants to handle arrows
privately can register a specific routine;  all others can register
the generic routine do_arrow() instead.  In fact change_term() is 
smart enough to register the generic routine do_arrow() for 
terminals that don't provide an entry point at all.  This avoids
having to patch every single driver.


-- 
Ethan A Merritt

Re: pngcairo: suggestion for additional option

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

On Mon, 26 Nov 2007, Ethan Merritt wrote:

> On Saturday 24 November 2007 11:29, Allin Cottrell wrote:
> > I'm attaching a set of 3 small patches that, I hope, 
> > jointly do the job in a reasonably elegant way.
> > 
> > 1) term_api.h is modified to add another term->foo function, 
> > namely term_scale, which (if applicable) retrieves a 
> > terminal-specific scale factor such as the oversampling_scale
> > in pngcairo.
> > 
> > 2) cairo.trm (pngcairo variant) is modified to provide that 
> > function, which simply returns the oversampling scale.
> 
> Thinking out loud...
> 
> Is there an advantage to having this be a function call, rather 
> than simply exporting the scale itself in TERM_TABLE?

As I understand it, yes.  For pngcairo, there's at present a 
hard-wired oversampling scale of 20, *if* oversampling is used.  
I believe it's always used at present, but in principle this could 
be user-configurable or otherwise depend on things at run time.

> Would we ever need separate scales for X and Y?

FWIW, I find it difficult to imagine that.

> What about auxilliary information like the mouse coordinate 
> format?

I guess that could be added where relevant: add_udv_by_name() is a 
nice flexible mechanism!

> What if someone wanted mouse feedback from the colorbar? We 
> don't do that now, but as long as we're looking into expanded 
> capabilities, why not?

Ditto.  I have no need for these things but they could be added.

> I have not yet had a chance to look at your patchset.
> Too busy reviewing character encoding fix-ups :-)

Fair enough!

> > You suggested this sort of thing might be done on a 
> > per-terminal basis via the term->text function.  I thought 
> > about that, but it would seem to create a potential problem.  
> > Suppose I plot using (say) pngcairo and the TERM_* values are 
> > set.  Then I plot again using some other terminal, and these 
> > values are not touched.  Now I'm going to get stale state 
> > information from the TERM_* variables.
> 
> But that will _always_ be the case, no matter where you put the 
> code. The TERM_* variables, and for that matter the GPVAL_* 
> variables, are only valid immediately after a plot command.  As 
> soon as you change anything with a "set ..." command, the values 
> become stale.

I'm not quite with you on that.  Suppose I do

set term pngcairo
set output '/dev/null'
plot x
print "bbox: ", TERM_XMIN, TERM_XMAX, TERM_YMIN, TERM_YMAX
# set something or other
set term dumb
print "bbox: ", TERM_XMIN, TERM_XMAX, TERM_YMIN, TERM_YMAX

Both instances of "print" (on gnuplot with my patch) produce

bbox: 79 620 37 460

This does not strike me as a case of stale information, since I'm 
getting the correct bounding box _for the last plot created_.  But 
now suppose I do:

set term pngcairo
set output '/dev/null'
plot x
print "bbox: ", TERM_XMIN, TERM_XMAX, TERM_YMIN, TERM_YMAX   
set term jpeg
set output '/dev/null'
plot x
print "bbox: ", TERM_XMIN, TERM_XMAX, TERM_YMIN, TERM_YMAX

If setting TERM_XMIN et al is optional and depends on the specific 
terminal, and if the jpeg terminal doesn't elect to do it, the 
second bbox print will be out of phase, won't it?  It'll still 
give the pngcairo bounding box while the user might reasonably 
expect it to give the jpeg box (or yield undefined values, perhaps 
-- but why bother to undef these values when they can be retrieved 
with ease).

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

Re: pngcairo: suggestion for additional option

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

On Monday 26 November 2007 11:44, you wrote:
> On Mon, 26 Nov 2007, Ethan Merritt wrote:
> > 
> > Is there an advantage to having this be a function call, rather 
> > than simply exporting the scale itself in TERM_TABLE?
> 
> As I understand it, yes.  For pngcairo, there's at present a 
> hard-wired oversampling scale of 20, *if* oversampling is used.  
> I believe it's always used at present, but in principle this could 
> be user-configurable or otherwise depend on things at run time.

I think the tool button on the wxt terminal allows you to toggle the
oversampling.  But isn't that exactly the same as term->xmax and
term->ymax changing dynamically when you resize the plot window?

> > > You suggested this sort of thing might be done on a 
> > > per-terminal basis via the term->text function.  I thought 
> > > about that, but it would seem to create a potential problem.  
> > > Suppose I plot using (say) pngcairo and the TERM_* values are 
> > > set.  Then I plot again using some other terminal, and these 
> > > values are not touched.  Now I'm going to get stale state 
> > > information from the TERM_* variables.
> > 
> > But that will _always_ be the case, no matter where you put the 
> > code. The TERM_* variables, and for that matter the GPVAL_* 
> > variables, are only valid immediately after a plot command.  As 
> > soon as you change anything with a "set ..." command, the values 
> > become stale.
> 
> I'm not quite with you on that.  Suppose I do
> 
> set term pngcairo
> set output '/dev/null'
> plot x
> print "bbox: ", TERM_XMIN, TERM_XMAX, TERM_YMIN, TERM_YMAX
> # set something or other
> set term dumb
> print "bbox: ", TERM_XMIN, TERM_XMAX, TERM_YMIN, TERM_YMAX
> 
> Both instances of "print" (on gnuplot with my patch) produce
> 
> bbox: 79 620 37 460
> 
> This does not strike me as a case of stale information, since I'm 
> getting the correct bounding box _for the last plot created_. 

I'm not saying that every "set" command inevitably invalidates
every variable.  But many "set" commands invalidate one or more
variables.  In particular, any command that affects the axis
ranges or scaling will invalidate the use of TERM_* for back-calculating
plot coordinates.  It would be tricky for gnuplot itself to know
whether it is still safe to present a value for a particular variable,
so the burden is on the user to capture a consistent snapshot of values.
And I think the only guaranteed safe time to do that is immediately 
after a plot command. 

> set term pngcairo
> set output '/dev/null'
> plot x
> print "bbox: ", TERM_XMIN, TERM_XMAX, TERM_YMIN, TERM_YMAX   
> set term jpeg
> set output '/dev/null'
> plot x
> print "bbox: ", TERM_XMIN, TERM_XMAX, TERM_YMIN, TERM_YMAX
> 
> If setting TERM_XMIN et al is optional and depends on the specific 
> terminal, and if the jpeg terminal doesn't elect to do it, the 
> second bbox print will be out of phase, won't it?

That is certainly an argument for requiring that the TERM_* variables
be updated for all terminal types.  The best mechanism for doing this
is under discussion.

-- 
Ethan A Merritt

Re: pngcairo: suggestion for additional option

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

On Mon, 26 Nov 2007, Ethan Merritt wrote:

> On Monday 26 November 2007 11:44, you wrote:
> > On Mon, 26 Nov 2007, Ethan Merritt wrote:
> > > 
> > > Is there an advantage to having this be a function call, rather 
> > > than simply exporting the scale itself in TERM_TABLE?
> > 
> > As I understand it, yes.  For pngcairo, there's at present a 
> > hard-wired oversampling scale of 20, *if* oversampling is used.  
> > I believe it's always used at present, but in principle this could 
> > be user-configurable or otherwise depend on things at run time.

Hans has put me right: I had thought of TERM_TABLE entries as 
constants but I was wrong.  However, it seems to me easier to add 
a function pointer at the end of the table: that way no *.trm code 
needs to be touched unless the term wants to offer a scale factor.

Allin Cottrell

Re: pngcairo: suggestion for additional option

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

On Monday 26 November 2007 10:11, Ethan Merritt wrote:
> Thinking out loud...
> 
> Is there an advantage to having this be a function call, rather than
> simply exporting the scale itself in TERM_TABLE?  
> 
> Would we ever need separate scales for X and Y?
> 
> What about auxilliary information like the mouse coordinate format?
> This is a sore point in the current X11 implementation. You can 
> continue to mouse an old plot even after gnuplot itself has exited,
> but the format used for mouse coordinates falls back to a generic
> one rather than the user-specified one.
> 
> What if someone wanted mouse feedback from the colorbar?
> We don't do that now, but as long as we're looking into expanded
> capabilities, why not?

Another thought, from my long-term wishlist...

Whatever mechanism we end up with, it would be nice to have it
available for the individual subplots within a multiplot.

-- 
Ethan A Merritt

Re: pngcairo: suggestion for additional option

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

Allin Cottrell wrote:

> Hans has put me right: I had thought of TERM_TABLE entries as 
> constants but I was wrong.  However, it seems to me easier to add 
> a function pointer at the end of the table: that way no *.trm code 
> needs to be touched unless the term wants to offer a scale factor.

Same difference.  Adding a variable at the end of the struct has the 
same net effect, and the benefit of being less risky.  An unsupported 
variable automatically defaults to zero, but an unsupported function 
defaults to an invalid function pointer, which is generally unsafe to use.