Just a quick point - after testing your included images, the font is not crooked - it is perfectly horizontal. The issue is that the hinting for the font at small sizes is terrible, or it's being rendered poorly without using the font hinting.

I wanted to post a quick follow-up that does confirm that the glyphs for English/Latin characters are extremely poor in the new i18n font for non-antialiased use. Here's a 300% zoom comparison of 10pt text with each font with no anti-aliasing applied.

I can do some digging tomorrow with FontForge to see if perhaps we can copy the latin characters from the old font and use them here. I can also confirm that even with anti-aliasing turned on, the glyph quality from the new I18n font is still worse than the prior one.

I have created a fixed font that contains all the correct per-character hinting and also fixes several glyph naming issues with the new "I18n" font. I'm a little unclear on how to submit for approval though - is it just a pull request?

@Nikhil Shringarpurey (Nikhil.Net) - I have created a fixed font that contains all the correct per-character hinting and also fixes several glyph naming issues with the new "I18n" font. I'm a little unclear on how to submit for approval though - is it just a pull request?

That would be wonderful

I'm a little unclear on how to submit for approval though

Normally changes are submitted as part of our "submit code" process, but that does not accept binary changes without a patch so doesn't work well for things like a font change.

Can you explain explain what you changed with the font exactly? And then zip it up and drag that zip into a comment on this thread.

TrueType fonts can contain rendering instructions called Hinting. These instructions allow the font to be grid-fit to screen pixels so that it renders properly at small sizes. Some background can be found here: Microsoft Typography - Hinting.

The new version of the Blender international font (bmonofont-i18n.ttf) did not have hinting information for any English characters, nor several accented latin characters. In addition, several glyph names were incorrect such as "fractionslash" which led to inconsistency in symbols such as fractions.

I have re-added hinting information present in the old font (bmonofont.ttf) into this new font, and updated broken/wrong glyph names and compound characters. There are still several characters without hinting applied, but auto-hinting is generally not great and manually hinting these will take significant time. I'll try to continue with this work, but in the interim, this will fix the horrible quality of the "i18n" font when small sizes are used. I also bumped the font internal version number from 2.33 to 2.331.

Attachments: ZIP of new, fixed font, and image showing fixed vs previous font.

@Nikhil Shringarpurey (Nikhil.Net) - manually hinting these will take significant time

Is this a process that can be described and therefore done by more people? Or would you prefer to continue as you are doing? Frankly, it sounds like you know what you are doing. LOL.

Are you working in FontForge?

We might need to document how work on the font is done in that program and, importantly, what options to select when exporting. We have also had previously some differences in hinting between platforms depending on those options. So we'll also have to check your changes on all platforms. My worry, of course, is that some other change will be made in the future and then this current work of yours will be lost because of an export option set incorrectly or some other issue.

In T75898#914404, @Harley Acheson (harley) wrote:

We might need to document how work on the font is done in that program and, importantly, what options to select when exporting. We have also had previously some differences in hinting between platforms depending on those options. So we'll also have to check your changes on all platforms. My worry, of course, is that some other change will be made in the future and then this current work of yours will be lost because of an export option set incorrectly or some other issue.

I'm far from a font expert, but I am reasonably comfortable with FontForge. The key thing to remember is that font hinting is used in 2 ways: first, the hinting instructions need to be embedded into the font. This was what I fixed - they were just straight up missing in the new font. Second, whatever text rendering engine has to apply those instructions.

The latter is what you are referring to about font issues across platforms, but the core font file itself was just wrong in this case, so this fix would be applied on any text rendering engine that followed TrueType font standards. Put differently, the changes I made are platform-agnostic. I did a basic test across Windows and Ubuntu and did not see issues, but can't test Mac, as I don't use Apple products.

In T75898#914404, @Harley Acheson (harley) wrote:

Is this a process that can be described and therefore done by more people? Or would you prefer to continue as you are doing? Frankly, it sounds like you know what you are doing. LOL.

Font hinting is very much a niche art and is time consuming, so I have no desire to be the sole person doing it, that's for sure! :) Basically it involves taking each glpyh (each character) and making sure it aligns to a pixel grid well. The link in my previous comment has much more detail on what's involved and the process. It would be learnable by most savvy folks within a day or two. But doing it well really is an art form.

As to documenting what I did - I simply copied the working and correct data from the prior version of the font to the specific sets of characters that were referenced in my change note. If you'd like me to put some more detail into a document, I'd be glad to do it, but it may take me a little time to get to it and do it right.

@Nikhil Shringarpurey (Nikhil.Net) - This was what I fixed - they were just straight up missing in the new font.

Yes, my worry is in not knowing how those were removed in order to ensure that it does not happen again with subsequent changes.

whatever text rendering engine has to apply those instructions.

