Use actual glyph width, not the guessed spaceWidth, to determine the width of the space character in VLW fonts#159
Open
kirberich wants to merge 1 commit intom5stack:developfrom
Open
Conversation
…width of the space character
Collaborator
|
Hello, @kirberich We need to investigate how this pull request affects other existing fonts, but this will take time, so it's difficult to merge it immediately. |
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.
I was hitting an issue where
textWidthwould give me results that were slightly off from the actual width of a string drawn to the display when using a VLW font today. After a bunch of digging, it seems that the problem is thatdrawCharuses a special case for the space character where it usesthis->spaceWidth(which according to the comment in the code is just a guess), instead of the width of the space glyph, buttextWidthdoesn't use this special case.I'm not sure why this special case was there, and I'm not sure if this would break for some other fonts, but for my case at least the rendering looks correct, and textWidth and drawChar now agree.
Note: the test was done with a custom font, Bookerly 24pt, created using the M5 font converter
Also note: I pointed this at
developas that's what i'm using, let me know if that's wrong