Philosophical questions about the fontNames

[Mark Waddingham]

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,

Mark.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps