Tk Source Code

The CI runners at GitHub being happy I'm merging and closing this ticket.

Thanks to the OP for the report, and many thanks to Casba Nemethi for the investigations and help!

Good suggestion, it seems to work. Thanks!

Proposal: Replace the 11 with 13 and the 22 with 26. I suspect that the xvfb has no times bitmap font of pixel size 11, but maybe it has one of pixel size 13.

The latest version of font-44.1 now passes with Xft but fails --without-xft, see the CI runner tests results here. Sigh.

I had looked at this already, the segfault is due to the too small size in this line, I didn't bother to change this to a malloc'ed array.

I have changed DEBUG_FONTSEL to 0, thanks.

Shouldn't DEBUG_FONTSEL be set to 0?  Otherwise the automatic CI on GitHub produces too much output.  In addition, I have seen that if it is on (1) then the test entry-13.24 causes a reproducible segmentation fault.  I havn't had time to examine where exactly the buffer overflow (?) happens.

Your proposal sounds reasonable to me and I have followed it, see latest commits in the bugfix branch. In addition I have just added a pointer to the present ticket in case font-44.1 was found to be failing again in the future, since your proposal to change to "times -11" could be defeated by future changes in the test file (so this is not very robust, but I admit I have no better idea).

I see the same problem when using xvfb-run. I think you are right that the failure exhibited when running xvfb or KDE (the latter on some machines only) is probably due to some kind of font caching. The following experiment seems to confirm this theory: If in font-44.1 you replace the two occurrences of 12 with 11 (for example) then the test passes.

This leads me to the following proposal: Instead of spending even more time desperately trying to change the code in such a way that the current version of font-44.1 passes in all environments, just change font-44.1 as described above. Even better (since more readable): Restore font-44.1 to its original version and after that replace "times -12" with "times -11" and "result 24" with "result 22".

I am attaching the output of "fossil diff", which contains the above-mentioned changes in font.test, along with a few further improvements in tkUnixRFont.c. IMHO, the two replacements of (int) by lround() make the debug output more realistic. The invocation of TkFontGetPoints() in GetTkFontAttributes() has made it necessary to have tkwin again as first argument of GetTkFontAttributes().

On my Debian 11 I can also reproduce the failure of font-44.1 when using xvfb to run the tests (the way the tests are performed by the CI runner).

KDE plasma version 5.20.5 here.

I have installed KDE Plasma (5.20) on LMDE 5 (which is de facto Debian 11 with the Cinnamon desktop) and repeated the test on KDE. Both font-42.3 and font-44.1 pass for me, but it is a bit strange that in the last two lines of the output for font-44.1, the length reported by MeasureChars() is 4 and 6, respectively (rather than 11 and 16), although the font size reported by GetTkFontAttributes() is 24 (corresponding to "tk scaling 0.5").

Do you have an older KDE Plasma version on your Debian 11 system?

I see the same output on KDE neon, where KDE Plasma has the latest currently available version 6.0.

The failure of font-44.1 I have reported previously below was for Debian 11 running KDE Plasma.

If on this same system I use Gnome on Xorg instead of KDE Plasma I do not see this failure when running;

    make test-classic TESTFLAGS="-file font.test -match \"font-42.3 font-44.1\" -verbose bepst"

Interesting, isn't it?

Yesterday I ran the test on Linux Mint 21.3, which is based on Ubuntu 22.04. Today I repeated it on LMDE (Linux Mint Debian Edition) 6 (which is based on Debian 12), 5 (which is based on Debian 11), and Ubuntu 20.04. In all of these cases, the result remained the same as on Ubuuntu 23.10. Needless to say, every time I used a freshly built Tk (i.e., a Tk version built on that system).

Regarding "family Nimbus Roman size 24", which I get in font-44.1: In the original version of this test, 24 was the expected result, corresponding to "tk scaling 0.5". The fact that I get this same result on Ubuntu 23.10, Ubuntu MATE 23.10, Ubuntu 20.04, LMDE 5, LMDE 6, and Linux Mint 21.3, makes me wonder why the result on your Debian 11 system and on GitHub running Ubuntu 20.04 is different from what I get. Very, very strange!

