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

Do not destroy ligs or SS #1089

Merged
merged 2 commits into from
Jan 28, 2023
Merged

Do not destroy ligs or SS #1089

merged 2 commits into from
Jan 28, 2023

Conversation

Finii
Copy link
Collaborator

@Finii Finii commented Jan 28, 2023

[why]
When a certain 'higher codepoint' glyph is needed for a substitution or ligature rule of a basic glyph and we replace the 'higher codepoint' glyph with a symbol that stylistic set or ligature will be broken.

[how]
We can not determine if a certain glyph is the target of a pos-sub rule (at least I could not find a way). What we do is remove all pos-sub entries that start at a symbol-patched glyph [1], but that is not the same.

Instead of walking through all substitution tables we just examine the 'basic glyphs' and also protect all glyphs that they reference through most of the possub tables.

In fact I encountered only "Substitution" entries and never "Ligature" entries, but we handle both alike. "Pair", "AltSub", and "MultSub" are not handled, but could be added if need be.

[1] #711

Fixes: #901

Reported-by: Xiangyu Zhu [email protected]

Requirements / Checklist

What does this Pull Request (PR) do?

How should this be manually tested?

Check all fonts and collect data on which codepoints will be skipped.

Any background context you can provide?

What are the relevant tickets (if any)?

Screenshots (if appropriate or helpful)

[why]
When a certain 'higher codepoint' glyph is needed for a substitution or
ligature rule of a basic glyph and we replace the 'higher codepoint'
glyph with a symbol that stylistic set or ligature will be broken.

[how]
We can not determine if a certain glyph is the _target_ of a pos-sub
rule (at least I could not find a way). What we do is remove all pos-sub
entries that _start_ at a symbol-patched glyph [1], but that is not the
same.

Instead of walking through all substitution tables we just examine the
'basic glyphs' and also protect all glyphs that they reference through
most of the possub tables.

In fact I encountered only "Substitution" entries and never "Ligature"
entries, but we handle both alike. "Pair", "AltSub", and "MultSub" are
not handled, but could be added if need be.

[1] #711

Fixes: #901

Reported-by: Xiangyu Zhu <[email protected]>
Signed-off-by: Fini Jastrow <[email protected]>
@Finii Finii added the Bug fix label Jan 28, 2023
@Finii
Copy link
Collaborator Author

Finii commented Jan 28, 2023

image

image

@Finii
Copy link
Collaborator Author

Finii commented Jan 28, 2023

Affected:

  • FantasqueSansMono: E005, E006, E008, E009
  • InconsolataGo: F40A
  • LiberationMono: F004
  • RobotoMono: F6C3
  • Tinos: F004
  • Ubuntu: F800 - F81D
  • UbuntuMono: F800 - F81D

Looks good. Astonished noone ever reported Ubuntu!

[why]
When --quiet and --no-progressbar is given we get a lot of empty lines
in the output.

[how]
Just output the carriage return when we have output som eunterminated
stuff before.

Signed-off-by: Fini Jastrow <[email protected]>
@Finii Finii merged commit f28295b into master Jan 28, 2023
@Finii Finii deleted the bugfix/protect-stylistic-sets branch January 28, 2023 14:43
LNKLEO pushed a commit to LNKLEO/Nerd that referenced this pull request Nov 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Incorrect display of character 'k' for "FantasqueSansMono" when "ss01" font feature is on
1 participant