Fonts on Linux #27

alexzk1 · 2025-04-12T22:06:50Z

I see you did some replaces into overlay, but main GUI still missing emoji:

P.S. my overlay is not detected. I added replacement to my code :D

Could it be easier to have something like
text = text + GetEmoji(MEMO)
?
So instead replacement you could just have proper one per OS detected.

The text was updated successfully, but these errors were encountered:

Silarn · 2025-04-12T22:42:09Z

It's definitely functional per the Wayland overlay but the methods used by the old x11 overlay don't work. I think you'd have to make use of pango to get more modern font rendering.

I modified it to use Xfc so it wasn't limited to bitmap fonts but this only makes it roughly comparable to the Windows overlay.

I think you do need to port over the changes related to vector marker support.

Silarn · 2025-04-12T22:43:38Z

Oh. Well my Linux environment is showing basic versions of emojis just like Windows. Could be a system related font thing.

In the tkinter window.

alexzk1 · 2025-04-12T22:46:20Z

Oh. Well my Linux environment is showing basic versions of emojis just like Windows. Could be a system related font thing.

Well, I dunno. On screenshot is main EDSM GUI. Whatever they do there.

In my overlay I modified to use TTF already. probably fonts just miss something. I'm not sure. I'm not fun of emojies.
Also I don't see any "compass" on overlay, not sure how should it work though, but I saw it in your code.

alexzk1 · 2025-04-12T22:47:50Z

Visual Studio Code with your code:

And when I paste this to chat GPT I can see pictures.

Silarn · 2025-04-12T22:54:14Z

That's the checkmark character. I guess your local font doesn't have it.

You do have to enable the radar but when I checked your code it has the same missing marker support as the original edmcoverlay2.

alexzk1 · 2025-04-12T22:57:30Z

Yes, I had this for last year:
inpstr.replace("\\u202f", "\\u00a0")
and added this today, because I stopped to see >> sign after git pull of your code:

.replace("\\ud83d\\udcc8", "*")
.replace("\\ud83d\\udcdd", "»")

But in GUI i still missing it, and it was there 1-2 weeks ago (I think).

Silarn · 2025-04-12T23:18:21Z

I don't think I changed that character so that's pretty strange.

It shouldn't be something that's translated.

If your code doesn't properly parse the vectors it may be simply not drawing the circles if you have the radar enabled.

Making use of that stuff really exposed some issues in the edmcoverlay2 code. Unfortunately when I tried using yours it seemed to be crashing so I wasn't able to test much. But that's was before I expanded my gaming machine and added a Linux dual boot.

I'll try it again to see what happens.

alexzk1 · 2025-04-12T23:25:47Z

As I recall I cleansed a little original overlay2 without wayland support, so it could inherit the problems.
Also I did X11 only too, as I use it.
And there is "shadows" supported check which throws exception if failed. Shadows aren't default in Linux. You must install / use composer for this, like picom. If it is not loaded, overlay will be solid black screen.

Silarn · 2025-04-13T00:23:05Z

I have it installed and working (I set the env variables so it would use X11 just to make sure).

I'll let you know what issues I see, but you can check my edmcoverlay2 fork to see the fixes I made for markers and color parsing.

Silarn · 2025-04-13T00:32:06Z

My tkinter display seems fine:

I did have to update the logic to make sure it did the substitutions like it does for X11 edmcoverlay2 but that seems to render fine:

I'll check the radar now.

Silarn · 2025-04-13T00:49:20Z

Yeah, it seems like neither the vector lines nor the markers are working.

The vector lines did generally work in the original edmcoverlay2 so not sure why that's failing unless the marker component is causing it to crash out.

In short, the actual lines use the main color. Markers use an additional 'color' tag inside the vector list. (A list of points and optional marker details.)

For more than one point, it should draw a line using the 'master' color value. For each point, it should check for a 'shape' and 'text' element. 'shape' can be 'circle' or 'cross'. Cross draws a small X centered on the point coordinate. Circle draws a small circle. If 'text' it set it's rendered just like normal sized text slightly offset from the point coordinates. All marker elements are drawn with the color set in the vector list element - which should be mandatory.

alexzk1 · 2025-04-13T08:57:21Z

My tkinter display seems fine:

