Change implementation of desiccated font files
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
Research direction
Start by tracing EncodingConfig into the encoder and reviewing how base entries, OutgoingEdges, and patch map entries currently interact. Done means desiccation is controlled separately from the presence of base entries, while ordered patches can build a full initial file before locale-specific patches are applied.
Written by the indexing model from the issue text.
Description
The current approach to EncodingConfig, and therefore the encoder, signals a desiccated font file by way of an encoding with no "base" entries. While this makes some sense in terms of simplicity but I think it would be better to separate the two concepts.
One minor aspect of this is that a desiccated file should lack much more than shaping information; it doesn't need a name table or an hmtx table or even rump glyf or CFF tables. However, absent other considerations it would be fine to hinge whether to desiccate on the lack of base entries. One could always throw .notdef in to make the difference.
The more compelling reason to separate the two is because the idea of base entries is still useful even when you intend to desiccate. Among other things the base is where you might throw entries that pose analysis issues and having to juggle them into each of the initial table-keyed patches, and then juggle them back out for subsequent patches, would be a pain. (It breaks the OutgoingEdges model, for example.)
In addition, we've extended the specification to allow multiple patches to be applied in order when a single patch map entry is selected. So we now have a cleaner mechanism for desiccation: Make a single patch that, when applied to the desiccated file produces a "full" initial file (with rump glyf/CFF) and then add the locale- (or whatever) specific patches on top of that. This makes it quite straightforward to separate the two ideas at the encoding level.
- Dominant language
- C++
- Stars
- 13
- Forks
- 9
- Avg merge
- 2d 23h
- Merged PRs (30d)
- 7
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from w3c/ift-encoder
-
Difficulty 5/5 Over a week Newbie friendliness 30/100
w3c/ift-encoder#271 ·
-
Consider adding a config setting that exempts high frequency codepoints from minimum group sizesOpen
Difficulty 5/5 Over a week Newbie friendliness 42/100
w3c/ift-encoder#269 ·
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
w3c/ift-encoder#262 ·
-
latest bazel does not workMay be free again @garretrieger claimed this 192 days ago, and no pull request is open. Open
w3c/ift-encoder#202 · 1 comment · 1 assignee ·
-
Difficulty 4/5 3-5 days Newbie friendliness 38/100
w3c/ift-encoder#108 · 1 comment ·
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 1 day
-
enhancement question
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
DarkStarSystems/pcons#224 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
LizardByte/Sunshine#5953 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
(S1 - Need confirmation)
Difficulty 2/5 1-3 hours Newbie friendliness 63/100
CleverRaven/Cataclysm-DDA#89133 ·
Maintainers usually reply within 1 day