New point release 1.9.5p9

[pjbroad]

I'd like to do another 1.9.5 point release. I've check and its OK with Radu. This will be the first since the TTF change and perhaps the last before the 1.9.6 release. Does anyone have changes they are about to make that are small enough to include? I know that @gvissers may be working more on sourcing TTFs from the data dir. I'm on a promise to try a patch for the sound files from @gamil-zirak. I think we have all the mac build changes done by @bendoughty. I'm not sure of the if the server list changes from @brunoramoslu are ready. I'd tag @feeltheburn too in case you have anything for a point release. I'd like to do this in the next few days. I'll happily do the minor version number changes and tagging etc. Any objections or comments?

[bendoughty]

Good to go here. There's still a small visual issue with the console input bar in highDPI mode, but otherwise I am ready to build the Mac client as soon as we have the final p9 data pack and the version number has been bumped.

Assuming we will have the TTF data dir support in time for this release, has any thought been given to which fonts will be distributed with the client data pack? How about the default settings for new installs?

[gvissers]

I know that @gvissers may be working more on sourcing TTFs from the data dir.

Uhm, yeah, I did not get round to doing that, yet. I'll try to get a patch in to remove duplicate fonts ASAP.

[gvissers]

Ok, patch comiited. Lightly tested, some more rigorous testing might be a good idea.

[feeltheburn]

All my stuff is for 1.9.6 so nothing here.

[gamil-zirak]

No objections here.

[pjbroad]

Ok, patch comiited. Lightly tested, some more rigorous testing might be a good idea.

Looks to work. It's a shame that existing font setting are lost but it not hard to reset them.

Good to go here. There's still a small visual issue with the console input bar in highDPI mode, but otherwise I am ready to build the Mac client as soon as we have the final p9 data pack and the version number has been bumped.

Oh yes, I've still to fix the input bar scaling. Should be done now.

Assuming we will have the TTF data dir support in time for this release, has any thought been given to which fonts will be distributed with the client data pack? How about the default settings for new installs?

I still think we should include the Ubuntu Fonts, those are my favourites. Any other suggestions?

[gvissers]

Ok, patch comiited. Lightly tested, some more rigorous testing might be a good idea.

Looks to work. It's a shame that existing font setting are lost but it not hard to reset them.

Yeah, sorry about that, I saw no way around that without an ugly bunch of helper code that would be executed at most once.

Assuming we will have the TTF data dir support in time for this release, has any thought been given to which fonts will be distributed with the client data pack? How about the default settings for new installs?

I still think we should include the Ubuntu Fonts, those are my favourites. Any other suggestions?

I happen to like Roboto a lot. Perhaps we should also look for a nice handwriting font for the books.

[bendoughty]

Ok, patch comiited. Lightly tested, some more rigorous testing might be a good idea.

Looks to work. It's a shame that existing font setting are lost but it not hard to reset them.

Can confirm I am not seeing any duplicate font entries here, though now when a font which exists in the system path is selected the setting does not appear to persist following a client restart. This seems to also happen with "duplicated" fonts which exist in both the system path and data path, though fonts which exist only in the data path work just fine after a client restart.

Log entry from a "duplicated" font:

[10:03:17, /Users/dev/Desktop/Eternal-Lands/elconfig.c:2147] Error: Failed to find value 'ArialBold.ttf' in multiselect option 'name_font'

Log entry from a font existing only in the system path:

[10:03:17, /Users/dev/Desktop/Eternal-Lands/elconfig.c:2147] Error: Failed to find value 'VerdanaItalic.ttf' in multiselect option 'chat_font'

Good to go here. There's still a small visual issue with the console input bar in highDPI mode, but otherwise I am ready to build the Mac client as soon as we have the final p9 data pack and the version number has been bumped.

~Oh yes, I've still to fix the input bar scaling.~ Should be done now.

Yes! The look is consistent now. Thank you!