Well, than we need checkbox in settings "Do not use emoji" which replaces it everywhere, without any automatic detection. I have "Ubuntu" font as system default.
Overlay tries fonts in order:

 static const std::vector<std::string> kFontsToTry = {
          "Liberation Mono", "DejaVu Sans Mono", "Source Code Pro", "Ubuntu Mono",     "Monospace",
          "Sans Serif",      "Liberation Serif", "Serif",           "Liberation Sans", "Open Sans",
        };

Both are missing the emoji.

alexzk1 · 2025-04-13T10:05:30Z

"Marker" is something new. This shape was absent in original code, but it is there in your copy.
...or I just forgot to port it, but I doubt though :/

alexzk1 · 2025-04-13T12:12:27Z

Ok, I added markers support, and fixed error I made. I added numeric font size and it was applied to any message in python, so it was making "shape" to be "text", this double switch is ignored by C++.
Also I don't have SCALE_* uses. So on 4K screen this may look as not expected by you.

alexzk1 · 2025-04-13T12:33:31Z

alexzk1 · 2025-04-13T12:37:30Z

Main issue with emoji in UI remains ;)

Silarn · 2025-04-13T17:39:41Z

"Marker" is something new. This shape was absent in original code, but it is there in your copy. ...or I just forgot to port it, but I doubt though :/

They are part of the original EDMCOverlay which is the key bit. Yes, they were not being parsed and handled by edmcoverlay2.

Ok, I added markers support, and fixed error I made. I added numeric font size and it was applied to any message in python, so it was making "shape" to be "text", this double switch is ignored by C++. Also I don't have SCALE_* uses. So on 4K screen this may look as not expected by you.

There are scaling corrections I need to make because the original EDMCOverlay stretches a 1280x1024 out to whatever your display resolution is, with an additional padding around the edge. Your display there looks reasonably good. The radar position is movable and resizable so I think that should be fine, any marker or font upscaling should be managed by the overlay if it's going to happen. 🤷

My tkinter display seems fine:

Well, than we need checkbox in settings "Do not use emoji" which replaces it everywhere, without any automatic detection. I have "Ubuntu" font as system default. Overlay tries fonts in order:
 static const std::vector<std::string> kFontsToTry = {
          "Liberation Mono", "DejaVu Sans Mono", "Source Code Pro", "Ubuntu Mono",     "Monospace",
          "Sans Serif",      "Liberation Serif", "Serif",           "Liberation Sans", "Open Sans",
        };
Both are missing the emoji.

I already modified the overlay so it'll detect eofl and swap out those symbols on the overlay. Xft has the same display issues as the original, more or less. But it does handle those replacement characters fine.

As far as the tkinter display goes, I'd never seen it not work with the emojis. Though I am using Fedora. I suppose I can add a setting for people who need it.

alexzk1 · 2025-04-13T17:43:25Z

I just added "Cairo" to draw circles, Chat GPT said it will do anti-aliasing by default. So radar looks smoother.

8000

Silarn · 2025-04-13T17:44:38Z

I just added "Cairo" to draw circles, Chat GPT said it will do anti-aliasing by default. So radar looks smoother.

Oh, nice. I was going to look into that for my modified edmcoverlay2. I think that should handle alpha values too, no?

The Wayland renderer does it very nicely.

alexzk1 · 2025-04-13T17:48:07Z

I just added "Cairo" to draw circles, Chat GPT said it will do anti-aliasing by default. So radar looks smoother.

Oh, nice. I was going to look into that for my modified edmcoverlay2. I think that should handle alpha values too, no?

The Wayland renderer does it very nicely.

Probably. Color passed includes alpha. I don't parse Alpha in hex code though. But we can add.
sscanf(name.c_str(), "#%02x%02x%02x", &r, &g, &b);
Do you know where to put alpha is proper position ?

Silarn · 2025-04-13T17:51:19Z

That was something else I had to fix. The Wayland one did it wrong too even though he did add marker support.

https://github.com/Silarn/edmcoverlay2/blob/c22d8188a62a414b3f4d3f26f7abe509260a97d9/X11/overlay.cpp#L149

It's actually the first value, so #aarrggbb. Most likely your color parsing for those vector lines is off since #rrggbbxx would result in a blue color. The internal vector lines have partial transparency.

Again, this is from the original EDMCOverlay code.

