Tk Source Code

Hi,
not a bug but when using text widget on my computer that is running macOS 10.15.1, the terminal report this:

2019-10-31 16:19:55.480 DLight[81101:588381] CoreText note: Client requested name ".SFNSMono-Regular", it will get Times-Roman rather than the intended font. All system UI font access should be through proper APIs such as CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:].
2019-10-31 16:19:55.480 DLight[81101:588381] CoreText note: Set a breakpoint on CTFontLogSystemFontNameRequest to debug.
2019-10-31 16:19:55.481 DLight[81101:588381] CoreText note: Client requested name ".SF NS Mono", it will get Times-Roman rather than the intended font. All system UI font access should be through proper APIs such as CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:].

best regards,
nicolas

As I said below, a better fix seems to be to call:
  [NSFont userFixedPitchFontOfSize:11];
instead of
 CTFontCreateUIFontForLanguage(fixedPitch, 11, NULL);
That results in a valid font in the Menlo family.


For the record, On November 15, 2019 I provided Apple with a short program to
demonstrate this bug.  They did not respond, and still haven't responded.
However, they now say:

Resolution: Potential fix identified - For a future OS update.

I will attach the program to this ticket.

I noticed the workaround proposed here (removing ".SF ") was changed again here:

https://github.com/tcltk/tk/commit/09fe4a9aaf45f55440dcd7af939040cc492c8acc

I wasn't able to find a reason for that change - could someone elaborate? I'm currently looking into a similar issue with my own application (which isn't using Tk).

Further investigation of this problem suggests that it is a bug in Apple's NSFontManager. Other system fonts with names beginning with a period are recognized by NSFontManager. Other ways of producing the default system fixed pitch font, such as calling

[NSFont monospacedSystemFontOfSize:11 weight:NSFontWeightRegular];

Other new bugs in NSFontManager have shown up, however. See ticket 90d555e088.

My pending bug report with Apple has not produced any results. After I finally insisted that the bug should be brought to the attention of an Apple Software engineer, instead of pretending that there is no bug, I stopped receiving any responses from Apple.

I received the following useless response from Apple:

"Please use CTFontCreateCopyWithSymbolicTraits() to find alternative faces
in the same family with the desired traits."

To call that function you need a font.  We don't have the font.  We have a
string representing the name of the font's family and some other information
like size and weight.

I wrote back to ask them to actually fix their broken font.  I will not hold by
breath.

The crash was caused by me not removing the call to CFRelease which had
presumably been needed when the font was created by Core Font.  The NSFont
method returns an autoreleased NSFont, which should not be released again.

I have merged the fix with the Menlo font and the call to CFRelease removed.

So I will close this ticket.

On HighSierra, I get this message:

bll-mac:/Users/bll/Desktop/BallroomDJ.app/Contents/MacOS/test.dir$ rlwrap ../darwin/64/tcl/bin/tclsh 
% package require Tk
2019-11-04 08:04:11.107 tclsh[786:7137] A system font, "Menlo-Regular 11.00 pt. P [] (0x7ff7e4d29db0) fobj=0x7ff7e4c3d240, spc=6.62", is requested to be deallocated. Ignoring...
8.6.10
% exit

I actually don't need to run this in my installer any more, so
it is not a stopper for me.

But it is rather odd.

I am getting an odd crash.
This happens in my installer.  If I run the script in question
outside of the installer, it is working ok.
This is just a tiny tcl script to make sure Tk works.

2019-11-04 07:06:38-08 bll-mac installd[620]: ./postinstall: 2019-11-04 07:06:38.259 tclsh[82042:799278] -[__NSCFType fontDescriptor]: unrecognized selector sent to instance 0x7f8355f48da0
2019-11-04 07:06:38-08 bll-mac installd[620]: ./postinstall: 2019-11-04 07:06:38.260 tclsh[82042:799278] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[__NSCFType fontDescriptor]: unrecognized selector sent to instance 0x7f8355f48da0'
2019-11-04 07:06:38-08 bll-mac installd[620]: ./postinstall: *** First throw call stack:
2019-11-04 07:06:38-08 bll-mac installd[620]: ./postinstall: (
2019-11-04 07:06:38-08 bll-mac installd[620]: ./postinstall:    0   CoreFoundation                      0x00007fff36ab3f53 __exceptionPreprocess + 250
2019-11-04 07:06:38-08 bll-mac installd[620]: ./postinstall:    1   libobjc.A.dylib                     0x00007fff6c9e0835 objc_exception_throw + 48
2019-11-04 07:06:38-08 bll-mac installd[620]: ./postinstall:    2   CoreFoundation                      0x00007fff36b3e106 -[NSObject(NSObject) __retain_OA] + 0
2019-11-04 07:06:38-08 bll-mac installd[620]: ./postinstall:    3   CoreFoundation                      0x00007fff36a5a6cb ___forwarding___ + 1427
2019-11-04 07:06:38-08 bll-mac installd[620]: ./postinstall:    4   CoreFoundation                      0x00007fff36a5a0a8 _CF_forwarding_prep_0 + 120
2019-11-04 07:06:38-08 bll-mac installd[620]: ./postinstall:    5   AppKit                              0x00007fff33db9321 -[NSFontManager traitsOfFont:] + 37
2019-11-04 07:06:38-08 bll-mac installd[620]: ./postinstall:    6   Tk                                  0x000000010d0110d7 TkpRedirectKeyEvent + 2327
2019-11-04 07:06:38-08 bll-mac installd[620]: ./postinstall:    7   Tk                                  0x000000010cf6cd89 TkCreateMainWindow + 169
2019-11-04 07:06:38-08 bll-mac installd[620]: ./postinstall:    8   Tk                                  0x000000010cf77a46 Tk_PkgInitStubsCheck + 31686
2019-11-04 07:06:38-08 bll-mac installd[620]: ./postinstall:    9   Tk                                  0x000000010cf78009 TkCreateFrame + 377
2019-11-04 07:06:38-08 bll-mac installd[620]: ./postinstall:    10  Tk                                  0x000000010cf6fb98 Tk_Init + 2168
2019-11-04 07:06:38-08 bll-mac installd[620]: ./postinstall:    11  Tk                                  0x000000010cf49690 Tk_CreateConsoleWindow + 80
2019-11-04 07:06:38-08 bll-mac installd[620]: ./postinstall:    12  Tk                                  0x000000010d015365 TkpInit + 581
2019-11-04 07:06:38-08 bll-mac installd[620]: ./postinstall:    13  Tk                                  0x000000010cf6fd6c Tk_Init + 2636
2019-11-04 07:06:38-08 bll-mac installd[620]: ./postinstall:    14  Tcl                                 0x000000010a9aad88 TclAddLiteralObj + 3112
2019-11-04 07:06:38-08 bll-mac installd[620]: ./postinstall:    15  Tcl                                 0x000000010a8f8661 Tcl_GetVersion + 1857
2019-11-04 07:06:38-08 bll-mac installd[620]: ./postinstall:    16  Tcl                                 0x000000010a8f4676 Tcl_EvalObjv + 342
2019-11-04 07:06:38-08 bll-mac installd[620]: ./postinstall:    17  Tcl                                 0x000000010a8f5fd3 Tcl_EvalEx + 2899
2019-11-04 07:06:38-08 bll-mac installd[620]: ./postinstall:    18  Tcl                                 0x000000010a9a4335 Tcl_FSEvalFileEx + 565
2019-11-04 07:06:38-08 bll-mac installd[620]: ./postinstall:    19  Tcl                                 0x000000010a9ac34d Tcl_MainEx + 2029
2019-11-04 07:06:38-08 bll-mac installd[620]: ./postinstall:    20  tclsh                               0x000000010a8d3a35 tclsh + 6709
2019-11-04 07:06:38-08 bll-mac installd[620]: ./postinstall:    21  libdyld.dylib                       0x00007fff6dd432e5 start + 1
2019-11-04 07:06:38-08 bll-mac installd[620]: ./postinstall:    22  ???                                 0x0000000000000002 0x0 + 2
2019-11-04 07:06:38-08 bll-mac installd[620]: ./postinstall: )
2019-11-04 07:06:38-08 bll-mac installd[620]: ./postinstall: libc++abi.dylib: terminating with uncaught exception of type NSException

This new update works fine on my system and displays Menlo as indicated with no error messages. I say this is good to merge into the core and release branches, and this ticket can be closed. Thanks, Marc!

I do not think that patch should be merged.  However, I made another checkin
which also avoids the warning messages.  It calls:
  [NSFont userFixedPitchFontOfSize:11];
instead of
 CTFontCreateUIFontForLanguage(fixedPitch, 11, NULL);
That results in a valid font in the Menlo family.

I would be comfortable merging that commit.

Menlo appears to be a "user font" family as opposed to a "system font" family.
But we are using the Tk fixed font in text widgets, not in the UI.  So I think
Menlo is actually an appropriate choice.

Marc, since your patch is reported to work around the issue, do you think it can be merged? Based on his recent commits, I think DGP is about to move ahead with another RC release of 8.6.10, and it would be good to have this fix in there.

I consider this a serious bug and I feel a fix needs to get into 8.6.10.

Taking into consideration how close 8.6.10 is to release, 
and how unlikely that Apple will do anything about this in a timely fashion,
I think that changing the code to use the Monaco font would be best.

If Apple actually ends up fixing this, the code can be wrapped with a
version == 10.15.1 test at a later date.

Indeed, I did get a Feedback ID.  It was FB7422964.  If you can use that to learn
anything I will be very pleasantly surprised.  The internet seems to think that
it is not possible to see anyone else's feedback submissions.

I am attaching a screenshot of what I currently see in the Feedback Assistant,
and if that changes I will post something in this ticket.

> @fvogel: you are kidding, right? Apple keeps all bug reports secret.

Well, no, in fact I was not kidding. The Feedback Assistant page states that When you file a bug, you’ll receive a Feedback ID to track the bug within the app or on the website.

Yes, that is possible even if it isn't what Apple wants us to do.  That is a
better idea than working around their bug if they don't fix it pretty quickly.

Yes, the system is picking the font, as the best fixed width system font for the language.

Running 8373c21f on High Sierra works, no issues.

% package require Tk
8.6.10
% font actual TkFixedFont
-family Monaco -size 11 -weight normal -slant roman -underline 0 -overstrike 0
% exit

Is it possible to just use Monaco for the TkFixedFont instead of .SF Mono?
(I assume the system is choosing the default fixed font?)
Still exists in Catalina.  And Monaco has been around a long time.

@fvogel: you are kidding, right?  Apple keeps all bug reports secret.  I guess
they don't want people to know how many bugs they have or which ones they
cannot fix.

Thanks Marc, any link to the bug report at Apple so that we can follow this perhaps?

I don't think we should use a workaround unless forced to.  I have filed a bug
report with Apple.

Also, this workaround is probably not quite correct.  I don't think they
always prepend ".SF ", but only do it in this one case. It turns out that there
is a font for iWatch named ".SF Mono" (SF is for San Francisco).  There is
also a macOS font named "NSMono" as we know.  So I think this is just a typo,
where some Apple programmer invented a hybrid font name ".SF NSMono" by
combining the two while pasting some code from iOS to macOS.

Hi,
the workaround works fine, no more warning.
Thank you !!

++

This is not a Tk bug but it is an Apple bug. The [NSFont fontFamily] method prepends ".SF " to the font name and the FontManager is then not able to find the font by name. The correct name for this default font, which FontManager accepts, is "NS Mono" not ".SF NS Mono".

I pushed a workaround in 8373c21f.

I imagine that Apple will fix this before too long. I don't know how long the workaround will need to remain in the Tk code, however.

Making this change and running simply text .t one now gets something slightly different:

% text .t
2019-11-01 14:41:03.365 wish[28115:193259] CoreText note: Client requested name ".SF NS Mono Light", it will get Times-Roman rather than the intended font. All system UI font access should be through proper APIs such as CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:].
2019-11-01 14:41:03.365 wish[28115:193259] CoreText note: Set a breakpoint on CTFontLogSystemFontNameRequest to debug.
.t

I can't test since I haven't upgraded yet, but it looks to me like the correct line would be:

faPtr->family = Tk_GetUid([[nsFont displayName] UTF8String]);

In the documentation for the familyName property Apple says:

The value in this property is intended for an application’s internal usage and not for display. To get a name that you can display to the user, use the displayName property instead.

Correct. Even more specifically, commenting out this line makes the warning disappear. Now, I'm wondering what is the kosher call that should replace this line...

in tkMacOSXFont.c,
if removing :
    nsFont = (NSFont*) CTFontCreateUIFontForLanguage(fixedPitch, 11, NULL);
    if (nsFont) {
	GetTkFontAttributesForNSFont(nsFont, &fa);
	CFRelease(nsFont);
    } else {

and the corresponding close of the else,
there's no more warning.

++

We certainly access the system fonts with one of the preferred API at the places CTFontCreateUIFontForLanguage is used. Nevertheless, from what I understand from the message there are other places where such preferred API is not used, thus triggering the message.

So where should we start looking at this problem?

The message advises to set a brekpoint on CTFontLogSystemFontNameRequest to debug. Right now we're not calling this anywhere in Tk. Moreover I didn't find any documentation on this function, is this a new beast in 10.15.1 perhaps?

Also I didn't find references to ".SFNSMono-Regular" or ".SF NS Mono" in the source code.

Random text output will certainly prevent portions of my application from working.

Apple seems to have made a previously private font available as a system font available in 10.15:

https://stackoverflow.com/questions/39890778/what-is-the-nsfont-name-for-the-font-sf-mono

We actually do access the system fonts with one of the preferred API's:

nsFont = (NSFont*) CTFontCreateUIFontForLanguage(
		HIThemeGetUIFontType(systemFont->id), 0, NULL);

I don't know if that reference to HITheme is throwing things off. HITheme in this context is considered old, but not deprecated.

From a user standpoint, I see no issue at all. TkFixedFont now seems to map to SF Mono, which is the same font used in Terminal. In other words, things seem to be working the way they are supposed to.

This appears to me to be one of those random warnings that Apple sometimes spews into the console. Annoying, but not really anything to worry about.

It appears to be the fixed width font causing the problems.
Does ".SF NS Mono" still exist?

@fvogel  Have 10.15.1 installed now, and the problem is reproducible.

@fvogel
I didn't saw that on 10.15, I'm seeing that on 10.15.1

++

Cannot reproduce on Catalina (10.15) when running pack [text .t].

Could you be more specific about your use of the text widget and what triggers this message?