No. Here is a side-by-side picture with the system Texmacs above and the AppImage version below. You have to open the image here to see, that the above image does raster the fonts poorly. On my screen you see it immediately.
Struggling with TeXmacs on 4k screen under Linux
Hi, TeXmacs is blurring in my Fedora 33(3840x2160, 150%, kde) and openSUSE(1080p, 125%, kde). Using the latest build from OBS and COPR. I’m try to find the problem.
The menu logo are also blur comparing with Ingolf.
It would be useful to know which versions of the Qt libraries TeXmacs is using. Also one could try the appimage if it is available.
@Ingolf I do not think freetype is the problem. Most probably some weirdness in the version of Qt TeXmacs is linked against, the appimage has its own version of the libraries. Can you check which is the version of Qt linked in the standard package?
1 Like
Both Fedora and openSUSE work with Qt 5.15.2.
The standard package in Arch/Manjaro is dynamically linked. Relevant portion from objdump:
NEEDED libfreetype.so.6
NEEDED libQt5PrintSupport.so.5
NEEDED libQt5Widgets.so.5
NEEDED libQt5Gui.so.5
NEEDED libQt5Core.so.5
And installed Qt version on the system is 5.15.2 (freetype 2.10.4 even if that might not matter).
Manually setting QT_SCREEN_SCALE_FACTORS to 1 from command line works around the problem by not scaling. That seems to be what the AppImage does as well.
2 Likes
export QT_SCREEN_SCALE_FACTORS =1 works for me! Thanks!
2 Likes
It would be useful to record this problem in the savannah bug tracker, I think the handling of HiDPI screens on Qt5 is still not ok. Alternatively one could try a build of TeXmacs with Qt4 if this is still possible.
I entered it into the bugtracker at savannah.
2 Likes
1 Like
This is interesting! (also to report on the bug report filed by @Ingolf). What about other programs, do they have the same problems? I wonder if we are doing something wrong or just there is a bug in the Qt library support for HiDPI (which is not so uncommon in my experience).
Firefox, telegram, kde applications are just fine. But Arduino-IDE is little blur.
The Appimage still uses Qt4.8, and no special Qt parameters are set to run it.
I can provide a Qt5 Appimage but I think it is built with Qt5.6 or 5.8, so as to be able to run on still supported LTS versions.
2 Likes
Sorry, what I meant was that the AppImage seems to use scaling 1.00 as well, i.e. ignore the different scaling factor of the desktop environment.
Looking at the Qt version history and Qt’s page on high DPI, it seems that possibly relevant functionality has been introduced in versions 5.6, 5.11 and 5.14.
Version 5.12 is the latest LTS, but will only be supported until December 2021. It seems that after v6 will be the only open source release receiving bug fixes.
I’m curious to hear more about your experiences with Qt. I’ve been looking into a potential move to v6, but my experience with Qt is fairly limited. What are the reasons for sticking to 5.6 or 5.8?
The KDE team will do bug fixes for Qt 5.14 in the form of patches to the last release for a while. That was part of the agreement between KDE and the Qt Company https://dot.kde.org/2021/04/06/announcing-kdes-qt-5-patch-collection
1 Like
This is a very annoying problem.
Are there any GNU Linux systems for which the fonts are displayed correctly with QT_SCREEN_SCALE_FACTORS different from 1?
If not, then we might simply set QT_SCREEN_SCALE_FACTORS to 1 under GNU Linux.
I can confirm that the official build with Qt 4 does not have this strange issue, so it’s probably related to how Qt 5 handles stuff.
2 Likes