alexzk1 · 2025-04-13T17:57:19Z

Is it proper now?

Silarn · 2025-04-13T17:57:50Z

Looks good to me.

alexzk1 · 2025-04-13T18:03:01Z

Cairo itself is double platform. With modifying build systems cairo based code can work on X11/Wayland, all the same without major differences.

alexzk1 · 2025-04-13T18:26:45Z

Can you detect suit swap ? I feel like this radar should be turned OFF if suit is not Arthemis. Same as we did with ships year ago.
Upd. it turns off on-foot with suit swapped, but remains in-ship...probably, it is ok :)

Silarn · 2025-04-13T18:41:53Z

Cairo itself is double platform. With modifying build systems cairo based code can work on X11/Wayland, all the same without major differences.

I tried adapting the Wayland version which is using python Gtk bindings. The 'layer shell' protocol it uses is only supported by some spins, which is what turns the window into an overlay. I was able to have it render on X with click-through and no decorations but keeping it on top required accessing the X window which I had trouble doing.

Can you detect suit swap ? I feel like this radar should be turned OFF if suit is not Arthemis. Same as we did with ships year ago. Upd. it turns off on-foot with suit swapped, but remains in-ship...probably, it is ok :)

The BioScan overlay should already disable if you're not in an Artemis suit, radar included. I've tested this so if it's not working for you I may need more info about which suit.

alexzk1 · 2025-04-13T18:44:49Z

The BioScan overlay should already disable if you're not in an Artemis suit, radar included. I've tested this so if it's not working for you I may need more info about which suit.

It disables on-foot it seems, but remains inside ship (ship is white-listed for bio, probably some logic conflict).

Silarn · 2025-04-13T20:49:43Z

I didn't really have it check the suit while in the ship. It's a bit tricky because that data isn't reliably reported until you actually go on-foot somewhere or change your current suit so I may not have the info I need to make that distinction until then.

It does already hide in combat mode among other things (I recently added detection for having various panels open - like comms or the gal map). I suppose I can try to hide it if we do have info about which suit is active, but it's getting to the point where I feel like I need some settings to let people decide if they want that.

alexzk1 · 2025-04-13T20:52:17Z

but it's getting to the point where I feel like I need some settings to let people decide if they want that

Yes, probably. I'm not sure either :D I just imagined that if I do settlement I wouldn't want to have radar over game's radar.

Silarn · 2025-04-13T21:03:23Z

I just went to build your latest version and ran into an issue because CMake 4 was set as the minimum version. I don't actually think it needs to be, I manually dropped the version down and was able to build it fine. 4.0 was only released a couple weeks ago and Fedora 41 isn't even on 3.31 yet.

alexzk1 · 2025-04-13T21:06:40Z

I just went to build your latest version and ran into an issue because CMake 4 was set as the minimum version. I don't actually think it needs to be, I manually dropped the version down and was able to build it fine. 4.0 was only released a couple weeks ago and Fedora 41 isn't even on 3.31 yet.

I have 4.01 after latest update. Work machine with Ubuntu 22 has it too. On work machine it broke all builds because of complaining "less than 3.10 is not supported". I got similar warning here too, so I just updated version to what I have.
But yes, it should work with any.

Silarn · 2025-04-13T21:08:24Z

The marker labels seem a bit more offset than they need to be? Maybe 5 pixels higher would be fine, I think.

I'd generally say put cmake on whatever the true lowest valid version is so it doesn't trip people up with less-than-cutting-edge packages.

alexzk1 · 2025-04-13T21:13:21Z

Nope, I think it is exactly equal:

 static constexpr int kMarkerHalfSize = 4;
cairo_move_to(xserv->cairo, marker.x - kMarkerHalfSize,
                                  marker.y - kMarkerHalfSize);
                    cairo_line_to(xserv->cairo, marker.x + kMarkerHalfSize,
                                  marker.y + kMarkerHalfSize);

                    cairo_move_to(xserv->cairo, marker.x - kMarkerHalfSize,
                                  marker.y + kMarkerHalfSize);
                    cairo_line_to(xserv->cairo, marker.x + kMarkerHalfSize,
                                  marker.y - kMarkerHalfSize);

I saw that many times old days, when I draw equal cross it looks like not equal. Some illusion.

Silarn · 2025-04-13T21:15:00Z

