Windows / font / text futures ...

[Khaled Hosny]

On Fri, Mar 04, 2016 at 12:04:38PM +0000, Caolán McNamara wrote:
> On Thu, 2016-03-03 at 13:44 +0000, Michael Meeks wrote:
> > Hi guys,
> 
> > 	Anyhow - what to do ?
> > 
> > 	While we could switch to DirectWrite on windows, which may
> > solve some
> > of our problems; this will be in itself disruptive.
> > 
> > 	So - I believe that we should switch to using harfbuzz and
> > freetype consistently everywhere.
> 
> So, like chromium and firefox etc do, I'm very much in favor of using
> our harfbuzz text shaper on all platforms to unify that complexity and
> have equal layout problems on different platforms :-).
> 
> If you look at the vcl/unx/generic/glyphs/gcach_layout.cxx getFontFuncs
> thing (and the firefox equivalents) then harfbuzz has mechanisms to
> allow us to integrate with CGFontRefs on MacOSX, FT_Face under Linux
> and presumably (?) hook into our existing Windows stuff to swap out the
> two windows shaping engines and keep (one of) the existing render paths
> ?

HarfBuzz has callbacks to get some of the stuff it wants from fonts,
char to glyph mapping, etc. This can be hocked into FreeType, Core Text,
DirectWrite or even GDI APIs, so you can keep loading/rendering fonts
with platform “native” API and use HarfBuzz for shaping and positioning.
Recent versions of HarfBuzz even has its internal font functions and you
just give it a memory blob representing the font file and it will read
the font tables on its own (Chrome has recently switched to using that,
for example) this means even more consistency since, for example,
FreeType can return different metrics in different versions.

> So layout wise I'm comfortable with harfbuzz everywhere. Window text
> rendering is as clear as mud to me though. Right now under Linux (and
> similar platforms) at the moment we are using cairo to render glyphs
> (from freetype faces) rather that using freetype to do that directly.
> And under Linux we render visually differently, albeit with the same
> positioning, depending on what features of the underlying freetype are
> enabled or disabled and all mediated by what desktop-wide font options
> are set. My experiences there suggests that if your text doesn't look
> like everyone else's on that platform there's constant moaning and
> complaining.
> 
> On Windows, peer apps like firefox and chromium etc seem to follow the
> pattern of eventually rendering their harfbuzz layouted text with the
> DirectWrite apis, whether directly, or through skia or through a forked
> cairo, that *seems* be where things end up. So that seems to be a
> fairly well trodden route.

Not using the “native” font rendering APIs is indeed more controversial
as it means you don’t respect system wide font rendering/hinting etc.
options which will be very visible especially on Windows since
FreeType’s support for ClearType hinting is rather incomplete. Shaping
difference on the other hand is more subtle, and HarfBuzz tries to
maintain computability with MS implementation (this does not help with
Mac OS X implementation, but usually differences there are considered
bugs in Apple implementation).

Another problem with using FreeType is it can be tricky to integrate it
with platform font searching APIs, there is no direct way, for example,
to create an FT_Face from a CTFont as FreeType wants either a filename
and face index (for font collections) or the full font memory blob and
CTFont has no API that gives this. Even if it has, you will end up
loading the font twice in memory, though this might not be such a big
issue.

Regards,
Khaled