Dealing with FONTFACENAMES
A Logo programming environment for Microsoft Windows
Brought to you by:
david_costanzo
Menu
▾
▴
#63 Dealing with FONTFACENAMES
FONTFACENAMES is a list of literal lists, some with blanks as separators. When I ask
PRINT MEMBER? [Aptos] FONTFACENAMES
the answer is "true as it should be. But when I ask
PRINT MEMBER? [Aptos Light] FONTFACENAMES
the answer is "false, though the variant of Aptos is in my FONTFACENAMES, and though it is correctly installed when I write
~~~
SETLABELFONT [ [Aptos Light] -24 0 0 400 0 0 0 0 3 2 1 18]
~~~
How can it be "false?
I tried to avoid the appearance of all fontfacenames by the following code:
~~~
TO SET_FONT :fontname
CATCH "ERROR [
SETLABELFONT (LIST :fontname -24 0 0 400 0 0 0 0 3 2 1 18)
]
IF NOT EQUAL? ERROR [] [PRINT [Font not found] THROW "TOPLEVEL]
END
SET_FONT [Aptos Bold]
~~~
knowing that [Aptos Bold] is NOT in my FONTFACENAMES. But the error is not caught, instead the whole list of all fontfacenames again appears in the console. This leaves me frustrated ...
Manfred writes
The output of FONTFACENAMES is documented as
Each of the lists happens to be a list of a single word, although that's not document. All that is documented is that SETLABELFONT would understand it. I don't have the Apotos font on my system, so I'll demonstrate with one that I do have.
Manfred writes:
I feel your frustration. I don't know why George designed SETLABELFONT the way he did, but it's documented as not throwing an error. From SETLABELFONT
I think an error would have made more sense, but maybe he was thinking you'd do it interactively, like having a conversation. So if you give it a font typeface it doesn't have, it answers the next question you'd ask: which font typefaces do you have?
Considering that SetLabelFont can accept without complaining any of these three forms:
Maybe FONTFACENAMES could return a list of SENTENCES, each SENTENCE a font name, instead of list of one-element lists in which the element is a WORD containing spaces.
Daniel Ajoy writes:
FONTFACENAMES was added in version 6.9.0, which was released on 2006-06-20. If I had anticipated this support request 19 years ago, I would have implemented it as you suggest. That said, it's possible that someone in the last 19 years someone has figured out that FONTFACENAMES returns a list with a single word and wrote code that depends on it. Changing FONTFACENAMES might help Manfred while breaking all the other programs (which might not exist) that depends on how FONTFACENAME behaves.
If someone wants to turn the output of FONTFACENAME into a list of sentences, it's easy to do with MAP and PARSE.
As a workaround try:
PRINT MEMBER? [|Aptos Light|] FONTFACENAMES
I'd like to thank both of you, David and Daniel, for your comments, that helped me to solve the problem. Sorry that I found no time to answer earlier.
I found a contradiction that is not easy to explain when teaching:
This means, there are structural differences in two versions that look the same when printed.
Yes, that can happen whenever you use vertical bars or backslashes to escape a special character. Brian Harvey (also a teacher) made an intentional decision to make PRINT and SHOW render a friendly form that ignores structural differences. PON shows a more honest form. I'm not an educator, so you might ask Brian for advice on how to teach this difference, as the same behavior exists in UCBLogo.
Here's a more extreme example:
One remark concerning FONTFACENAMES.
Of course you can use it to check programmatically whether or not a desired fontface is a member of it. But there is no need to print it all unsorted and spoiling the console, because you only need to go to the FMSLogo-menu choosing Set -> Label Font... and find there everything you want to know, detailed and well-sorted.