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
.AppleSystemUIFont!
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
appropriate
set the textFont of fld "Y" to "Segue UI"
... set all the rest of the objects
break
case "MacOS"
set the textFont of fld "X" to "something"
....
break
case "next platform"
etc.
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)"
etc
and eliminate the switch statement entirely.
set
_______________________________________________
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
