OpenType Issues

[psubhashish]

@lianghai, Hi, I've included a list of issues (expected vs. current output) here. Please let me know if I should write the glyph names instead to make it easier.

[lianghai]

Thanks for preparing this. Seems like a simple misconfiguration of lookup flags and GDEF classes. Not difficult to fix:

Suggestions before I start a PR:

• Unless you really want to source control such transient documents, such PDFs can be simply shared as an attachment to an issue ticket.
• Source controlling the exported font files seems convenient, but can get very confusing as they tend to get outdated compared to the collocated source files. I recommend publishing them as release assets, so the sources and builds are clearly separated.
• Please convert the source format to .glyphspackage for easier collaboration in a repo. See also https://github.com/typotheque/public-documentation/blob/main/source-file-requirements.md#font-info for three useful custom parameters.

Can you also talk a bit about how the FEA code was originally written? It appears to be decompiled from a font, rather than manually written. I’m not sure how much I need to retain its peculiarities.

[psubhashish]

Thanks for the suggestions @lianghai.

Thanks for preparing this. Seems like a simple misconfiguration of lookup flags and GDEF classes. Not difficult to fix:

Suggestions before I start a PR:

• Unless you really want to source control such transient documents, such PDFs can be simply shared as an attachment to an issue ticket.

Noted for next time.

• Source controlling the exported font files seems convenient, but can get very confusing as they tend to get outdated compared to the collocated source files. I recommend publishing them as release assets, so the sources and builds are clearly separated.

Good suggestion. Done

• Please convert the source format to .glyphspackage for easier collaboration in a repo. See also https://github.com/typotheque/public-documentation/blob/main/source-file-requirements.md#font-info for three useful custom parameters.

This is done.

Can you also talk a bit about how the FEA code was originally written? It appears to be decompiled from a font, rather than manually written. I’m not sure how much I need to retain its peculiarities.

So this project's FEA code was built on @coldbreeze16's work-in-progress typeface. You're most welcome to change as they would make sense. @coldbreeze16 would mostly adapt those changes into that typeface.

[psubhashish]

Hi @lianghai quickly checking if I responded to your suggestions properly. Please let us know when the issues are fixed. We're planning for the first stable release by the end of this month.

[lianghai]

Thanks for the reminder. The past weeks have been hectic, but yes, I can spend some time on this around this coming weekend.

[psubhashish]

Thank you much Liang. That would be perfect.

[lianghai]

Done with two major commits:

• 59431f0: This is only organization, without changing the font’s behavior in any meaningful way.
• cac79b8: This is where I fixed the issues.

The FEA code was quite chaotic, with casually written rules (often for a wrong glyph sequence) randomly placed in lookups.

Glyphs are not named consistently either. Besides the _ba vs _va issue, there’s also inconsistencies like _i vs _ikaar.

Good suggestion. Done

You misunderstood my suggestion. The point is to not source control artifacts (font files) and only attach them to releases. Please read my original comment again, and refer to conventional repos like https://github.com/notofonts/oriya/releases for references.

[psubhashish]

@lianghai thanks much for the fixes and reorganising. Nasim, who originally used Microsoft VOLT to compile the features (attached here) if there is any need.

You misunderstood my suggestion. The point is to not source control artifacts (font files) and only attach them to releases. Please read my original comment again, and refer to conventional repos like https://github.com/notofonts/oriya/releases for references.

My bad and noted.

[lianghai]

Also, inside https://github.com/ofdn/Chapakala/tree/d11d0e028a17dd2a94cef20d8e21176a70d8540f/19, I suggest you should remove the “Doc” directory (which is not relevant anymore) and remove “fonts/Chapakala19.ttf”, then move “Chapakala19.glyphspackage” to be right under the “19” directory next to README.md. Overly nested directory structure isn’t useful.

Btw, currently this font doesn’t have much mark attachment (anchoring), and thus besides the nonspacing combining mark characters there’s only or_reph being GDEF class 3 (marks). GDEF class 3 is a requirement for mark attachment and once you start making additional glyphs have GDEF class 3 (by overriding glyph info like what I did to or_reph; see screenshot below), the usage of lookup flags will need to be reviewed.