Re: text to path conversion API proposal

Cameron McCormack:
>> 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.

On 23/10/11 4:37 PM, Alex Danilo wrote:
> (1) is always going to be the case. Different native OS font engines
> do different things - like ClearType sub-pixel positioning of glyph
> edges vs. OS X grey anti-aliasing. These engines do very different
> things - i.e. the shape of the hinted outline in ClearType needs to
> be adjusted so that no colour fringing appears. This effectively
> forces the outlines to be different with the different rasterization
> technique.
>
> Also importantly, most system APIs that return glyph outline data do
> it with the raw font outline - not after hinting. Hinting is applied
> once the size of the font to be rasterized is known, etc. The outline
> APIs just return the unhinted data.

Yeah.  I agree these are issues that prevent easy cross platform
identical results from such an API.

> So, to have consistent results you'd burden all UAs with having to
> read the raw font data, decide a normalized size or similar and then
> apply hinting.

I would still be happy with the API if the paths returned did not take
into account hinting.  Am I right than in most implementations
text-rendering="geometricPrecision" turns off hinting?  Having similar
rendering between text painted with that property and the paths returned
from the API would be acceptable to me.

>> 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.
>
> So what you're saying here "write script that can deform text in ways
> that can’t be done with the built-in functionality" is what is
> achievable with OpenType fonts (WOFF or local) only.
>
> Funnily enough SVG fonts can do all of this use case already.
>
> If the outlines coming back from this API are unhinted, then clearly
> this use case solves a lack of implementation of the SVG font
> features in a web engine more than provide new capability IMHO.

You can get at the path data of the SVG fonts, but you can't get the
results of the laid out text.  The decoration shapes you also cannot get.

Received on Monday, 24 October 2011 22:09:57 UTC