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