[cairo] Funky text metrics

[Owen Taylor]

On Sun, 2004-12-19 at 19:13 -0800, Keith Packard wrote:

> cairo computes the global font transformation by taking the font matrix and
> mutiplying by the current transform matrix (ctm).  This matrix is then
> decomposed into two separate pieces -- the x and y 'scale' factors and then
> matrix holding the rest of the transformation (I believe this transform is
> area preserving).
> 
> Within FreeType, these two factors are used in very different ways.  The x
> and y scale factors are applied within the glyph loader itself as they are
> required by all of the hinters.  The transformation matrix is applied after
> the glyph is hinted but before the outline is rasterized.  The
> transformation matrix is *not* used when computing overall font metrics.
> 
> Given the way cairo applies transforms to fonts, this overall tactic 
> ensures that glyph shape is determined entirely by the pixel size of the 
> glyph, without regard to any area preserving transforms (rotate, mirror or 
> shear).
> 
> Now in looking at the font metrics functions, I see that the front-end/
> back-end interface is defined to return all extents in device space; these
> extents are then fed through the ictm to yield user space values.
> 
> This cannot work because all of the extent values are returned as scalars,
> not vectors.  Any rotating, shearing or reflecting transform will have 
> these values nicely scrambled.  A 90 degree rotation will set all of the 
> vertical scalars to zero in the current implementation:
> 
> > autoimport Cairo;
> > cr = new ();
> > set_font (cr, "sans-12")
> > set_matrix (cr, (matrix_t) { { 0, 1 }, { -1, 0 }, { 0, 0 } });
> > current_font_extents (cr)
> {ascent = 0, descent = 0, height = 0, max_x_advance = 0, max_y_advance = -16}
> 
> Obviously we have to let the back-end compute the user-space coordinates 
> as the data structure doesn't have the ability to represent these vectors 
> in device space.  I think this is possible, but performing the right 
> conversion will be tricky as we have to separate out the effects of the 
> font transform from the global transform.

Passing metrics in user-space coordinates sounds right to me. (The
convention of user space coordinates with hinting based on the global
transform is what Pango uses everywhere.)

Few notes here:

 - Cairo should be disabling hinting if there is any non-scale piece to
   the overall transform. (Conceivably h-stem hinting could still be
   useful for an artificial oblique font, but I don't think FreeType
   is able to do that, so not worth worrying about)

   This makes things easier, since you just have to take the unhinted
   metrics and apply the font transform to them... the user space
   results are independent of the global transform.

 - Hinting for 90/180/270 rotations: I'd really like this for Pango, but
   the metrics are the smaller piece of this ... either you have to
   implement hinting for these rotations inside FreeType or you have
   to *render* unrotated (possibly VBGR or VRGB) and rotate the bits.

 - Worth keeping in mind ... one thing that I want for Pango eventually
   is the ability to flip characters over on their side within the
   text stream (either side) ... the main use case for this is vertical
   text; for  characters with vertical metrics, the vertical advance
   replaces the horizontal text, but being 

   I'm not sure if this is best represented by recognizing 90/270
   degree rotations in the font transform and special casing
   (other rotations in the font transform are  basically meaningless...)
   or a separate API.

Regards,
						Owen



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20041220/b6275ffb/attachment.pgp