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 ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
