printing figures with development version

Ben Abbott bpabbott at mac.com
Thu Apr 2 08:50:26 CDT 2009


On Apr 2, 2009, at 5:18 AM, Ben Abbott wrote:

>
> On Apr 1, 2009, at 11:32 PM, Shai Ayal wrote:
>
>> On Thu, Apr 2, 2009 at 2:21 AM, Ben Abbott <bpabbott at mac.com> wrote:
>>>
>>> On Apr 1, 2009, at 5:16 PM, Rik wrote:
>>>
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> Subject:
>>>>> Re: printing figures with development version
>>>>> From:
>>>>> Ben Abbott <bpabbott at mac.com>
>>>>> Date:
>>>>> Sat, 28 Mar 2009 13:38:38 -0400
>>>>> To:
>>>>> "John W. Eaton" <jwe at octave.org>
>>>>>
>>>>> To:
>>>>> "John W. Eaton" <jwe at octave.org>
>>>>> CC:
>>>>> octave-maintainers at octave.org
>>>>>
>>>>> 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
>
> Hi Shai,
>
> opps, I wasn't clear.
>
> I don't want to change the defaults for all octave sessions, only  
> for the one that is running.
>
> For example, the default axes fontsize can be set from the command  
> line by ...
>
> 	set (0, "defaultaxesfontsize", 18)
>
> Then new axes will then have the tick labels with size 18pt. For  
> example ...
>
> octave:1> plot (1:10)
> octave:2> get (gca, "fontsize")
> ans =  12
> octave:3> set (0, "defaultaxesfontsize", 18)
> octave:4> figure
> octave:5> plot (1:10)
> octave:6> get (gca, "fontsize")
> ans =  18
>
> Ben

Shai, Rik, All ...

I should be more suspicious of late night programming ... after a  
nights sleep and my coffee, I am unable to reproduce my trouble with  
the default today.

Rik,

If you place the lines below in a startup script ... say startup.m

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

And then start octave using ...

	octave --norc --persist startup.m

Those default figure properties will be in effect, and any pdf's  
generated will be 6.4x4.8 inches.

(sigh) ... For a sanity check, I'll spend some time trying to  
reproduce my difficulties.

Ben	





More information about the Octave-maintainers mailing list