Re: AspectRatio Patches [changeset]

[logari81]

On Thu, 2010-10-28 at 14:20 +0800, Ben Abbott wrote:
> On Oct 28, 2010, at 1:54 PM, Ben Abbott wrote:
> 
> > On Oct 28, 2010, at 11:57 AM, Ben Abbott wrote:
> > 
> >> On Oct 28, 2010, at 5:25 AM, logari81 wrote:
> >> 
> >>> On Wed, 2010-10-27 at 23:11 +0800, Ben Abbott wrote:
> >>>> On Oct 27, 2010, at 10:38 PM, logari81 wrote:
> >>>> 
> >>>>> Hi all,
> >>>>> 
> >>>>> in continuation to:
> >>>>> https://www-old.cae.wisc.edu/pipermail/octave-maintainers/2010-January/014960.html
> >>>>> 
> >>>>> now that the native graphics seem to have reached a pretty mature state,
> >>>>> I think is the right moment to fix the daspect,pbaspect, axis square,
> >>>>> axis equal issue, once for ever.
> >>>>> 
> >>>>> First of all we have to be sure that we all have the same understanding
> >>>>> of what Matlab does. So please consider the following:
> >>>>> 
> >>>>> http://www.mathworks.com/help/techdoc/ref/daspect.html
> >>>>> http://www.mathworks.com/help/techdoc/ref/axes_props.html
> >>>>> http://www.mathworks.com/help/techdoc/visualize/f4-24991.html
> >>>>> http://www.mathworks.com/help/techdoc/visualize/f4-48363.html
> >>>>> 
> >>>>> especially the table in the "DataAspectRatio" section of the second
> >>>>> link.
> >>>>> 
> >>>>> I have invested some time in making octave (at least the fltk backend)
> >>>>> behave similarly to Matlab. In the attached patch-files
> >>>>> "octave_aspectratios_1.patch" and "octave_aspectratios_2.patch" you can
> >>>>> find an implementation of the relation between dataaspectratio,
> >>>>> plotboxaspectratio, xlim, ylim and zlim as it is described in the Matlab
> >>>>> documentation.
> >>>>> 
> >>>>> The file "octave_genprops_comments.patch" includes a minor comment
> >>>>> improvement.
> >>>>> 
> >>>>> An overview with test cases comparing octave before and after my
> >>>>> modifications with Matlab can be found here:
> >>>>> http://files.ubuntu-gr.org/forum/logari81/Bugs/comparison_aspectratios.pdf
> >>>>> 
> >>>>> The patches attached in this mail also replace the patch that I provided
> >>>>> some days before as a fix for bug #30343:
> >>>>> https://savannah.gnu.org/bugs/?30343 
> >>>>> 
> >>>>> TODO:
> >>>>> 
> >>>>> 1. After the adoption of the attached patches the "axis equal" command
> >>>>> could be converted to be based on daspect instead of pbaspect, so that
> >>>>> it is compatible with Matlab.
> >>>>> 
> >>>>> 2. The test case on page 5 of the above given pdf shows a problem with
> >>>>> the modified version and the gnuplot backend. This should be fixed. In
> >>>>> all other cases the modified version works better even for the gnuplot
> >>>>> backend.
> >>>>> 
> >>>>> Please let me know what do you think about my proposals.
> >>>>> 
> >>>>> Best regards,
> >>>>> 
> >>>>> Kostas
> >>>> 
> >>>> I'll try to look at the effect of the patches tomorrow.
> >>>> 
> >>>> For now, without your patches, when I try ...
> >>>> 
> >>>> backend gnuplot
> >>>> close all
> >>>> plot (1:10)
> >>>> set (gca, "activepositionproperty", "position")
> >>>> pbaspect ([1, 3, 1])
> >>>> print -dpdfwrite gp-pbaspect.pdf
> >>>> 
> >>>> ... I get the attached pdf. Why does your "original" and "modified" 
> >>>> gnuplot results give such a different result? My tip is 11159. which I 
> >>>> assume should be the same as your "original". Do you get this result as 
> >>>> well.
> >>>> 
> >>>> Ben
> >>>> 
> >>>> p.s. When the "activepositionproperty" is set to "outerposition", Octave 
> >>>> is unable to exactly detemine the size of the plot box, so when pbaspect 
> >>>> is set, the result will deviate from what is desired. To fix the 
> >>>> pbaspect correctly, the "activepositionproperty" needs to be set to 
> >>>> "position".
> >>>> 
> >>> 
> >>> Actually my changes are not related to the "activepositionproperty". If
> >>> you refer to the very small plotbox in some of my screenshots, this is
> >>> probably some other bug observed both in the original and the modified
> >>> version. It has nothing to do with my modifications. Changing
> >>> "activepositionproperty" doesn't improve the problem.
> >> 
> >> My mentioned of the activepositionproperty was just to explant that when 
> >> it is set to outerposition the plotboxaspectratio be rendered improperly. 
> >> This *feature* is due to lacking a method to determine the textextents for 
> >> the text objects (including the ticklabels).
> >> 
> >>> I can confirm that my "original" version is 11159 as well, and running
> >>> your test gives me the same result as in your gp-pbaspect.pdf .
> >>> 
> >>> What my patch is simply about, is adding daspect support. Currently in
> >>> octave there is no real daspect support. Up to now octave just mimicked
> >>> daspect behavior through pbaspect.
> >> 
> >> I'm partly responsible for the current behavior. When the axis limits 
> >> (xlim or ylim), dataaspectratio, and plotboxaspectratio are all set, one 
> >> of the three must yield to the others. I tried to mimic the behavior of 
> >> Matlab, but it doesn't surprise me that I missed something.
> >> 
> >>> My changes where done with the fltk backend in mind. The setting of
> >>> aspect ratios with this backend seems error free and absolutely
> >>> consistent with Matlab. Concerning gnuplot, I consider its aspectratio
> >>> behavior anyway broken, so I just tried to confirm a posteriori that I
> >>> didn't make it worse. The only regression I found is shown on page 5. I
> >>> will investigate it. In other cases my changes improved the behavior of
> >>> the the gnuplot backend as well (e.g. pages 6, 7 and 8).
> >> 
> >> 
> >> I'm having a bit of trouble following your graphical examples. For 
> >> example, the pdf's you attached show a very small plot box for gnuplot, 
> >> This seems to be in conflict with your confirmation that you get the same 
> >> result as I for the example I gave.
> >> 
> >> Perhaps we can use a standard script. Is the attached one ok? I've 
> >> attached the resulting pdf as well. From this script is the problem with 
> >> how the gnuplot backend handles aspect ratios present? If not, can you 
> >> provide a simple example that can be added to the demos?
> >> 
> >> I have another problem to look at before this one. I'll try applying the 
> >> patches later.
> >> 
> >> Ben
> >> 
> >> <test_aspect.m><aspect_demos.pdf>
> > 
> > I'd forgotten that FLTK-aqua on MacOS X has a problem with initialization. 
> > Please ignore the prior FLTK plots.
> > 
> > To detect conflicts between the data and plot box aspect ratios, I've added 
> > tests to daspect.m and pbaspect.m which set both aspect ratios (the 
> > changeset for that has been pushed).
> > 
> > I've also applied your patches, modified my test script to work around the 
> > FLTK-aqua problem on MacOS X. The cumulative result is that the fltk 
> > backend looks like it is doing the right thing, but the gnuplot behavior is 
> > not correct when both the data and plot box aspect ratios are set.
> > 
> > I've attached both the updated test script, and the pdf it produces for me.
> > 
> > If there is no objection (from you or anyone else), I can push these 
> > changes for you.
> > 
> > Ben
> > 
> > <test_aspect.m><aspect_demos.pdf>
> 
> Kostas, I've consolidated your patches and added an entry into the ChangeLog. 
>  Please confirm I've got your name correct, and that it is ok to push.
> 
> Ben
> 

Hi Ben,

thank you for reviewing the patches. The changelog entry seems to be ok.

As soon I find some time I will try to improve the behavior of the
gnuplot backend as well, so that it can also work (more or less)
correctly with both daspect and pbaspect set to manual. I will also try
to fix the bug of the incorrectly calculated plot area in gnuplot when
both daspect and pbaspect is set.

I will also take a look at your demo and try to make it cover some more 
complicated cases.

Kostas