My graphics card on this Debian 11 laptop is an NVIDIA Corporation GT215GLM [Quadro FX 1800M], but I can't imagine how the graphics card could have an impact on how fonts are selected by Tk.

The configuration of the CI runner on Linux for the tests is ubuntu-20.04 (see the workflow file), which is detailed here for the software. The hardware is virtualized and described here.

I'm suspecting some kind of font caching happening, or perhaps this is only due to the differences in fonts our systems feature, which lead to different substitutions/choices at runtime.

Your output shows that GetTkFontAttributes has "family Nimbus Roman size 9" in font-42.3, and later in font-44.1 it has "family Nimbus Roman size 24".

In contrast, my output shows GetTkFontAttributes has "family Nimbus Roman size 8" in both tests.

What is very strange is that in both tests the request is for what I understand to be the same font:

TkpGetNativeFont: -xyz-times-*-*-*-*-[ 12.0 0 12.0 0]-*-*-*-*-*-*-*

TkpGetNativeFont: times -12

I'm in the dark with you here. However what I find very interesting is that when running 42.2 + 44.1 (which is again a request for the same font) instead of 42.3 + 44.1 then 44.1 passes. With 42.2 GetTkFontAttributes has "family Nimbus Roman size 23", which makes the difference I guess.

This is *very* myterious.  I have repeated the test on Wayland, but got exactly the same result as on Xorg.  Maybe the graphics card makes a difference?  I have an AMD card -- how about you?  And: Does anybody know the configuration of the Linux PC used on Github?  Does Debian behave differently from Ubuntu (which is just a more user-friendly Debian system)?

I have spent many ours trying to understand what is going on here, but without success.

The failure of font-44.1 is reproduced at Github Actions:

https://github.com/tcltk/tk/actions/runs/9188994947

On Ubuntu MATE 23.10 I get the same result as on Ubuntu GNOME 23.10: Both font-42.3 and font-44.1 pass.  And font-44.3 works as expected, too, with both display scalings 100% and 200%.

The relevant part of the output:


---- font-42.3 start
TkpGetNativeFont: -xyz-times-*-*-*-*-[ 12.0 0 12.0 0]-*-*-*-*-*-*-*
TkpGetFontFromAttributes: times -12 0 0
GetTkFontAttributes: family Nimbus Roman size 9 weight 80 slant 0
MeasureChars: I length 4 bytes 1
MeasureChars: 0 length 6 bytes 1
++++ font-42.3 PASSED
TkpGetNativeFont: times 0
TkpGetFontFromAttributes: times 0 0 0
GetTkFontAttributes: family Nimbus Roman size 12 weight 80 slant 0
MeasureChars: I length 5 bytes 1
MeasureChars: 0 length 8 bytes 1
---- font-44.1 start
TkpGetNativeFont: times -12
TkpGetFontFromAttributes: times -12 0 0
GetTkFontAttributes: family Nimbus Roman size 24 weight 80 slant 0
MeasureChars: I length 11 bytes 1
MeasureChars: 0 length 16 bytes 1
++++ font-44.1 PASSED


I am attaching the complete output in test.out.

I have committed a slightly better debug support in tkUnixRFont.c. Could you please "fossil update bug-8162e9b7a9", build Tk and then run:

make test-classic TESTFLAGS="-file font.test -match \"font-42.3 font-44.1\" -verbose bepst"

Here is (the relevant part of) the output I get:

<snip>
---- font-42.3 start
TkpGetNativeFont: -xyz-times-*-*-*-*-[ 12.0 0 12.0 0]-*-*-*-*-*-*-*
TkpGetFontFromAttributes: times -12 0 0
GetTkFontAttributes: family Nimbus Roman size 8 weight 80 slant 0
MeasureChars: I length 4 bytes 1
MeasureChars: 0 length 6 bytes 1
++++ font-42.3 PASSED
TkpGetNativeFont: times 0
TkpGetFontFromAttributes: times 0 0 0
GetTkFontAttributes: family Nimbus Roman size 12 weight 80 slant 0
MeasureChars: I length 5 bytes 1
MeasureChars: 0 length 8 bytes 1
---- font-44.1 start
TkpGetNativeFont: times -12
TkpGetFontFromAttributes: times -12 0 0
GetTkFontAttributes: family Nimbus Roman size 8 weight 80 slant 0
MeasureChars: I length 4 bytes 1
MeasureChars: 0 length 6 bytes 1


