Re: AspectRatio Patches

[logari81]

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.

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.

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).

Best regards,

Kostas