[cairo] text measuring speed

[Jon Smirl]

On 6/13/05, Keith Packard <keithp at keithp.com> wrote:
> On Mon, 2005-06-13 at 02:04 -0400, Jon Smirl wrote:
> 
> > How about having the composer provide a transform function? Then
> > modify Cairo/Freetype call the external transform function if
> > provided. Also long as someone appropriately transforms the
> > coordinates Cairo and Freetype don't care where the coordinate come
> > from, right?
> 
> It's not a matter of doing the transformation.  FreeType hints are only
> defined for a scaling transformation; if you re-read the article I wrote
> about how FreeType and cairo work together, you'll note that hinting is
> applied after the simple scaling operation and before the secondary
> affine transformation.

Isn't the concept behind the freetype autohinter to try and keep
important parts of the glyph from disappearing, like the opening in
the middle of an 'o'? The desire to keep the middle of the 'o' open
shouldn't change no matter what the transform is. I agree that the
secondary affine transform will break the normal font hinting programs
in the font file. But does it break the autohinter too? How can it
tell that the transformed 'o' just isn't some normal glyph out of Thai
that need autohinting?

> That's probably survivable; we'd likely just extract the outlines from
> the library to pass directly into the rasterizer.  Figuring out what
> nominal 'pixel size' to execute hints against might be a bit of fun, but
> we could fake something for odd cases as long as the rectilinear
> transformations were right.
> 
> However, cairo doesn't know how to stroke objects correctly in a
> projective space -- our whole stroke algorithm is defined only for fixed
> device-space pen polygons.  We could probably execute the algorithm in
> some affine space that was 'fine enough' to avoid visible artifacts
> post-projective transform, but we're talking a serious rework of the
> internals of cairo at this point, with some potentially major
> performance implications.

This is a much bigger problem. Can you fix this without changing the
current Cairo API?

> So, the current affine limitation within FreeType and cairo is not just
> a limitation within the API, but is carried deep into the libraries
> where it simplifies (and speeds) many fundemental algorithms.  Going
> back and reworking these to live in a projective space is possible, but
> there are obvious concerns about performance which can't just be
> shrugged off, given the already serious performance problems present in
> the cairo implementation.
> 
> -keith
> 
> 
> 
> BodyID:349523302.2.n.logpart (stored separately)
> 
> 


-- 
Jon Smirl
jonsmirl at gmail.com