Assuming we will have the TTF data dir support in time for this release, has any thought been given to which fonts will be distributed with the client data pack? How about the default settings for new installs?

I still think we should include the Ubuntu Fonts, those are my favourites. Any other suggestions?

I happen to like Roboto a lot. Perhaps we should also look for a nice handwriting font for the books.

I like both. I have personally been running Ubuntu Regular for everything for the past couple of weeks and have found it to be a decent replacement for the old font. Unfortunately it doesn't appear to be compatible with the Encyclopaedia.

[gvissers]

Can confirm I am not seeing any duplicate font entries here, though now when a font which exists in the system path is selected the setting does not appear to persist following a client restart. This seems to also happen with "duplicated" fonts which exist in both the system path and data path, though fonts which exist only in the data path work just fine after a client restart.

Huh. Obviously, that shouldn't happen. Will have a look.

[gvissers]

Ben, I'm sorry, I can't reproduce your problem.[*] This isn't classic MacOS where the directory separator is :, right? (the client splits on forward or backward slash).

Could you try and see if this

diff --git a/elconfig.c b/elconfig.c
index 237a1c25..8a058f55 100755
--- a/elconfig.c
+++ b/elconfig.c
@@ -2121,6 +2121,7 @@ void check_deferred_options()
                        const char* value = opt_idx_ok ? var->args.multi.elems[opt_idx].value : NULL;
                        if (!value || strcmp(value, opt_val))
                        {
+printf("Expected value for %s at index %d is %s, but actual option value is %s\n", var->name, opt_idx, opt_val, value);
                                int new_idx = find_multi_option_by_value(var, opt_val);
                                if (new_idx >= 0)
                                {

gives any more information?

[*] though I thought I did. Turns out I was testing on a different server profile then where I changed the font. :facepalm:

[bendoughty]

You're a genius, @gvissers, that does indeed tell us what is going on!

[17:51:35, /Users/dev/Desktop/Eternal-Lands/elconfig.c:2124] Error: Expected value for name_font at index 181 is VerdanaBold.ttf, but actual option value is Verdana Bold.ttf
[17:51:35, /Users/dev/Desktop/Eternal-Lands/elconfig.c:2148] Error: Failed to find value 'VerdanaBold.ttf' in multiselect option 'name_font'

Seems something is causing us to lose the space(s) that are present in certain font file names. When I try to load a font from a file that has no spaces, it works and persists after a restart as expected. Looks like the Ubuntu fonts were working as expected all along because those files have no spaces.

[gvissers]

That... is one of the more interesting bugs I have seen in a while. I can reproduce it here. Now to find out what's causing this. EDIT: Ugh. check_var() in elconfig.c strips all spaces. I'm too tired to fix this now, will have another try tomorrow.

[gvissers]

Should be fixed now

[bendoughty]

Should be fixed now

Yes! I can confirm that it is now working correctly for me too.

I was wondering, does the index number in the setting (e.g #ui_font= 7(AquaKana.ttc), #name_font= 180(Ubuntu-Regular.ttf)) prevent us from having a default TTF font value for those options? Presumably different systems will have different numbers of fonts. How can we reliably know the index of (for example) Roboto or Ubuntu?

[gvissers]

Shouldn't matter. If the value at the index does not match the stored value, it will search the list. Only when the stored font name cannot be found is the index used.

[bendoughty]

Shouldn't matter. If the value at the index does not match the stored value, it will search the list. Only when the stored font name cannot be found is the index used.

Ah! Thank you for explaining, that is a really clever solution. I am truly in awe of your new TTF font feature, it makes the game look so much more crisp and modern (especially in high res mode!). Thank you for the time and hard work you have put into making it a reality, I am sure folks are going to love it.

[gvissers]

Thanks for your kind words Ben, and indeed, blocky fonts on a high res screen was what prompted me start this whole endeavour in the first place.

Yet, I still managed to introduce a new bug in the last patch, where the stripped string value is not processed further but the unstripped source string (or at least only stripped on the left side). Ah well, noone would have noticed, but it is fixed now as well, and saves a rather pointless string copy in the process. (~Edit: or rather, it will be fixed in half an hour, once I get back to my computer and can push out...~ Done)

BTW, we still need a candidate for a nice monospaced font for the encyclopedia and other help text.[*] I'm using Hack Regular right now, though I must admit I have no idea if it's a free font. Suggestions for a nice handwriting font for the books would also be good. I'm using Segoe script right now, but that's definitely not free. Besides, it doesn't look quite right anyway. I might have to go shopping on Google Fonts a bit.

[*] I have worked on an encyclopedia rewrite a bit, to have it work with variable width fonts, but progress has been slow and requires an entire rewrite of the encyclopedia itself anyway. Code is in my encyclopedia branch if anyone is interested, but as said, no progress in the last couple of months.

[bendoughty]

BTW, we still need a candidate for a nice monospaced font for the encyclopedia and other help text.[*] I'm using Hack Regular right now, though I must admit I have no idea if it's a free font.

I have given Hack Regular a spin and it looks pretty good, seems that it is indeed free too. I have also found a monospaced version of the Ubuntu fonts on Google Fonts. Ubuntu Mono Regular works well, especially if used in tandem with Ubuntu Regular elsewhere in the game. How do you feel about the Ubuntu fonts in general?

Suggestions for a nice handwriting font for the books would also be good. I'm using Segoe script right now, but that's definitely not free. Besides, it doesn't look quite right anyway. I might have to go shopping on Google Fonts a bit.

So many options! I tried about 15 different fonts in-game, and these are the two that stood out to me the most (with a slight size increase): Shadows Into Light Two, Marck Script. I honestly can't choose a personal favourite between those. Marck is more like the old font, Shadows is a little easier to read.

Have you had any further thoughts about fonts, @pjbroad?

[gvissers]

How do you feel about the Ubuntu fonts in general?

I have no problem with them being the default whatsoever. Personally, though, I prefer a font with a bit more "detail". Not being a font designer, I lack the vocabulary to express clearly with I mean, but e.g. the arches on the 'm' and 'n' characters in the Ubuntu fonts start right at the top of the stem, the 't' is not crossed through but the bar only extends to the right, etc. This makes for a very clear font, but it is bit too smooth for my taste.

So many options! I tried about 15 different fonts in-game, and these are the two that stood out to me the most (with a slight size increase): Shadows Into Light Two, Marck Script. I honestly can't choose a personal favourite between those. Marck is more like the old font, Shadows is a little easier to read.

Two very nice options. You're right about legibility, fonts like Shadows are a lot easier to read. I also had a look at Meddon, I absolutely love the look of this font in the web browser. Unfortunately, it seems to rely heavily on kerning, which the EL client does not support, resulting in text being smashed into the capital letters. [EDIT: that's not quite right, this font does not have kerning info. The problem also seems restricted to capital letter 'A'. Very strange. EDIT 2: Not restricted to 'A'. The problematic characters have a large negative horizontal offset, which the client does not take into account. ~This requires some more thought, will probably not be fixed before the point release~ EDIT 3: committed a fix. Taking the offset into account properly massively improves script fonts, not doing so would be a shame.]

This brings me to another point: At some point I added a shadow outline to the TTF fonts because the text was looking rather washed out, especially on the login screen. This works reasonably well, but not for book text, where it is more a hindrance to legibility than a help. Here's an illustration of what I mean (using Marck): With outline: Without outline:

I have some code lined up to not draw the outline for the book font (could possibly also be worked into a config option, though I'm not sure we want to do that), but with the new release on the horizon I am a bit hesitant to commit. Diff stat:

 font.cpp | 33 ++++++++++++++++++++++-----------
 font.h   | 20 +++++++++++++-------
 2 files changed, 35 insertions(+), 18 deletions(-)

@pjbroad , what are you thoughts?

[pjbroad]

Clearly better in the second picture. I have noticed that the change to soften the outline makes the fonts I'm using look thicker and less crisp IMHO. I think it entirely depends on the background colour.

There's no need to rush the p9 release, I had hoped to get it out this week but its better to get it right IMHO.

[bendoughty]

I have some code lined up to not draw the outline for the book font (could possibly also be worked into a config option, though I'm not sure we want to do that), but with the new release on the horizon I am a bit hesitant to commit.

Oh wow, removing the outline on the book font makes a HUGE difference to the legibility. Marck is now even nicer than I first thought! I would vote against making the book outline a config option, we already have waaaay too many options (imo) and seeing the difference it makes I can't imagine why somebody would ever want to intentionally enable it there.

Meddon is a little "extra" in terms of curvy-woo-woo-fancy for my tastes, though I have to admit it does very much suit the game and context of use.

It seems as of right now we have two good (and free) options to consider for each area:

• UI/Name/Chat/Etc (Roboto, Ubuntu Regular)
• Encyclopaedia (Hack Regular, Ubuntu Mono Regular)
• Book (Marck Script, Meddon)

Edit: added links

[gvissers]

Clearly better in the second picture. I have noticed that the change to soften the outline makes the fonts I'm using look thicker and less crisp IMHO. I think it entirely depends on the background colour.

There's no need to rush the p9 release, I had hoped to get it out this week but its better to get it right IMHO.

Agreed, I made the change in an effort improve the books, but it did not have as much of an effect as I had hoped for. Removing the outline for the book font altogether is better. Will reinstate black outline, and remove the outline from the books.

we already have waaaay too many options

Agreed.

Meddon is a little "extra" in terms of curvy-woo-woo-fancy for my tastes, though I have to admit it does very much suit the game and context of use.

Having tried it in game for a while, I find it too spindly for practical use, and too straining on the eyes. I prefer Marck.

[pjbroad]

The latest changes are much better.

How do people feel about me sneaking in a search function for multi-select config window options? I've done the coding and quite a bit of testing, it's largely self contained and really useful IMHO for the fonts, at least during set-up.

[gamil-zirak]

Regarding book fonts, I also prefer Marck. Meddon looks so informal, such as one would use when writing a personal journal or a letter.

How do people feel about me sneaking in a search function for multi-select config window options? I've done the coding and quite a bit of testing, it's largely self contained and really useful IMHO for the fonts, at least during set-up.

I don't have much of an opinion on this one. I don't think I'd use it much but if others find it valuable and intituitive I see no reason to not do it.

[gvissers]

How do people feel about me sneaking in a search function for multi-select config window options? I've done the coding and quite a bit of testing, it's largely self contained and really useful IMHO for the fonts, at least during set-up.

If you know what you're looking for. But I agree, during testing I have often wished for such a functionality. I would love to have it.

[bendoughty]

How do people feel about me sneaking in a search function for multi-select config window options? I've done the coding and quite a bit of testing, it's largely self contained and really useful IMHO for the fonts, at least during set-up.

That would be fantastic!

Having tried it in game for a while, I find it too spindly for practical use, and too straining on the eyes. I prefer Marck.

Regarding book fonts, I also prefer Marck. Meddon looks so informal, such as one would use when writing a personal journal or a letter.

Okay, so it seems we have a very strong preference for using Marck Script for the book font default. That (currently) leaves us with the following:

• UI/Name/Chat/Etc (Roboto or Ubuntu Regular)
• Encyclopaedia (Hack Regular or Ubuntu Mono Regular)
• Book (Marck Script)

Does anybody have any additional font suggestions, or preferences between the options we currently have on the list?

[pjbroad]

Thanks for the feedback, I've committed the the search function. I also committed a simple change to display the version string on the login window if you hover near the bottom. I didn't like having it show permanently but this can help identify the version of the client more easily. Scope creep I know.

I did notice while testing that for "Ubuntu Mono Regular", the bottom of the glyph is not rendered at some scales. For example "[" misses the bottom bar. I presume this is a round issue somewhere. You can see this in the help text for the multi-select search.

As for default font selection, I like any of those choices. Roboto is a little smaller than Ubuntu but they are both nice. I don't mind which we use.

[gvissers]

Thanks for the search feature, it is excellent!

I have two suggestions, if I may:

• Could we make it case insensitive? (should be simple, there is a strcasestr type function in asc.h IIRC).
• If a search string is not found, could we have some visual indication (search string printed red or a "(not found)")? I don't know how much work that would be, if it's too much trouble, nevermind.

I did notice while testing that for "Ubuntu Mono Regular", the bottom of the glyph is not rendered at some scales. For example "[" misses the bottom bar. I presume this is a round issue somewhere.

Hmmm, maybe, but I'm guessing it's something else. Will take a look.

[gvissers]

I did notice while testing that for "Ubuntu Mono Regular", the bottom of the glyph is not rendered at some scales. For example "[" misses the bottom bar. I presume this is a round issue somewhere.

Hmmm, maybe, but I'm guessing it's something else. Will take a look.

Nope, not a rounding issue. The outline was not properly accounted for. Should be fixed in 9f3650e3.

[pjbroad]

Nope, not a rounding issue. The outline was not properly accounted for. Should be fixed in 9f3650e.

Thanks much better.

I have two suggestions, if I may:

* Could we make it case insensitive? (should be simple, there is a strcasestr type function in asc.h IIRC).

* If a search string is not found, could we have some visual indication (search string printed red or a "(not found)")? I don't know how much work that would be, if it's too much trouble, nevermind.

I considered making it case-insensitive, but decided case-sensitive was useful. Anyway, I've made it switch-able (using TAB) [Aa] is appended to the prompt if case-sensitive is enabled. Also, as suggested, if the string is not found, its printed red.

[gvissers]

I considered making it case-insensitive, but decided case-sensitive was useful. Anyway, I've made it switch-able (using TAB) [Aa] is appended to the prompt if case-sensitive is enabled. Also, as suggested, if the string is not found, its printed red.

Seems to work well here. Wonderful, thanks!

[pjbroad]

Sorry, just spotted another font oddity. The character spacing looks odd when using "Ubuntu Italic". I set the chat font to this and you can see the odd spacing with words like "level" where the "l" looks shifted right and "special" where the "i" and "l" look shifted. There's the same effect with "Ubuntu Mono Italic". "Roboto Italic" looks fine.

Edit: Hmm, it's not 100% reproducible.

[gvissers]

Yes, that looks... "special" indeed. I will see if I can find the problem, though TBH, I have no idea what to look for in this case.

[pjbroad]

I have on screen currently, "level" and "special" look fine now, but "eye" and "age" have the "g" and "y" overlapping the first characters.

[bendoughty]

To assist in the decision making (and to help folks who can't/don't want to play with font settings themselves) I have created comparison images for our current font options. Easy to see the differences in each area if you open them in separate tabs and switch between the two:

Game view: Ubuntu Regular Roboto Regular

Console view: Ubuntu Regular Roboto Regular

Encyclopedia: Hack Regular Ubuntu Mono Regular

The above images were captured with a client running in highDPI mode using default client settings (aside from the font selection).

Edit: My personal preference continues to be Ubuntu (it just seems friendlier and more.. game-y somehow) though Roboto has grown on me a little. Ubuntu also looks a little better scaled down in low-res mode on the mac, though I will admit that is not a concern for 95% of players.

[gvissers]

Okay, hopefully 03fa7491 got it right.

with Ubuntu Italic:

and Ubuntu Mono Italic:

[gamil-zirak]

To assist in the decision making (and to help folks who can't/don't want to play with font settings themselves) I have created comparison images for our current font options. Easy to see the differences in each area if you open them in separate tabs and switch between the two:

Game view: Ubuntu Regular Roboto Regular

Console view: Ubuntu Regular Roboto Regular

Encyclopedia: Hack Regular Ubuntu Mono Regular

The above images were captured with a client running in highDPI mode using default client settings (aside from the font selection).

Edit: My personal preference continues to be Ubuntu (it just seems friendlier and more.. game-y somehow) though Roboto has grown on me a little. Ubuntu also looks a little better scaled down in low-res mode on the mac, though I will admit that is not a concern for 95% of players.

I played around with the fonts, especially what happens when I scale the user interface down for small windows -- I do this normally for alts.

In game view I find Ubuntu Regular more readable, especially when I scale down the user interface.

In console view Ubuntu Regular is more readable but I like Roboto because it takes less space and more text fits per line.

For the encyclopedia it's hard for me to say which looks better. At normal scales, Ubuntu Mono Regular is brighter and crisper while Hack Regular looks somewhat faded. As smaller scales Ubuntu's crispness becomes a disadvantage and Hack Regular becomes easier to read. If I had to choose, I'd go with Ubuntu Mono Regular because then by default the brightness of the Encyclopedia text would match the brightness of the Game text.

[pjbroad]

Yes, that fixes it. I know I'm pushing it, but there is still a slight variation for text drawn with draw_ortho_ingame_string() like the name text. I've adjusted the scaling (the name uses ALT_INGAME_FONT_X_LEN normally) so I can get them the same size, but you can see the chat font looks fine where as the name font has the "ye" overlapping. The "/35" overlaps a bit too. This is the "Ubuntu Italic" font again. Edit: Yes I have a test char call blueeyes, from when I was testing if blue eyes actually worked OK.

[gvissers]

know I'm pushing it, but there is still a slight variation for text drawn with draw_ortho_ingame_string() like the name text.

Yeah, I missed that, sorry. Should be fixed by f026063b. And no need to feel guilty about reporting bugs, let's try to make this release as good as we can.

[revifr]

I see a weird issue with the roboto fonts: the 'r' and 'f' are rendered slightly above the baseline (see attached screenshot):

[pjbroad]

know I'm pushing it, but there is still a slight variation for text drawn with draw_ortho_ingame_string() like the name text.

Yeah, I missed that, sorry. Should be fixed by f026063. And no need to feel guilty about reporting bugs, let's try to make this release as good as we can.

Great, that fixed the name too.

I notice that the y distance between the name and the numbers above is too small. This was probably not obvious until you fixed the issue with missing the bottom of some fonts. I see the function calculates the y step at line 442 in actors.c using: double bar_y_len=ALT_INGAME_FONT_Y_LEN*12.0*name_zoom*font_scale; The number 12.0 is curious and increasing it make the y spacing better. The same number is used in many paces for font calculations and I've previous wondered where it comes from. I can't remember if I worked it out but forgot, but do you know?

[gvissers]

I see a weird issue with the roboto fonts: the 'r' and 'f' are rendered slightly above the baseline (see attached screenshot):

:raised_eyebrow:

I'm sorry, I really have no idea what's causing this. It doesn't happen on my machine. What text size are you using? Is this Roboto Regular?

[revifr]

That was "roboto medium", but the other roboto versions show the same issue. some other fonts show something similar on other letters. Not sure if it needs to be said, but I don't see that issue in other programs...

Tbh, I've never been happy with the TTF rendering on my system. And this screenie was made with the latest github master

[pjbroad]

That was "roboto medium", but the other roboto versions show the same issue. some other fonts show something similar on other letters. Not sure if it needs to be said, but I don't see that issue in other programs...

Tbh, I've never been happy with the TTF rendering on my system. And this screenie was made with the latest github master

Which version of the SDL TTF library are you using? The latest library has better support. I'm using 2.0.15.

[gvissers]

The number 12.0 is curious and increasing it make the y spacing better. The same number is used in many paces for font calculations and I've previous wondered where it comes from. I can't remember if I worked it out but forgot, but do you know?

Not really sure, but 12 is the width in pixels of a character in the old default font (which for some mysterious reason got scaled down to 11 pixels when actually drawing, but I digress). I'm guessing the reasoning was something like:

font_scale = 1/ALT_INGAME_FONT_X_LEN

so that ALT_INGAME_FONT_Y_LEN*font_scale is the ratio between height and width of a character. That would make 12.0*ALT_INGAME_FONT_Y_LEN*font_scale the pixel height of the font, which is then multiplied by the name zoom factor. And in fact, the old draw_ortho_ingame_string() had a

displayed_font_y_size=font_y_scale*name_zoom*12.0;

Now I wonder where I left that 12, though... oh, it's been incorporated into the call to width_pos().

[gvissers]

That was "roboto medium", but the other roboto versions show the same issue. some other fonts show something similar on other letters. Not sure if it needs to be said, but I don't see that issue in other programs... Tbh, I've never been happy with the TTF rendering on my system. And this screenie was made with the latest github master

Which version of the SDL TTF library are you using? The latest library has better support. I'm using 2.0.15.

Interesting. I built SDL_ttf 2.0.14 from source, and indeed I can see the same problem @revifr has, though with different characters ('i' in my case), and only on small font sizes. Quite annoying, to say the least, and you're also missing the outline with SDL_ttf < 2.0.15. I'll see if I can find out how to fix this, but no promises.

EDIT: grmbl, the glyph dimensions reported by SDL_ttf are simply wrong for the offending characters, y_max-y_min=10, yet there are only 9 pixels. EDIT 2: I can trick SDL_ttf 2.0.15 into doing this too, when I disable the outline. Darn. EDIT 3: this really is a bug in SDL_ttf, I think something might be going wrong when downsampling from the bitmap that freetype provides. Rendering a full string using TTF_RenderText_Solid() gives this: Note how the 'i' is not placed on the base line.

[gvissers]

TTF_RenderGlyph_Blended() seems to not suffer from the same problem as TTF_RenderGlyph_Solid(). @revifr , can you check if cbb817a fixes your problem?

Also, the outline is now drawn on systems with an older version of SDL_ttf (pre 2.0.15). @pjbroad , I seem to remember that you had some issues with the outline on such systems (on the RPi, perhaps?, dunno), can you check if this has now been solved?

[revifr]

I just pulled and compiled the last GIT, that gives a big improvement! Thank you very much.

Not only do all letters align correctly now for Roboto fonts, also other fonts now render correctly, especially serif fonts (which I prefer for console use, call me old-fashioned)

[bendoughty]

TTF_RenderGlyph_Blended() seems to not suffer from the same problem as TTF_RenderGlyph_Solid(). @revifr , can you check if cbb817a fixes your problem?

I just pulled and compiled the last GIT, that gives a big improvement! Thank you very much.

Not only do all letters align correctly now for Roboto fonts, also other fonts now render correctly, especially serif fonts (which I prefer for console use, call me old-fashioned)

This change appears to have introduced a noticeable notch in the ether bar (particularly noticeable at lower resolution). To my eye the fonts in this area now look more fuzzy too:

Before:

After:

Above images were taken from a client running in low res mode, though I am seeing the same (albeit more subtly) at high res.

[gvissers]

This change appears to have introduced a noticeable notch in the ether bar (particularly noticeable at lower resolution).

This is unrelated to the font change, but should be fixed now.

To my eye the fonts in this area now look more fuzzy too:

Looking at your pictures, I find the name to look a bit sharper, and the number somewhat fuzzier. It's not impossible they are a bit less sharp, since the border is now blended with the background. I'm not sure how much I can do about that,