Hi Jonathan, Interesting. In fact, I had to port my Arabic fallback-shaping logic from FriBidi to Python last week and in the process was considering different designs for HarfBuzz.
So, before I had two designs in mind: 1. Synthesized GSUB of *Unicode characters*, with a modified layout engine that checks cmap before substituting. This is what iculayout does. I used to like this approach, but I'm not a huge fan anymore because I think it's too limiting and intrusive. 2. Just do it in a callback in the right place in the complex code. Now your approach is new to me. And a very interesting one in fact. I'm not a huge fan however, for very simple reason: I don't like dynamic memory allocation in hb and want to avoid it as much as possible. When thread-safety stuff comes in, it gets even uglier. Given that the code involved to do a the fallback is around 20 lines at this point, I'm leaning towards just doing it. Let me give this a try today. What fonts are you using for testing? behdad On 04/04/2012 12:29 PM, Jonathan Kew wrote: > Hi Behdad, > > I was thinking about the issue of shaping legacy Arabic fonts using > presentation-forms codepoints, when no GSUB features are available. > > ISTM that the hb_substitute_complex_fallback() placeholder currently in > hb_ot_shape_execute_internal isn't really the right place to do this, because > by that time hb_map_glyphs has replaced the original character codes with > glyph IDs, so doing shaping directly in terms of Unicode codepoints isn't a > convenient option any longer. > > An alternative I'd like to suggest is that, to minimize the amount of shaping > code that needs to be maintained in two places or forms - one for shaping > using the OpenType features and GSUB lookups, and one based on Unicode > character codes - we could handle fonts like this by synthesizing an > appropriate GSUB table on the fly, and then simply using the existing OT > shaping code. > > To see how feasible this would be, I've hacked up some code to synthesize a > basic Arabic GSUB, implementing the init/medi/fina/isol/rlig features. I'll > attach it for your ... review? amusement? It seems to work fine, at least with > the couple of fonts I've tried. > > What's still needed is to figure out a nice way to integrate this - if we're > going to supply a synthetic GSUB, this need to be done up front, before the > shaping plan is compiled, so that the proper table is used both to collect the > lookups and then to execute them. Maybe some kind of > complex_shaper_preflight() call, where the shaper gets the chance to probe the > font's table(s) and see if they support the script it requires, and provide an > alternative if desired. This would happen before compiling the feature maps. > (Note that we'll need to do this table-replacement dynamically depending on > the script of the buffer being shaped, as the font might have a GSUB that > supports Latin script but not Arabic, for example.) > > WDYT? > > - JK > > _______________________________________________ HarfBuzz mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/harfbuzz
