Re: text to path conversion API proposal

I'm not sure if hinting comes into play when generating outlines.
At Adobe, none of our applications are aware of hinting when they generate
the outlines and I haven't heard of this causing any issues.

Rik

On Sun, Oct 23, 2011 at 7:37 PM, Alex Danilo <alex@abbra.com> wrote:

> 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 Monday, 24 October 2011 01:40:39 UTC