Re: Changeset 14257 oddities

[Ben Abbott]

On Mar 10, 2012, at 10:07 PM, Ben Abbott wrote:

> On Mar 10, 2012, at 7:33 PM, Ben Abbott wrote:
> 
>> On Mar 10, 2012, at 6:21 PM, Ben Abbott wrote:
>> 
>>> On Mar 10, 2012, at 5:23 PM, Rik wrote:
>>> 
>>>> On 03/10/2012 11:17 AM, Ben Abbott wrote:
>>>> 
>>>>> On Mar 10, 2012, at 10:29 AM, Ben Abbott wrote:
>>>>> 
>>>>>> On Mar 10, 2012, at 12:04 AM, Rik wrote:
>>>>>> 
>>>>>>> 3/9/12
>>>>>>> 
>>>>>>> Ben,
>>>>>>> 
>>>>>>> I've just noticed that this changeset is causing oddities in the
>>>>>>> documentation.  All of the printed images, which are supposed to be 750 
>>>>>>> x
>>>>>>> 525 are being rendered as 525 x 750.  The changeset deals with
>>>>>>> paperorientation so perhaps this is not surprising.
>>>>>>> 
>>>>>>> changeset:   14257:5cc69bafe3b9
>>>>>>> parent:      14254:73086d4b64fa
>>>>>>> user:        Ben Abbott  <address@hidden>
>>>>>>> date:        Tue Jan 24 08:29:33 2012 -0500
>>>>>>> summary:     Add updating for figure paperorientation property. Bug # 
>>>>>>> 35329.
>>>>>>> 
>>>>>>> Code which provokes the problem for me
>>>>>>> 
>>>>>>> plot (1:10)
>>>>>>> get (gcf, 'paperorientation')
>>>>>>> => portrait
>>>>>>> get (gcf, 'papersize')
>>>>>>> =>   8.5000   11.0000
>>>>>>> set (gcf, 'papersize', [5.0 3.5])
>>>>>>> get (gcf, 'paperorientation')
>>>>>>> => landscape
>>>>>>> get (gcf, 'papersize')
>>>>>>> =>   3.5000   5.0000
>>>>>>> print foo.png
>>>>>>> 
>>>>>>> The printed png is printed in a portrait mode which is 3.5 wide X 5.0 
>>>>>>> high
>>>>>>> instead of the papersize I set.
>>>>>>> 
>>>>>>> --Rik
>>>>>> Rik, I've cc'd the list, as I think this merits some discussion (and I'm 
>>>>>> not sure what the proper solution is)
>>>>>> 
>>>>>> When I experimented with Matlab, I found its behavior inconsistent. I 
>>>>>> don't recall all the details now. I'll take a look when I'm done with 
>>>>>> the fixing the text objects set_position method.
>>>>>> 
>>>>>> In any event (from memory), the current implementation was intended to 
>>>>>> map a wide page to "landscape" and a tall page to "portrait" orientation 
>>>>>> (and vice versa). Perhaps this is not consistent with how print() works ?
>>>>>> 
>>>>>> The Matlab docs do not specifically indicate that a wide page -> 
>>>>>> "landscape" and a tall page -> "portrait".
>>>>>> 
>>>>>> I suggest we attempt to determine the proper behavior from the Matlab 
>>>>>> docs and implement that.
>>>>>> 
>>>>>> If the orientation does not map to wide/tall, but just rotates the page, 
>>>>>> then the fix needs to be in graphics.cc and your example will work like 
>>>>>> ...
>>>>>> 
>>>>>>> plot (1:10)
>>>>>>> get (gcf, 'paperorientation')
>>>>>>> => portrait
>>>>>>> get (gcf, 'papersize')
>>>>>>> =>   8.5000   11.0000
>>>>>>> set (gcf, 'papersize', [5.0 3.5])
>>>>>>> get (gcf, 'paperorientation')
>>>>>>> => portrait
>>>>>>> get (gcf, 'papersize')
>>>>>>> =>   5.0000   3.5000
>>>>>> If the orientation does map to wide/tall then the fix needs to be in 
>>>>>> print.m and your example will remain the same except the output will be 
>>>>>> 5x3.5 
>>>>>> 
>>>>>> Thoughts / opinions ?
>>>>>> 
>>>>>> Ben
>>>>> I just noticed Rik's example is working at intended. 
>>>>> 
>>>>> The size of the image is determined by paperpostion(3:4), not by the 
>>>>> papersize.
>>>>> 
>>>>> Even so, we may want change how orientation is handled, and if not, 
>>>>> improve the documentation to avoid confusion.
>>>>> 
>>>>> Ben
>>>> 
>>>> I agree with your earlier thought to at least check what Matlab is doing in
>>>> this situation.  However, there is no reason to follow them down the garden
>>>> path if they have done something stupid.
>>>> 
>>>> In fact, for the printing I think we would be fine designing our own system
>>>> as long as it was sensible and intuitive.  Right now, it is *not* intuitive
>>>> to me to set the size of the image by changing its position on the page. 
>>>> We have time to figure this out as the documentation doesn't need to build
>>>> again until 3.8.
>>>> 
>>>> --Rik
>>> 
>>> The two issues we need to decide upon are;
>>> 
>>> (1) Shall the image size be determined by paperposition(3:4) as Matlab does 
>>> (and Octave currently does), or by papersize / paperorientation?
>>> 
>>> (2) Currently Octave's paperorientation determines if the pagesize is tall 
>>> (portrait) or wide (landscape). While Matlab's paperorientation determines 
>>> if paper output horizontally or vertically oriented on the paper 
>>> (independent of the width and/or height dimensions of the paper).
>>> 
>>> I'm inclined to follow Matlab's docs. I'll start looking at (2). My 
>>> expectation is that changes will needed to be made in two function in 
>>> graphics.cc.
>>> 
>>>     figure::properties::update_papersize
>>>     figure::properties::update_paperorientation
>>> 
>>> A change to orient.m may also be needed.
>>> 
>>> Ben
>> 
>> Opps ... busy day ... I forgot to add links to Matlab's doc info.
>> 
>>      
>> http://www.mathworks.com/help/techdoc/ref/figure_props.html#PaperOrientation
>> 
>> --------------------
>> Horizontal or vertical paper orientation. Determines how to orient printed 
>> figures on the page.
>> 
>>      • portrait — Orients the longest page dimension vertically.
>> 
>>      • landscape — Orients the longest page dimension horizontally.
>> --------------------
>> 
>>      http://www.mathworks.com/help/techdoc/ref/figure_props.html#PaperSize
>> 
>> --------------------
>> [width height]
>> Paper size. Size of the current PaperType, measured in PaperUnits. See 
>> PaperType to select standard paper sizes.
>> --------------------
>> 
>>      http://www.mathworks.com/help/techdoc/ref/orient.html
>> 
>> --------------------
>> orient landscape sets the paper orientation of the current figure to 
>> full-page landscape, orienting the longest page dimension horizontally. The 
>> figure is centered on the page and scaled to fit the page with a 0.25 inch 
>> border.
>> 
>> orient portrait sets the paper orientation of the current figure to 
>> portrait, orienting the longest page dimension vertically. The portrait 
>> option returns the page orientation to the MATLAB default. (Note that the 
>> result of using the portrait option is affected by changes you make to 
>> figure properties. See the "Algorithm" section for more specific 
>> information.)
>> 
>> orient tall maps the current figure to the entire page in portrait 
>> orientation, leaving a 0.25 inch border.
>> --------------------
>> 
>>      
>> http://www.mathworks.com/help/techdoc/ref/figure_props.html#PaperPosition
>> 
>> --------------------
>> four-element rect vector
>> 
>> Location on printed page. A rectangle that determines the location of the 
>> figure on the printed page. Specify this rectangle with a vector of the form:
>> 
>>      rect = [left, bottom, width, height]
>> 
>> where left specifies the distance from the left side of the paper to the 
>> left side of the rectangle and bottom specifies the distance from the bottom 
>> of the page to the bottom of the rectangle. Together these distances define 
>> the lower-left corner of the rectangle. width and height define the 
>> dimensions of the rectangle. ThePaperUnits property specifies the units used 
>> to define this rectangle.
>> --------------------
>> 
>>      
>> http://www.mathworks.com/support/solutions/en/data/1-16WME/?solution=1-16WME
>> 
>> --------------------
>> The JPEG, PNG, and TIFF drivers in MATLAB 5.x and later rely upon a figure's 
>> "PaperPosition" to specify the size of the output file.
>> --------------------
>> 
>> The description of paperorientation on the Mathworks website implies that 
>> papersize(1) < papersize(2). The Matlab implementation does not force this, 
>> and I've found Matlab to behave unexpectedly when papersize(1) > 
>> papersize(2). Octave does force papersize(1) < papersize(2) when the 
>> orientation is portrait. 
>> 
>> Octave currently modifies the papersize and paperposition properties when 
>> paperorientation changes. This is done to ensure that papersize(1) < 
>> papersize(2). This behavior deviates from Matlab, but I think Octave's 
>> behavior is preferable.
>> 
>> Ben
> 
> I've prepared a changeset for improving the documentation for how the print() 
> function is intended to work.
> 
> Ben
> 
> <changeset.patch>

Rik / others,

I pushed a change that describes Octave's current implementation of print().

        http://hg.savannah.gnu.org/hgweb/octave/rev/05635e4c605a

Ben