[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Changeset 14257 oddities
From: |
Ben Abbott |
Subject: |
Re: Changeset 14257 oddities |
Date: |
Sun, 11 Mar 2012 20:57:34 -0400 |
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
- Re: Changeset 14257 oddities, Ben Abbott, 2012/03/10
- Re: Changeset 14257 oddities, Ben Abbott, 2012/03/10
- Re: Changeset 14257 oddities, Rik, 2012/03/10
- Re: Changeset 14257 oddities, Ben Abbott, 2012/03/10
- Re: Changeset 14257 oddities, Ben Abbott, 2012/03/10
- Re: Changeset 14257 oddities, Ben Abbott, 2012/03/10
- Re: Changeset 14257 oddities,
Ben Abbott <=
- Updaters and default property values (was :Changeset 14257 oddities), Ben Abbott, 2012/03/11
- Re: Updaters and default property values (was :Changeset 14257 oddities), Michael Goffioul, 2012/03/12
- Re: Updaters and default property values (was :Changeset 14257 oddities), Ben Abbott, 2012/03/12
- Re: Updaters and default property values (was :Changeset 14257 oddities), Michael Goffioul, 2012/03/12
- Re: Updaters and default property values (was :Changeset 14257 oddities), Ben Abbott, 2012/03/12
- Re: Updaters and default property values (was :Changeset 14257 oddities), Michael Goffioul, 2012/03/12
- Re: Updaters and default property values, Rik, 2012/03/12
- Re: Updaters and default property values, Ben Abbott, 2012/03/12
- Re: Updaters and default property values, Rik, 2012/03/12
- Re: Updaters and default property values, Ben Abbott, 2012/03/12