Revisiting shaping fallbacks in 3.x

[springmeyer]

Surfacing this issue from the discussion at

• https://github.com/mapnik/mapnik/commit/64d5153aeaeb1c9e736bfead297dfea39b066d2c#commitcomment-4895530

Details:

• Mapnik 3.x only supports font fallbacks by text item: https://github.com/mapnik/mapnik/blob/3d142c2712d3f7161edfa2f7e18aa8b0258a3015/include/mapnik/text/harfbuzz_shaper.hpp#L106-L118
• Mapnik 2.3.x supported per glyph fallbacks. (TODO: confirm)
• Which is more desirable / what are the tradeoffs / what is our test coverage of this behavior?

Refs https://github.com/arielm/Unicode/tree/67a55b593b5ba4241c69640e32afed90b9b939dd/Projects/ShapingFallback

[springmeyer]

/cc @arielm in case you have more thoughts on the best approach since our earlier discussion.

[arielm]

Hey @springmeyer,

FWIW,I have made some progress since the last time we discussed these issues:

My old Unicode repo is not relevant anymore. Everything is now integrated into my new-chronotext-toolkit repository.

The ZFont (aka VirtualFont) system supports by-the-book Harfbuzz font fallback together with itemization ("script + BIDI (via ICU) + tag".)

It's pretty stable for a while (the only missing feature is unicode compliant word-wrapping...)

Entry point related to font fallback: https://github.com/arielm/new-chronotext-toolkit/blob/develop/src/chronotext/font/zf/VirtualFont.cpp#L200-306

Example of a VirtualFont (i.e. including fallbacks per language) xml definition: https://github.com/arielm/new-chronotext-toolkit/blob/develop/samples/TextWheel/resources/babel_serif_osx.xml

Sample projects: 1) https://github.com/arielm/new-chronotext-toolkit/blob/develop/samples/TextWheel/src/Sketch.cpp 2) https://github.com/arielm/new-chronotext-toolkit/blob/develop/samples/TextWorks2/src/Sketch.cpp

HTH!

[mikemorris]

IIRC, I temporarily introduced per-glyph fallback and ended up scrapping it based on feedback from @nickidlugash that it introduced unpredictable and inconsistent text rendering. Can't remember what behavior 2.3.x supported.

[springmeyer]

confirming: In Mapnik 2.3.x fallback has been per-glyph because:

• During final rendering get_glyph is called here, and;
• get_glyph makes a loop over each fontset here

So @mikemorris I presume the unpredictable and inconsistent rendering you saw was due to some other bug. That is not to say that per-glyph is the way to go, just that at least both options are on the table still I think.

[springmeyer]

@arielm thank you very much for the links. Not had a chance to look over them yet, but plan to. In the meantime, what do you mean exactly by by-the-book Harfbuzz font fallback?

[mikemorris]

Quick clarification on what I meant by unpredictable and inconsistent: I suppose those are the wrong word choices, but fallback glyphs of a different font showing up in a label seemed to be an unexpected behavior for some designers, and it's not always easy to locate examples of labels with some fallback characters when selecting a fontstack.

[arielm]

@springmeyer By-the-book?.. After understanding a lot of crucial topics by 1) studying state-of-the-art solutions like pango and 2) receiving feedback and from authorities like Behdad and Khaled.

@mikemorris Font fallback is inherent to international text support. No way to escape it. The question is: how much energy and talent can one invest in building the right "configurations".

Btw, I don't really understand the question of "glyph" vs "font" fallback. Fallback can only take place at the cluster (i.e. one or more glyphs) level.

e.g. Take an arbitrary sentence (i.e. mixing between different languages) and ask OSX to "shape" it using, say, Helvetica. The purely latin cluster will use the Helvetica physical font, but for the rest: no way (proof that cluster-level font-fallback is happening all the time...)

[mikemorris]

@arielm Well aware that that fallbacks of some sort are needed, simply relaying a concern that it can be jarring from a design standpoint to see mixed glyph fallback like Helvetica and Arial characters in a single label.