Re: Any new comments on the non-uniform scaling patch?

["Marcel Toele" <dpy dia gmail com>]

I'm not convinced that the default_scale attribute is the right way to
go about handling the scaling issues.  It means that whereas the
super-shape ignores the absolute scale and just uses the coordinates as
relative coordinates in a 2x2 cm space, the sub-shape actually uses the
units of the SVG, modified by the default_scale.  This is confusing: The
coordinates of the super-shape and the sub-shape are now interpreted in
different ways, one of which is controlled by a "default_scale"
attribute whose meaning is not clear from context.  If the default_scale
was on the main shape, it would be less confusing and at the same time
close a long-standing bug.

Another problem with the default_scale is that it's defined relative to
something that's not in the shape definition, namely the unit system.
mm might be default in many locals (I frankly don't know, and would
rather not have to remember), but how would the shape be rendered in the
US, where inches or suchlike are the default? 

In my defense, the DEFAULT_WIDTH and DEFAULT_HEIGHT are defined as
2.0, "whatever the current unit system in use".

Meaning, that custom shapes default to 2x2cm in europe and 2x2in. in the US.
From this follows that the "default_scale", which is also taken as "just" a scalar value,
adapts to the current unit system in use as well.

So if not a clean/nice solution, there is no descrepancy between meaning of the values 
with respect to the unit system of either the super-shape and the sub-shape.

However, I'm investigating whether I can get rid of the dreaded DEFAULT_WIDTH/
DEFAULT_HEIGHT, or at least have them only be applied as a fall back
(to avoid functional regression).

cheers,

Marcel