Dr. Nikolaus Klepp composed on 2019-02-10 08:42 (UTC+0100):
Anno domini 2019 Sat, 9 Feb 21:52:33 -0500 Felix Miata
composed:
> Dr. Nikolaus Klepp composed on 2019-02-10 00:58
(UTC+0100):
> > Anno domini 2019 Sat, 9 Feb 18:49:48 -0500
Felix Miata composed:
> >> Dr. Nikolaus Klepp composed on 2019-02-10
00:36 (UTC+0100):
>>>> I just upgraded my devuan boxes to
beowulf. Most things work as expected, but there are 2 issues that just kill my nerves:
>>>> 2) DPI settings are not correct
anymore: I have dpi set to 120 via tde controlcenter. After the upgrade gtk2-applications
still use 120 dpi, but TDE ignores the dpi-settings, it uses 96. Now this is quite
irritating.
>>> Where do you see it report 96?
>> Nowhere. I just mesured the ratio from fonts
in applications that did not change (e.g. menu in libreoffice) and compare it to fonts in
applications that changed (e.g. menu in kmail): Result is that kmail fonts are ~ 20%
smaller than before --> ~ 96 dpi.
I think I'd need to see some contextual screenshots to understand, but from KMail it
probably
wouldn't tell me much, since I never use it.
> Which Kmail, TDE's, or KDE5's?
I only have TDE running, so it's TDE kmail (and
konqueror, ...) :-)
That was a confused request that even now I don't understand. :-p
> Which apps besides Kmail have small fonts? Are any
of them using QT5, GTK3 or GTK4?
It affects all TDE applications.
Firefox is also affected (see below).
geany and libreoffice are OK.
gimp 2.10 is OK (besides the fact that some genius broke the layers tab).
This is backwards from what I expect, though my expectations are limited by lack of
familiarity
with apps above mentioned and lyx. Most of my installations are lean, so no Gimp or LO.
This box
has Gimp 2.8 and LO 6.04. LO I use too little to know what to expect. Gimp's main menu
bar text
matches the OS. In the rest of Gimp, everything is tiny enough to cause headache and
backache if
used longer than very briefly.
What I expect from TDE apps is QT3 behavior. I rarely use them though, except for Konq,
KCalc and
the tdecmshell utilities xserver and fonts.
Firefox is my main non-QT yardstick. This is from openSUSE Tumbleweed & TDE:
http://fm.no-ip.com/SS/Moz/Fonts/monospace201902suse.jpg
Note the UI text in 60.5 matches the (GTK2) 17.0 UI text that also matches Konq's and
Konsole's.
The same cannot be said of the content text however.
This is from TDE 14.1 on Kubuntu 18.04 on same PC using the very same two firefox
profiles:
http://fm.no-ip.com/SS/Moz/Fonts/ff60-gtk3-tinyUI-buntu1804.jpg
Note here the mousetype UI in (GTK3) 60.5, much smaller than in Konq, Konsole &
Firefox 17.
I tried FF on Buster, but neither ESR52 nor ESR60 will run on it. ESR60 on Stretch &
14.0.6 behaves
like Tubutu (GTK3 mousetype).
> Do any of these apps allow to choose font family
and/or font size directly, rather than inheriting
> from DE settings? *buntu*fonts and *fonts*buntu* tend to render a physical size or
two less than
> the majority of other families of identical nominal size. DPI typically plays a role
in whether or
> not this happens or for which nominal sizes.
http://fm.no-ip.com/Auth/Font/fonts-face-samplesM.html
> among others can be used to notice this. e.g.:
>
http://fm.no-ip.com/SS/Fnt/ubuntuAREsmaller120.jpg
the image you linked shows 120dpi and it is 120dpi on
my screen, too (1in is 1 in). That's what it used to look like befor upgrade. Now it
says instead of 120 dpi "unknown" and the test-square of 1in is not 2.54mm but
2.12mm or 100dpi (giving some error in my previouse measurement this could be the correct
value).
I can adjust firefox to the correct DPI if I set layout.css.devPixelsPerPx=1.22 - but I
do not
know what that breaks :-)
The breakage is too complicated for me to remember in detail. Not all the dumbing down to
Chrome
level appears in the Firefox UI. Some is in the browser engine, originally Gecko, recently
switched
to Quantum(?). Some of the Gecko browser code required to make fonts-face-samplesM.html
work as it
should has been purged. It never got put into Quantum. The notes at the bottom of that URL
mention
some of what's changed, but more has been lost since.
One recent change comes from anti-fingerprinting policy, which prevents the page from
reporting the
UA string. I'm not sure when it hit, sometime after current ESR series, but whether it
was in
before 65 I don't know either.
An older one is web browser specifications some years ago purged the ability to produce
even a
resemblance of accurate physical sizes on a display screen. The spec usurped the meanings
of the
physical sizes, including pt, cm, in & pica. Instead of pt meaning point, it means CSS
px. IOW, px
and pt are exactly the same thing in CSS used for display screens. That means unlike real
point
sizes, their equivalent px sizes do not vary with display density.
Gecko was the last mainstream browser engine to do the purge. For several years it had a
proprietary unit (mozmm) that could be used to create physical sizes, but no longer. So,
my page
only works close to or in fact as intended with Konq, or older Mozilla products that
support mozmm,
or really really really old other browsers, among which neither Chrome nor Chromium, but
IE6,
mostly yes.
The purging of pt as a physical unit doesn't just show up in unexpected page text
sizing. It also
has affected optional themes, and some internal theming. Mix in a GTK3 problem[1][2] and
HiDPI
mutations, and you get a good definition of unpredictable.
[1]
https://bugzilla.gnome.org/show_bug.cgi?id=757142
Recent change breaks HiDPI setup based on calculated or forced DPI
https://bugzilla.mozilla.org/show_bug.cgi?id=1269274
UI text sizes no longer inherited from Linux system
[2]
https://bugzilla.opensuse.org/show_bug.cgi?id=1022830
GTK3 apps not honoring system-wide DPI settings nor KDE mouse cursor
This bug's fix counters the GTK problem upstream created. I've not seen evidence
any other distro
has offered this solution.
--
Evolution as taught in public schools is religion, not science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata ***
http://fm.no-ip.com/