Re: bug in terminals affected by 'set size'

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

On Thu, 6 Oct 2005, Ethan Merritt wrote:

> 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.

Do you mean the automatic ones? I always to multiplots by hand and they
also work for plots with sizes greater than 1.

> > 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.

I agree. Sounds like a plan and a lot of work.

> 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.

May be we should start with this task of two different clipping boxes
(plot and canvas). Then, the rest could be done sequencially.


I still have the idea that there should be a terminal-independent option
that changes the size of the canvas by a factor. I am aware that this
would be difficult to explain because a thing like
  set canvasscale 1.5,1.5
  set terminal png size 640,480
would lead to a picture of the size 960 x 720 which seams pretty
unlogical. But in some cases such a function could be useful. For some
terminals this new function would then do the same as a 'set size' before
'set terminal' does now. But I think, this functionality could be added
after providing a clean solution for differentiation between plot size and
canvas size.

Best regards
Harald

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