Re: text to path conversion API proposal

Hi Cam,

 Nice chicken and egg discussion...

--Original Message--:
>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.

(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.

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.

In something like WebKit or Mozilla for that matter that are moving
to things like Harfbuzz for shaping, etc. you need to run the entire
shaping engine to get the outline out. WebKit has different paths for
different fonts - simple and complex (shaped). So, whenever the
system font engine gets used you get stuck with unhinted outlines.
On the complex shaped text you need to run the shaping engine
to generate the outline.

All sounds like a lot of work for the UA to implement. So I
agree when Boris says "Assuming they want to".

(2) not moving ahead with the API may be a bit drastic at this
point. However, the implementation of the API is likely to be
non-trivial for every UA out there. 

Given the lack of hinted outline generation in the system font
engines, this API is likely to return unhinted outlines in most
cases, or be unreliable if some engines can return hinted
data whilst others can't due to O/S architecture restrictions.

Not to mention the fonts that don't want you to get at their
outlines...

>> 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.

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.

Alex

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

Received on Sunday, 23 October 2011 23:37:52 UTC