==== font-44.1 TkFontGetPixels: size < 0 FAILED
==== Contents of test case:

    set oldsize [expr {-(-12.0 / $oldscale)}]
    tk scaling 0.5
    expr {round([font actual {times -12} -size] / $oldscale * 0.5) - round($oldsize) == 0}

---- Result was:
0
---- Result should have been (exact matching):
1
==== font-44.1 FAILED
<snip>

So I'm only running two tests, font-42.3 and font-44.1.

I have found that when 42.3 is not run then 44.1 passes; when 42.3 is run 44.1 fails. This is also true if I replace 42.3 by 42.5 but not when replacing 42.3 with 42.2 (for instance).

I have run "make test-classic" again on Ubuntu (Xorg, not Wayland), on an unscaled display.  The only font-related tests that fail for me are font-4.9 and font-21.6 -- both of them are not relevant regarding the font size.

Both the old and new versions of font-44.1 fail for me on Linux Debian 11 with a display scaling of 100% when previous tests from font.test are run. Example of failure (this is for the old version of the test):

=== font-44.1 TkFontGetPixels: size < 0 FAILED
==== Contents of test case:

    tk scaling 0.5
    font actual {times -12} -size

---- Result was:
9
---- Result should have been (exact matching):
24
==== font-44.1 FAILED

Changes now committed, let's see what GitHub Actions thinks of them.

For the records, here are my test results, Csaba. This is on Linux Debian 11, Tk built with Xft.

Display scaling 200 %: running font.test or only font-44.* from font.test passes in both cases. The test script from ticket [61550f38bf] passes.

Display scaling 100 %: running only font-44.* from font.test passes, but running the entire font.test fails. The test script from ticket [61550f38bf] passes.

So we're not yet totally done here.

Besides, I have yet to understand/test what will be happening when this will be merged to trunk though, since trunk does not show the bug even without this change.

BTW:  The test script you mentioned in ticket [61550f38bf]

  package require Tk
  font metrics -xyz-times-*-*-*-*-12-*-*-*-*-*-*-* -linespace
  tk scaling 0.5
  font actual {times -12} -size

returns for me 24 with Tk 8.6.12, 8.6.13, 8.6.14, trunk, and the patched core-8-6-branch version.

@Francois:

- Both my test script and the new test font-44.3 work on Ubuntu with a display scaling of 200% (and of course, also with a display scaling of 100%).

- After inserting the old version of font-44.1 before the new one (and renaming it to font-44.0), I ran "make test-classic", with the result that both font-44.0 and font-44.1 passed.

@Csaba: are you totally sure? I mean, it's tricky:

- does it work with a display scaling of 200% in addition to the 100% case?

- font-44.1 may pass in isolation but not when the entire font.test file is run, or the opposite. See my findings in ticket [61550f38bf] that lead to my (erroneous?) commit [84cd707d].

I can't check myself for the moment, sorry.

@Francois:  Please forget what I wrote about your 3rd change, in line #510.  After reverting that change, too, everything works for me as expected, including both the old and new versions of the font-44.1 test and the newly added test font-44.3.

@Jan: you're right. Thanks for your review, what you write makes sense. I have reverted this.

@Csaba: Many thanks for your input! I have committed your version of GetTkFontAttributes(). This makes font-44.3 now pass (Linux Debian 11, display scaling 200%), but font-44.1 now fails because [font actual {times -12} -size] returns the point size instead of the pixel size. I have starred at the code for quite some time but could not make font-44.* all pass at the same time. Thinking more, perhaps font-44.1 is incorrect as a test (I mean, even the original version of this test, before my changes in [84cd707d]).

