Tk Source Code

[tk scaling] does not work correctly for Xft/FreeType font rendering on X11/Wayland systems.  The bug exists for Tk 8.6 and 8.7.

THE BUG:

If [tk scaling] is increased, screen lengths (e.g. widget borders) defined in points should become larger, if defined in pixels they should be unchanged.  See extract from tk(n) below.

Tk fonts drawn with Xft do not work this way.  Taking care to re-configure fonts and draw fresh widgets after each change in [tk scaling]:

* A font sized in points has the same screen size and pixel measurements when [tk scaling] is changed.
* A font sized in pixels shrinks when [tk scaling] is increased.

This suggests that Xft works with screen distances, and therefore
(a) ignores [tk scaling] for fonts sized in points
(b) interprets [tk scaling] as specifying the screen distance to be used for a font sized in pixels.

Outcome (a) suggests that Xft is aware of the display dpi without obtaining a value from [tk scaling].  If this information can be read from Xft, it would be useful in library/scaling.tcl where (on X11 systems) [tk scaling] is set.

The bug is not evident if [tk scaling] is set to the actual screen resolution and then left unchanged (and this is a workaround for the bug).  Many scripts use fonts sized in points, and in those scripts the bug appears to be that changes in [tk scaling] have no effect (bugs [71b20a4c69], [3426824]).  The nature of the bug is clear only if fonts are sized in pixels and also [tk scaling] is changed.

See example script in attached file tkScalingBugXft.tcl

====

tk(n) states for [tk scaling]:

A  “point”  is  a unit of measurement equal to 1/72 inch.  A scaling factor of 1.0 corresponds to 1 pixel per point, which is equivalent to a standard 72 dpi monitor.  A scaling factor of 1.25 would mean 1.25 pixels per point, which is the setting for a 90 dpi monitor; setting the scaling factor to 1.25 on a  72  dpi  monitor would cause everything in the application to be displayed 1.25 times as large as normal.  The initial value for the scaling factor is set when the application starts, based on properties of the installed monitor, but it can be changed at any time.  Measurements made  after  the  scaling factor is changed will use the new scaling factor, but it is undefined whether existing widgets will resize themselves dynamically to accommodate the new scaling factor.

Hi Francois,

Apologies that I am busy this week and cannot give a full report: I will reply in detail in a few days.

The screenshots that you have posted show Tk behaving correctly - and some of my systems do the same.
Another system gives the wrong result, as shown in the attached screenshots (for Tk 8.6 and Tk 8.7).
Experimentation with redirection of the display to another machine shows that the bug is correlated with the X11 server and not the Tcl/Tk X11 client.  Perhaps the bug is not in Tk.

I will supply more information shortly.

Best wishes,

Keith.

Keith, could you please describe the expected result from the test script you have attached?

On Linux with Xft, I'm seeing what you are describing: "If [tk scaling] is increased, screen lengths (e.g. widget borders) defined in points should become larger, if defined in pixels they should be unchanged.". I'm attaching screenshots on Linux.

What I'm seeing on Linux is the same with or without Xft, and is again the same as on Windows 10.

Yet more bug reports describe the same issue with font scaling on X11: [bf95ba78d7] and [1fba28d328].

In addition to bugs [71b20a4c69], [3426824] mentioned above, font sizing bugs [844fbf66f6] and (likely) [0917069c05] describe similar issues.