Re: AspectRatio Patches

[Ben Abbott]

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
Description: Binary data

aspect_demos.pdf
Description: Adobe PDF document