With SBL-Hbrw.ttf from http://www.sbl-site.org/Fonts/SBL_Hbrw.ttf, on the sequence 05e0 05b8 0591 05da 05b0 hb-shape gives [uni05DA05B0=3+991|uni2009=0+0|uni0591=0@75,0+0|uni05B8=0@495,0+0|uni05E0=0+683] I think the advance of uni2009 should be 200 (its normal advance) not 0. Looking at the font and the trace output of HarfBuzz, I cannot see any lookup that zeros the advance of uni2009. What's happening is that 0591 gets decomposed into 0591+2009 (by lookup 41, called from lookup 17). I guess HarfBuzz's zeroing of 2009 has something to do with 0591's being a mark.
I can confirm that Uniscribe generates different results than HarfBuzz, which are consistent with what you describe. Will take a look.
If I was to guess what's happening: when we decompose a glyph into two, we inherit properties of the originating glyph to both of the new glyphs, and zero their widths. Looks like Uniscribe doesn't do this, and it's not always desirable. We need to figure out what to do to fix this and not regress other things. It's nontrivial. Jonathan?
I know this is an extremely tricky area, but I will make a suggestion anyway. Before commit 568000274c8edb5f41bc4f876ce21fcc8bdaeed8, you were zeroing mark advances in fix_mark_attachment. I like that approach a lot: attaching a mark using MarkToBase while still using the original advance doesn't make a lot of sense. Zeroing mark advances based on the Unicode general category when the font provides a proper "mark" feature seems overly aggressive to me. So here's my suggestion: - if the GPOS table provides the "mark" feature, do what you were doing before that commit (ie zero mark advances in fix_mark_attachment except for Indic and Myanmar); - otherwise, do what you are doing now. I suggest checking for the "mark" feature rather than just checking for GPOS, because there are fonts (eg Georgia in Windows 8) that have a GPOS without the "mark" feature but include non-spacing marks with non-zero advances. Here is some relevant history https://bugzilla.mozilla.org/show_bug.cgi?id=609604 https://bugzilla.mozilla.org/show_bug.cgi?id=635639 http://lists.freedesktop.org/archives/harfbuzz/2010-November/000953.html
Sorry forgot I wasn't on github and that commits aren't autolinked. The commit I was talking about is: https://github.com/behdad/harfbuzz/commit/568000274c8edb5f41bc4f876ce21fcc8bdaeed8 Another approach might be to do for decompositions something similar to what you are already doing for ligatures: https://github.com/behdad/harfbuzz/commit/7e08f1258da229dfaf7e1c4b5c41e5bb83906cb0
Fixed: commit 9e834e29e0b657f0555df1ab9cea79ff7abcf08d Author: Behdad Esfahbod <behdad@behdad.org> Date: Sat Jul 26 20:34:01 2014 -0400 [hebrew] Zero mark advance by GDEF late Seems to be what Uniscribe does. At this point I think it's work checking our default... Fixes Bug 76767 - Zeroing of advance of 2nd component of multiple substitution with SBL Hebrew https://bugs.freedesktop.org/show_bug.cgi?id=76767 Micro-test added.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.