Re: Outerposition Patch

[logari81]

On Wed, 2011-02-23 at 19:03 -0500, Ben Abbott wrote:
> On Feb 23, 2011, at 7:01 PM, Ben Abbott wrote:
> 
> > 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
> 
> The upload is picking up speed. It should be done in less than an hour (still 
> pokey slow though).
> 
> Ben

in my time zone it is midnight already, so I will check the plots
tomorrow :)

Kostas