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:
https://quality.livecode.com/show_bug.cgi?id=22564
Mark Waddingham declared it was not a bug but a documentation issue,
so I filed and enhancement request:
https://quality.livecode.com/show_bug.cgi?id=22569
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.
_______________________________________________
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
