Philosophical questions about the fontNames

Paul Dupuis paul at
Thu Mar 12 11:53:39 EDT 2020

On 3/12/2020 3:46 AM, Mark Waddingham via use-livecode wrote:
> On 2020-03-11 23:38, Paul Dupuis via use-livecode wrote:
>> I filled a bug report on this back in February:
>> Mark Waddingham declared it was not a bug but a documentation issue,
>> so I filed and enhancement request:
>> Personally, I think the following code SHOULD work:
>> set the textFont of fld "X" to "(Text)"
>> put the effective textFont of fld "X"
>> And return the actual font used for (Text) on the current platform
>> (for example Segue UI on Windows 10.
>> My goal was to be able to read somewhere like in the dictionary or
>> user guide or run some code to find out what the actual font is for
>> each of the "specials" on Windows and macOS.
> To be accurate, your request / report is entirely different from 
> Richard's
> philosophical question.

True. I thought is was on the same topic though, so I responded.

> You want 'the effective fontName' of a chunk / object to return the 
> actual
> name of the font which the system is using to render the glyphs - which
> would be huge departure from its current (very LC-specific) meaning.
> Also I did not declare it a documentation issue (because it is not). My
> exact wording was:
> "I suspect it is possible to get the names of the actual system-provided
> fonts - but there is no facility in LiveCode for this at present. Please
> file an enhancement request for this ability."

My apology for mis-characterizing what you said. Yes, I interpreted that 
a "enhancement" for what I wanted, could be delivered by a documentation 
request and I thought that documenting the fonts corresponding to the 
fontNames engine directives would be easier that any sort of technical 
change to the engine - another assumption based on observation of the 
rate of documentation fixes vs the rate of engine technical fixes. Both 
are impressive for the size of the team, but doc fixes do seem to out 
pace technical changes since they are generally easier.

> This is precisely because the mapping is not fixed. Both Windows and 
> Linux
> allow the user to change the relevant fonts used at the system level, and
> macOS uses highly-specialized UI fonts for the purpose (as Klaus and I
> recently discovered when he was having a problem with text extraction 
> from
> PDFs printed from LC!).

True, and this point negates that a documentation approach would solve 
what I was looking for. So, my bad for being short sighted in asking for 
a documentation enhancement. That was a mistake, and I see that now.

> My current point of view is that this need represents an edge-case, 
> and it
> is more than likely that changing your approach to whatever it is you 
> believe
> you need it for means you won't...
> So, an important question is here why do you need to know the actual font
> being used when an object is set to render with one of the meta-(theme)-
> fonts?

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.

My problem, if I try to follow platfrom UI guidelines by setting the 
text field's font to (Text), I then can not - say get the effective 
textFont of fld "X" - to find out which Fontname in the UI standard 
popup font menu should be checked as the current font.

Now in the scheme of our own list of App bugs to fix and enhancements to 
build, whether the Font menu precisely corresponds to UI standards or 
not is not at the top of our list, but it still would have been nice not 
to have conflicting UI standards issues: Using textFont = (Text) gets me 
the appropriate fonts by platform, but then I can show what the selected 
font for the field is in a standard UI font menu.

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.

More information about the use-livecode mailing list