#2792 Plot text not rendering nicely in kitty

[Anonymous]

Hello,

I'm having problems rendering the text in my plots in the kitty terminal. This is an application where it's important to render directly in the terminal, so I can't just create an image file.

Basically, the graph itself looks great, but the text in the graph (title, labels) is rendered with a greenish tinge instead of white as I had requested. I believe this may have to do with having a transparent background. I've attached an image showing the problem, which I've produced using these basic commands:

set terminal kittycairo transparent
set title "Test" textcolor rgb "#ffffff" font "Arial,14"
plot sin(x)

I'd appreciate any help getting this fixed!

System info:
kitty 0.41.1 created by Kovid Goyal
gnuplot 6.0 patchlevel 2
Xorg

[Ethan Merritt]

While it is possible that the values for hinting or antialiasing sent from the gnuplot kittycairo terminal to the cairo library might have a slight effect on the result, I don't think that is what you see here. I would guess that it is a compositing failure by the terminal emulator you are using to run gnuplot in. I can't tell from your screenshot whether the visible background is being managed by your terminal emulator or whether the terminal emulator is set to transparent and you are seeing through it to a backgound image on the desktop. If the latter then possibly the display manager is also partly at fault. But most likely it is the fault of the terminal emulator.

Here is a screenshot from my machine using the KDE Konsole terminal emulator, set to partial transparency so you can see through to a background image displayed behind it. The odd color effect is not visible here.

[Graeme]

I just tested with Konsole and ghostty and had the same problem, so looks like it's not a problem with the terminal emulator. In each case transparency was set using the terminal emulator config. So what should I look at next? The compositor?

[Graeme]

Oddly enough, I just tested this on my laptop and I'm getting the same problem, this time on Wayland. So it must be either a) a problem with gnuplot or b) a problem with my window manager, Qtile.

[Graeme]

Ok, I don't think it's Qtile, I've tested also with Sway and Hyprland and I'm getting the same results. Btw, the terminal has partial transparency, not full.

[Ethan Merritt]

I think the first thing to do is to pin down whether the output from gnuplot is already corrupt, or the gnuplot output is fine but something goes wrong when displayed in a particular terminal or display.

Could you please attach the kitty output from your machine here as a text file? That way I can view it on my system and see whether it looks correct on not.

set term kittycairo transparent size 1000,700
set output 'dump.kitty'
set title "Longer title so I can see it better " textcolor rgb "#ffffff" font "Arial,14"
plot sin(x) with boxes fs solid border lt -1 fc rgb "#ffffff"
unset output
quit

We can also try the test in the other direction. I have attached the output I get here. On my machine it displays correctly. If you download this and type "clear; cat dump.kitty", do you see the problem or not?

(edited: Example output now includes solid fill that should match text color)

[Graeme]

Hi Ethan, thanks for the continued help!

Your dump.kitty looks fine on my machine, but my output does not! So the file itself has the text drawn wrong somehow. Attaching just so you can confirm. At this point I'm assuming you'll need more system info to debug, so let me know how I can provide that.

[Graeme]

Whoops, here's the file

[Ethan Merritt]

The prime suspects would be the flow of text rendering through cairo->pango->[harfbuzz?] support libraries.

It could be that one of the component libraries is a bad version all by itself, but it is also possible that each of the libraries is fine on its own but there is a mismatch between them. pango and harfbuzz in particular have undergone a lot of churn in recent years and there have been a lot of problems reported with font kerning and hinting. I haven't seen a report of bad coloring, but going back to my original comment I could imagine that the process of hinting could mess up by merging in an incorrect background color. That could be tested by applying a patch and rebuilding gnuplot from source, but it wouldn't fix anything - it would just confirm the hypothesis.
https://sourceforge.net/p/gnuplot/patches/820/

I can offer only limited guidance on debugging your machine, but I'd start with

ldd `which gnuplot` | grep pango
ldd `which gnuplot` | grep cairo
ldd `which gnuplot` | grep harfbuzz

That should give you a list of the libraries that gnuplot will access when run. Here I get

libpangocairo-1.0.so.0 => /lib64/libpangocairo-1.0.so.0 
libpango-1.0.so.0 => /lib64/libpango-1.0.so.0 
libpangoft2-1.0.so.0 => /lib64/libpangoft2-1.0.so.0 
libpangocairo-1.0.so.0 => /lib64/libpangocairo-1.0.so.0 
libcairo.so.2 => /lib64/libcairo.so.2 
libcairo-gobject.so.2 => /lib64/libcairo-gobject.so.2 
libharfbuzz.so.0 => /lib64/libharfbuzz.so.0 

Unfortunately it then becomes system-dependent how to query which packages provided those libraries. If your system uses rpm then you can query the packages versions with (in this case)

[~/temp] rpm -qf /lib64/libpango-1.0.so.0 /lib64/libcairo.so.2 /lib64/libharfbuzz.so.0
lib64pango1.0_0-1.50.14-1.mga9
lib64cairo2-1.17.6-2.mga9
lib64harfbuzz0-7.0.1-1.mga9

So I have cairo version 1.17.6 pango version 1.50.14 and harfbuzz 7.0.1

I am sure there are equivalent queries for systems that use apt or yum or brew or whatever but I don't know what they are. With the version information in hand, you could then look for problem reports either on the corresponding project web site or on an issue tracker for your particular OS (Fedora/Mint/Ubuntu/MacOS/whatever).

Or you could try upgrading/downgrading one or more of those libraries to match a set of versions known to work.

Let me know what you find.

[Graeme]

I'm on Arch so my versions are much later. However I downgraded everything to match the exact versions you posted and I still have the same problem. Any other ideas?

[Ethan Merritt]

Try a different kind of font? In particular compare the results using a font

• known to be provided as *.ttf
• known to be provided as *.otf
• known to be provided as *.pfb (these are mostly TeX fonts I think)

[Graeme]

No luck, I continue to have the problem regardless of font type