I'm talking about the marker text, not the markers themselves. Those look fine.

alexzk1 · 2025-04-13T21:19:01Z

I'm talking about the marker text, not the markers themselves. Those look fine.

I used your numbers. But this can be because of 2 reasons:

Cairo draws the lines but Xft draws the text. Probably they mismatch coordinates.
I have configurable font over python gui, so depend on size fixed offset will look more or less bad.

Silarn · 2025-04-13T21:23:41Z

The edmcoverlay2 X11 tries (imperfectly) to replicate the 1280x1024 render area from the original EDMCOverlay. So it may be more or less exaggerated.

I think yours just uses the true screen dimensions, no? I'm not applying any scaling corrections to the radar lines.

alexzk1 · 2025-04-13T21:25:09Z

The edmcoverlay2 X11 tries (imperfectly) to replicate the 1280x1024 render area from the original EDMCOverlay. So it may be more or less exaggerated.

I think yours just uses the true screen dimensions, no? I'm not applying any scaling corrections to the radar lines.

Yes, it uses window size 1:1, and it can be changed in python GUI. By default It covers whole screen I think.

Silarn · 2025-04-13T21:33:37Z

There aren't many plugins that draw shapes but the few that do may look a bit odd.

I derived my correction code from the LandingPad plugin which also draws a little station diagram on the overlay. In includes corrections designed for the original EDMCOverlay which are at least close enough for the edmcoverlay2 X11 renderer but I imagine will be warped for both the Wayland and edmcoverlay_for_linux displays.

That's why I have overlay detection code and some differing rendering pipelines set up.

Ah well.

alexzk1 · 2025-04-13T21:37:56Z

Proper way is to set transformation matrix, from resolution you use to resolution output does on output device. If we had openGL output that would be 1 call.

Hmm..I just think, what if to use SFML ? :D Instead all that tricksteries.

Silarn · 2025-04-13T21:46:17Z

Yeah, I don't know. Again, I detect the overlay so I can manage the scaling properly based on the active overlay but I'm not aware of any other plugin making those checks.

I'm just letting you know that the few that exist may end up looking a little different since the render space scaling will be different, unless they account for that when sending the shape coordinates like I am.

alexzk1 · 2025-04-13T21:46:24Z

Is it better?

I used font size:

const auto extents = xserv->measureUtf8String(font, {marker.text.at(0)});

                xserv->drawUtf8String(font, marker.color,
                                      marker.x + kMarkerHalfSize + extents.width / 3,
                                      marker.y + kMarkerHalfSize + extents.height / 3, marker.text,
                                      ETextDecor::NoRectangle);

Silarn · 2025-04-13T21:47:06Z

I think that looks good.

(If you're wondering why my lines are different above, it's in logarithmic scaling mode.)

alexzk1 · 2025-04-13T21:51:41Z

Btw, I use 2 days old your code. So probably, I have "correction" here.

Silarn · 2025-04-13T21:55:31Z

It should be the same as my current code. For the edmcoverlay2 Wayland renderer and yours, I don't apply any corrections since they use the actual screen dimensions. (Even if the render area is set smaller the x:y scale remains the same.)

For EDMCOverlay, you have to scale the X or Y coordinates to account for mapping the 1280x1024 draw area and stretching that out to the screen dimensions. (And EDMCOverlay includes an additional padding at the edge as well.)

The edmcoverlay2 X11 (original) renderer does the 1280x1024 render space but doesn't include the extra padding.

alexzk1 · 2025-04-13T21:58:36Z

Oh wow, things are getting complicated :D

Silarn · 2025-04-13T22:01:21Z

I'll make sure to mention that your overlay works well for X11 in my next release. So people can choose the one they prefer.

To be honest even the Wayland one is problematic because it has a tendency to crash if the gtk-layer-shell module is out of date (and it is on most distros - other than Arch and one other). And the spin needs to support the layer shell protocol. Gnome still doesn't while KDE and some others do. To get it working I had to manually compile the latest version and use that instead.

But it looks good and even supports emoji characters. 🤷

alexzk1 · 2025-04-13T22:05:11Z

Thanks.

Silarn added the enhancement New feature or request label Apr 21, 2025

Fonts on Linux #27

Fonts on Linux #27

Comments

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

8000 Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!