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

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

> >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.
And I don't see a way to do it for pbm output either.
 
> - 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.

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.

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.

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195