We are using FreeType on all platforms for that. Although, to be fair, we are not allowing it to do that very well. With any options that turn on subpixel hinting we are supposed to be using floats for widths and advances, but we are using integers for everything. That will have to be addressed one day, especially if ever allow cleartype-like hinting as an option (now that Microsoft's related filtering patent has expired).

Put differently, the changes I made are platform-agnostic.**

I believe you. I'm probably miss-remembering earlier issues.

Basically it involves taking each glpyh (each character) and making sure it aligns to a pixel grid well...
...I simply copied the working and correct data from the prior version of the font to the specific sets of characters...

Thanks for your help with this. I'm unclear on whether you are hand-aligning each glyph (first sentence) or have copied something from the old version to the new one (second sentence). I have seen the former but not sure of the latter. Sorry for the confusion. Again, mostly wanting enough information to ensure we don't get into this situation again or have to redo your work here because of some error or omission.

In T75898#914469, @Harley Acheson (harley) wrote:

@Nikhil Shringarpurey (Nikhil.Net) - This was what I fixed - they were just straight up missing in the new font.

Yes, my worry is in not knowing how those were removed in order to ensure that it does not happen again with subsequent changes.

Understood - my guess is someone was using a tool like FontForge and did not have the preferences set to copy metadata when copying characters. Total guess though.

In T75898#914469, @Harley Acheson (harley) wrote:

Thanks for your help with this. I'm unclear on whether you are hand-aligning each glyph (first sentence) or have copied something from the old version to the new one (second sentence). I have seen the former but not sure of the latter. Sorry for the confusion. Again, mostly wanting enough information to ensure we don't get into this situation again or have to redo your work here because of some error or omission.

For this initial pass, I simply copied the known-good and working hinting instructions from the previous non-i18n version of the font. However, for the missing characters, I'll have to grid-fit them manually which will definitely take some time. With my level of skill, I'd estimate 20-30 minutes per glyph which may vary due to complexity. Hinting CJK languages for example, is well outside my comfort zone.

@Nikhil Shringarpurey (Nikhil.Net) - my guess is someone was using a tool like FontForge and did not have the preferences set to copy metadata when copying characters. Total guess though.

Good guess. I just checked that setting on my FontForge and it is indeed off. So guessing that is off by default.

For this initial pass, I simply copied the known-good and working hinting instructions from the previous non-i18n version of the font.

Ah, so just recopying those but with that CopyMetaData Preference turned on. Thanks!

I'll have to grid-fit them manually which will definitely take some time.

Is it really necessary to grid-fit the glyphs like that? I mean hinting should be telling the layout system which parts of the glyph that can/should be moved to align to the grid used at the time of output. So when loading a glpyh that is unhinted, isn't it enough to just select Hints/AutoHint within FontForge and it will mark (usually okay) the parts that should be aligned? And then alter that if it guesses wrong? Or am I misunderstanding this process?

I did some digging and found that rBdc3f073d1c52 already broke the hinting instructions. It doesn't matter if anti-aliasing is enabled or not, but without it, it's more noticeable.

It's also not using the FreeType auto-hinter, since if I force-enable that, I get yet again different results. Better looking but still not as good as the old (likely native) font hinter. It seems like currently no hinting is used at all unless slight hinting is enabled (in which case it may just be using the auto-hinter if the font doesn't support vertical only hinting). So I guess the hinting information is just missing on some glyphs, but the font still tells freetype that it can do hinting (or is it the driver that tells freetype that?).

So really, I think all we should do is bring back the old hinting instructions. Nobody needs to spend huge amount of time on getting more glyphs to hint better. If that really is an issue I'd rather switch to auto-hinting for non-latin fonts.

Also, are you sure you're 2.83 is fine @vas (Alumx) and @Nikhil Shringarpurey (Nikhil.Net)? Changes here were done in 2.83, no further changes were done here since the 2.90 branch exists.

Yes, there could be some testing confusion here...

Prior to 2.83 you would click on "Translation" in Preferences and at that moment the smaller (bfont.ttf) font was swapped out for the larger (droidsans.ttf) font. There was complaint at that time that the two fonts had subtle differences. You would see a small number of the glyphs shift slightly. It gave the feeling that the smaller font was a bit tighter and the larger a bit looser.

I needed to correct for that in order to move toward using the international fonts always. And that was done for 2.83. At that point switching between the two fonts would show no noticeable differences with default settings. But I did not also look at any further differences with different hint options or without antialiasing.

For 2.90 we have simply removed the "Translations" button and we are using the larger international font always. So in comparing these we must be careful in identifying the fonts we are testing.

The following zip contains the two current (large international) fonts but with lower latin set copied again from the old small versions. But this time being careful to turn on CopyMetaData in the Preferences of FontForge to ensure that the hint information is also copied over. I honestly do not know if this fixes the issue since I'm not sure of a good testing strategy.

