27595 - Cocoa Font Names are Inconsistent in TextAreas, StyledText compared to Xojo.Font

General
1

In Xojo Cocoa builds, there is a discrepancy with Font Names that exists between the values returned by REALBASIC.Font(), Font names used with TextArea.SelTextFont, and font names that exist within StyledText and StyleRun and Graphics objects.

The discrepancy is due to the fact that on OS X, all fonts have two names, their “system” name and their “PostScript”-style name. The former name is a combination of the Font Family and Font Face, and the latter is the old PostScript name. The names are similar, and in some cases, match exactly, so there are particular fonts and styles where the programmer may not realize there is a problem, but in generally this is a systemic issue.

Note that this has been reported multiple times, and I’d ask that you merge in the following reports:
<https://xojo.com/issue/26394>
<https://xojo.com/issue/11923>
<https://xojo.com/issue/15005>
<https://xojo.com/issue/11223>

There is a workaround (see below) but it’d be much nicer if the framework just handled this automatically.

Workarounds:
It’s possible to translate the font names at runtime. This code will do the trick to convert the PostScript-style name (which is used internally in TextArea.SelTextFont, StyledText.RTFData, StyleRun and Graphics objects:

Function ConvertFontName(name as String) As string
' converts PostScript type font name to Cocoa-style font name
#if TargetCocoa
  const kATSOptionFlagsDefault = 0
  const kInvalidFont = 0
  soft declare function ATSFontFindFromPostScriptName lib kCarbonLib (iName as CFStringRef, iOptions as UInt32) as UInt32

  dim theRef as UInt32 = ATSFontFindFromPostScriptName(name, kATSOptionFlagsDefault)
  if theRef = kInvalidFont then
    //LogWarning CurrentMethodName + " invalid font for " + name
     return name ' returns the original name which may be OK
  end if

  soft declare function ATSFontGetName lib kCarbonLib (iFamily as UInt32, iOptions as UInt32, ByRef oName as CFStringRef) as Integer
  dim CFname2 as CFStringRef
  dim OSError as Integer = ATSFontGetName(theRef, kATSOptionFlagsDefault, CFname2)
  if OSError = 0 then
    //LogWarning CurrentMethodName + " ATSFontGetName error for " + name
  end if 
  dim fname2 as string=cfname2
  return fname2
#endif
End Function
2

In feedback, you can select multiple feedback items and use the gear icon to Request a Merge.

3

I can, and did, although it turns out that Merge only works when all of the cases are the same view ability (Public vs. Private). So I also added the explicit note within the case (case 26394 is a beta case)

5

Ah, OK. Just wanted to make sure you were aware of that. I did make a feature request for Feedback, <https://xojo.com/issue/27228>: Request “Make Public” method for feedback cases. However, I think that this should be automatic when requesting merges of Private/Public cases. It would seem obvious that if a private/limited visibility issue is being requested to be merged with a public issue, then the issue isn’t private. I would assume that those processing the merge requests could make that decision also.

6

I don’t think this would be safe, since people other than the author can request a merge. I wouldn’t want my “super top secret” Beta feedbacks made public w/o my permission.

7

They wouldn’t be able to see it to request a merge if it were super secret. If others can see it, it’s not really secret, it’s just for a limited group such as beta testing and those are public to a large number of users. Anyone can be part of the beta testing process after asking Xojo to join and all Pro owners are automatically a part of it.

8

[quote=15773:@Michael Diehr]Workarounds:
It’s possible to translate the font names at runtime. This code will do the trick to convert the PostScript-style name (which is used internally in TextArea.SelTextFont, StyledText.RTFData, StyleRun and Graphics objects:[/quote]

The code Michael posted uses ATS, which is deprecated. I posted some more information about the CoreText approach in another thread.

9

Thanks Joe - any sense about how important it would be to use CTFontCreateWithName for the workaround instead? E.g., if you think apple is obsoleting that ATS call soon sooner than Xojo might have this fixed internally?

10

ATS is deprecated (which I would call obsolete), but it’s not going away anytime soon. Doing so would break binary compatibility, which they haven’t done much. For example, even though the QuickDraw headers are no longer included in the Xcode SDKs, the QuickDraw framework still exists on disk.

As for using CoreText vs waiting for Xojo to release a fix, I’d say they aren’t mutually exclusive.

11