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

font-patcher: Allow glyphs with altuni for exactEncoding #793

Merged
merged 1 commit into from
Sep 7, 2022

Conversation

Finii
Copy link
Collaborator

@Finii Finii commented Feb 22, 2022

Description

[why]
Some symbol fonts might come with glyphs that have multiple codepoints.

When we want to patch them with 'Exact': true (i.e. at their 'original'
codepoints) we want to patch them into the codepoint that has been used
in the selection process. That means between SymStart and SymEnd.

But this is not the case. We patch them in into their 'main' codepoint,
which can be outside the expected range of points.

This came up when patching with FontAwesome V6. It has for example these
glyphs:

Glyph 'music' has a main codepoint 0x1F3B5, but it is present in the
font also on codepoint 0xF001.

Glyph 'heard' has a main codepoint 0x1F9E1, but it is present in the
font also on codepoints 0x2665, 0x2764, 0xF004, 0xF08A, 0x1F499, ...

When doing a 'Exact': true patch (i.e. exactEncoding = true) the
glyphs is patched into the target font at its (the glyph's) main
codepoint, regardless of our patch-codepoint-range.

[how]
We examine all codepoints that a glyph occupies in the symbol font. From
all these codepoints we take the nearest to the last glyph be patched
in. Nearest means from the possible codepoints the lowest that come
after the previous used codepoint.

For example the 'heard':

Last patched in codepoint was 0xF003.
Main codepoint: 0x1F9E1
Alternate codepoints: 0x2665, 0x2764, 0xF004, 0xF08A, 0x1F499, ...
-=> 0xF004

Later in the patching process we might encounter the same glyph again,
but this time the previous codepoint was 0xF089, so we need to take
0xF08A.

Requirements / Checklist

What does this Pull Request (PR) do?

Put symbol glyphs that have additional unicodes (altuni) into the expected (i.e. next possible in the range we work on) codepoint slot.

From Fontforge Python Docu:

glyph.altuni

Returns additional unicode code points for this glyph. For a primary code point, see glyph.unicode .

How should this be manually tested?

Any background context you can provide?

What are the relevant tickets (if any)?

#727 (reply in thread)

Screenshots (if appropriate or helpful)

@Finii Finii mentioned this pull request Feb 22, 2022
@Finii Finii force-pushed the bugfix/symbolfont-with-altuni branch from 4db8813 to 7901bf7 Compare February 22, 2022 12:02
@Finii
Copy link
Collaborator Author

Finii commented Feb 22, 2022

The code had a bug when the primary codepoint is low (i.e. lower than the current slot we work on).
That is not the case for any FontAwesome V6 glyph, but it would be possible for some future symbol font.
Force push

@Finii Finii force-pushed the bugfix/symbolfont-with-altuni branch from 7901bf7 to eaedfc8 Compare February 22, 2022 13:35
@Finii
Copy link
Collaborator Author

Finii commented Feb 22, 2022

*cough*

                     possible_codes += [ v for v, s, r in sym_glyph.altuni if v > currentSourceFontGlyph ]
-                currentSourceFontGlyph = sorted(possible_codes)[0]
+                currentSourceFontGlyph = min(possible_codes)
             else:

force push

@Finii Finii added the ⚠ bug label Feb 22, 2022
@Finii Finii added Bug fix and removed ⚠ bug labels Mar 3, 2022
@Finii Finii added this to the v2.3.0 milestone Aug 22, 2022
[why]
Some symbol fonts might come with glyphs that have multiple codepoints.

When we want to patch them with `'Exact': true` (i.e. at their 'original'
codepoints) we want to patch them into the codepoint that has been used
in the selection process. That means between SymStart and SymEnd.

But this is not the case. We patch them in into their 'main' codepoint,
which can be outside the expected range of points.

This came up when patching with FontAwesome V6. It has for example these
glyphs:

Glyph 'music' has a main codepoint 0x1F3B5, but it is present in the
font also on codepoint 0xF001.

Glyph 'heard' has a main codepoint 0x1F9E1, but it is present in the
font also on codepoints 0x2665, 0x2764, 0xF004, 0xF08A, 0x1F499, ...

When doing a `'Exact': true` patch (i.e. exactEncoding = true) the
glyphs is patched into the target font at its (the glyph's) main
codepoint, regardless of our patch-codepoint-range.

[how]
We examine all codepoints that a glyph occupies in the symbol font. From
all these codepoints we take the nearest to the last glyph be patched
in. Nearest means from the possible codepoints the lowest that come
after the previous used codepoint.

For example the 'heard':

Last patched in codepoint was 0xF003.
Main codepoint: 0x1F9E1
Alternate codepoints: 0x2665, 0x2764, 0xF004, 0xF08A, 0x1F499, ...
-=> 0xF004

Later in the patching process we might encounter the same glyph again,
but this time the previous codepoint was 0xF089, so we need to take
0xF08A.

Signed-off-by: Fini Jastrow <[email protected]>
@Finii Finii force-pushed the bugfix/symbolfont-with-altuni branch from eaedfc8 to d8727b9 Compare September 7, 2022 03:31
@Finii Finii merged commit 0e45cd6 into master Sep 7, 2022
@Finii Finii deleted the bugfix/symbolfont-with-altuni branch September 7, 2022 03:42
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.

1 participant