Re: printing figures with development version

[Shai Ayal]

On Thu, Apr 2, 2009 at 2:21 AM, Ben Abbott <address@hidden> wrote:
>
> On Apr 1, 2009, at 5:16 PM, Rik wrote:
>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> Subject:
>>> Re: printing figures with development version
>>> From:
>>> Ben Abbott <address@hidden>
>>> Date:
>>> Sat, 28 Mar 2009 13:38:38 -0400
>>> To:
>>> "John W. Eaton" <address@hidden>
>>>
>>> To:
>>> "John W. Eaton" <address@hidden>
>>> CC:
>>> address@hidden
>>>
>>> On Mar 28, 2009, at 12:17 PM, John W. Eaton wrote:
>>>
>>>> On 27-Mar-2009, Ben Abbott wrote:
>>>>
>>>> | What you see is intended. You'll need to adjust the figure's paper
>>>> properties. Specifically, "papersize" and "paperpositon"
>>>> |
>>>> | If you'd like an 6.4in x 4.8in eps file
>>>> |
>>>> | figure (1)
>>>> | clf
>>>> | plot (randn (50, 1))
>>>> | set (gcf, "paperunits", "inches"); # the default is "inches"
>>>> | paper_size = [6.4, 4.8];
>>>> | set (gcf, "papersize", paper_size)
>>>> | set (gcf, "papertype", "<custom>")
>>>> | set (gcf, "paperposition", [0, 0, paper_size])
>>>> | print (gcf, strcat ("figtest", version, ".eps"), "-depsc")
>>>> |
>>>> | This will be much simpler once the all listeners for these
>>>> properties are in place.
>>>>
>>>> If I print to a .eps file, I expect that the bounding box of the
>>>> figure will be fairly tight around the figure so that it may be
>>>> included directly in another document without a lot of extra
>>>> whitespace surrounding it.  I think that is most useful.  I also don't
>>>> expect to have to fiddle with paper properties to make that happen
>>>> (how would I know that 6.4x4.8 inches are good values?).
>>>>
>>>> Earlier versions of Octave did not add extra whitespace around the
>>>> figure, so I think we will see a lot of complaints about this change
>>>> if it escapes into a stable version.
>>>>
>>>> What is the motivation for the change?  Is there something good about
>>>> this design choice that I'm missing?  If the change is purely for
>>>> Matlab compatibility, then I think this is one of those things that we
>>>> should not copy.
>>>>
>>>> jwe
>>>
>>>
>>> The current implementation produces compatible behavior ... except
>>> that the BoundingBox defined by gnuplot is not tight, and the one
>>> produced by Matlab is.
>>>
>>> The current implementation may be modified to obtain the desired
>>> result by changing the papersize for the eps output to ...
>>>
>>>   papersize = paperposition + [50, 50, 100, 100]/72;
>>>
>>> Where the paperunits are implied to be "inches". The 50pt border is a
>>> gnuplot feature.
>>>
>>> I'll prepare a changeset.
>>>
>>> Ben
>>>
>> Per John's observation, I think this will generate a lot of complaints
>> from people used to the old style.
>>
>> Of more immediate concern to me, there are 22 figures in the Octave
>> documentation that are auto-generated by Octave code.  The output format
>> is png for the HTML documentation and pdf for the pdf documentation
>> (Duh!).  Under the old code these figures slipped into the text nicely
>> but they now have about 1/3 of a blank page above and below them.  If it
>> is certain that this is the new format for the print command I will
>> re-code the figure generation scripts to include all of the
>> papersize-setting commands above.  If there is an option to flip
>> Matlab-compatability on or off I would prefer to use that and not change
>> the scripts.
>>
>> Cheers,
>> Rik
>
> Rik,
>
> I certainly get all the credit for this problem. I was focused on the goal
> of compatibility with Matlab and didn't consider the documentation.
>
> In any event, I think the best solution would be one that is compatible with
> Matlab, and is simple to implement.
>
> My first thought was to run the lines below prior to producing the figures
> for the documentation.
>
>        image_size = [6.4, 4.8]; % in inches
>        border = 0; % For postscript use 50/72
>        set (0, "defaultfigurepapertype", "<custom>")
>        set (0, "defaultfigurepapersize", image_size + 2*border)
>        set (0, "defaultfigurepaperposition", [border, border, image_size])
>
> This *should* produce pdf files at 6.4x4.8 inches.
>
> Unfortunately, these defaults are not passed onto the figures :-(
>
> Even so, as the defaults not set for the figure is a bug, I recommend this
> solution.
>
> Rik, do you know enough c++ to take care of setting the figure's default
> properities? (I don't).
>

you would have to change the following 2 functions in src/graphics.cc:
default_figure_papersize
default_figure_paperposition

also, in src/graphics.h.in, you would have to change the line which has:
radio_property papertype , "{usletter}|uslegal|a0|a1|a ..."
and move the curly brackets to surround <custom> instead of {usletter}

Shai