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

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

Hi again,

I'm currently repairing the 2x2cm "bug". It already works in my test bench.

What I have done is:

- I have separated the Unit definitions from lib/widgets.c and lib/widgets.h and put them in lib/units.c and lib/units.h so they can be used elsewhere in the code.
- I have added two optional tags to our "implicit" shape-ns:
      1. <default-width>
      2. <default-height>
  A few notes on these tags and their possible values:
      - They are optional, if they are not specified, then the system falls back to the 2x2cm, this ensures that there will be no functional regression.
      - If they are specified, the default size for a new shape of that type is taken from these values.
      - If only one of the two tags is specified, the other is automatically calculated using the given value and the aspect ratio taken from the SVG (the nice thing about an aspect ratio is that it is unitless).
      - Values are specified using either integer or decimal notation suffixed with an optional unit (the default unit is point atm, but this
can be changed), e.g.:   2cm;   1.4in;   5ft.
- I have removed the "default_scale" tag from the implicit shape-ns for the subshapes, it can now be derived automatically. For this, the "default_width" of the shape is used (I have to use either this one or the default_height, but since subshape scaling is also connected to horizontal width, this sounded the best way to go).
    
To do:

- I have to do a little bit of optimization, currently the "default_scale" is calculated each time transform_coord is invoked.
- When the fall back kicks in (neither default-width or default-height tag was defined), the derived "default_scale" is 
0.0 (i.e. the subshapes disappear)