Re: Scale change for Plot Figures in the Manual

[Rik]

> On Nov 28, 2009, at 5:05 PM, Ben Abbott wrote:
>   
>> On Nov 28, 2009, at 4:27 PM, John W. Eaton wrote:
>>
>>     
>>> On 27-Nov-2009, Michael D. Godfrey wrote:
>>>
>>> | I looked at the current octave.pdf to see if my method
>>> | of recovering from the doc/interpreter build problem had
>>> | worked.  This caused me to notice that the Figures in the
>>> | Plotting Chapter are now about 1/5 intended size.  I looked
>>> | back at a Manual generated on 23 November.  (Before the
>>> | build problem.)  It shows the same scale problem.
>>> | 
>>> | I believe that the build script always uses octave -f, so
>>> | the problem is probably not due to my having backend("fltk")
>>> | in my .octaverc file.
>>> | 
>>> | Is this problem happening to others?
>>>
>>> Yes, it seems that we are now using
>>>
>>> print -dpdf
>>>
>>> to create the PDF files and the resulting output is not cropped
>>> tightly around teh bounding box of the figure.
>>>
>>> If that is what the -dpdf option is supposed to do, then I guess we
>>> should probably just have the  Makefile produce .eps files and then
>>> convert them to formats we need instead of using Octave's print
>>> function to generate the various formats.
>>>
>>> jwe
>>>       
>> "print -dpdf" should output the size of which is defined by the "pagesize" 
>> property.
>>
>> Seeing this reminded me that we'd discussed this some months ago. See the 
>> thread below.
>>
>>      
>> http://old.nabble.com/printing-figures-with-development-version-td22746152.html#a22835985
>>
>> The problem can be resolved by switching to eps. However, it is possible 
>> that the axes labels may be clipped. In that case, the pdf size may be 
>> specified by changing the defualtpapersize and defaultpaperposition prior to 
>> generating the pdfs.
>>
>>        image_size = [6.4, 4.8]; % in inches 
>>        border = 0;
>>        set (0, "defaultfigurepapertype", "<custom>") 
>>        set (0, "defaultfigurepapersize", image_size + 2*border) 
>>        set (0, "defaultfigurepaperposition", [border, border, image_size]) 
>>
>> If the axes labels for the pdf get cut off, the "border" may be increased.
>>
>> Ben
>>     
>
> The changeset below looks like it was the result of the thread above.
>
>       
> http://hg.savannah.gnu.org/hgweb/octave/diff/77e71f3da3d6/doc/interpreter/plotimages.m
>
> I'm unfamiliar with how the documentation is created, but It appears to me 
> that the files below need to have similar changes.
>
>       
> http://hg.savannah.gnu.org/hgweb/octave/log/cddd5c3d5f04/doc/interpreter/geometryimages.m
>
>       
> http://hg.savannah.gnu.org/hgweb/octave/log/cddd5c3d5f04/doc/interpreter/interpimages.m
>
>       
> http://hg.savannah.gnu.org/hgweb/octave/log/cddd5c3d5f04/doc/interpreter/sparseimages.m
>
> I'm presently unable to build the developers version of octave.  Can someone 
> tell me if the attached works?
>
>   
The attached patch is good because it helps set consistent image sizes
across all of the documentation images.  I will check it in once John
finishes updating the documentation build process to get rid of
conf.texi.  However, pdf image size remains unchanged by the patch.

The problem is specific to the pdf engine and is not related to the
plotimages.m script.  Running octave normally I can create a figure, set
the appropriate parameters such as papersize on the current figure, and
then use print.  If I print to png or eps the papersize is respected. 
If I print to pdf the default paper size of US letter is used.  I used
pdfinfo on the output file to verify the pagesize rather than just
eyeballing it.  It seems that getting pdf printing to work under normal
conditions would fix it for the documentation as well.

Octave version : current tip
and according to pdfinfo
Creator:    gnuplot 4.2 patchlevel 5
Producer: GPL Ghostscript 8.61

--Rik