[cairo] Rounding bug in cairo_ft_font.c

[Keith Packard]

Around 0 o'clock on Jan 9, Owen Taylor wrote:

> But for the case of a stretch, for a case of a shear, we do have a 
> reasonable interpretation of what the metrics should be in user space.
> And driving the API off of rotation doesn't make sense because setting
> a font transform that is a rotation doesn't make sense. 

Shear is a hard one for me -- the existing metrics don't provide any 
geometrical hint as to how the bounding box will change under the shearing 
transformation.

But, as you say, the killer here is rotation, which you suggest is 
uncommon enough that to let it drive the whole architecture is a bad idea.
But, I still need some sensible meaning for metrics under rotation.  

Should I just compute a user-space bounding box and let silly people who 
rotate fonts live with that result?

> I'm not sure offhand of whether the line spacing changes...it probably
> depends on the details of how we extract the y_scale factor. If the 
> x_scale/y_scale factor extraction is indeed area preserving, then that
> implies the line spacing stays the same.

The scaling factors are the length of unit X and Y vectors as transformed 
by the matrix.  Off the top of my head, that doesn't sound area 
preserving -- an area preserving shear transformation will generate 
non-identity scale factors.  If you have a better equation, sent it along 
or I'll have to think about it on my own.

> (Implementation thought: FreeType can compute the bounding box of the
> transformed outline in pixel space... after all, it needs it to figure
> out what to render for the glyph. And the *common* case is that 
> pixel space and user space differ only by a scale. A dead-slow path
> for the general case is probably fine.)

Actually, once the outline is computed, finding the bounds isn't all that 
expensive -- just walk over the coordinates for the final outline.  This 
is precisely what FreeType does to compute the scaled metrics (which it 
does before the transform is applied).

However, we have to decide what space to do this computation.  Pixel space 
is clearly wrong as there might be a rotation in the ctm.  One of my 
little goals is to have the metrics invarient (except for hinting) under 
any user space transformation.

> Get a bounding box for the rendered area for text is a really
> fundamental. The only way we can punt on this is if we simply outlaw
> artificial oblique.

Knowing the axes of the box seems like the first problem to solve.  
Measuring the bounds of the glyph in an arbitrary space is easy once we 
know what that space is...

-keith


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050109/58a2e650/attachment.pgp