octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: printing figures with development version


From: Rik
Subject: Re: printing figures with development version
Date: Wed, 01 Apr 2009 14:16:42 -0700
User-agent: Thunderbird 2.0.0.21 (X11/20090318)

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]