mapnik / mapnik

Mapnik is an open source toolkit for developing mapping applications
http://mapnik.org
GNU Lesser General Public License v2.1
3.67k stars 826 forks source link

Revisiting shaping fallbacks in 3.x #2524

Open springmeyer opened 10 years ago

springmeyer commented 10 years ago

Surfacing this issue from the discussion at

Details:

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

springmeyer commented 10 years ago

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

arielm commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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

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 commented 10 years ago

@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 commented 10 years ago

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 commented 10 years ago

@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 commented 10 years ago

@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.