[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Outerposition Patch
From: |
Ben Abbott |
Subject: |
Re: Outerposition Patch |
Date: |
Wed, 23 Feb 2011 19:03:16 -0500 |
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
- Re: Outerposition Patch, (continued)
- 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, 2011/02/23
- Re: Outerposition Patch, Ben Abbott, 2011/02/23
- Re: Outerposition Patch,
Ben Abbott <=
- Re: Outerposition Patch, logari81, 2011/02/23