Feature: stable codepoints #778
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Please consider 159820b independently, that commit just improves code maintainability with no functional change. |
Finii
force-pushed
the
feature/stable-codepoints
branch
from
4919ec7
to
228f437
Compare
[why] In patch set definitions we have for the source ranges SymStart and SymEnd and for the destination we can specify SrcStart and SrcEnd The SrcEnd can be automatically generated. For SrcEnd values that differ from the autogenerated value (are lower) the script would crash, or (are higher) ignore them anyhow. There are two modes: 'exact = True' and 'exact = False'. The SrcStart and SrcEnd values are ignored if exact is True, because the glyphs are patched into the same codepoint where they originate. This also means that gaps in the symbols are preserved - all patched in glyphs have the same codepoint as they have in the source (symbol) font. When exact is False on the other hand, all (non empty) glyphs are filled into the codepoints that start at SrcStart. Gaps (empty glyphs) are ignored and thus are not present as gap in the patched font anymore (*). The to-be-filled-next codepoint in the patched font just increases by 1 on every filled symbol. See note for the reason. This also makes maintining the patch set easier as noone needs to 'calculate' a SrcEnd value anymore. [how] Use directly the start value and the counter instead of filling an array with a range, that is then indexed by the counter. Before this commit: list_of_patched_font_codepoints = list(range(SrcStart, SrcEnd + 1)) current_codepoint = list_of_patched_font_codepoints[loop_counter] After this commit: current_codepoint = SrcStart + loop_counter [note] Maybe related to code removed with c728079. I guess the code uses the list, because it has been believed that glyphs can only be indexed by strings containing a hex number. The array supposedly contained that strings. But in fact the fontforge python module docu is like this: font.__getitem__(key) If key is an integer, then returns the glyph at that encoding. If a string then returns the glyph with that name. May not be assigned to. Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why] The Font Logos and Octicons codepoints depend on the parallel existence of FontAwesome. I.e. Font Logos is shifted of Octicons or FontAwesome is also present in the patched font; Octicons is shifted if FontAwesome is present. This means that people, although using a Nerd Font, can expect the symbols in different locations. The reason is clear; people that just want one or some symbols and use a specifically patched font will be able to use the original symbol font codepoints. But I guess that these uses are nonexisting. Almost all will use 'complete' patched fonts and that is what we deliver and document. To make the documentation less complicated we should fix the code point ranges that a specific symbol set will be patched in at. [how] Just drop the associated functions and use a False constant instead. [note] The two possible places where Octicons / Font Logos ends up are there since they have been added back in 2015/6 (commits 9620d47, f933b5a). Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why] The patch set table has 'contradicting' or 'complicated' entries. [how] When we use exact patching a SrcStart will be ignored and shall be None to make that clear. The other two cases patch in only one glyph, make the entries more easy we could either make them 'exact' (reuse source codepoint) or specify a SrcStart. At the moment they rely on the (hidden?) rule that non-exact entries without SrcStart still reuse the SymStart... Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
Finii
force-pushed
the
feature/stable-codepoints
branch
from
228f437
to
501dd29
Compare
LNKLEO
pushed a commit
to LNKLEO/Nerd
that referenced
this pull request
Nov 24, 2023
…ints Feature: stable codepoints
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
The Font Logos and Octicons codepoints depend on the parallel existence
of FontAwesome. I.e. Font Logos is shifted of Octicons or FontAwesome is
also present in the patched font; Octicons is shifted if FontAwesome is
present.
This means that people, although using a Nerd Font, can expect the
symbols in different locations. The reason is clear; people that just
want one or some symbols and use a specifically patched font will be
able to use the original symbol font codepoints.
But I guess that these uses are nonexisting. Almost all will use
'complete' patched fonts and that is what we deliver and document.
To make the documentation less complicated we should fix the code point
ranges that a specific symbol set will be patched in at.
The two possible places where Octicons / Font Logos ends up are there
since they have been added back in 2015/6 (commits 9620d47, f933b5a).
Requirements / Checklist
What does this Pull Request (PR) do?
Make the codepoints of symbol sets stable, i.e. independent of other also incuded symbol sets.
It also drops
SrcEndfrom the patch table with 159820b. This improves the maintainability of the code and should be cherry-picked even if the complete PR is not merged.How should this be manually tested?
Generate
--completefont before and after this changes, fonts are identical (maybe use fontforge font compare, orcmp) (I did this).Any background context you can provide?
What are the relevant tickets (if any)?
Came up with #762 i.e. on https://github.com/ryanoasis/nerd-fonts/wiki/Glyph-Sets-and-Code-Points.
Screenshots (if appropriate or helpful)