But with "Full" hinting turned on, it does give a result that I would expect, with more vertical parts lining up with pixel boundaries.

In T75898#914483, @Harley Acheson (harley) wrote:

Is it really necessary to grid-fit the glyphs like that? I mean hinting should be telling the layout system which parts of the glyph that can/should be moved to align to the grid used at the time of output. So when loading a glpyh that is unhinted, isn't it enough to just select Hints/AutoHint within FontForge and it will mark (usually okay) the parts that should be aligned? And then alter that if it guesses wrong? Or am I misunderstanding this process?

You're correct that you can use AutoHint as a starting point and it does OK, but it usually does not do a great job. Manual is best if you really want to be 100% optimal, but it really is a case of just deciding how much time investment is worth it.

@Julian Eisel (Severin) Yeah it was 2.83, but I just notice that the font hinting changed from Alpha to Beta

If I start with the version of the file in 2.82 and the change only the glyphs needing changing since I do get something that looks a bit better with antialiasing off. Following shows the current font on the left, and the new one I just made on right:

There is definitely some subtle differences between them. Here is the file if you want to test it:

Hi,
I fired up Blender 2.83 beta to test it and noticed the text antialising issue.

With droidsans.zip that @Harley Acheson (harley) posted above everything is fine, but i needed to manually find this discussion and install it by myself.

I wonder if 2.83 official release will contain this fixed font for aliased text, right now it's not included it seems.

I think we can commit the fixed fonts to the 2.83 branch. After all this appears to be caused by an accidental meta-data loss and it is a 2.83 regression. Also, IIRC font hinting is incorrect now even with anti-aliasing.

@Brecht Van Lommel (brecht) would you be fine with that? I didn't actually test the updated fonts yet but will carefully before committing.

If this affects just the case without anti-aliasing it's fine with me to put this in 2.83.

If it affects anti-aliasing, then I want to see what that difference looks like, since all the screenshots here seem to be without anti-aliasing.

It would be nice to update the font with the one linked above, but I remain disappointed that I could not determine how the difference actually occurred.

The FontForge setting for copying meta data when copying characters seemed like it. But turning that on and then copying glyphs from the old font to new did not fix them. The “fixed” font is starting fresh with an older font and copying over only the deliberate changes since: some new symbols we are using for menu shortcuts, status bar, some fixes for some Cyrillic, etc.

In T75898#927056, @Brecht Van Lommel (brecht) wrote:

If this affects just the case without anti-aliasing it's fine with me to put this in 2.83.

If it affects anti-aliasing, then I want to see what that difference looks like, since all the screenshots here seem to be without anti-aliasing.

The modified bmonofont from Nikhil also restores (full) font hinting with anti-aliasing enabled - this has been broken in recent builds. Note: there's a slight scaling difference in the Python console compared to 2.80, but this might be unrelated to the font:

1. Hinting broken
2. Hinting works
3. Hinting works (but marginally smaller Python text)
4. Slight scale adjustment, 4 matches 2.

Also, the modified droidsans posted here on 21st April (5704060 bytes) seems to fix hinting elsewhere in the UI and matches the previous releases for each of the hinting modes as far as I can see:

So it looks as though the fonts used from earlier this year were scrubbed of their hinting data.

Edit: Just to add, the screenshots above are with the 2.83 beta but the incorrect rendering is consistent with 2.90 which this report is about.

So, just to be as clear as possible. The following zip contains two font files:

• The fixed-pitch version is "bmonofont-i18n.ttf" and is the one fixed by @Nikhil Shringarpurey (Nikhil.Net) and supplied on April 20th.
• The proportional version is droidsans.ttf and is the one I recreated from a prior good version, supplied on April 21st and is 5,704,060 bytes.

I have made no further changes to them, simply stuck these two in a single zip file. But I did check them to ensure that they do include the symbol glyphs needed and the fixes to some Cyrillic characters.

@Paul R (intracube) has illustrated that these corrected font are an improvement, but I would appreciate anyone taking a look and confirming that these versions should go into master.

The fonts look fine testing here.

In T75898#930824, @Harley Acheson (harley) wrote:

So, just to be as clear as possible. The following zip contains two font files:

• The fixed-pitch version is "bmonofont-i18n.ttf" and is the one fixed by @Nikhil Shringarpurey (Nikhil.Net) and supplied on April 20th.
• The proportional version is droidsans.ttf and is the one I recreated from a prior good version, supplied on April 21st and is 5,704,060 bytes.

fonts.zip5 MBDownload

Yep, those fonts are working fine here in 2.83 Beta and 2.90 - rendering now matches 2.82a and previous versions.