Re: Modern font features, hacky patch

On Fri, Mar 30, 2012 at 01:11:59PM +0100, Caolán McNamara wrote:
> On Fri, 2012-03-30 at 11:39 +0200, Steve White wrote:
> > Basic features
> > ==============
> > (Background reading: search for "typographic features", "font feature
> > registry", "layout tag registry".)
> >
> > Some features that really ought to be activated most of the time, in
> > most scripts
> > * ligatures for Latin and most alphabetic scripts
> > * localized replacement (based on text language, region)
> > * pair kerning
> > * mark positioning
>
> So, I asked Steve to post to the list, so I could dump some experimental
> code to a wider audience with its context
>
> Lets put graphite aside for a moment, its something of a red herring
> really for a lot of these things. 
>
> If we look at 
> https://bugs.freedesktop.org/show_bug.cgi?id=31821
> I've a patch there that shows that a lot of our woes with otf fonts is
> probably a simple bug/lack of implementation in out ServerFont::GetTable
> that it doesn't handle OpenType. freetype does it fine, but we're not
> using freetype to get the tables, but parsing them outselves.
>
> Patch at fdo#31821 
> a) hacks in using freetype to get the tables (does anyone know if there
> a freetype api to just get the offset of a table and not a full copy of
> it ?, we've already mmapped the file so we don't need to copy them)
> b) hacks in using the icu layout engine for all text, and not just for
> CTL text. I wonder if its just a performance reason that we have out own
> "simple" font engine for the non-CTL case ?
> c) overrides IcuFontFromServerFont::mapCharToGlyph to not filter out the
> zero width joiner glyphs before applying the gsub table. The icu Indic
> layout engine doesn't filter it, not sure why the non-Indic ones *do*
> filter it.
>
> So, I reckon we should continue to refactor out font handling code to
> remove various custom ttf/otf parsing and try and use more of the
> freetype apis so that LibreOffice gets to know about GSUB etc tables in
> opentype fonts, and maybe look into removing the simple font layout
> engine and just use the icu one for all fonts. 

For a while now I had the idea that we should move away from ICU layout
engine (which is pretty dead and serious bugs aren't fixed anymore), and
replace it with HarfBuzz, but HarfBuzz's Indic support is not finished
(Arabic and simple scripts are fine) and I'm waiting for its next
release for that. HarfBuzz is more active, more developer friendly
(though under documented at the moment) and its code base have been
widely used in free software applications (more tested) and is the most
feature rich free OpenType implementation. HarfBuzz would make it much
simpler to implement many of the points raised above, which would be
near impossible with ICU layout engine.

But regardless of the layout engine we use, this only affects
non-Windows non-Mac platforms, while on Windows we use Uniscribe and on
Mac we use, the now deprecated, ATSUI, which is IMHO another limitation
that we should get rid of and move to a unified text layout engine in
all platforms (which would solve lack of OpenType support on Mac).
Firefox have been doing that lately, and IMO it has the best typographic
support of all browsers.

If there is interest in this, I can try implementing optional HarfBuzz
support next to ICU so we can experiment more with this (though I'm not
the best person to do this, but I can try).

Regards,
 Khaled