font/freetype: Enable bitmap glyphs for non-color faces #3837
+66
−29
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
|
@mitchellh Since you were the author of #1428, can you elaborate on what you mean by "issues with cell metrics and rasterization"? |
The original version had issues converting properly and caused broken glyphs. This version tries to be as simple as possible in order to make it easy to understand. I haven't measured the performance but in practice this will only happen during the first render of the glyph after a face change (i.e. during launch or when changing font size).
This allows for crisp bitmap font rendering once again.
sin-ack
force-pushed
the
font-bitmap-glyphs
branch
from
4eb01b5 to
ea8fe9a
Compare
sin-ack
changed the title
mitchellh
reviewed
Dec 29, 2024
| // | ||
| // This must be enabled for color faces though because those are | ||
| // often colored bitmaps, which we support. | ||
| .no_bitmap = !self.face.hasColor(), |
There was a problem hiding this comment.
Just noting I'm going to consider the implications of this a bit further. I don't remember the full history here.
Now we can be certain that bitmap fonts stay crisp. :^)
This is an expected occurrence with bitmap glyphs and causes unnecessary spam when using the terminal with one.
|
Okay, I've been running locally with this pulled in for a couple days, and I can't remember why that original comment was there. I think it's likely that Qwer's work on metrics just resolved that for us (or some other work along the way, since that line is ancient). Merging. |
mitchellh
added a commit
that referenced
this pull request
Dec 30, 2024
macOS bitmap-only fonts are a poorly documented format, which are often distributed as `.dfont` or `.dfon` files. They use a 'bhed' table in place of the usual 'head', but the table format is byte-identical, so enabling the use of bitmap-only fonts only requires us to properly fetch this table while calculating metrics. ref: https://fontforge.org/docs/techref/bitmaponlysfnt.html Reverts #3550 for obvious reasons, and may close issue #2168 because this should now mean that bitmap fonts are properly supported under both font backends due to #3837 - unless `otb` fonts are still not properly supported under FreeType (they are not supported under CoreText because CoreText does not know how to handle them). I tested this change with the `.dfont` distribution of [Cozette](https://github.com/slavfox/Cozette) v1.25.2 and saw no visual issues.
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.
This allows for crisp bitmap font rendering once again. Tested with Terminus (TTF), and at both 1x and 2x DPI the font renders perfectly (click for 1:1 size):