Philosophical questions about the fontNames

Paul Dupuis paul at
Thu Mar 12 13:23:43 EDT 2020

On 3/12/2020 12:47 PM, Mark Waddingham via use-livecode wrote:
> On 2020-03-12 15:53, Paul Dupuis via use-livecode wrote:
>> So here is the simple use-case I ran into. We have a field with an
>> editor toolbar for rich content editing in an app. The field is set to
>> (Text) upon start up, as in:
>> set the textFont of fld "X" to "(Text)"
>> So that the font is initially in the appropriate default font for the
>> platform the app is running on. In the toolbar we also have a Font pup
>> menu with the available fonts listed for the user to change the font
>> they want in the field. It is the UI standard that such a menu SHOW
>> the user the currently selected font.
> ...
>> If there is a good work-around for this apparent conflict, I'm
>> definitely open to giving it a try or if I simply missed something
>> obvious, I'm happy to be educated.
> I think the conflict comes from the assumption that having the default 
> be '(Text)' (or the font underlying them) is the correct thing to do.
> If the field allows user-settable styling (even just font), then I'd 
> suggest that it doesn't need to use the 'default system font for the 
> platform' and you can just choose a sensible default - i.e. it isn't a 
> UI text area from a HIG perspective, it is a user styled text 
> area/document area.
> As a comparison, TextEdit defaults to Helvetica and WordPad defaults 
> to Calibri or Times New Roman (depending on version I think) [ I can't 
> remember what Notepad uses on Windows 10, something horrendously ugly 
> and bitmap based still, probably! ]
> My point of view here is mainly motivated by the following...
> A couple of weeks ago (or maybe longer?) Klaus noticed a really 
> strange problem with text extraction from a PDF printed using LiveCode 
> on macOS - specifically digits did not extract as digits (they looked 
> absolutely fine). [ He seemed to get quite 
> hot-under-the-collar-about-it, but they may have just been his 
> Germanic enthusiasm ;) ].
> Changing the font to Courier or Arial solved the problem - digits 
> could be copied as digits again.
> It wasn't until I ran an internal tool I wrote for Kognition many 
> moons ago on the generated PDF that I figured out what the cause was. 
> The effective font of the offending field was '(System)' - this came 
> out in the PDF as '.SFNSText'.
> (Note: I still don't quite know why it munges digits - my guess is 
> that it doesn't have a traditional CMAP table).
> This is a font you won't find listed in the fontNames, nor (I don't 
> think) In FontBook or anywhere else. It is a seemingly highly 
> specialized and custom crafted font designed only for screen display 
> in the macOS UI.
> Indeed, if I interrogate the NSFont object we get internally when 
> requesting the font for (Text), I get '.AppleSystemUIFont' - which is 
> similarly not appropriate for what you want.
> TL;DR version: Theme fonts '(...)' should only be used for 'fixed' UI 
> display - they won't print in the same way and cannot be chosen in the 
> same way by name. For text that might be printed, or where the font 
> can be chosen by the user, you should choose sensible default fonts 
> similar to those of the basic apps for styled text entry on the 
> platform the program is running on.
> Hope this helps,

Yes, it does. Lacking a detailed technical understanding of the 
ridiculous complexity of the macOS (or Windows for that matter), is one 
reason we used/use HyperCard, SuperCard, MetaCard, Revolution, LiveCode 
for the past 25+ years for our app development.

It *SEEMED* like a reasonable attempt at HIG compliance to set the fonts 
of our objects to the special names and also *SEEMED* like it was then 
reasonable to want to show what font was selected in a menu, but it is 
absolutely true that I was assuming that "(Text) became Segui UI on 
Windows and Calibri (or whatever) on macOS and NOT something like 

So, we'll revert our code back to the classic conditional of:

switch platform()
    case "Win32"
       set the textFont of fld "X" to "Segue UI" -- or whatever seems 
       set the textFont of fld "Y" to "Segue UI"
       ... set all the rest of the objects
    case "MacOS"
      set the textFont of fld "X" to "something"
    case "next platform"

We went down a rabbit hole where, without knowing better, it seemed that 
the above could be replaced with

set the textFont of fld "X" to "(Text)"
set the textFont of fld "Y" to "(Text)"

and eliminate the switch statement entirely.


More information about the use-livecode mailing list