@Francois:  In commit [84cd707d] you changed the order in which XFT_SIZE and XFT_PIXEL_SIZE are passed to XftPatternGetDouble().  Your new code starts by calling this function with XFT_PIXEL_SIZE, which sets ptsize to 12.0 and thus the variable size will have the value -12.0.  This is due to the fact that TkDefaultFont was configured with "-size -12".  (Side note: Even if TkDefaultFont would have been configured with "-size 9", this call would return XftResultMatch and thus it would set ptsize to 12.0, resulting again in size = -12.0.).

The 2nd change that you made is that in line #218 you assign TkFontGetPoints(tkwin, size) rather than just size to faPtr->size.  Being that now size is negative, that function sees it as a font size in pixels and thus it returns the corresponding size in points.  However, the result of this conversion is highly dependent on [tk scaling], which in our example is 1.33, in spite of the fact that the display's scaling is set to 200%.  For this reason, the function will return 9 (pt) rather than 18 (pt).  The same code works as expected in Tk built from trunk or core-8-branch, because the scaling-related stuff contained in these versions makes sure that [tk scaling] will be 2.66.

The code obtained by reverting the two above-mentioned changes (only) works for me as expected: The two labels have the same size and the output reads:

-family {Noto Sans} -size 5 -weight normal -slant roman -underline 0 -overstrike 0]
-family {Noto Sans} -size 5 -weight normal -slant roman -underline 0 -overstrike 0]

The size 5 is the result of the incorrect [tk scaling].  The labels appear pretty small but of the same size.  By prepending "tk scaling 2.66" or "font configure TkDefaultFont -size 9" to the test script, the two labels will be rendered in the same size as with Tk 8.6.13.

Note that in your commit [84cd707d] there is a 3rd change, in line #510.  IMHO, that change should not be reverted.  The original version in line #509 appears to me as a bug, which had the side effect that it doubled the size of the two labels.

I am attaching my version of the GetTkFontAttributes() function, which is basically the result of the two above-mentioned revert actions.

I don't think [7edb872510f3565a|this] comment makes sense.....

Yes XFT_PIXEL_SIZE is a double, but that's already handled in line 191. The line you changes is handling a fallback, for the case that reading both XFT_PIXEL_SIZE and XFT_SIZE as a double failes, then it is tried again as an integer. I suspect there are older systems which (wrongly) implemented XFT_PIXEL_SIZE as an integer.

I fully agree with you, Francois. Color makes life more beautiful ;-) Harald

I had seen this comment, I even wrote an answer but finally deleted it since debating this is a waste of time IMO.

I'm simply following our own guidelines: https://wiki.tcl-lang.org/page/Getting+Started+With+Working+On+The+Tcl%2FTk+Core#fc972014a3d342706c845dc4abb7b551e1d90c76a2a35b95baf63c52aab54cec

<off topic> Comment by magic Richard: https://fossil-scm.org/forum/forumpost/3b94306d21 </off topic>

<off topic>
Yeah, sorry for the \n in the commit color. Happened when typing

fossil commit -m "commit message" --branch bug-xxx --branchcolor "#f0a0a0

and I hit the newline key before closing the last quote. This quote is needed otherwise #something is considered a comment in the shell.
</off topic>

Commit [86036921] broke tk web interface. There was a "\n" within the color specification. Weired bug... Thanks for all, Harald

I don't think commit [84cd707d] introduced this issue. I think this commit exposed an issue there already was, which was solved in trunk but never backported. That's my guts feeling.

I have reproduced this on Linux with a display scaling of 200%. It only happens with Xft, not without, and on core-8-6-branch but not in trunk.

I have added a (currently failing) test case in [86036921] and have performed a first analysis of the problem. The commit [84cd707d] I made indeed introduced this issue. I have ideas about the cause. However I can't explain yet why the issue does not happen with trunk (Tk 9.0).

I will investigate more.

@csaba: thanks, no problem. This is already a ticket, so no ticket needed, was stupid. Maybe, the title may be corrected if more insight is known. But magic-Jan is already on the track...

Thank you all, Harald

@Harald: I have just realized that I probably misunderstood your question.  If you meant whether I could _submit_ a ticket related to this one then my answer is "yes".  Just not right now, but maybe tomorrow.

I suspect this commit as the cause for this change. I don't see anything wrong with this commit, but it could result in a change in font size.

@fvogel, what you you think?

I created a [a2234d9121f716eb|branch] for experimenting (which doen't mean I intend to merge this to core-8-6-branch!)

The same change was also done in Tk 8.7 and 9.0, so it's strange that they don't have any problem.....

@Harald: I'm afraid, I must say "no" to your question.  Everyting I have made related to the scaling is for Tk 8.7 and 9, nothing of that stuff has gone into Tk 8.6.  I have no expertise related to the fonts in Tk, at least not at C level.  Both Jan and Francois are by far more knowledgeable than I regarding the implementation of the font API.

Hi Csaba, you are the magic scaling expert. Thanks for that test. Could you author a ticket?

Hi Philipp, thanks for bringing this up. I tested Csabas script on Windows with TCL 8.6.13 and 8.6.14 with 100% and 200% setting on Windows. They constantly return:

-family {Segoe UI} -size 9 -weight normal -slant roman -underline 0 -overstrike 0]

Take care, Harald

Hey everyone, thanks for the replies! I'd agree with the assumption that my code can be translated as font2 being derived from font1. And seeing that you can replicate it with "pure tcl" sounds great, so it's not just some tiny edge case. I'd be interested to see if this happens on other OSs to, but I have absolutely no idea how to test it on Windows & macOS. 

There shouldn't be any differences in font capabilities, as both versions I tested were created on the same version of the Freedesktop SDK, the base of Flatpaks:
https://gitlab.com/freedesktop-sdk/freedesktop-sdk

Small correction: The output produced by Tk built from trunk is

-family {Noto Sans} -size 10 -weight normal -slant roman -underline 0 -overstrike 0]
-family {Noto Sans} -size 10 -weight normal -slant roman -underline 0 -overstrike 0]

This is due to the fact that in Tk 8.7 and later TkDefaultFont on X11 is created with a size of 10.

Unfortunately, my Python knowledge is quite limited, let alone the one related to tkinter.  For this reason, I can only guess that font2 is derived from font1 as shown in the following Tcl script:


set font1 TkDefaultFont
set font2 [font create Font2 {*}[font actual $font1]]

puts [font actual $font1]]
puts [font actual $font2]]

label .thing1 -text Thing1 -font $font1
label .thing2 -text Thing2 -font $font2
grid .thing1 .thing2 -padx 6p -pady 6p


I have tested this script on Ubuntu 23.10, with a display scaling of 200%.  With Tk 8.6.13 or earlier (as well as with Tk built from trunk), the two labels appear rendered in the same font and the two puts commands produce the output

-family {Noto Sans} -size 9 -weight normal -slant roman -underline 0 -overstrike 0]
-family {Noto Sans} -size 9 -weight normal -slant roman -underline 0 -overstrike 0]

OTOH, with Tk 8.6.14 the first label appears quite small, the second one has the same size as with 8.6.13, and the output becomes

-family {Noto Sans} -size 9 -weight normal -slant roman -underline 0 -overstrike 0]
-family {Noto Sans} -size 18 -weight normal -slant roman -underline 0 -overstrike 0]

This seems to confirm the reported behavior and looks like a bug in Tk 8.6.14.

Dear Phillip, thanks for the ticket. To my knowledge, it is important for the Tk build, which font capabillities are build in on compile time. Is there any difference in xft & friends ?

Sorry, for the stupid comment from a Windows centric user. I have only seen that in the past...

If you look to the "changes" file, the followin entries may be relevant:

2023-01-05 Correct rounding of [nsFont pointSize] (nijtmans)

2024-01-03 (bug)[52df66] nonXft: [font measure] results inconsistent (vogel)

The issue is on Linux, right? On MacOS there are other changes...

Take care, Harald

@csaba, can you please hava look at this ticket?