[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Outerposition Patch
From: |
Ben Abbott |
Subject: |
Re: Outerposition Patch |
Date: |
Tue, 22 Feb 2011 21:28:08 -0500 |
On Feb 21, 2011, at 10:03 PM, Ben Abbott wrote:
> On Feb 19, 2011, at 9:42 AM, Ben Abbott wrote:
>
>> On Feb 19, 2011, at 2:21 AM, logari81 wrote:
>>
>>> On Fri, 2011-02-18 at 19:06 -0500, Ben Abbott wrote:
>>>
>>>> On Feb 18, 2011, at 6:35 PM, logari81 wrote:
>>>>
>>>>> On Fri, 2011-02-18 at 22:40 +0100, Konstantinos Poulios wrote:
>>>>>
>>>>>> On Fri, Feb 18, 2011 at 6:07 PM, bpabbott <address@hidden> wrote:
>>>>>>
>>>>>>> On Feb 18, 2011, at 12:02 PM, bpabbott <address@hidden> wrote:
>>>>>>>
>>>>>>> On Feb 18, 2011, at 11:04 AM, Konstantinos Poulios <address@hidden>
>>>>>>> wrote:
>>>>>>>
>>>>>>> On Fri, Feb 18, 2011 at 2:36 PM, Ben Abbott <address@hidden> wrote:
>>>>>>>> On Feb 18, 2011, at 2:37 AM, logari81 wrote:
>>>>>>>>
>>>>>>>>> On Thu, 2011-02-17 at 21:09 -0500, Ben Abbott wrote:
>>>>>>>>>
>>>>>>>>>> On Feb 17, 2011, at 4:32 PM, logari81 wrote:
>>>>>>>>>>
>>>>>>>>>>> On Wed, 2011-02-16 at 19:37 -0500, Ben Abbott wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On Feb 13, 2011, at 12:05 PM, logari81 wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, 2011-02-10 at 20:00 +0100, Konstantinos Poulios wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Thu, Feb 10, 2011 at 1:59 PM, Konstantinos Poulios wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Thu, Feb 10, 2011 at 9:25 AM, David Bateman <address@hidden>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Le 10 févr. 2011 à 00:25, logari81 <address@hidden> a
>>>>>>>>>>>>>>>> écrit :
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> thank you for this information.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It seems that the previously attached patch causes problems
>>>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>> legends. However, in order to treat legends correctly I need
>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> understand their logic. How do legends exploit the
>>>>>>>>>>>>>>>>> outerposition
>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>> position properties? Is anyone familiar with legend.m to give
>>>>>>>>>>>>>>>>> me
>>>>>>>>>>>>>>>>> a short
>>>>>>>>>>>>>>>>> introduction?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Best regards
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You shouldn't try to understand the logic of legend's use of
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> position and outerposition properties. It's just a hack that
>>>>>>>>>>>>>>>> worked with the
>>>>>>>>>>>>>>>> existing behavior. If your patch doesn't work well with legend
>>>>>>>>>>>>>>>> it is
>>>>>>>>>>>>>>>> probably legend that needs to be fixed
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> D.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The attached patch replaces the previous one and implements the
>>>>>>>>>>>>>>> calculation of both position and outerposition depending on the
>>>>>>>>>>>>>>> value
>>>>>>>>>>>>>>> of activepositionproperty.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It is not very well tested yet, so there will probably be some
>>>>>>>>>>>>>>> issues,
>>>>>>>>>>>>>>> e.g. legends will not work, but it brings a feature that maybe
>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>> awesome. It is something that Matlab cannot do and maybe you
>>>>>>>>>>>>>>> like
>>>>>>>>>>>>>>> it.
>>>>>>>>>>>>>>> See the following video:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://ubuntuone.com/p/cYM/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The position property is calculated dynamically while you rotate
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> view, so that all labels fit in outerposition. I think it works
>>>>>>>>>>>>>>> quite
>>>>>>>>>>>>>>> well in order to keep it. What do you think?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> As this operation involves certain computational overhead, it
>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>> interesting to get some tests on older machines. Unfortunately
>>>>>>>>>>>>>>> all
>>>>>>>>>>>>>>> pc's that I have access to, are too fast.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This patch also fixes http://savannah.gnu.org/bugs/?31610 for
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> fltk toolkit.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Finally, if we adopt the attached patch we have to adapt
>>>>>>>>>>>>>>> legend.m
>>>>>>>>>>>>>>> also.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> BR
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Kostas
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> After some more testing and fixes I think the patch is quite
>>>>>>>>>>>>>> mature
>>>>>>>>>>>>>> in
>>>>>>>>>>>>>> the form you find in the attachment. I think it could be checked
>>>>>>>>>>>>>> in.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have just checked in this changeset along with some further
>>>>>>>>>>>>> fixes/improvements. Now, I would like to provide some additional
>>>>>>>>>>>>> information and ask for some help with regard to the open issues
>>>>>>>>>>>>> that
>>>>>>>>>>>>> I
>>>>>>>>>>>>> had listed.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> There are still some general issues with fltk that I will try to
>>>>>>>>>>>>>> sum
>>>>>>>>>>>>>> up:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1. In some demo plots axes labels seem to be too close to the
>>>>>>>>>>>>>> axes
>>>>>>>>>>>>>> (e.g. demo legend 9). Probably in some of the previous changes
>>>>>>>>>>>>>> there
>>>>>>>>>>>>>> is something that I have overseen.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Actually after testing older revisions of octave I realized that
>>>>>>>>>>>>> the
>>>>>>>>>>>>> problem is not new. The reason that I hadn't noticed it before is
>>>>>>>>>>>>> because the problem appears only in the print output and not in
>>>>>>>>>>>>> the
>>>>>>>>>>>>> plot
>>>>>>>>>>>>> window. It seems that gl-render and gl2ps position strings
>>>>>>>>>>>>> differently
>>>>>>>>>>>>> considering either the bottom line or the baseline of the string
>>>>>>>>>>>>> respectively. It is not difficult to fix, we just have to decide
>>>>>>>>>>>>> which
>>>>>>>>>>>>> of gl-render and gl2ps are we going to fix in order to make both
>>>>>>>>>>>>> consistent.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2. Legends for barplots don't show colors (this is an old
>>>>>>>>>>>>>> problem).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 3. Some small y axes interference for plotyy (also not new).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 4. Now there is no labels-titles interference in demo subplot 1,
>>>>>>>>>>>>>> so
>>>>>>>>>>>>>> there is no need for extra space between the subplots, we can
>>>>>>>>>>>>>> reduce
>>>>>>>>>>>>>> a
>>>>>>>>>>>>>> bit the padding (someone which is familiar with subplot.m I
>>>>>>>>>>>>>> suppose).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Waiting for someone familiar with subplot.m
>>>>>>>>>>>>
>>>>>>>>>>>> I"ve just pushed a changeset that improves the layout of the
>>>>>>>>>>>> subplots.
>>>>>>>>>>>>
>>>>>>>>>>>> http://hg.savannah.gnu.org/hgweb/octave/rev/7b67bbf9dbbb
>>>>>>>>>>>>
>>>>>>>>>>>> I'm also attaching a test script that runs under Octave and Matlab.
>>>>>>>>>>>> Results for both are attached.
>>>>>>>>>>>
>>>>>>>>>>> This script is cool, I was thinking of doing something like that
>>>>>>>>>>> but I
>>>>>>>>>>> didn't realize that it can be done so easily.
>>>>>>>>>>>
>>>>>>>>>>>> The test script places dashed blue lines around the position of
>>>>>>>>>>>> each
>>>>>>>>>>>> axis, and dashed red around the outerposition.
>>>>>>>>>>>
>>>>>>>>>>> You mean blue lines around the original axes position before adding
>>>>>>>>>>> labels and titles. The version of the script that I have attached in
>>>>>>>>>>> this email visualizes the updated positions which correctly coincide
>>>>>>>>>>> with the axes.
>>>>>>>>>>
>>>>>>>>>> Ok. I see your point. I'll have to do some experimenting with the
>>>>>>>>>> corrected version.
>>>>>>>>>>
>>>>>>>>>>>> When subplot (3,3,1:3) is used to replace the first row of
>>>>>>>>>>>> subplots, a
>>>>>>>>>>>> green dashed box is used to encompass the new position, and a
>>>>>>>>>>>> dashed magenta
>>>>>>>>>>>> for the outerposition.
>>>>>>>>>>>>
>>>>>>>>>>>> The problems I see are ...
>>>>>>>>>>>>
>>>>>>>>>>>> 1) The activeposition property is still "outerposition".
>>>>>>>>>>>
>>>>>>>>>>> why is this a problem? Maybe we prefer this, maybe not, see my
>>>>>>>>>>> comment
>>>>>>>>>>> on (2). ML sets it to "position" but we do not have necessarily to
>>>>>>>>>>> do
>>>>>>>>>>> the same.
>>>>>>>>>>
>>>>>>>>>> We may decide to deviate from compatibility with Matlab, but before
>>>>>>>>>> doing so we should discuss it on the list. The list has already
>>>>>>>>>> discussed
>>>>>>>>>> and agreed to Matlab compatibility (before my time here), it would be
>>>>>>>>>> improper to deviate from that agreed upon approach without
>>>>>>>>>> discussion first.
>>>>>>>>>>
>>>>>>>>>> Can we abide by Matlab's example for now and discuss changes later.
>>>>>>>>>> If
>>>>>>>>>> nothing else, that would make it easier (for me) to review the state
>>>>>>>>>> of
>>>>>>>>>> graphics for Octave (via dump_demos and such).
>>>>>>>>>>
>>>>>>>>>>>> 2) The width of subplot (3,3,1:3) has been improperly modified on
>>>>>>>>>>>> the
>>>>>>>>>>>> c++ side.
>>>>>>>>>>>
>>>>>>>>>>> Actually this is not really "improperly". It is doing what it was
>>>>>>>>>>> expected to do. What we programmed in c++ is a minimum left margin
>>>>>>>>>>> of
>>>>>>>>>>> 13% of outerposition(3). For the upper subplot the total width is 3
>>>>>>>>>>> times the width of the other subplots so the minimum left margin is
>>>>>>>>>>> also
>>>>>>>>>>> 3 times higher. It is ugly.
>>>>>>>>>>> This would be a reason for switching to
>>>>>>>>>>> activepositionproperty=position.
>>>>>>>>>>> This way, we wouldn't let sync_position do its job but we would do
>>>>>>>>>>> it
>>>>>>>>>>> manually in the frontend. Now we are able to, before we couldn't
>>>>>>>>>>> because
>>>>>>>>>>> we couldn't get any tightinset values.
>>>>>>>>>>
>>>>>>>>>> If consistent with Matlab, the subplot(3,3,1:3) would produce an axes
>>>>>>>>>> with a position property that encompasses the original 3 axes (Matlab
>>>>>>>>>> documents this, but I've noticed some minor "bugs" on their part).
>>>>>>>>>>
>>>>>>>>>> For now, can the position/outerposition synchronization be
>>>>>>>>>> implemented
>>>>>>>>>> in the manner that is consistent with Matlab's documentation?
>>>>>>>>>>
>>>>>>>>>> Meaning that when outerposition is active …
>>>>>>>>>>
>>>>>>>>>> I) position(1) is adjusted to the right (never to the left), to
>>>>>>>>>> ensure
>>>>>>>>>> no object extends to the left of outerposition(1).
>>>>>>>>>>
>>>>>>>>> Right now, no objects should extend left of outerposition(1). If there
>>>>>>>>> is a test case not respecting this rule, please let me know (only
>>>>>>>>> exception is if you make the plot window tiny).
>>>>>>>>
>>>>>>>> I don't see any cases of that. What I do see is that you're requiring a
>>>>>>>> minimum of space between the outerposition and position boxes. So
>>>>>>>> you're
>>>>>>>> adding features, correct?
>>>>>>>>
>>>>>>>>>> II) position(2) is adjusted upward (never downward), to ensure no
>>>>>>>>>> object
>>>>>>>>>> extends below the outerposition(2)
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> likewise
>>>>>>>>
>>>>>>>> Your approach is not consistent with the "never downward" part,
>>>>>>>> Correct?
>>>>>>>>
>>>>>>>>>> III) position(3) is decreased (never increased) to ensure no object
>>>>>>>>>> extends beyond the outerposition(1)+outerposition(3).
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> likewise
>>>>>>>>
>>>>>>>> Same.
>>>>>>>>
>>>>>>>>>> IV) position(4) is decreased (never increased) to ensure no object
>>>>>>>>>> extends beyond the outerposition(2)+outerposition(4).
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> likewise
>>>>>>>>
>>>>>>>> Same again.
>>>>>>>>
>>>>>>>>>> When the position property is active the relationship is reversed.
>>>>>>>>>> Its
>>>>>>>>>> been a couple of years since I looked that this in detail. Is my
>>>>>>>>>> understanding of how Matlab works consistent with yours?
>>>>>>>>>>
>>>>>>>>>>>> 3) The positions have been shifted to the left relative to what was
>>>>>>>>>>>> specified by subplot.m. Originally, their left edges were very
>>>>>>>>>>>> close to the
>>>>>>>>>>>> left edge of the outerpositon.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> What do you mean by "left edges" I don't get this point.
>>>>>>>>>>
>>>>>>>>>> Opps ... not "left", but "right"!
>>>>>>>>>>
>>>>>>>>>> My observation was that the right edge of the "position" has been
>>>>>>>>>> shifted to the left even though no object impinged upon the right
>>>>>>>>>> edge of
>>>>>>>>>> the outerposition.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This is 9.5%. The problem is that we consider these minimum margins
>>>>>>>>> 13%
>>>>>>>>> to the left, 9.5% to the right, 11% to the bottom, 7.5 %to the top.
>>>>>>>>> This
>>>>>>>>> is compatible with ML for normal plots, but for subplots ML reduces
>>>>>>>>> this
>>>>>>>>> limits. Actually subplot in ML is quite a hack. We have different
>>>>>>>>> possibilities of achieving the same behavior. I make a proposal at the
>>>>>>>>> end.
>>>>>>>>
>>>>>>>> Actually Matlab does not have "minimum margins". Those margins are set
>>>>>>>> by
>>>>>>>> the "defaultaxisposition" and "defaultaxisouterposition" properties
>>>>>>>> (present
>>>>>>>> in the root, figure and axes objects). Thus, they are controlled on by
>>>>>>>> m-file side by the user. So I think the current synchronization isn't
>>>>>>>> compatible with Matlab, even for normal plots.
>>>>>>>>
>>>>>>>>>>>> 4) The xticklabels and yticklabels should be tigher to the axes.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> This is adjustable I think. Maybe it makes sense to calculate the
>>>>>>>>>>> distance of ticklabels from axes as percentage of axes sizes.
>>>>>>>>>>
>>>>>>>>>> This isn't a documented by MathWorks. However, I did some
>>>>>>>>>> experimenting
>>>>>>>>>> and found that ...
>>>>>>>>>>
>>>>>>>>>> a) xlabel baseline is (2*fontsize + 7) points below the axis position
>>>>>>>>>>
>>>>>>>>>> b) x-axis ticklabels are (fontsize + 1.5) points below the axis
>>>>>>>>>> position
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> the bigger the font, the higher the distance from the axis
>>>>>>>>
>>>>>>>> Yes.
>>>>>>>>
>>>>>>>>>> c) the right extent of the y-axis ticklabels is (20/fontsize + 1)
>>>>>>>>>> points to the left of the axis position.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> so, the bigger the font, the closer to the axis? Interesting.
>>>>>>>>
>>>>>>>> Keep in mind that the extent property is designed for type-settting, so
>>>>>>>> there is some white space included. Thus, the visual result does not
>>>>>>>> give
>>>>>>>> the impression the characters are closer to the axis box. Matlab and
>>>>>>>> Octave's extents aren't yet consistent, so there is good reason not to
>>>>>>>> blindly copy this feature. However, I do think the spacing should rely
>>>>>>>> upon
>>>>>>>> the font and not the axis.
>>>>>>>>
>>>>>>>>> Do you believe these 3 approximations a,b and c are fixed or they
>>>>>>>>> could
>>>>>>>>> change proportionally to the axes width/height.
>>>>>>>>
>>>>>>>> No they do not. This is easily seen my resized the figure with the
>>>>>>>> mouse.
>>>>>>>>
>>>>>>>>>> As this isn't documented by MathWorks, they could change it. So
>>>>>>>>>> there is
>>>>>>>>>> no compelling reason to copy the specifics.
>>>>>>>>>>
>>>>>>>>>> However, if there are multiple axes in the same figure, I think the
>>>>>>>>>> spacing between axes, ticklabels, and labels should be consistent
>>>>>>>>>> (assuming
>>>>>>>>>> the fontsize is consistent). Does that make sense? Other thoughts /
>>>>>>>>>> concerns?
>>>>>>>>>>
>>>>>>>>>> Ben
>>>>>>>>>
>>>>>>>>> SUGGESTION:
>>>>>>>>>
>>>>>>>>> 1st step: Add a new property (hidden?) to the axes object:
>>>>>>>>> minmargins = [l b rt]
>>>>>>>>> with default value derived from defaultaxesposition:
>>>>>>>>> l=defaultaxesposition(0)
>>>>>>>>> b=defaultaxesposition(1)
>>>>>>>>> r=1-defaultaxesposition(0)-defaultaxesposition(2)
>>>>>>>>> t=1-defaultaxesposition(1)-defaultaxesposition(3)
>>>>>>>>
>>>>>>>> I rather not see this done. The margins are currently defined by the
>>>>>>>> user
>>>>>>>> on the m-file side by changing the position/outerposition of the axes.
>>>>>>>> This
>>>>>>>> just looks more complicated to me with no added capability.
>>>>>>>>
>>>>>>>>> 2nd step: Modify sync_positions so that it takes into account
>>>>>>>>> minmargins
>>>>>>>>> instead of defaultaxesposition. This would mean no change for all
>>>>>>>>> other
>>>>>>>>> plots, but for subplots it gives as the possibility to reduce the
>>>>>>>>> minimum margins from the frontend (e.g. reduce the ugly 9.5% to the
>>>>>>>>> right).
>>>>>>>>
>>>>>>>> I'd prefer that the synchronization limit itself to the compatible
>>>>>>>> behavior. For activepositionproperty = "outerposition"
>>>>>>>>
>>>>>>>> I) position(1) is adjusted to the right (never to the left), to ensure
>>>>>>>> no
>>>>>>>> object extends to the left of outerposition(1).
>>>>>>>>
>>>>>>>> II) position(2) is adjusted upward (never downward), to ensure no
>>>>>>>> object
>>>>>>>> extends below the outerposition(2).
>>>>>>>>
>>>>>>>> III) position(3) is decreased (never increased) to ensure no object
>>>>>>>> extends beyond the outerposition(1)+outerposition(3).
>>>>>>>>
>>>>>>>> IV) position(4) is decreased (never increased) to ensure no object
>>>>>>>> extends
>>>>>>>> beyond the outerposition(2)+outerposition(4).
>>>>>>>>
>>>>>>>> In short the position property never expands, but retracts to keep
>>>>>>>> itself
>>>>>>>> and its children inside the outerposition.
>>>>>>>>
>>>>>>>> Conversely, when the activepositionproperty == "position", the
>>>>>>>> outerposition never contracts, but expands so as to encompass the axis
>>>>>>>> and
>>>>>>>> its children.
>>>>>>>>
>>>>>>>> One of the difficulties I'm having with subplot is that the
>>>>>>>> synchonization
>>>>>>>> second guesses the specified position. In addition, the current
>>>>>>>> solution
>>>>>>>> will be difficult to document.
>>>>>>>>
>>>>>>>>> 3rd step: Optimize subplot.m making use of the new property minmargins
>>>>>>>>>
>>>>>>>>> Only by setting minmargins to zero would eliminate most problems that
>>>>>>>>> we
>>>>>>>>> observe now with subplot. More sophisticated use of minmargins would
>>>>>>>>> even allow us to synchronize the insets in rows and columns of the
>>>>>>>>> subplot grid (AFAIK is what ML does, can you confirm this?).
>>>>>>>>>
>>>>>>>>> What do you think? Should I add the a property minmargins or something
>>>>>>>>> similar?
>>>>>>>>
>>>>>>>>
>>>>>>>> Ok, Please propose a changeset with the default for minmargins set to
>>>>>>>> zero so that we'll have a compatible solution.
>>>>>>>>
>>>>>>>> Ben
>>>>>>>>
>>>>>>>
>>>>>>> Hmm, I have a suggestion. Since I thought that the implementation of
>>>>>>> sync_position for single plots (not subplots) is compatible with ML,
>>>>>>> and you are saying that it isn't, this should be the first issue to
>>>>>>> fix. Could you provide me with an example of a single plot that
>>>>>>> demonstrates the difference between ML and Octave?
>>>>>>>
>>>>>>> As soon as I fix this we can come back to subplot again and continue
>>>>>>> our discussion.
>>>>>>>
>>>>>>> BR
>>>>>>>
>>>>>>> Kostas
>>>>>>>
>>>>>>> First example is for activeposition == "position"
>>>>>>> figure (1)
>>>>>>> clf
>>>>>>> set (gca, 'position', [0 0 1 1], 'activepositionproperty',
>>>>>>> 'outerposition')
>>>>>>> plot (0:1,0:1)
>>>>>>> axis ([0 1 0 1])
>>>>>>> outerposition = get (gca, 'outerposition')
>>>>>>> I've attached the result from Matlab. The outerposition from Matlab is
>>>>>>> outerposition = -0.1677 -0.1350 1.2903 1.2270
>>>>>>> Octave's result does not grow the outerposition.
>>>>>>> outerposition = 0 0 1 1
>>>>>>
>>>>>> ouuuuups!!! I introduced this bug in 98772e4e8a2a. It used to work
>>>>>> correctly before. I have just pushed the fix, so it should be ok
>>>>>> again.
>>>>>>
>>>>>>> If this example so that activeposition == "outerposition" ...
>>>>>>> figure (1)
>>>>>>> clf
>>>>>>> set (gca, 'position', [0 0 1 1], 'activepositionproperty',
>>>>>>> 'outerposition')
>>>>>>> set (gca, 'outerposition', [0 0 1 1])
>>>>>>> plot (0:1,0:1)
>>>>>>> axis ([0 1 0 1])
>>>>>>> … then I see that the default axis position is restored. This does
>>>>>>> behave in
>>>>>>> the manner you're suggesting, but it is not described by the
>>>>>>> documentation.
>>>>>>> http://www.mathworks.com/help/techdoc/creating_plots/f1-32495.html
>>>>>>> This behavior is new to me (wasn't there when I examined this a few
>>>>>>> years
>>>>>>> back). So it appears I owe you an apology for the back-n-forth.
>>>>>>> I did a quick google, and found that someone else named "Ben" had
>>>>>>> figured
>>>>>>> out what is happening.
>>>>>>> http://undocumentedmatlab.com/blog/tag/outerposition/
>>>>>>> Rather than minmargins, may I suggest you use "looseinset" as Matlab
>>>>>>> does?
>>>>>>> For the subplots, the looseinset may be set to some reasonable value by
>>>>>>> the
>>>>>>> subplot.m function.
>>>>>>> Ben
>>>>>>>
>>>>>>>
>>>>>>> Same article, but this time a direct link
>>>>>>> http://undocumentedmatlab.com/blog/axes-looseinset-property/
>>>>>>> Ben
>>>>>>
>>>>>> I am working on looseinset now. It shouldn't take long to implement.
>>>>>>
>>>>>> BR
>>>>>>
>>>>>> Kostas
>>>>>
>>>>> Hi Ben,
>>>>>
>>>>> in the attached changeset you can find a first implementation of
>>>>> looseinset. The sync_position function relies now on looseinset instead
>>>>> of default_axes_position.
>>>>>
>>>>> Known limitations: looseinset remains always in normalized units (since
>>>>> it is a hidden property I see no need to support other kinds of units)
>>>>>
>>>>> Please test this patch and send me any comments.
>>>>>
>>>>> BR
>>>>>
>>>>> Kostas
>>>>> <looseinset-1a.changeset>
>>>>
>>>> For consistency, how difficult is it to implement the units conversion?
>>>> ... or maybe a more proper question is; Is there a reason that units
>>>> conversion is prohibitive?
>>>
>>> the units conversion itself is not a problem, but how different units
>>> for looseinset will be interpreted in sync_positions is not very
>>> straightforward. My main concern however is that by adding further
>>> checks and conversions to sync_positions it becomes heavier and heavier.
>>> Since looseinset is not supposed to be accessed by users maybe it makes
>>> sense to support only normalized units. This should be sufficient for
>>> achieving a decent subplot behavior. What do you think?
>>
>> I'd thought the axes properties were always stored normalized, and that
>> conversion only occurred when the user did a set/get from the m-file side.
>> Meaning that accessing the axes properties on the c++ side would return
>> values in the default units, and that units conversion had to be done
>> explicitly.
>>
>> How does the conversion work on the c++ side? Can you not directly access
>> the properties without triggering a conversion? ... if conversion always
>> happens, then why isn't setting units="normalized" sufficient to fix the
>> conversion in all cases (i.e. position, outerposition, tightinset,
>> looseinset)? In either event, if units=="normalized" no conversion needs to
>> be done, so I'm confused as why this is a problem. Am I making sense?
>>
>> Ben
>
> I studied the code over the last few days. I now understand why leaving
> looseinset in normalized units is preferred.
>
> I think understand your point regarding the subplot behavior is correct as
> well. For subplot the units won't matter since the looseinset would be set to
> [0 0 0 0], is correct?
>
> Please push the change. When that is done, I'll push a change for subplots
> and run dump_demo to produce an updated page.
>
> Ben
I've pushed a change for subplot and run dump_demos
http://homepage.mac.com/bpabbott/12439/compare_plots.html
I didn't look closely at the results. I did notice a problem with the 20th
legend demo.
Ben
- Re: Outerposition Patch, (continued)
- Re: Outerposition Patch, Ben Abbott, 2011/02/18
- Re: Outerposition Patch, Konstantinos Poulios, 2011/02/18
- Re: Outerposition Patch, bpabbott, 2011/02/18
- Re: Outerposition Patch, bpabbott, 2011/02/18
- Re: Outerposition Patch, Konstantinos Poulios, 2011/02/18
- Re: Outerposition Patch, logari81, 2011/02/18
- Re: Outerposition Patch, Ben Abbott, 2011/02/18
- Re: Outerposition Patch, logari81, 2011/02/19
- Re: Outerposition Patch, Ben Abbott, 2011/02/19
- Re: Outerposition Patch, Ben Abbott, 2011/02/21
- Re: Outerposition Patch,
Ben Abbott <=
- Re: Outerposition Patch, logari81, 2011/02/23
- Re: Outerposition Patch, Ben Abbott, 2011/02/23
- Re: Outerposition Patch, Ben Abbott, 2011/02/23
- Re: Outerposition Patch, logari81, 2011/02/23