Re: square behavior

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:

>>left edge and whatever ends up with white space, right or top, so be 
>>it.  In the case of "square" size it's as though one anchors from the lower, 
>>    
>>
> <>
>
> In a word: no. Not the way the code is currently laid out.
> You'd enter a possibly infinite cycle of re-adjusting and recalculating
> and re-laying out and retesting.


Maybe this can be made to work out.  In a few weeks I will have a look; 
perhaps I'll revisit the key patch at the same time since it is related.

Also, in some patch I think I once put code that balanced the left and 
right or top and bottom whitespace in the case of "square".  I'd like to 
propose putting that back in if I can find it again.  It looked so much 
better in X11 plots.  Also, I bet it would look a whole lot better with 
multiplot subplots that use the square size option, in all terminals.

I just think there is no case where a user wants that extra white space 
in an EPS file that comes about from "square".  It's tolerable in X11, 
but not as an imported graphic.

First, there is a philosophical restriction here in that the BoundingBox 
must be output before other PostScript command are.  I don't think we 
want to approach this by, say, rerouting PostScript commands to a temp 
file, computing the BoundingBox, generating header in desired output 
file, then dumping the temp file to the desired output file.  No?  So 
that means we must stay away from a terminal level solution?

That being the case, the multiplot plots really pose a problem because 
each multiplot plot is done as a separate plot command.  There is 
absolutely no way to generate BoundingBox information in that situation 
because we are forced to send out plots before closing the multiplot.  
This may not be such a severe limitation.  In the case of multiplot, 
unless ones specifies all subplots sizes "square", there will be some 
whitespace that can't be removed.

OK, so let's just consider the single plot scenario.  In the code are 
the following few commands when starting a plot.

    /* EAM June 2003 - Although the comment below implies that font 
dimensions
     * are known after term_init(), this is not true at least for the X11
     * driver.  X11 fonts are not set until an actual display window is
     * opened, and that happens in term->graphics(), which is called from
     * term_start_plot().
     */
    term_init();        /* may set xmax/ymax */
    term_start_plot();

    /* compute boundary for plot (xleft, xright, ytop, ybot)
     * also calculates tics, since xtics depend on xleft
     * but xleft depends on ytics. Boundary calculations depend
     * on term->v_char etc, so terminal must be initialised first.
     */
    boundary(plots, pcount);

term_init() is where the BoundingBox is written.  I believe that 
boundary() is where axes etc. are computed, but nothing is written to 
the terminal.  So, if boundary() could be moved before 
"term_start_plot()" and BoundingBox could be written inside 
term_start_plot() we might have knowledge of the extent of the image 
before writing the BoundingBox.  Could the bounding box info be passed 
into the terminal via the "options" function and most terminals just 
ignore it?

Dan