Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Examine the implementation of GPOS lookup types 3, 4, 5 & 6. #16

Open
typesupply opened this issue Feb 1, 2016 · 1 comment
Open

Examine the implementation of GPOS lookup types 3, 4, 5 & 6. #16

typesupply opened this issue Feb 1, 2016 · 1 comment

Comments

@typesupply
Copy link
Member

When I wrote Compositor, I didn't have any test cases for these so I implemented them following my interpretation of the spec. The spec for these is pretty complex and (as I recall) incomplete/contradictory/confusing. So, the implementation is probably not correct. Now that the .fea syntax supports these lookup types, some test cases can be built and the implementation can be validated.

The test cases need to be incremental and atomic so that only one variable is being tested at a time. A simple text format that builds an in-memory font on the fly with defcon and pushes it through feaLib is going to be the easiest way to implement this.

I need to document the meaning of the values in compositor's glyph records after GPOS processing.

  • The x/y placement values are the adjustment to the initial drawing position of the glyph.
  • the x/y advance values are adjustments to the glyph's width/height. They do not incorporate the glyphs's width/height.

The idea is that these are "pure" GPOS values, especially for the advances. In theory, this makes it easier to evaluate the results of GPOS processing. That was the original goal of compositor.

Lookup Type 3 - Cursive Attachment

Syntax
Specification

# syntax: position cursive <glyph|glyphclass> <entryAnchor> <exitAnchor>;

glyph1.width = 100
glyph1.height = 1000

glyph2.width = 300
glyph2.height = 3000

#         no exit | no entry
position cursive glyph1 <anchor NULL> <anchor NULL>;
position cursive glyph2 <anchor NULL> <anchor NULL>;
<glyph1 0 0 0 0> <glyph2 0 0 0 0>

#            exit | no entry
position cursive glyph1 <anchor NULL> <anchor 10 30>;
position cursive glyph2 <anchor NULL> <anchor NULL>;
<glyph1 0 0 0 0> <glyph2 -90 -970 ? ?>

#         no exit |    entry
position cursive glyph1 <anchor NULL> <anchor NULL>;
position cursive glyph2 <anchor 1 3> <anchor NULL>;
<glyph1 0 0 0 0> <glyph2 -1 -3 ? ?>

#            exit |    entry
position cursive glyph1 <anchor NULL> <anchor 10 30>;
position cursive glyph2 <anchor 1 3> <anchor NULL>;
<glyph1 0 0 0 0> <glyph2 -91 -973 ? ?>

# entry + no exit | no entry + exit
position cursive glyph1 <anchor 10 30> <anchor NULL>;
position cursive glyph2 <anchor NULL> <anchor 1 3>;
<glyph1 0 0 0 0> <glyph2 0 0 0 0>

Lookup Type 4 - Mark To Base Attachment

Syntax
Specification

Test Case Syntax Goes Here

Lookup Type 5 - Mark To Ligature Attachment

Syntax
Specification

Test Case Syntax Goes Here

Lookup Type 6 - Mark To Mark Attachment

Syntax
Specification

Test Case Syntax Goes Here
@typesupply
Copy link
Member Author

@typemytype: FYI, here is where I'll start working out some test cases for fixing the GPOS attachment positioning.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant