Created attachment 4112 [details]
screenshot without forced 96 DPI (much easier to make too big smaller than too small bigger)

This bug report hasn't seen any action since before Mga4 release. Is it still valid in current cauldron (or, for traditional installer: with the 6dev1 snapshot, or for live isos with Mga5)?

Keywords: (none) => NEEDINFO

Created attachment 7722 [details]
144 DPI screenshot of cauldron as of 20160427

(In reply to Marja van Waes from comment #2)
> This bug report hasn't seen any action since before Mga4 release. Is it
> still valid in current cauldron (or, for traditional installer: with the
> 6dev1 snapshot, or for live isos with Mga5)?

Bug 18317 is currently blocking use of Plasma directly, but if MCC in IceWM is to be any guide, nothing has improved. In IceWM at least, Xft.dpi is not forced regardless of its absence in /etc/X11/Xresources.

Thanks for the feedback, Felix, please inform us when bug 18317 got fixed and you tested in Plasma5

CC: (none) => marja11

(In reply to Marja van Waes from comment #4)
> Thanks for the feedback, Felix, please inform us when bug 18317 got fixed
> and you tested in Plasma5

Assigning to KDE maintainer, anyway

Assignee: bugsquad => mageia

Just as additional info, there seems to be no problem to me:

[zz@localhost ~]$ xrdb -query | grep dpi
Xft.dpi:	107
[zz@localhost ~]$

Also:

[zz@localhost ~]$ cat /etc/X11/xorg.conf | grep DisplaySize
    DisplaySize 303.7 189.8 # 14.1"
[zz@localhost ~]$ 

Maybe I'm not understanding the problem.

After changing the forced 107 dpi in Xfce Appearance config to forced 96, I get:

[zz@localhost ~]$ xrdb -query | grep dpi
Xft.dpi:	96
[zz@localhost ~]$

Of course, that won't work with a 107dpi screen -- or with a 120dpi one, also.

96 dpi is supposed to give you fonts without scaling (because most are made for Windows) in the hopes things look like they were planned to look. Surely any graphic (including a 1-inch ruler) won't be displayed at the right size.

Please correct me if I'm not seeing the real issue here.

Hmm, in KDE you already forced 96dpi, but Xft.dpi is 120... is that the bug? What about changing the setting above (Use anti-aliasing) from System Settings to Configured?

Finally, Felix, it seems your expectations seem to be a little off... if your display is 120dpi, forcing lower settings will make fonts smaller (just tried now with 48dpi, it becomes unreadable). IOW, don't use 96 dpi or fonts will get tiny and you'll need indeed a magnifying glass.

In Firefox, you can either increase the default font sizes, or change the variable "layout.css.devPixelsPerPx" to 1.25 (=120/96) to make it work with 107dpi.

Going to the site in your pic, I see the one inch is rendered at the correct size in my screen with Firefox 45.6 ESR (well, I used a plastic ruler, but it is not far from 25mm). For day-to-day checkings, I usually start up Libreoffice and measure the rendered image of a page against a real sheet of paper. It usually leads to a close enough match, if display size is calculated carefully (a good site for that is https://www.sven.de/dpi/ (BTW, thanks, Sven Neuhaus!).

CC: (none) => mkare

(In reply to Renato Dali from comment #6)
> ...Maybe I'm not understanding the problem.
 ...

Clearly you've misunderstood what I've written here. :-(

	Raising DPI == raising text size.

	Mageia sets Xft.dpi low (96).

Thus:

	Mageia makes fonts too small when display density is materially higher than 96.

> https://www.sven.de/dpi/

I have my own tools for these things, e.g.:
http://fm.no-ip.com/PC/displays.html
http://fm.no-ip.com/Auth/dpi-screen-window.html
http://fm.no-ip.com/PC/fonts-linux-about.html

> Clearly you've misunderstood what I've written here. :-(

*sigh* It's not the first time in the last few days... maybe I need a vacation...

> Mageia sets Xft.dpi low (96)

OK, now I begin to understand. For comparison, in another distribution it is not set at all -- "xrdb -query | grep dpi" returns nothing.

In Mga6 sta2 (updated from sta1) with Xfce, good news: that command returns 107dpi, the same value resulting from DisplaySize. That may have been influenced by Xfce; see below please.

Testing in Mageia 5.1 KDE4 without any DisplaySize option yielded the same 107dpi, but KDE was forcing that value (107).

After turning off that the setting (to force a particular dpi), the system was rebooted and now Xft.dpi was not set; xdpyinfo returned 96dpi. I wonder if that's a X11 default or if it failed detecting the EDID information (actually, I don't know whether EDID includes that information!).

Inserted the DisplaySize clause, rebooted and:

- Xft.dpi was still undefined and
- xdpyinfo now correctly reports 107 dpi.

It seems KDE (and other DEs or maybe even Mageia in the case of IceWM) are responsible for setting Xft.dpi.

I think this is right.

The problem is what do applications use when it is undefined. Empirical tests (oxymoron?) show both Konsole and Firefox follow the dpi resulting from the DisplaySize option.

If your configuration still results in a 96dpi Xft.dpi setting, it's possible KDE has that initial setting (done by Mageia)... when and if I reinstall KDE4/Mageia 5 I might give it a look. If confirmed, and from the above tests, it might be easy for the KDE maintainers to fix.

Thanks for the links and sorry for preaching to the choir...

HTH.

(In reply to Renato Dali from comment #8)
...
> After turning off that the setting (to force a particular dpi), the system
> was rebooted and now Xft.dpi was not set; xdpyinfo returned 96dpi. I wonder
> if that's a X11 default or if it failed detecting the EDID information

96 DPI has been forced by Xorg for about a decade, which has nothing directly to do with Xft.dpi.

Xft.dpi is a tool that enables specifying a particular logical DPI value directly via configfile, instead of needing to override the forced 96 default indirectly via DisplaySize, or by using xrandr. 

Absent DisplaySize, Xorg reads the display dimensions from EDID, then ignores them, and runs as though the actual dimensions are those necessary to result in 96 logical DPI (which are those it prints in Xorg.#.log). This is essentially the same result as is found in Windows.

> (actually, I don't know whether EDID includes that information!).

EDID contains display dimensions, from which Xorg determines the display's physical density.

> It seems KDE (and other DEs or maybe even Mageia in the case of IceWM) are
> responsible for setting Xft.dpi.

Xft.dpi is an interloper. It's not necessary in a pure KDE environment. Xft.dpi is only necessary (AFAICT):

1-as a per user setting to override either the DPI calculated automatically by Xorg from DisplaySize (KDE and TDE use it when force DPI is selected in systemsettings); or

2-as a per user setting to override a globally configured Xft.dpi (Mageia 5 sets it in Xresources, and apparently elsewhere too, the latter of which is the reason for this bug); or

3-gnome-settings-daemon uses it as a desktop zoom control; or

4-Other DEs might use it as well either as KDE and TDE do or as Gnome does.
 
> The problem is what do applications use when it is undefined.

The empirical evidence is that competent applications don't need it. They simply embrace the environment Xorg presents to them. Among these are KDE and other QT apps. GTK apps shouldn't need it (e.g. Firefox), but when absent and built with GTK3 >3.16, they will behave as if it is set to 96 whether it is set or not[1].

> Empirical tests (oxymoron?) show both Konsole and Firefox follow the dpi resulting
> from the DisplaySize option.

Firefox when run in a GTK3 environment >3.16 stopped in rv46.
 
> If your configuration still results in a 96dpi Xft.dpi setting, it's
> possible KDE has that initial setting (done by Mageia)... when and if I
> reinstall KDE4/Mageia 5 I might give it a look. If confirmed, and from the
> above tests, it might be easy for the KDE maintainers to fix.

As to "easy", see:
https://bugs.kde.org/show_bug.cgi?id=367499
and 
https://bugzilla.mozilla.org/show_bug.cgi?id=1269274

[1] https://git.gnome.org/browse/gtk+/commit/?id=bdf0820c501437a2150d8ff0d5340246e713f73f

See Also: (none) => https://bugs.freedesktop.org/show_bug.cgi?id=98909

Thanks for the explanations. As you probably have noticed, I too think that's important and probably will give the problem some consideration.

It's certainly a complex issue, not only at Mageia level but also UPSTREAM.

> 2-as a per user setting to override a globally configured Xft.dpi (Mageia 5 sets it in Xresources, and apparently elsewhere too, the latter of which is the reason for this bug);

I've seen that turning that KDE option off effectively makes Xft.dpi undefined in Mageia (as returned from xrdb -query | grep dpi). Even DisplaySize does not create it; the resulting correct dpi (in your case, 120, not 96) appears in xdpyinfo, for instance.

Dumb question, but where can we see Xft.dpi defined if the situation in the above paragraph applies?

Another one: In case you are complaining about MCC font size, did you install that KDE-GTK3 compatibility font module? (you get a GTK extra module under Fonts in Application Appearance, in System Settings)

I'm going to test it all on Mageia 6 and 5 (I'm in another computer now) and then report if I see something unexpected.

Finally, do you want to solve the problem for your own use or do you by chance design web pages?

Because the first might be solvable, the second, well, not so much.

The dpi in firefox can be set independently of the system dpi by changing the layout.css.devPixelsPerPx value in about:config.

There is a walk through from fedora here
https://fedoramagazine.org/how-to-get-firefox-looking-right-on-a-high-dpi-display-and-fedora/

CC: (none) => cae

Created attachment 8799 [details]
widescreen 144 DPI screenshot of KDE4 on MGA5

(In reply to Renato Dali from comment #10)
> I've seen that turning that KDE option off effectively makes Xft.dpi
> undefined in Mageia (as returned from xrdb -query | grep dpi). Even
> DisplaySize does not create it; the resulting correct dpi (in your case,
> 120, not 96) appears in xdpyinfo, for instance.
 
> Dumb question, but where can we see Xft.dpi defined if the situation in the
> above paragraph applies?

I was remiss in constructing comment 3. Further testing indicates that Xft.dpi apparently became a non-issue as of Mageia 4, confirming your observation. In today's testing of MGA4 and MGA5 with IceWM and KDE4, I found Xft.dpi non-null (set to 96) only in IceWM, and only if I did not first comment the last lines in /etc/X11/Xresources and /etc/X11/xdm/Xresources. In KDE it remains unset unless choosing to force DPI in the KDE fonts control module. These are expected behaviors.

> Another one: In case you are complaining about MCC font size, did you
> install that KDE-GTK3 compatibility font module? (you get a GTK extra module
> under Fonts in Application Appearance, in System Settings)

MCC depends on GTK3? That's an awful of KDE users! As you can see in this new attachment, KDE3 configuration is available in systemsettings in KDE4 in MGA5.
 
> Finally, do you want to solve the problem for your own use or do you by
> chance design web pages?

Primarily I'm an advocate for A11Y and U7Y for PC and laptop users with vision somewhere between 10% and 50-60%, visual acuity, not bad enough to need "assistive technology", but neither "good". My own use is a distant second. I spend only as much time in web design as necessary for advocacy.
 
> Because the first might be solvable, the second, well, not so much.

This screenshot was made on the same (freshly updated) MGA5 system as comment 3 but with a widescreen LCD. I stripped the old KDE settings from ~/.config and ~/.kde4, reconfigured Xorg for the different display, with qtconfig changed font-size from 9 to 10 and changed only Konqueror's default web browser engine to KHTML so as to match Firefox's configuration and ability to render http://fm.no-ip.com/Auth/dpi-screen-window.html as expected, which WebKit cannot do. All windows except Konsole's remain at their default sizes. To fully appreciate what the screenshot shows, it needs to be viewed such that the black blocks in the FF and Konq windows measure the indicated width. To highlight what's shown:

1-window decorations are much too small
2-titlebar fonts are much too small
3-KDE menu and panel fonts are much too small
4-much text in the welcome window is no more than unintelligible scribble, while the main/button items are hard to use because text is too small, with gray text on gray background
5-left MCC pane text is much too small, while its right pane icons are little bigger than totally useless, about like icons in System Settings
6-font sizes in KDE menu/panel, left MCC pane and Welcome window apparently are unaffected by either qtconfig font size or KDE font size settings.
7-Xft.dpi is unset (null)
8-default window open sizes other than KCalc and KCM modules are considerably inadequate
9-12pt @ 144 DPI equates to 24px (which means 10pt=20px; 9pt=18px; 8pt=16px; 10px=5pt=1.76mm)
10-dominant text size in MCC is considerably different than in System Settings, and than in the Welcome Window

What's causing KDE menu/panel fonts to be so tiny I have no idea. I cannot recall ever having seen such disjunction between menu/panel fonts and font settings in openSUSE/KDE4, Kubuntu/KDE4 or Fedora/KDE4.

Follow-up with Cauldron and Plasma remains blocked by bug 18317.

Sorry if I cannot give you a more considered and complete answer. I'm in a pinch because it's end of year, a critical time for me.

> MCC depends on GTK3?

I don't know whether it is gtk3 or gtk2. I have a faint memory that it is gtk-based since long (there must be a simple way to check that via some urpmq/urpmi tool or in MCC itself). There's a lot of software which don't use KDE settings because they're gtk(2|3) based: Inkscape, Gimp, Firefox... this is a source of suffering.

There's a package devised to transfer KDE font settings to Gnome configs. Just checked in MCC: it's called kde-gtk-config (effects are not instant when adjusts are made and may even require restarting the gtk application).

There are other problems, like changing the mouse pointer theme and seeing it does not work in drakconf/MCC (it's a user problem, mouse theme must be copied to a directory under "/root"). And so on... multiple choice brings problems.

> What's causing KDE menu/panel fonts to be so tiny I have no idea.

After you install the above mentioned package a new module appears in System settings/Application Appearance under Fonts -- called GTK, IIRC. There you can set some things including gtk apps default font size.

Try tweaking the Menu font in font settings to see what happens. I just have seen it works here in KDE, but maybe KDE reduces the font by 1 or 2pts... try setting it at 11pt to see if that helps. Yeah, I know it's a hack.

> I cannot recall ever having seen such disjunction between menu/panel fonts and font settings in openSUSE/KDE4, Kubuntu/KDE4 or Fedora/KDE4.

I'm looking at KDE right now (another distribution) and that problem does not occur. Must be really a Mageia thing.

Again, sorry for not being able to give a proper response now.

@Charles

Please read below about my trial and error adjustments of layout.css.devPixelsPerPx ...

@Felix

I did some experimentation which might allow some conclusions.

First, I selected 100% for the page zoom in Firefox to remove undesired deviations in measurements.

In second place, I went to this page:

https://en.wikipedia.org/wiki/Pixel_density

and verified that the rendering of the page was not correct. The square depicted there should be 2 inches, but it was somewhat off.

I then adjusted layout.css.devPixelsPerPx to 1.1 up from the recommended 1.0625 for my monitor -- by trial and error until the square had the desired size (2 inches).

Why was it off? My theory is that I've been interpreting that variable in a wrong way. What I wanted was to adjust the image as to see objects at their real size on screen; I surmise Firefox developers have another aim: they want to render pages at the same proportion as it would be rendered on a 96dpi monitor. Of course, as it is rather frequent, I might be wrong.

Then I checked my adjustments on these two pages:

https://pt.piliapp.com/actual-size/paper-a4/ and
https://www.piliapp.com/actual-size/cm-ruler/

I input my monitor size: 21.5 inch.

The results were flawless. Again, I checked that on your example page:

http://fm.no-ip.com/Auth/dpi-screen-window.html

Everything was correct, but I additionally adjusted layout.css.dpi to 0 (from -1) with no noticeable difference.

Another reason why that factor had to be 1.1 (IMHO) is that we have errors in screen measurements, rounding errors, maybe even errors in X11 (who knows?) etc. etc.

Next, I repeated my former test and tried to copy the note on your page and paste it on kwrite, with the same font (obtained with FF's "inspect element") and adjusting the window width so as to obtain line breaks at the same words.

I found that 11pt (or 11 in KDE units whatever they may be) was closer to your page rendered text -- in appearance, at least, but one line would not break at the same point.

Then I decided to manually adjust the size of the font in KDE. Amazingly, kwrite allows replacing a font size with a chosen measure. I saw that 10.5 replaced 11 in the size options. KDE does the same -- and never ceases to surprise me...

Further adjustments led to a size of 10.7 in KDE which made kwrite mirror perfectly your font (which seems to be 12pt; in my monitor it matches the 16px font).

For practical uses, I'd say a KDE size of 11 (for the same font!) is a reasonably good approximation to 12pt. For reference, I chose a default size of 16px and my monitor has 102dpi (21.5", 1920x1080).

Apart from the strange variations observed in Mageia's menu size, I believe KDE can be made to look like Firefox with some patience. On my side, I did it and it seems fonts are the same size (don't forget the kde-to-gtk compatibility package).

In other pages, though, I observed variations that I attribute to the page designer own preferences, or different methods to specify font size or some other reason. Wikipedia, for instance, seems to use a tad smaller font.

It's interesting that your page has a 16px font which increases as one changes FF's default font size from 16px to, say, 28 -- but the fonts in points (8, 10, 12 and 14pt) won't change.

I don't know if you're aware of problems in setting font size in pages one designs, but please also take a look at: http://terrillthompson.com/blog/589

With all that said, in practice, I use a FF extension called Zoom Page and most pages are set to be displayed at a default 120% -- not just because normal text is starting to be harder to read, but mostly because of the pictures -- details show up better at a bigger scale.

Sorry for an inaccuracy:

layout.css.devPixelsPerPx was actually _reduced_ to 1.01 (not 1.1).

Hi, Felix, I just browsed a few of your pages and found most of the things I said you already knew.

Also, I see you have an interest on web page design and strives to promote good practices -- which is both commendable and very necessary these days.

Merry Christmas, everyone!

(In reply to Renato Dali from comment #13)
> > MCC depends on GTK3?

> I don't know whether it is gtk3 or gtk2. I have a faint memory that it is
> gtk-based since long (there must be a simple way to check that via some
> urpmq/urpmi tool or in MCC itself). There's a lot of software which don't
> use KDE settings because they're gtk(2|3) based: Inkscape, Gimp, Firefox...
> this is a source of suffering.

ISTR that MCC and other Mageia tools make use of WebKit. If that's true, I suspect it's at the root of this. In web pages at least, if not entirely, WebKit doesn't seem to have any support for font sizing that is screen density dependent. IOW, pt always is equal to px (according to CSS specification that changed from CSS2), never varying according to DPI.

In KDE, TDE, word processing apps and most apps other than web browsers all use pt for specifying text sizes. GTK-built apps may be doing the same as web apps. Other than Gimp and Mozillas I don't think I have any other GTK apps that I ever use.
 
> Try tweaking the Menu font in font settings to see what happens. I just have
> seen it works here in KDE, but maybe KDE reduces the font by 1 or 2pts...
> try setting it at 11pt to see if that helps. Yeah, I know it's a hack.

Hacking is working around, not getting at the root problem, which is what this bug is supposed to be about.

(In reply to Renato Dali from comment #14)
...
> Why was it off? My theory is that I've been interpreting that variable in a
> wrong way. What I wanted was to adjust the image as to see objects at their
> real size on screen; I surmise Firefox developers have another aim: they
> want to render pages at the same proportion as it would be rendered on a
> 96dpi monitor. Of course, as it is rather frequent, I might be wrong.

What they are trying for is adhering to CSS specifications.

With layout.css.devPixelsPerPx appropriately set to 1.0, and configuring X to run an accurate match of logical screen density to physical screen density, it can render physical sizes with reasonable accuracy.
 
> Next, I repeated my former test and tried to copy the note on your page and
> paste it on kwrite, with the same font (obtained with FF's "inspect
> element") and adjusting the window width so as to obtain line breaks at the
> same words.

> I found that 11pt (or 11 in KDE units whatever they may be) was closer to

They are pt.

> For practical uses, I'd say a KDE size of 11 (for the same font!) is a
> reasonably good approximation to 12pt. For reference, I chose a default size
> of 16px and my monitor has 102dpi (21.5", 1920x1080).

@96DPI, 11pt is 14.6667px. With your 102DPI, it takes 15.5833px to make 11pt. So it will use 16px when 11 is called for, and 15px when 10.5 is called for. http://fm.no-ip.com/Auth/Font/font-rounding.html might be instructive for understanding the practicalities of font size rounding.
 
> Apart from the strange variations observed in Mageia's menu size, I believe
> KDE can be made to look like Firefox with some patience.

I don't understand your goal here.

> In other pages, though, I observed variations that I attribute to the page
> designer own preferences, or different methods to specify font size or some
> other reason. Wikipedia, for instance, seems to use a tad smaller font.

Most web sites that have redesigned since they stopped supporting IE6 are sizing without regard to user setings, e.g. largely or entirely in px. Even when they size in  relative units they usually start with a base size that is an arbitrary fraction of the user's default. Wikipedia is using a main body font sized to .875em, which means text is 76.5625% of the physical size (.875^2) of the browser default, somewhat larger than most web sites specify.
 
> It's interesting that your page has a 16px font which increases as one
> changes FF's default font size from 16px to, say, 28 -- but the fonts in
> points (8, 10, 12 and 14pt) won't change.

Referring to http://fm.no-ip.com/Auth/dpi-screen-window.html the pt column text depends on DPI while the px displayed is whatever the browser default is set to, assuming zoom level is 100%. Change your FF default size and the new setting will appear in my page on refresh. To change pt values requires changing X configuration and restarting it. This is what well-behaved apps do in their UI, automatically change the size of the sizes specified in KDE settings if you change to a display with a different DPI and have X change to match. If KDE is set to use size 10 while using 96 DPI, it will use 13px. Change to a 144 DPI configuration, and size 10 will use 20px automatically. Change to 168 and 10 will use 23px automatically.
 
> I don't know if you're aware of problems in setting font size in pages one
> designs, but please also take a look at: http://terrillthompson.com/blog/589

He writes little that I haven't already written long before in the linked pages at the top of http://fm.no-ip.com/Auth/wauth1.html I appreciate your having shown me that page. It's rare to see anyone in the web design business write that user respect should be job 1.

> ISTR that MCC and other Mageia tools make use of WebKit.

I don't know, but this has been developed since the epoch of Mandrake -- (TM), (C) the owners etc.

Wikipedia has a "drakconf" entry stating it was developed in Perl. When I read the gurus talking, it seems I heard the word Perl being mumbled more than once. Maybe Python would have been a better idea...

> In KDE, TDE, word processing apps and most apps other than web browsers
> all use pt for specifying text sizes.

Me, too, but recently I thought about testing Xfce and LXDE, out of concerns about Plasma's stability.

> Hacking is working around, not getting at the root problem,
> which is what this bug is supposed to be about.

I also consider important to fix the bug at its origin -- and even if we're unable to fix it, but come to understand the root cause, that is worthy in itself, in a way.

Small deviations might take place, no matter how accurately one constructs any device. Because of all that, we use a "engineering" mentality and adopt correction factors to make e.g. sizes on screen match real objects (like a 30cm ruler).

BTW, though I succeeded in making onscreen measurements match real life, the "Your DPI" page states (as you warn in the Note) a 101dpi; perhaps because of that the available width is reported as 1888... even in fullscreen when it should be 1920.

> With layout.css.devPixelsPerPx appropriately set to 1.0, and configuring X to run an accurate match of logical screen density to physical screen density, it can render physical sizes with reasonable accuracy.

Thanks, now I understand why the factor I used was 1.01: that means I set DisplaySize very close to the correct measure. Maybe I should revise it until the factor can be 1.0 and sizes get even more accurate.

>> Apart from the strange variations observed in Mageia's menu size, I believe
>> KDE can be made to look like Firefox with some patience.

> I don't understand your goal here.

Well, generally speaking the overall aim is to make all parts of a Linux system follow unified settings. I try to make everything coherent, but it's not easy (see e.g. bug 15641... not really a bug).

Usually, I strive to do the opposite: make Firefox fit well in KDE font settings.

In the present case, though, I was merely trying to determine which size was effectively being rendered by Firefox, by adjusting KDE fonts until I got a perfect match with regard to:

- visual size aspect and
- line breaking.

That is because I have more confidence in KDE to follow what is set in its preferences than in Firefox. Not that FF is bad, but there are _way_ more variables involved...

> Most web sites that have redesigned since they stopped supporting IE6
> are sizing without regard to user setings...

What do you think about extensions like Zoom Page? I know that's also a hack, but I found that invaluable at reducing web page size disparities -- because it can remember site-specific settings...

Frankly, no matter if we really make Mageia the most accurate distro regarding font metrics... trying to make every web page somehow follow good practices would be very quixotic, to say the least.

> Referring to http://fm.no-ip.com/Auth/dpi-screen-window.html the
> pt column text depends on DPI while the px displayed is whatever
> the browser default is set to, assuming zoom level is 100%. [parts omitted]

The thing is that we actually have it backwards: historically, "pt" is a length unit like a meter -- in modern times, 1/72 of an inch. Since computers have no eyes, we construct them to base the size of a point on a known quantity: dots per inch. But problems arise when something which should be constant can vary from one computer model to another -- or even be adjusted at will by developers, distributors or the end user.

Were that the end of the story, we should get some relief by recommending the user to make sure he has the correct dpi which would ensure that an inch measures exactly one inch on the screen (which is what you already do). But the problem is that people use non-units (px), different environments have different settings (like Qt x GTK), algorithms have different assumptions (even rounding of the font sizes can follow different rounding conventions!). I read that Gnome makes it worse by allowing dpi change! I hope this is not true, because it will create a lot of trouble for its users.

Perusing your web pages, I concluded that much of what I recommended was already researched in more depth by you; that is why I apologized earlier; I guess nonetheless our aims overlap to some extent, even if we come from different directions.

(In reply to Renato Dali from comment #18)
> Usually, I strive to do the opposite: make Firefox fit well in KDE font
> settings.
 
> In the present case, though, I was merely trying to determine which size was
> effectively being rendered by Firefox, by adjusting KDE fonts until I got a
> perfect match with regard to:

This bug is about UI and  applications exclusive of output within browser viewports. Browser output is its own special problem, primarily due to web pages being designed primarily to please web site constructors and web site owners, but also in significant part due to the CSS3 specification change that eliminated physical sizes (pt, cm, in, mm, etc) meaning what they mean in the rest of the world's contexts.
 
> What do you think about extensions like Zoom Page? I know that's also a
> hack, but I found that invaluable at reducing web page size disparities --
> because it can remember site-specific settings...

The zoom concept as it applies to browser viewports is a defensive construct. It wouldn't be necessary but for offensive (disrespectful) design practices. It's a kludge, a hack. 
 
> > Referring to http://fm.no-ip.com/Auth/dpi-screen-window.html the
> > pt column text depends on DPI while the px displayed is whatever
> > the browser default is set to, assuming zoom level is 100%. [parts omitted]
 
> The thing is that we actually have it backwards: historically, "pt" is a
> length unit like a meter -- in modern times, 1/72 of an inch. Since
> computers have no eyes, we construct them to base the size of a point on a
> known quantity: dots per inch. But problems arise when something which
> should be constant can vary from one computer model to another -- or even be
> adjusted at will by developers, distributors or the end user.

Again, what happens in a browser viewport is secondary to this discussion because it's a special case. Web designers through CSS and scripting have been given, and with rather few exceptions exercise, excessive power to control viewport output without regard to propriety for the user's environment.

All sizes everywhere should be handled by the computer, not just font sizes. It's something computers are good at doing automatically, and people who can't see the ultimate screen output are particularly bad at doing. The user configures the ideal sizes for particular design elements or contexts through his environmental settings application. Once that's done, applications should respect those sizes, using them or fractions thereof as sizing units. In CSS such sizes are provided by the em, rem, ex and % units, plus xx-small, x-small, small, medium, large, x-large and xx-large. It shouldn't matter at all what unit of measurement was used to determine the sizes specified through the user configuration application.

Making elements particular physical sizes is an exceptional sizing case. There are obviously situations where it needs to be possible to make objects at least resemble particular physical sizes, with the understanding that accuracy does indeed depend on an accurate match between logical display density and physical display density. But use of physical sizes must be an exception to general design practice that sizing should normally be relative to and respectful of the sizes configured by the user. Arbitrary px sizes in application development should not even be possible. Instead, they should always be relative to user specified configuration. Always.
 
> I read that Gnome makes it worse by allowing dpi change! I
> hope this is not true, because it will create a lot of trouble for its users.

The way I understand it, Xft.dpi provides a "knob" that Gnome users can "turn" to globally zoom or unzoom their entire environment, which is initialized to 96 DPI without regard to physical display density. I think XFCE and/or Enlightenment do similarly.

It shouldn't matter how a user gets the respect he deserves, as long as he gets it. Unfortunately for non-Gnome users, the Gnome commit referenced in comment 9 has produced a serious obstacle to achieving that end for users of GTK3- and GTK4-built apps in environments of a density higher than the 96 reference standard (which IMO is outside the scope of this bug).

> This bug is about UI and  applications exclusive of output
> within browser viewports.

That's good in order to keep objectivity. I'll move some aside points to the end, if I'm allowed to do it.


In that vein, the basic idea is to make sure that the user can set and see a 12 pt sized font and not diminutive letters. I understand this is the point of this bug report.

Since Xft.dpi is no longer messed up by anything, it's my understanding that a convenient DisplaySize option can make KDE4 display correctly sized text in Mageia 5. This is what I verified. I also tested Xfce in Mageia 6 and found it to work the same, if a forced dpi setting is not used.

On both DEs the user still has the option to use a forced dpi setting. I understand this affects text and may not affect e.g. icons.

This way, if we just care about _one_ DE showing the correct size, IMHO the bug is solved (and probably since some time it has become INVALID).

If the intent is to check it under KDE, we got two options:

1) for Mageia 5, it is likewise solved IMHO;
2) for Mageia 6/Cauldron, we'll have to wait for the blocking bugs to be solved.

What do you think, Felix?

=====================================

Now, some aside aspects:

> Making elements particular physical sizes is an exceptional sizing case.

We need some way to know whether we're talking about the same thing. Any reference will do, but physical sizes are useful to the extent they are already known to everyone. We can begin to talk only after we make sure everybody can see the same size... and know it! If people see different things (and don't know it) there will be endless and futile arguments.

> The zoom concept as it applies to browser viewports is a defensive construct.

AFAIU a user should have the ability to zoom things. This is akin to using a magnifier in the real world. Not offering that is what I deem to be disrespectful.

> Instead, they should always be relative to user specified configuration. Always.

I agree with that. And it's a zoom factor which enables us to have the best of both worlds: a common size reference and images adjusted to the user needs. All the time.

So how can the web designer control what the user sees? He can't. It is left to user to choose a 1:1 scale and then appreciate a page the way it was designed -- if he so chooses.

> It shouldn't matter how a user gets the respect he deserves,
> as long as he gets it.

That borders on Philosophy, but it is a pet peeve of mine.

It matters how respect is earned. If one has to fight to conquer respect, whatever respect is gained is worthless -- because it is in reality just fear.

There is one thing I forgot. In Mageia (5, for instance) the KDE menu is rendered with a font that is at least on point smaller than what is set in KDE SystemSettings / Application Appearance / Fonts.

As Felix explains well in one of his pages, the effect of this reduction is quadratic: for example, the characters don't go from 8pt to 7pt (12.5% smaller), they go from 8x8 to 7x7 (well, something like that), which means there has been a ~23.4% reduction. That can be unreadable for some people.

At least in one other distribution, this difference is not present: the KDE menu is rendered with exactly the size chosen by the user.

is this still valid with current cauldron ?

CC: (none) => mageia

Created attachment 9108 [details]
108 DPI mga6b2/plasma screenshot

(In reply to Nicolas Lécureuil from comment #22)
> is this still valid with current cauldron ?

I can see no evidence of improvement even at only 108 DPI. e.g. mageiawelcome description text is painfully tiny (as is the left pane of MCC), and the gray on gray "buttons" in mageiawelcome are similarly tough to read.

Hello,
New release of Mageiawelcome should now be more adaptative to screen resolution and default font size.
Can you confirm?
1.93 in cauldron.

CC: (none) => yves.brungard_mageia

I haven't had Cauldron running since Mageia 6 release. Hopefully I can get to it before much longer.

(In reply to papoteur from comment #24)
> New release of Mageiawelcome should now be more adaptative to screen
> resolution and default font size.
> Can you confirm?
> 1.93 in cauldron.

I just made my first mga6 to mga7b2 upgrade, then tried to try mageiawelcome. It was not installed, so I tried to urpmi mageiawelcome (v1.95), and by selecting the either option, lib64gtk-gir3.0 or lib64gtk-gir2.0, it wants to install 48 packages using 122MB of disk space, a big bunch of mostly gtk, python & qt5 packages not needed by the DE I am using (TDE).

I went ahead and installed those to try to follow up here, but now the original bug is exhibited with a vengeance. I try to work around this via an xrandr script, but no matter where I put script in /etc/X11/:

/etc/X11/Xsession.d/
/etc/X11/xsession.d/
/etc/X11/wmsession.d/
/etc/X11/xinit.d/xinitrc.d/
/etc/X11/xinit.d/

the script gets ignored. So I tried to use IceWM instead of TDE, but it won't install because icewm-theme-oxygen-aya cannot be installed because mageia-theme cannot be installed because bootsplash cannot be installed because of unwanted unsatisfied plymouth*. IceWM-light also refuses to install, for same basic reasons.

Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information.

Closing as OLD.

Resolution: (none) => OLD
Status: NEW => RESOLVED

Created attachment 12916 [details]
screenshot @ 120 DPI showing fonts still undersize in MCC & mageiawelcome

There is still improvement needed on MCC and mageiawelcome.

It's not very welcoming to have a "welcome window" that makes squinting required to read the little bit of text surrounded by vast areas of "whitespace".

MCC's left pane fonts are uncomfortably tiny compared to selections texts in the right pane.

Version: Cauldron => 8
Resolution: OLD => (none)
Status: RESOLVED => REOPENED

Hi @Renato Dali (Comment 14)

Can you please tell me how did you check the dpi adjustment?

Also, I really want to know, Is there a difference between DPI and PPI?

Because when I check on the online ruler(https://ruler-online.net), it shows PPI.
What's that?

CC: (none) => royalengg2827