Re: [ gnuplot-Patches-1356114 ] set term post size <foo>in,<baz>in (also cm)

[Harald H. <h.h...@tu...>]

On Thu, 17 Nov 2005, Ethan Merritt wrote:

> > >remember that just because gnuplot thinks the output
> > >resolution is 300 pixels per something, that doesn't
> > >mean the actual display device will have that resolution.
> >
> > This only applies to screen terminals. Screen terminals as
> > x11 should read the system-wide value as default.
>
> There is no such thing as a system-wide default for x11.
> It is different for every display session.
>
> > But for all pixel-based terminals (png, gif, ...), the
> > resolution can be written into the output file.
>
> Actually, it can't.  Or at least, not using libgd.
> That is a failing of libgd but we are stuck with it at present.

If I remember correctly, the developer of libgd has worked together with
the gnuplot developers several times. I we ask him to include resolution
support, he probably will add it in future.

> And I don't see a way to do it for pbm output either.

I do not know the pbm format well enough to say anything about it.

> > - A patch exists that fixes clipping for many (or all?)
> > terminals.
>
> You are referring to patch #1104264?
> That patch does not fix the root problem at all. It just
> multiplies the reported screen limits by a factor large
> enough to let the arrows escape clipping.  This works for
> PostScript because it doesn't really care that you are drawing
> outside of the limits it previously reported.
> On terminals that do care, your patch could make things worse
> rather than better.

No, I am talking about patch #1353539.

The thing is that term->xmax and term->ymax are not what they seem. They
are the internal coordinate values for the position on the screen where
the screen coordinates are 1. In many situations, this position is
identical with the upper right corner of the canvas. But there are also
many situations where this is not the case. For example when using 'set
offset' or 'set size' in postscript, png, jpg, fig (may be more, I have
not tested more).

This test adds "BoundingBox canvas;" to "struct TERMENTRY". By default,
the canvas boundaries and xmax,ymax are identical. They are only changed
when 'set size' or 'set origin' is used in terminals which support a
change of the plot and canvas by this.
It maybe also should rename xmax and ymax to something that fits better
what these variables mean. But I have decided not to touch every file.

Have a look at the newly uploaded patch, compile it with DEBUG defined,
and try out the attached script.
It shows that clipping works correctly for postscript, png, and x11. For
fig, clipping isn't done at all (but the clipping routines are not
invoked. Thus it cannot work with any existing code, but the new code
issues a warning).

> I would much rather the problem, if it is one, be fixed
> by having the terminals correctly report a legal range of
> x and y values.  That would make the current clipping code
> work for all terminals, rather than having to special-case
> terminals that report silly values.

Do you agree that this patch fulfills this? With it, all terminals report
the position of screen 1,1 in term->xmax,term->ymax and the size and
position of the canvas in term->canvas.

> But if we *do* have to special-case post.trm, it's better to
> just turn off clipping altogether rather than "fix" it
> by describing an over-large drawing area.
> Please try the patch I sent you earlier today.

This sounds like a good idea. Does this also apply to libgd? Or does it
produce core dumps when trying to produce a pixel outside of the picture
canvas?

But still terminals as fig have to be able to place labels and arrows
everywhere where other elements of the plots can also appear.

I have had a look to your Postscript clipping patch. I think this could be
useful in addition. I am preparing an extension because Postscript does
not do the clipping by default but can be told to do it.

Best regards
Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de