Re: Outerposition Patch

[logari81]

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
Description: Text document