Menu
▾
▴
gnuplot-beta
|
From: Allin C. <cot...@wf...> - 2007-11-27 01:49:44
|
On Tue, 27 Nov 2007, Hans-Bernhard Bröker wrote: > 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. I thought things were set up so that an unsupported function defaults to a null pointer (and my proposed code tests for that). Is that incorrect? On the other hand, having the scale variable default to zero would not be good at all -- it should really default to 1, though I suppose one could work around a broken default of 0. Allin Cottrell |
|
From: Ethan A M. <merritt@u.washington.edu> - 2007-11-27 02:04:05
|
On Monday 26 November 2007 17:48, Allin Cottrell wrote: > On the other hand, having the scale variable > default to zero would not be good at all -- it should really > default to 1 Just put a fix-up line in change_term() along with the others at term.c lines 1524-1536 -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: <HBB...@t-...> - 2007-11-27 19:13:22
|
Allin Cottrell wrote: > On Tue, 27 Nov 2007, Hans-Bernhard Bröker wrote: >> 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. > I thought things were set up so that an unsupported function > defaults to a null pointer (and my proposed code tests for that). Correct. More to the point, as long as new elements only get added at the end of the struct, every unsupported member defaults to a zero of the approriate type. Numeric variables end up as zero, pointers as null pointers. > On the other hand, having the scale variable > default to zero would not be good at all -- it should really > default to 1, though I suppose one could work around a broken > default of 0. Testing for variable == 0 is no harder than testing for function pointer == 0. |
|
From: Allin C. <cot...@wf...> - 2007-11-28 00:42:57
|
On Tue, 27 Nov 2007, Hans-Bernhard Bröker wrote: > Allin Cottrell wrote: > > On Tue, 27 Nov 2007, Hans-Bernhard Bröker wrote: > > > > 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. > > > I thought things were set up so that an unsupported function > > defaults to a null pointer (and my proposed code tests for > > that). > > Correct. More to the point, as long as new elements only get > added at the end of the struct, every unsupported member > defaults to a zero of the approriate type. Numeric variables > end up as zero, pointers as null pointers. > > > On the other hand, having the scale variable default to zero > > would not be good at all -- it should really default to 1, > > though I suppose one could work around a broken default of 0. > > Testing for variable == 0 is no harder than testing for function > pointer == 0. Granted; we can assume that scale == 0 means scale == 1. Should I take this comment as a "vote" in favor of handling this issue by means of a new variable in the terminal structure rather than a new function pointer? If so, I have only one other point to suggest to the contrary. That is, Ethan has (I think) alluded to things other than a simple scale factor, that specific terminals might want to provide. A function pointer is inherently extensible, but if we add a variable to handle scale, it's possible we might end up having to add more variables to cope with fancier variants on the basic idea. I'll be travelling from tomorrow till mid-December, so please don't take lack of further responses on this topic to indicate lack of interest! I really would like to see this settled, one way or the other. -- Allin Cottrell Department of Economics Wake Forest University, NC |
|
From: <HBB...@t-...> - 2007-11-28 21:41:27
|
Allin Cottrell wrote: > Should I take this comment as a "vote" in favor of handling this > issue by means of a new variable in the terminal structure rather > than a new function pointer? Yes. > That is, Ethan has (I think) alluded to things other than a simple > scale factor, that specific terminals might want to provide. A > function pointer is inherently extensible, Not really. An API entry point created with the pre-existing intention of extending it later, in some as yet unkown way, is basically a declaration of capitulation. It states "I don't know how to design this, so I won't design it at all." As soon as you add features to the function, you just end up having to do exactly what the terminal API was explicitly designed *not* to need: to patch up all drivers that already have the new function to cover its new aspect. > but if we add a variable to handle scale, it's possible we might end > up having to add more variables to cope with fancier variants on the > basic idea. That's exactly how the system is supposed to be used, yes. |
|
From: Allin C. <cot...@wf...> - 2007-12-19 16:18:15
Attachments:
term_bounds_diffs.tgz
|
On Wed, 28 Nov 2007, Hans-Bernhard Bröker wrote: > Allin Cottrell wrote: > > > Should I take this comment as a "vote" in favor of handling > > this issue by means of a new variable in the terminal > > structure rather than a new function pointer? > > Yes. 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. Allin Cottrell |
|
From: Ethan A M. <merritt@u.washington.edu> - 2007-12-25 20:33:48
|
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'. This is
because the coordinate mapping is more complicated. In the case of
the png terminal:
Y(coord) = (term->ymax - coord)
Other terminals, particularly postscript, are more complicated yet.
Postscript has to deal with landscape/portrait mode as well as
bounding box offsets. I suspect that the only way to do this properly
is to have each terminal report its own mapping.
As an aside, I realized while looking at the patch code that aside
from scaling these numbers are already available as
axis_array[FIRST_X_AXIS].term_lower
axis_array[FIRST_X_AXIS].term_upper
and so on.
Ethan
--
Ethan A Merritt
|
|
From: Allin C. <cot...@wf...> - 2007-12-26 22:05:55
|
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
|
|
From: Ethan A M. <merritt@u.washington.edu> - 2007-12-26 23:10:20
|
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
|
|
From: Allin C. <cot...@wf...> - 2007-12-28 00:20:16
|
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 |
|
From: Ethan A M. <merritt@u.washington.edu> - 2007-12-28 22:45:07
Attachments:
term_bounds_28dec2007.patch
|
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
|
|
From: Allin C. <cot...@wf...> - 2007-12-31 05:09:02
|
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 |
