Philosophical questions about the fontNames
mark at livecode.com
Thu Mar 12 12:47:37 EDT 2020
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
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 Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
More information about the use-livecode