Thanks to all who have looked into this.
What a huge difference the FontName makes in Sierra. My clients are able to choose the fonts so I can’t hard-code it in, but it’s good to have a suggestion for them when they call in. Interesting that Helvetica is twice as fast as Helvetica Neue. I will think about at least changing the default font in my Mac apps to Helvetica now.
Well it only took three and a half months to get a reply from an Apple engineer, but I did and it’s one short sentence:
[quote]Please use proper PostScript name ArialMT instead of Arial.
[/quote]
So I tried this and indeed he/she is right. Assigning ArialMT to the graphics.textfont property improves performance dramatically - on par with Yosemite, while Arial causes a 5X slowdown.
I looked up the PostScript font names in my Mac System report. All the proper PostScript names are in Bold. Trying with other name-corrections led to the same results:
Helvetica Neue works better as HelveticaNeue
Futura works better as Futura-Medium
Times New Roman works better as TimesNewRomanPSMT
The good news is I now know what the issue is. So how do I get the PostScript names from Xojo? I don’t see any built-in support for this.
You dont
Xojo doesn’t expose individual font names - rather font family names (I think thats the right term)
And therein lies the difficulty
This keeps code that worked a long time ago in the Carbon Ages from needing to be updated since those names remain the same But it does present issues with certain macOS API’s that need the postscript name (esp if you use a plugin or declare that calls those directly and needs the postscript font name instead)
You can open Font Book and see this difference in names there by clicking on the inspector
This is Arial on my machine
I don’t use any plugins. The problem here occurs just by using the Xojo-supplied fontnames with the graphics object.
I have been recommending to my users to choose Helvetica. I didn’t know why it works so much faster until now - the PostScript name and the Xojo-supplied name are both “Helvetica”.
There has to be a way to solve this. Using non-PS xojo-supplied fontnames degrades performance on my app to such an extent as to be almost unusable.
Just wanted to re-iterate that this issue does not affect my apps running under pre-Sierra MacOS. Yosemite and ElCapitan both run great. This is something that changed with Sierra. Apparently the way Sierra resolves non-PS fontnames.
I don’t have Feedback installed on this computer, but if I were you I would log a Feedback case pronto. It seems like you need a function for converting “Displayable Font Names” into “postscript font names”.
Or a function for extracting a “Postscript font names” and then a function for converting them to “Displayable Font Names”.
This can be accomplished with either the MBS or some declares, Did Apple confirm that this is a bug or a iOS ‘upgrade’ made to macOS?
oh declares etc can get you the name etc but there’s more magic than JUST that
Say you want “Arial” in Bold to draw on a graphics surface
ie/
graphics.textfont = "Arial"
graphics.bold = trueYou have to take that set of properties - Family name (Arial) and the selected setting (bold) - and find the correct variant in the ArialMT ttf
And its called Arial-BoldMT
So if you go this route & look these names up you then need to
AFAIK underline is NOT handled like this in a font itself - just regular bold & italic
This is where the OLD font manager did some magic. If you had a font that did NOT include the bold or italic variations you could still make that font appear bold or italic. The font manger would craft a means of doing this despite not having the font to do it as part of the font. So Bold & Italic appeared to be “properties” of EVERY possible font (which is how its more or less presented in Xojo)
Now move to OS X where if you have no BOLD variation then you cannot select Bold for that font
Its no longer a property - but an actual font and if you have no bold variation in the font file you cant set Bold on
Xojo would have to list about 3x as many “fonts” if we showed all the PS font names - as there are that many if each has regular bold & italic variations (and some have others like “Bold Italic”)
I think this is one reason Font Book on OS X displays as hierarchical lists with the family name as the main expandable entry and the variations as sub entries (see my picture previously)
As we modernized things for Cocoa we debated how to do this so it wouldn’t break a lot of code AND would also use the newer apis and make sense to users. You’d never had to consider “I want to use Arial in bold. Do I have Arial Bold in the font file?”
At the time we decided to make Xojo behave more like the old font manager and use the family name and then, if I recall correctly, we do the variant look up and find “Arial-BoldMT” when you set font = Arial and bold.
This breaks the least code from what people had in Carbon to where we needed to get to in Cocoa.
But as this thread demonstrates it has issues now
It COULD be just a deprecated API we use or something similar
I dont know that code in detail
A bug report with notes from the thread is definitely in order
I do believe that there is a API for changing the font name to bold (if the font has a bold variation).
From my experience I would agree with this, I seem to recall it’s a paragraph setting on the NSAttributedString. Interestingly enough it’s also a separate property with CSS.
[quote=320817:@Norman Palardy]But as this thread demonstrates it has issues now
It COULD be just a deprecated API we use or something similar
I dont know that code in detail[/quote]
It may not even be a Xojo issue, it could be a new bug introduced into Core Text on the macOS, a iOS bug that’s been ported into the macOS or even simply a undocumented change that Apple have made. Without further information it makes it hard to know what to do about it. I would assume that Apple are not going to fix it and plan for that.
It’s very worrying for me as I use g.textfont all over the place without any concern for getting the postscript name of the font, which means that almost every single one of my applications is susceptible to this unwanted change and could take a long time to fix everywhere.
[quote=320810:@Sam Rowlands]I don’t have Feedback installed on this computer, but if I were you I would log a Feedback case pronto. It seems like you need a function for converting “Displayable Font Names” into “postscript font names”.
Or a function for extracting a “Postscript font names” and then a function for converting them to “Displayable Font Names”.
This can be accomplished with either the MBS or some declares, Did Apple confirm that this is a bug or a iOS ‘upgrade’ made to macOS?[/quote]
Issue is that each “font” in current xojo parlance may have one or more “variants”
For instance in the picture I posted before there is
Arial (the name Xojo presents as the "font name")
the Regular variant - with a postscript name of ArialMT
the bold variant - with a postscript name of Arial-BoldMT
the italic variant - with a postscript name of Arial-ItalicMT
the Bold Italic variant - - with a postscript name of Arial-BoldItalicMTso each “font” could have many “postscript names”
You might need
postscriptFontNameForFont( familyName as string, bold as boolean, italic as boolean) as string
Or maybe
postscriptFontNameForFont( familyName as string, paramarray styles() as string) as stringAnd you call it like
dim s as string = postscriptFontNameForFont( "Avenir Next Condensed", "Italic", "Bold")
and this would return “AvenirNextCondensed-BoldItalic” IF that font existed (and not sure what to return if that variation doesnt exist or the font doesnt exist)
As there are many more options than bold & italic
On my machine I have American Typewriter which has
light
regular
bold
condensed
condensed light
condensed bold
and i have others with “medium”, “semibold” and several other styles as well
The basic issue then is that you kind of have to know that the fonts you want are installed & have the variations you expect
EDIT : oh there we go Avenir Next Condensed has
Medium
Regular
Ultra Light
Italic
Medium Italic
Ultra Light Italic
Bold
Demi Bold
Heavy
Bold Italic
Demi Bold Italic
Heavy Italicand a different PS font name for each 
I think there is a FR for a “Font” type class that would be better suited to the modern realities of all this
Not sure the # though
[quote=320818:@Sam Rowlands]
It’s very worrying for me as I use g.textfont all over the place without any concern for getting the postscript name of the font, which means that almost every single one of my applications is susceptible to this unwanted change and could take a long time to fix everywhere.[/quote]
The fact that we have been doing all the correct PS font name look up for the last 5+ years and this is really the first major bug we’ve run into (which may not be our fault) suggests that maybe it was done pretty decently way back when
We’ll have to revisit the case Richard pointed out (46020) and then we can see whats up and why this might suddenly NOT be working as it always has
[quote=320795:@Richard Nicolella]Please use proper PostScript name ArialMT instead of Arial.
So I tried this and indeed he/she is right. Assigning ArialMT to the graphics.textfont property improves performance dramatically - on par with Yosemite, while Arial causes a 5X slowdown.[/quote]
Is it possible for you to share the actual e-mail from Apple, I’m interested to know if they expect you to create the NSFont with the postscript name.
This I understand from working directly with Core text and NSAttributedString.
[quote=320819:@Norman Palardy]I think there is a FR for a “Font” type class that would be better suited to the modern realities of all this
Not sure the # though[/quote]
hmm… Yeah I can’t think of a self explanatory solution to this nightmare, I’ve written and deleted several already.
Good Job Apple, Good Job
Would you like a politically correct response?
As long as it doesn’t involve us waiting for Apple to fix bugs
Joe filed one Radar that came back as a duplicate of an existing case - from 1997 (or so)
I think I’m going back to Windoze…
A sentiment that appears to becoming common place amongst Photographers & Videographers at the moment. Possibly other professional fields also.
[quote=320821:@Sam Rowlands]Is it possible for you to share the actual e-mail from Apple, I’m interested to know if they expect you to create the NSFont with the postscript name.
[/quote]
It wasn’t an email - it was posted to my report in Apple Bug Reporter as the single sentence quoted above. The only other significant item is the updated State of the report: “3rd party to Resolve.” So I think we can gather that there will be no Apple fix forthcoming.
[quote=320820:@Norman Palardy]The fact that we have been doing all the correct PS font name look up for the last 5+ years and this is really the first major bug we’ve run into (which may not be our fault) suggests that maybe it was done pretty decently way back when
[/quote]
I totally agree, I think Xojo has done a great job of insulating us from this so far. I don’t think this is their fault. It does appear that Apple has made some under-the-hood changes in Sierra that has caused a bottle-neck when resolving non-PS fontnames.
BTW, I even considered making a hard-coded lookup table to get postscript names, but on further thought, that seems too prone to local installation issues, and an unsure font future.
Unfortunately, I don’t see an immediate remedy, except to continue suggesting that my clients select the Helvetica font (Tahoma, Verdana and Courier also seem to work well as they share PS/displaynames and all variant/decoration attributes work.)
Windows seems to be getting worse too. Ads, updates, computer telemetry, …
If things keep going the way they are now, I think Linux is going to get a lot more popular. That’s my current backup plan anyway. I just hope Apple get’s it’s act back together somehow. At least they still seem mostly trustworthy. I don’t trust Microsoft. I don’t even work on the Windows 10 machines at our office very much, but I think if I saw somebody wearing a OneDrive ball cap, I might be tempted to punch them in the gut. LOL JK
I seem to remember that I read a PostScript definition name in the PostScript Language Reference (some 20-30 years ago).
Back then, I started to have trouble while trying to print to PostScript printer(s) because the bitmap font name used [the PostScript font name] was set using the mood of the moment (!).
I started to search the PostScript font real file name (in the PostScript Font file), use that to set my screen Font file name (the bitmap one) and all my troubles went away.
Then the Apple / Microsoft True Type fonts comes / I stopped to use a PostScript printer and totally forgot about that.
All I believe it that there was a lack of file name enforcement (from the OS vendor[s ?]) and we fall into the situation we can read in this conversation.
Whoses faultive ? Who cares ! The important thing is to get the real way to do the things, follow that rule, et voilà.
BTW: do you know that TextEdit (from macSierra) ia able to download a missing (or many) Font from the document you are loading ?
TextEdit from El Capitan does not do that when I load the same rtf file (I created that file with my little fingers ;)).
Sadly this is often the attitude I get when I report security issues or other issues which can cause the user plenty of frustration. I get told don’t do that! Erm… Okay I wasn’t going to, but if I found this, I can guarantee that others will and may use it to cause harm to the user or steal data.
Here’s what I can tell you. They replaced the much used PDFKit in Sierra, breaking a ton of PDF applications, including their own Preview. The replaced it a PDF handler from iOS. Several years ago they replaced Core Image on the Mac with the version from iOS and that caused me hell.
Now back to PDF, the entire display language used by the OS is PDF (IIRC) and therefore migrating a locked down mobile phone PDF handler to the desktop computer it doesn’t surprise me that issues like this appear. Afterall the mobile OS doesn’t allow the user to install or use custom typefaces.
It appears that iOS is the base of all Apple OSes and the rest are simply different GUIs. I’m pretty certain Apple knows that this model is destructive for their Mac customers, but they simply don’t care as for every dollar earned in the Mac department, they make 10 for iPhone.
[quote=320895:@Richard Nicolella]BTW, I even considered making a hard-coded lookup table to get postscript names, but on further thought, that seems too prone to local installation issues, and an unsure font future.
Unfortunately, I don’t see an immediate remedy, except to continue suggesting that my clients select the Helvetica font (Tahoma, Verdana and Courier also seem to work well as they share PS/displaynames and all variant/decoration attributes work.)[/quote]
I am pretty certain there is a way we can translate the font names… Do you subscribe to xDevMag? In the latest edition I show you how to create a Font popup menu (which displays the font in the font)… I bet there’s a way we can extract the postscript name from the NSFont…
Just FYI we have some suspicions about whats changed and how we might deal with it IF our suspicions are correct
Pretty sure you can get the postscript name though either using CoreText or NSFont
https://developer.apple.com/reference/coretext/1510887-ctfontcopypostscriptname?language=objc
https://developer.apple.com/reference/appkit/nsfont/1526183-fontname?language=objc
But the issue with NSFont is creating it since NSFont.FontWithName
https://developer.apple.com/reference/appkit/nsfont/1525977-fontwithname?language=objc
says
The value of the font?Name parameter is a fully specified family-face name, preferably the PostScript name, such as Helvetica-BoldOblique or Times-Roman. (The Font Book app displays PostScript names of fonts in the Font Info panel.)
NSFontManager might help
https://developer.apple.com/reference/appkit/nsfontmanager/1462316-availablemembers