[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Outerposition Patch
From: |
logari81 |
Subject: |
Re: Outerposition Patch |
Date: |
Wed, 23 Feb 2011 07:56:12 +0100 |
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
- Re: Outerposition Patch, (continued)
- 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, 2011/02/22
- Re: Outerposition Patch,
logari81 <=
- Re: Outerposition Patch, Ben Abbott, 2011/02/23
- Re: Outerposition Patch, Ben Abbott, 2011/02/23
- Re: Outerposition Patch, logari81, 2011/02/23