* Using Harfbuzz for shaping and platform APIs for rasterization
should work OK. Shapers generally don't take hinting into account.
They may want glyph bounds sometimes, but we can get those from the
platform. There shouldn't be much duplicate caching between the
platform and Harfbuzz.
* Pros for using Harfbuzz on Mac/Windows:
** Core Text is weak at Opentype
** We can implement whatever Opentype features we want
** Consistent shaping across platforms
** We get full control over which Opentype features are enabled
(useful since we want to expose that control to authors via CSS)
** Currently we get performance wins by making certain assumptions
(e.g., fonts don't shape across ASCII spaces, shaping doesn't depend
on line break placement) which are untrue in general; we need APIs to
tell us when it's OK to use those assumptions, but platforms don't
** We get control over performance-critical code so we can optimize
it, parallelize it, etc
** Enables shaping on Windows Mobile where there's no Uniscribe
* Cons for using Harfbuzz on Mac/Windows
** Lacks AAT support
** Script support lags behind Uniscribe
** Inconsistent shaping between apps on the same platform --- but
Windows apps are already wildly inconsistent, and Safari isn't
consistent with other Mac apps
* Download size impact should be measured but not expected to be
* Our feeling: support Harfbuzz alongside Core Text on Mac and
Uniscribe on Windows; decide which system to use based on the font/
script/language in a text run. Prefer Harfbuzz; use Harfbuzz on Mac
unless the font has AAT. Use Harfbuzz on Windows unless it's a script
Harfbuzz doesn't support.
* Required work steps:
** Improve Harfbuzz so it's comparable to Pango in shaping
** Switch from Pango to Harfbuzz for GTK
** Integrate Harfbuzz for Mac and Windows
** Keep improving Harfbuzz script/shaper coverage
Some additional things that came up:
* Need two-phase clustering
** initial clustering phase that's just based on Unicode tables, can
** font selection should avoid font changes inside clusters (e.g. a
base character and a combining mark should be given a font that
supports both characters)
** once we've selected the font, we need a second clustering phase
that can fuse clusters if the font needs it (e.g. the font may combine
two characters into a 'stacked glyph' where selecting half of it makes
no sense, i.e. ligature splitting simply makes no sense)
* Need to measure perf impact of using shaping for all font sizes and
for measuring glyph bounds at all font sizes (should be easy)
I think the lack of AAT support is going to make things a bit tricky on Mac, many of the fonts that ship even with 10.5 only support complex scripts via AAT, not OpenType. Maybe that will change with 10.6, dunno. So I think we'll need to fallback to ATSUI layout for cases where the AAT fonts are matched, unless CoreText supports AAT-based shaping.
> * Need two-phase clustering
> ** initial clustering phase that's just based on Unicode tables, can
> be cross-platform
> ** font selection should avoid font changes inside clusters (e.g. a
> base character and a combining mark should be given a font that
> supports both characters)
I think we'll need fast-path font matching code for the "no clusters" case and a separate version for the "has clusters" case. And the "avoid font changes within clusters" rule should get pushed back into the CSS3 Fonts spec.
One other suggestion would be to also review ICU Layout code, there may features or techniques that might be useful to incorporate.
> Overall, sounds like a great plan.
> I think the lack of AAT support is going to make things a bit tricky
> on Mac, many of the fonts that ship even with 10.5 only support
> complex scripts via AAT, not OpenType. Maybe that will change with
> 10.6, dunno. So I think we'll need to fallback to ATSUI layout for
> cases where the AAT fonts are matched, unless CoreText supports
> AAT-based shaping.
What stops Harfbuzz from gaining AAT support? Too much work?
Yeah, we definitely have to keep supporting AAT. The best way to do
that seems to be to retain the Core Text path for AAT fonts (it does
support AAT shaping). I'm assuming we won't ship Harfbuzz on Mac until
we drop support for 10.4, so we won't have to deal with Harfbuzz and
ATSUI at the same time.
Adding AAT support to Harfbuzz is an option, but it seems like a lot
of work without much benefit.
We have some platform-specific rendering artifacts with a few Indic
scripts, would Harfbuzz be able to help there?
Great initiative. I briefly looked at using Harfbuzz for shaping on
OS/2 (where we currently don't shape at all), but lack of documentation
really kept me from pursuing this further. But when I looked at this
it seemed to me that in addition to Harfbuzz code one would still need
to generate shaping tables (per language), in addition to just using
the code. Has that changed, did I misunderstand, or do we already have
those tables somewhere in a form that allows them to be used under
tri-license (or with MPL)?
I should have explained this further. AAT is basically an Apple-only
technology. It makes sense to support AAT on Mac, where a lot of the
system fonts are AAT, but it doesn't seem useful for non-Mac platforms
where the system fonts aren't AAT. I haven't heard any interest in
downloadable fonts in AAT format, and it's hard to see why there would
Yes, in the sense that we'd be able to fix any shaping bugs we cared
I'm not sure what you mean by "shaping tables". There's shaping code
in Harfbuzz, and there are fonts containing Opentype tables used by
that code, but I'm not aware of any additional data required.
Because there is no documentation, I was pointed to
as an example on how to do shaping with Harfbuzz. Looking at e.g.
the devanagari() function in there I found a long table of glyphs
that make up the ShapeTable. So at first glance I thought that one would
still have to specify those things by hand for every language. Never
had time for a deeper look.
Looking at that again now, I see that I missed before that this is some
kind of unit test. Now I note that these explicit tables only seem to be
used to check the result.