The UI text font in 2.90 with anti-aliasing off looks crooked and unreadable on smaller scales #75898

New Issue

Vas · 2020-04-19T16:17:54+02:00

Vas commented

2020-04-19 16:17:54 +02:00

System Information
Operating system: Windows-10-10.0.17763-SP0 64 Bits
Graphics card: GeForce GTX 1050 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 442.19

Blender Version
Broken: version: 2.90 (sub 0), branch: master, commit date: 2020-04-18 16:48, hash: 1f1520a045
Worked: 2.83.11

Short description of error
I noticed that interface font in 2.90 looks really weird with anti-alias off
It looks specially bad if its scaled down (also ignore the black box on third image, I accidentally cut it out for the next example)

Exact steps for others to reproduce the error
[Please describe the exact steps needed to reproduce the issue]
[Based on the default startup or an attached .blend file (as simple as possible)]

Default blender scene
Go to user pereferences > Interface >Text Rendering > Anti-Aliasing = off
Try changing resolution scale number / zooming in or out with Numpad +/- to notice text artifacts

**System Information** Operating system: Windows-10-10.0.17763-SP0 64 Bits Graphics card: GeForce GTX 1050 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 442.19 **Blender Version** Broken: version: 2.90 (sub 0), branch: master, commit date: 2020-04-18 16:48, hash: `1f1520a045` Worked: 2.83.11 **Short description of error** I noticed that interface font in 2.90 looks really weird with anti-alias off It looks specially bad if its scaled down (also ignore the black box on third image, I accidentally cut it out for the next example) ![image.png](https://archive.blender.org/developer/F8483553/image.png) ![image.png](https://archive.blender.org/developer/F8483555/image.png) ![image.png](https://archive.blender.org/developer/F8483558/image.png) ![image.png](https://archive.blender.org/developer/F8483560/image.png) **Exact steps for others to reproduce the error** [Please describe the exact steps needed to reproduce the issue] [Based on the default startup or an attached .blend file (as simple as possible)] - Default blender scene - Go to user pereferences > Interface >Text Rendering > Anti-Aliasing = off - Try changing resolution scale number / zooming in or out with Numpad +/- to notice text artifacts

Vas commented

2020-04-19 16:17:54 +02:00

Added subscriber: @Alumx

blender-admin commented

2020-04-19 16:17:54 +02:00

#77772 was marked as duplicate of this issue

Nikhil Shringarpurey commented

2020-04-20 05:57:02 +02:00

Added subscriber: @Nikhil.Net

Nikhil Shringarpurey commented

2020-04-20 05:57:02 +02:00

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.

Nikhil Shringarpurey commented

2020-04-20 06:27:27 +02:00

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 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. ![Blender_font_comparison.png](https://archive.blender.org/developer/F8484517/Blender_font_comparison.png)

Nikhil Shringarpurey commented

2020-04-20 17:46:13 +02:00

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?

Richard Antalik commented

2020-04-20 17:56:51 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Harley Acheson commented

2020-04-20 18:11:37 +02:00

Added subscriber: @Harley

Harley Acheson commented

2020-04-20 18:11:37 +02:00

@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.

> @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.

Nikhil Shringarpurey commented

2020-04-20 19:29:17 +02:00

This comment was removed by @Nikhil.Net

*This comment was removed by @Nikhil.Net*

Nikhil Shringarpurey commented

2020-04-20 19:46:49 +02:00

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.
Blender Fonts Issue #75898.zip

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](https://docs.microsoft.com/en-us/typography/truetype/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. [Blender Fonts Issue #75898.zip](https://archive.blender.org/developer/F8485533/Blender_Fonts_Issue_T75898.zip) ![Blender Hinting Fix.png](https://archive.blender.org/developer/F8485532/Blender_Hinting_Fix.png)

Harley Acheson commented

2020-04-20 20:54:34 +02:00

@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.

> @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.

Nikhil Shringarpurey commented

2020-04-20 22:50:11 +02:00

In #75898#914404, @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 #75898#914404, @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.

> In #75898#914404, @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 #75898#914404, @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.

Harley Acheson commented

2020-04-20 23:27:58 +02:00

@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.

> @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.

Nikhil Shringarpurey commented

2020-04-21 01:48:34 +02:00

In #75898#914469, @Harley wrote:

@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 #75898#914469, @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.

> In #75898#914469, @Harley wrote: >> @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 #75898#914469, @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.

Harley Acheson commented

2020-04-21 02:26:26 +02:00

@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?

> @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?

Julian Eisel commented

2020-04-21 19:01:41 +02:00

Added subscriber: @JulianEisel

Julian Eisel commented

2020-04-21 19:01:41 +02:00

I did some digging and found that dc3f073d1c 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.

I did some digging and found that dc3f073d1c 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.

Julian Eisel commented

2020-04-21 19:04:07 +02:00

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

Harley Acheson commented

2020-04-21 19:59:19 +02:00

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.

fonts.zip

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

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. [fonts.zip](https://archive.blender.org/developer/F8487754/fonts.zip) But with "Full" hinting turned on, it does give a result that I would expect, with more vertical parts lining up with pixel boundaries. ![FullHinting.png](https://archive.blender.org/developer/F8487760/FullHinting.png)

Nikhil Shringarpurey commented

2020-04-21 21:59:10 +02:00

In #75898#914483, @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.

> In #75898#914483, @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.

Vas commented

2020-04-22 00:10:42 +02:00

@JulianEisel Yeah it was 2.83, but I just notice that the font hinting changed from Alpha to Beta

@JulianEisel Yeah it was 2.83, but I just notice that the font hinting changed from Alpha to Beta ![image.png](https://archive.blender.org/developer/F8488161/image.png)

Harley Acheson commented

2020-04-22 01:03:35 +02:00

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:

droidsans.zip

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: ![Hinting.png](https://archive.blender.org/developer/F8488288/Hinting.png) There is definitely some subtle differences between them. Here is the file if you want to test it: [droidsans.zip](https://archive.blender.org/developer/F8488290/droidsans.zip)

Marco G commented

2020-05-08 11:34:55 +02:00

Added subscriber: @marcog

Marco G commented

2020-05-08 11:34:55 +02:00

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

With droidsans.zip that @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.

Hi, I fired up Blender 2.83 beta to test it and noticed the text antialising issue. With droidsans.zip that @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.

Julian Eisel commented

2020-05-08 13:19:43 +02:00

Added subscriber: @brecht

Julian Eisel commented

2020-05-08 13:19:43 +02:00

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 would you be fine with that? I didn't actually test the updated fonts yet but will carefully before committing.

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 would you be fine with that? I didn't actually test the updated fonts yet but will carefully before committing.

Brecht Van Lommel commented

2020-05-08 15:42:34 +02:00

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.

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.

Harley Acheson commented

2020-05-08 15:43:20 +02:00

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.

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.

Paul R commented

2020-05-09 20:32:41 +02:00

Added subscriber: @intracube

Paul R commented

2020-05-09 20:32:41 +02:00

In #75898#927056, @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:

Hinting broken
Hinting works
Hinting works (but marginally smaller Python text)
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:

Examples at UI scale of 1.10 included, as the hinting issue is clearer at that size.

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.

> In #75898#927056, @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: ![bmonofont_font_comparison_2.83beta_vs_2.80.png](https://archive.blender.org/developer/F8523518/bmonofont_font_comparison_2.83beta_vs_2.80.png) 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: ![droidsans_font_comparison_2.80_vs_2.83beta_v2b.png](https://archive.blender.org/developer/F8523532/droidsans_font_comparison_2.80_vs_2.83beta_v2b.png) Examples at UI scale of 1.10 included, as the hinting issue is clearer at that size. 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.

Harley Acheson commented

2020-05-13 17:42:15 +02:00

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.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.

@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.

fonts.zip

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.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. @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. [fonts.zip](https://archive.blender.org/developer/F8533108/fonts.zip)

Brecht Van Lommel commented

2020-05-13 18:14:34 +02:00

The fonts look fine testing here.

Paul R commented

2020-05-13 18:35:27 +02:00

In #75898#930824, @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.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.zip

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

> In #75898#930824, @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.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.zip](https://archive.blender.org/developer/F8533108/fonts.zip) Yep, those fonts are working fine here in 2.83 Beta and 2.90 - rendering now matches 2.82a and previous versions.

Julian Eisel commented

2020-05-14 20:19:57 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Julian Eisel closed this issue

2020-05-14 20:19:57 +02:00

Julian Eisel self-assigned this 2020-05-14 20:19:57 +02:00

Julian Eisel commented

2020-05-14 20:19:57 +02:00

Alright, tested the fonts again here, also on Retina. Everything seemed fine, so I committed 3ced9c1c72 and 2efe77ca51.
Thanks all for the help, you guys were really helpful!

Alright, tested the fonts again here, also on Retina. Everything seemed fine, so I committed 3ced9c1c72 and 2efe77ca51. Thanks all for the help, you guys were really helpful!

Robert Guetzkow commented

2020-06-11 18:52:43 +02:00

Added subscribers: @Funtomas78, @rjg

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

The UI text font in 2.90 with anti-aliasing off looks crooked and unreadable on smaller scales #75898