New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Font rendering seems to glitch out at certain font sizes #46
Comments
issue spamming, would be posting the same issue over and over. These issue bug reports are great. Especially with the added screenshots and stuff. not really related to this issue, but @franko : maybe it would be good to make an issue template, where OS version, lite-xl version, user module (init.lua) are requirements. At least for bug reports (doesn't make sense for feature requests). |
Hmm, I already knew about this problem with Fira Sans and I was silent because the fix is a little bit complicated and time consuming. Actually it was there well before the 1.16 release. I guess now that it's been discovered I'll have to correct it, right? :-) Ok, so I will add this in the top of the list of the priorities! |
Haha, I actually encountered this in the past but it didn't really cause much of an issue for me then as I use a different size anyways. I figured that if I found it again, I may as well report it. |
Seen with some fonts like FiraSans, github issue: #46 The fix works essentially by looking to the bounds of each glyph to accurately ensure that there are no overlaps between the glyphs. The construction of the font atlas was changed to make some related improvements now that the bounds of each glyph are know. The main changes are: - no longer align glyph on the baseline but align them on their upper bounds. We ensure this way that very tall fonts do not leak in the upper part - terminate the row based on x bounds of the glyph to be more accurate - for each row keep trace of the y of the more larger along y of the glyph. The value is used to start a new row to be sure that the new now does not overlap with the previous one - sort glyphs by y size before drawing them. In this way the space utilization is better. The algorithm used is the very simple insert sort. It behaves like O(n^2) with the number of characters but should be ok since n is always small, typically below 128. - compute the optimal image width and height for the given font's atlas for optimal memory usage. As a bonus now the lite's code don't have to try and repeat to get a good image size
Seen with some fonts like FiraSans, github issue: #46 The fix works essentially by looking to the bounds of each glyph to accurately ensure that there are no overlaps between the glyphs. The construction of the font atlas was changed to make some related improvements now that the bounds of each glyph are know. The main changes are: - no longer align glyph on the baseline but align them on their upper bounds. We ensure this way that very tall fonts do not leak in the upper part - terminate the row based on x bounds of the glyph to be more accurate - for each row keep trace of the y of the more larger along y of the glyph. The value is used to start a new row to be sure that the new now does not overlap with the previous one - sort glyphs by y size before drawing them. In this way the space utilization is better. The algorithm used is the very simple insert sort. It behaves like O(n^2) with the number of characters but should be ok since n is always small, typically below 128. - compute the optimal image width and height for the given font's atlas for optimal memory usage. As a bonus now the lite's code don't have to try and repeat to get a good image size
Ok it is a relief to finally close this bug now that the new release is out. It was a long ride and more complicated than I believed but it was worth doing it. Now we can use the beautiful FiraSans font family :-) |
The font used is Fira Sans, at size
13 * SCALE
. At size12 * SCALE
it renders correctly.PS. Sorry for spamming your issues but 1.16 has been giving me some weird problems with my config :P
The text was updated successfully, but these errors were encountered: