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

[Gurmukhi] Inappropriate illustration of the nukt feature #95

Closed
lianghai opened this issue Apr 1, 2020 · 1 comment
Closed

[Gurmukhi] Inappropriate illustration of the nukt feature #95

lianghai opened this issue Apr 1, 2020 · 1 comment
Assignees

Comments

@lianghai
Copy link

lianghai commented Apr 1, 2020

https://github.com/n8willis/opentype-shaping-documents/blob/master/opentype-shaping-gurmukhi.md#32-nukt

The “ਡ ਼ → ੜ” substitution is a widespread but inappropriate usage of this feature. Please use a different example. Not sure if this information is valuable to shaper development, but font producers should be aware of this bad practice, so I’ll make sure to discuss this in http://github.com/typotheque/text-shaping.

I recommend “ਸ ਼ → ਸ਼” as the example, because ਸ਼ is both a frequently used nukta-ed letter and the first one in the alphabetical list of nukta-ed letters: ਸ਼ ਖ਼ ਗ਼ ਜ਼ ਫ਼ (ਲ਼)

@n8willis
Copy link
Owner

So, looking back on this now, I suspect that my sole reason for choosing "dda" for the illustration was that it was the only nukt lookup in Noto Gurmukhi for which it was visually clear that the application itself was a substitution with a whole new glyph and not a repositioning for the mark.

I definitely tried to choose illustrations that were more resistant to that sort of misunderstanding where there's a possibility of doing so. Still, that is not as important of a factor as picking a typographically correct example. I glanced at Noto Sans & Serif again and didn't find any candidates that would check-off both the "correct" and "visually not a GPOS move" columns, so I'm totally happy to make the change.

But, as a general principle as well as here, if there's something that I've missed that would also help fill that visual-unmistakability goal, please let me know. (I feel like examples in shaper docs can lean more towards "always be hard to misunderstand" whereas examples in docs for type designers need to lean more towards "most useful in practice", but that's not a scientific theorem or anything.)

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

2 participants