W3C home > Mailing lists > Public > www-svg@w3.org > October 2011

Re: text to path conversion API proposal

From: Rik Cabanier <cabanier@gmail.com>
Date: Sun, 23 Oct 2011 21:40:10 -0400
Message-ID: <CAGN7qDB2bRJp9xnQs=H8QcXdmVur8XamehKqez3r2tugHN5QwQ@mail.gmail.com>
To: Alex Danilo <alex@abbra.com>
Cc: Cameron McCormack <cam@mcc.id.au>, Boris Zbarsky <bzbarsky@mit.edu>, www-svg@w3.org
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 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:49 GMT