Re: bug in terminals affected by 'set size'

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

On Thursday 06 October 2005 12:17 pm, Harald Harders wrote:
> 
> [... a lot of discussion about sizes above 1 ...]
> 
> In my opinion, there are two mutually exclusive solutions:
> 
> 1.) 'set size' before 'set terminal' can affect the canvas size. Then,
> sizes below and above 1 have to be valid because then 'size 1,1' means the
> default size. Partly, this is the current state while sizes > 1 only work
> partly.

I am being educated about this use of "set size".  It's not the way I
have been using it, but I fully understand the argument about not
necessarily wanting to scale line widths and font sizes with the 
graph size.  So I retract my previous claim that sizes greater than 1
are never correct.

But, as you say, it only partly works now.
For instance, setting the size to something other than 1,1 before
setting the terminal seems to break multiplot layouts.

 
> 2.) 'set size' only affects the size of the plot within the current
> canvas while the canvas (or bouding box or what ever) is influenced by
> another mechanism, e.g., 'set terminal <term> size <x,y>'. Here, the
> possible values can be different for different terminals, e.g.,
>   set terminal postscript size 5cm,3cm
>   set terminal postscript eps size 300pt,200pt
>   set terminal postscript eps size 300,200 # could default to pt
>   set terminal postscript eps size 300,200 offset 100,150
>        # results in %%BoundingBox: 100 150 400 350
>   set terminal gif size 300,200 # defaults to pixel
>   set terminal gif size 1in,1in resolution 300 # = 300 x 300 pixel, 300dpi

That is the way I would prefer to have it work.
The range of reasonable canvas sizes is clearly terminal-dependent, 
so choosing a size should done in the terminal-specific initialization.
It will mean modifying drivers, but it seems straightforward.


Next problem:

The harder task related to this is the larger issue of remedying
the lack of line and text clipping in the core routines.
Right now  "set size 0.1,0.1;  set term <foo>; test"
will crash on many terminal types because the various 
lines and text on the test page are not clipped against the
reduced canvas size.  Regular plotting is somewhat better, since
the actual plot elements are properly clipped. But elements such
as the key, title, and individually placed arrows or labels are
not clipped and still prone to cause segfaults.  The pdf terminal
is particularly sensitive to this, but all drivers that use
the shared routines in bitmap.c suffer the same problem.

The code in the current clipping routines would do the job,
except currently it explicitly clips to the plot area, not the canvas.
I think the way forward is to:

1) move  xright, xleft, ytop, ybot into a new structure, e.g.
   struct {int xright; int xleft; int ytop; int ybot;} bounding_box.

2) create and maintain two global instances of such a structure;
   one that describes the plot area, another that describes the
   whole canvas.

3) modify the clip_line() and clip_point() to clip against whichever
   bounding_box structure is currently active

4) Existing calls to the clipping routines will continue to
   work as always, and clip against the plot area.
   Any code that needs to place elements outside the plot (key, title,
   arrows, axis lables, ...) would change the active bounding_box
   to the entire canvas, clip, and then restore the bounding_box.

At that point we would have protected all drivers against 
out-of-range vectors and moves.  Text clipping would not be
perfect, but better than it is now.

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