Improve text rendering

[0xHexadecimal]

Is your feature request related to a problem? Please describe.
MTA has switched to a new text renderer, it has a couple of problems;

• Smaller texts look a lot worse, more blurry, this is especially noticeable for column text on gridlist.
  
• Spacing between letters are inconsistent and sometimes overlap a clear example of this is the 'c' in Recent tab where the e is overlapping the c and there is a noticeable space between letters.
  

Describe the solution you'd like
In the cases described above I'd like it to be at least comparable to the old text renderer.

Additional context
Letter overlap with the V & i in Video, A & u in Audio and A & d in Advanced.

[Pirulax]

I wonder if its an issue with the font we're using, rather than with freetype itself.
Since the font spacing is related to the font itself as well (well at least afaik).
Perhaps we should update the font we're using, or change it to a similar one?

[prnxdev]

Roboto is now very popular

[4O4]

@Pirulax it might be both. Font files may contain additional rendering hints. The renderer might ignore these hints or respect them, and even if it respects them the results might differ depending on the version of the renderer or configuration.

AFAIR There is also a licensing problem because cleartype hints / engine is Microsoft's thing and for example the freetype lib had to remove the chunk of code supporting this standard because of patents. This made some fonts look worse in quality and just way off in general, spacing was affected too. When I wanted to render fonts that looked subjectively good in any size, with nice antialiasing on one of my linux distros, I had to tinker a lot with configs and use freetype with unofficial patches that brought back the patented algorithm.

What version of freetype is MTA currently using and what defaults does it ship with?

Are the font files up to date or are they coming from the XP ages? And do they have proper hints embedded?

[4O4]

As I mentioned on Discord I will try to look into it. I already have some more input on the topic.

Apparently ClearType patents have expired and for example Archlinux started shipping freetype2 package with ClearType subpixel rendering enabled by default this year. This is a quite a good news.

MTA does not have ClearType hinting enabled however, because we have the default configuration from the upstream which only uses a fallback subpixel rendering method called Harmony (more info here: https://www.freetype.org/freetype2/docs/reference/ft2-lcd_rendering.html).

Enabling the ClearType by defining FT_CONFIG_OPTION_SUBPIXEL_RENDERING option might not be enough to make the fonts look good because there are more aspects of the whole freetype rendering chain options that affect the final look of the fonts. Finding the perfect combination of options might require some trial-and-error.

I will test different variants and will provide some screenshots of the end results. I'm going to start with the patches which are applied by default in the Arch package (https://github.com/archlinux/svntogit-packages/tree/packages/freetype2/trunk), then I will try to switch to older TrueType bytecode interpreter version (v38 Infinality) as it usually looks better from my experience. I will also test "ultimate5" LCD filter as seen in this patch: https://aur.archlinux.org/cgit/aur.git/tree/like-ultimate5.patch?h=freetype2-ultimate5 which I'm personally using for best results on my linux desktops.

More on bytecode interpreters here: https://www.freetype.org/freetype2/docs/subpixel-hinting.html
If someone wants to learn more about fonts rendering internals, problems and solutions, Arch wiki has a nice summarized knowledge base and is a great starting point: https://wiki.archlinux.org/index.php/font_configuration (some parts might be distro-specific, but concepts are well described and apply everywhere).
And here's interesting article which might be a bit controversial, but there's a a good chunk of knowledge there. It explains some concepts and shows font rendering differences between OSes or techniques: https://pandasauce.org/post/linux-fonts/

[Pirulax]

Man, you're an encyclopedia of font rendering.

[4O4]

Man, you're an encyclopedia of font rendering.

😆 Sadly I had to dig into it in the past after freetype updates suddenly made my fonts look ugly in the desktop UI. I really wish I never had to know about any of that while being just an end-user 😄

[Pirulax]

Man I feel your pain, trust me. But any knowledge is valuable, so

[4O4]

Sad news. CEGUI does not seem to support subpixel rendering. In order to use subpixel rendering, render mode must be FT_RENDER_MODE_LCD (or LCD_V but that would be for some unusual screens only) but CEGUI uses the default FT_RENDER_MODE_NORMAL when loading glyphs and all further code makes assumptions based on that render mode. Glyphs rendered with subpixels are 3 times wider than standard ones, so some portion of CEGUI font rendering code would have to be adjusted to support these wider texture buffers and scale them properly for final render.

Newer version doesn't seem to support it either, I don't see any indication of proper subpixel rendering in the 0.8.7 cegui code. It's all "normal mode rendering" with basic grayscale antialiasing and I guess this always worked good enough with older versions of freetype to not bother with subpixels.