Repository navigation
fix(cpfont): write maxInkTop into the style entry - #2
Closed
martinqnguyen wants to merge 1 commit into
Closed
martinqnguyen wants to merge 1 commit into
martinqnguyen wants to merge 1 commit into
Conversation
The style entry has 4 reserved bytes after dataOffset. Fill the first 2 with the style's tallest ink above the baseline, as a little-endian int16. CrossPoint never reads those bytes, so its behaviour does not change. A firmware that places the first line of a page from the tallest ink can now use the real value instead of a guessed inset, which matters for faces whose accents rise above the nominal ascender. Files written before this carry 0 there, which such a firmware reads as "unknown", so old files keep working. The entry stays 32 bytes and the format version stays 4.
Owner
|
Thank you for this. Your commit is on master as f880e05, with your authorship. I put the field behind a setting that is off by default, in 89e27e6. CrossPoint does not read these bytes, and writing them changes the content hash of every font built. With the setting off, the bytes stay 0 as before. To turn it on, add Your test now checks both states. The build stamp has a test for the setting too. |
Contributor
Author
|
Thanks. Off by default makes sense; we will set |
This file contains hidden or 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
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.
Each style entry in a
.cpfonthas 4 reserved bytes afterdataOffset, and they are always 0 today. This fills the first 2 with the style's tallest ink above the baseline (int16, from the glyph tops the converter already has). A firmware that places a page's first line from the real ink height can then stop guessing an inset, so tall marks such as Vietnamese double accents are not clipped. tenor/cross, a CrossPoint fork, reads this field. The entry stays 32 bytes and the version stays 4, and a 0 still means "unknown" for files built earlier.CrossPoint upstream never reads those bytes (
SdCardFont::loadstops atdataOffset), so its behaviour does not change; the font's content hash differs only because it is computed over the file bytes.A new test builds a two-style font from a synthetic face and checks each entry's field against the largest glyph top read back from the file. It fails without the fix (0 against 18) and passes with it, and the full suite passes. I also built Geist at size 12 with
reading, vietnamesecoverage and got 27 for Regular and 28 for Bold, matching the tallest glyph in each style.