Re: text to path conversion API proposal

Boris Zbarsky:
> The alternative is to embed a definition of all the details of
> shaping, kerning, etc, etc, in the spec, yes?  And then wait for UAs
> to actually implement it all.  Assuming they want to.

Right, that seems to be an unlikely path forward.  So the choices are:
(1) accept that text layout engines will do different things, and that
exact font glyph data will be encoded differently, or (2) not move ahead
with the API.

> Or restrict the API to font formats that don't support any of that
> stuff, of course.  But that makes it unusable for some text, of
> course.
> 
> A related question: what are the actual use cases for the API?  Is
> compatibility of the metrics returned with actual text rendering by
> the browser important, say?  If so, then you can't require path data
> uniformity, since browsers do not in fact render things identically.

The use case I’m interested in having the API solve is allowing authors
to write script that can deform text in ways that can’t be done with the
built-in functionality.  For this, I want the paths returned to be what
is (or would be) rendered natively in that particular browser, but not
across different browsers.

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Sunday, 23 October 2011 18:33:55 UTC