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