RE: [Devel] pixel size, hinting and scaling

[Graham Asher]

David,

I think actually we are in agreement. You said "On the other hand, I'm
pretty certain that we still need to separate the transforms, and make the
distinction to the end user when this makes sense." My idea of having a
single function would do that implicitly: it would decompose the
transformation into scaling and the rest, and set the pixel sizes according
to the scaling only. I take your (implied) point, though, that it is easier
for the user sometimes to have two separate API functions. But that only
reinforces my original idea that there is a design flaw: if the transform
should not do any scaling, this should ideally be enforced by the API in
some way. At present the user is free to apply scaling by calling
FT_Set_Transform, and thus screw up the pixel sizes with respect to hinting.

<<<<<<
Here's a proposed algorithm:

   let A be the matrix   | ax  bx  |
                         | ay  by  |

   then the scaling factors can be computed as:

      sx = sqrt( ax*ax + ay*ay )
      sy = ( ax*by - ay*bx ) / sx

   if sy > 0, we can write that A is equal to:

      | ax/sx  bx/sy  |  multiplied by | sx   0 |
      | ay/sx  by/sy  |                |  0  sy |

   if sy < 0, we can write that A is equal to:

      | ax/sx  -bx/sy  |  multiplied by | sx   0  |
      | ay/sx  -by/sy  |                |  0  -sy |
>>>>>>

thanks - that's very useful and I think much more efficient than what I am
doing, which is so naive it's embarrassing ;-) I do it this way:

1. Use the matrix to rotate a vector that originally points in a known
direction (say, up).
2. From the vector, determine an angle by which to rotate the matrix in the
other direction. This removes rotation.
3. The scale factors are now elements 0 and 3 in the matrix. I can divide
the original matrix by them, thus separating
scaling from the rest.

You can tell from this that I gave up maths at age 15 at school, and never
really caught up.

Best regards,

Graham