somehow the XP and YP are different compared a pre LayoutEngine version of compositor about compositor

[typesupply]

Any GPOS support beyond single and pair positioning is almost certainly broken. It's weird that the two versions give different results. I don't recall changing anything in the core. Are these from the same binary?

KeyError

Yeah. This is a feaLib issue. I'm going to open a PR for that when I have a chance. It needs to raise a FeaLibError with a note about the unknown glyph.

[typemytype]

This is not really a feaLib issue as I was just reading binaries files.

I fixed it by returning the fallback glyph whenever a glyph is requested that does not exist
maybe I have to fork-patch and pull those little changes

gr Frederik
www.typemytype.com

On 31 Jan 2016, at 02:27, Tal Leming [email protected] wrote:

Any GSUB support beyond single and pair positioning is almost certainly broken. It's weird that the two versions give different results. I don't recall changing anything in the core. Are these from the same binary?

KeyError

Yeah. This is a feaLib issue. I'm going to open a PR for that when I have a chance. It needs to raise a FeaLibError with a note about the unknown glyph.

—
Reply to this email directly or view it on GitHub #14 (comment).

[typesupply]

Got it. I'll fix it.

I've found where the value difference is happening. I'm trying to figure out a way to fix it now. (It's a chicken or egg issue.)

[typesupply]

So, here's what is happening on the value difference. Previously, the glyph records resulting from GSUB processing had their advance width set before processing GPOS. See here. This advance width value is used internally to calculate x placement values in some of the GPOS subtable types. For example.

The issue that I'm stuck on is that the new LayoutEngine object doesn't know anything about glyphs and so it therefore doesn't have an advance width to preset before processing GPOS. I can modify the LayoutEngine object to have something like a hmtx table. However, I'm not certain that my GPOS code is correct (for subtable types beyond basic pair positioning), so the first thing I want to do is get that working with a high degree of certainty. I'll open a new issue for that and then come back to this.

[typemytype]

the layout engine could call willBeginProcessGSUB didProcessGSUB and the same for GPOS

the font object could then add the overwrite didProcessGSUB and adjust the advanceWidth values of the glyph records

gr Frederik
www.typemytype.com

On 01 Feb 2016, at 05:23, Tal Leming [email protected] wrote:

So, here's what is happening on the value difference. Previously, the glyph records resulting from GSUB processing had their advance width set before processing GPOS. See here. https://github.com/typesupply/compositor/blob/db296a7ec7d0b09b58791231f356b511b8604f90/Lib/compositor/__init__.py#L211 This advance width value is used internally to calculate x placement values in some of the GPOS subtable types. For example. https://github.com/typesupply/compositor/blob/master/Lib/compositor/subTablesGPOS.py#L363
The issue that I'm stuck on is that the new LayoutEngine object doesn't know anything about glyphs and so it therefore doesn't have an advance width to preset before processing GPOS. I can modify the LayoutEngine object to have something like a hmtx table. However, I'm not certain that my GPOS code is correct (for subtable types beyond basic pair positioning), so the first thing I want to do is get that working with a high degree of certainty. I'll open a new issue for that and then come back to this.

—
Reply to this email directly or view it on GitHub #14 (comment).

[typesupply]

the layout engine could call willBeginProcessGSUB didProcessGSUB and the same for GPOS

the font object could then add the overwrite didProcessGSUB and adjust the advanceWidth values of the glyph records

All GPOS processing may need the advanced width set for proper calculation in the complex subtable types. So it can't just be in the subclass.