| Summary: | Zeroing of advance of 2nd component of multiple substitution with SBL Hebrew | ||
|---|---|---|---|
| Product: | HarfBuzz | Reporter: | jjc <jjc> |
| Component: | src | Assignee: | Behdad Esfahbod <freedesktop> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | freedesktop, jfkthame |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
jjc@jclark.com
2014-03-29 02:27:33 UTC
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.