Philosophical questions about the fontNames
paul at researchware.com
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
> 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
> 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
> 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
> 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
> 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)-
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