Re: Outerposition Patch

[Ben Abbott]

On Feb 23, 2011, at 1:56 AM, logari81 wrote:

> On Tue, 2011-02-22 at 21:28 -0500, Ben Abbott wrote:
> 
>> 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
> 
> Hi Ben, are you sure this is the correct comparison link? 12439? For
> example I see the blue axis error in plotyy that should be already
> fixed.
> 
> Kostas

I may have had some old png's there. I've started fresh. Some of the png's 
cause a crash. Those should show up empty. I have a slow upload speed today. I 
doubt the upload will be done before midnight my time (5 hrs from now).

Ben