Re: fontNames woes

[Tom Glod via use-livecode]

Thanks Neville, for doing this research, noting your results in public and
putting together the library of corresponding font names.
Your effort will make it easier for livecode to fix things up.
I have some plans for doing some more advanced font work, so I'm sure down
the road it will help me also.
Thanks again,
Tom


On Fri, Oct 28, 2022 at 8:00 AM Neville Smythe via use-livecode <
use-livecode@lists.runrev.com> wrote:

> In my last post I alluded to an elusive problem on Windows 10 with the
> fontnames function. I think I have identified at least one circumstance
> where fontNames() causes a crash on Windows 10.
>
> If in a Windows standalone you call
>
> stop using font file foo.ttf
>
> and then try to get fontNames() without first calling
>
> start using font file bar.ttf
>
> for some font bar.ttf
>
> I get a crash (or, if I use a try wrapper or errorDialog handler, "error
> in statement get the fontNames”. Thereafter any call to fontNames will
> fail, so something is fatally corrupted). In the IDE the code works as if
> there had  been no error but the list of fonts returned may be corrupted,
> it may for example contain foo.tff. The same code works without error on a
> Mac.
>
> Most apps will probably just start using some custom fonts when they
> launch, and then stop using them when cleaning up, so will not be affected
> by this bug. In my case I am examining a sequence of custom fonts, adding
> one at a time and removing it before processing the next.
>
> As it turns out I didn’t  need to call fontNames() directly after stop
> using one font and before adding the next font. When this nugatory bit of
> code was rewritten it all worked happily - well, almost: in processing 4000
> font files I still got that “error in statement” error 16 times, seemingly
> randomly and not fatally. Running the code again on just those 16 fonts had
> no problems, so it is not a case of corrupted fonts. Which means there is
> still a problem lurking there, my guess being that stop using font file can
> leave some font library in a fragile state. The Windows 10 system font
> cache is evidently well-known for being easily corrupted and perhaps that
> is what is going on here, but somehow I feel this is an LC problem because
> the font rendering itself seems to be OK.
>
> Anyway I have my data so I can ignore the problem for now: for those who
> came in late I am compiling a database of fonts to provide the different
> fontnames used by the 3 platforms for each font, and the lengths of
> rendered strings and their ascent and descent for cross-platform layout and
> vertical alignment. When that is done I shall put together a bug report for
> Quality Control.
>
>
> Neville Smythe
>
>
> ___
> 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
>
___
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

Re: fontNames woes

[Neville Smythe via use-livecode]

In my last post I alluded to an elusive problem on Windows 10 with the 
fontnames function. I think I have identified at least one circumstance where 
fontNames() causes a crash on Windows 10.

If in a Windows standalone you call 

stop using font file foo.ttf

and then try to get fontNames() without first calling 

start using font file bar.ttf

for some font bar.ttf 

I get a crash (or, if I use a try wrapper or errorDialog handler, "error in 
statement get the fontNames”. Thereafter any call to fontNames will fail, so 
something is fatally corrupted). In the IDE the code works as if there had  
been no error but the list of fonts returned may be corrupted, it may for 
example contain foo.tff. The same code works without error on a Mac.

Most apps will probably just start using some custom fonts when they launch, 
and then stop using them when cleaning up, so will not be affected by this bug. 
In my case I am examining a sequence of custom fonts, adding one at a time and 
removing it before processing the next. 

As it turns out I didn’t  need to call fontNames() directly after stop using 
one font and before adding the next font. When this nugatory bit of code was 
rewritten it all worked happily - well, almost: in processing 4000 font files I 
still got that “error in statement” error 16 times, seemingly randomly and not 
fatally. Running the code again on just those 16 fonts had no problems, so it 
is not a case of corrupted fonts. Which means there is still a problem lurking 
there, my guess being that stop using font file can leave some font library in 
a fragile state. The Windows 10 system font cache is evidently well-known for 
being easily corrupted and perhaps that is what is going on here, but somehow I 
feel this is an LC problem because the font rendering itself seems to be OK.

Anyway I have my data so I can ignore the problem for now: for those who came 
in late I am compiling a database of fonts to provide the different fontnames 
used by the 3 platforms for each font, and the lengths of rendered strings and 
their ascent and descent for cross-platform layout and vertical alignment. When 
that is done I shall put together a bug report for Quality Control.


Neville Smythe


___
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

fontNames woes

[Neville Smythe via use-livecode]

My grand project to compile a database of cross-platform LC font metrics is 
slowly progressing, though rather hindered by bugs in LC.

In particular fontNames() produces inconsistent results between Mac and Windows 
(and is not available in Linux) and worse can produce incorrect results on the 
Mac.

To demonstrate, start using font file Akshar[wght].ttf, which is one of the 
Google opentype fonts. This file includes 5 style variations, which are 
certainly all quite different fonts in appearance. The naming and style 
conventions for fonts are so complex that the bug is understandable — but its 
still a bug.

On the Mac, fontNames() produces
Akshar Light
Akshar Light
Akshar Light Medium
Akshar Light SemiBold
Akshar Light Bold

This is a bug: the first two are supposed to be references to quite different 
variations (a Regular and Light version of Akshar). Since they have the same 
name one of them cannot be accessed by setting textFont. This list does not 
match the MacOS knowledge of the font.

On Windows, fontNames() produces
Akshar

This is perhaps not a bug, but gives no way to access the 4 non-Regular 
versions of the font; the variations would be accessed by a Windows user or app 
by setting a style variation, but this cannot be done in LC.  It also does not 
match what the Windows system knows about the fonts in the family.. 

If you look at Akshar[wght].ttf in the Mac Font Book application, you find that 
the system says the name of the font family is Akshar, with fonts
Akshar Regular
Akshar Light
Akshar Medium
Akshar SemiBold
Akshar Bold

If you look at Akshar[wght].ttf in the Windows Font Manager application, you 
find that the system says the name of the font family is Akshar Light, with 
fonts
Akshar
Akshar Light
Akshar Medium
Akshar SemiBold
Akshar Bold 

Using Linux the Fonts application (Ubuntu) the family name appears as Akshar, 
Light (note the comma) and with named variations
Regular, Light, Bold, Medium, SemiBold

The LC function fontNames() is not implemented in Linux but there is a shell 
command fc-list which explains a lot. After parsing a little we get
Akshar,Akshar Light 
Akshar,Akshar Light:style=Regular   
Akshar,Akshar Light:style=Bold
Akshar,Akshar Light:style=Medium
Akshar,Akshar Light:style=SemiBold
Akshar,Akshar Light:style=Light,Regular

The items before the colon are alternative names for the font. The first line 
with no styles attached give the family names – 2 alternative names, Mac uses 
#2, Win uses #1. So fonts can have many names, often including non-Roman script 
names. They also can have multiple styles, many being international names of 
English style names. Akshar is actually a comparatively straightforward case. 
Which names should be returned by fontNames() for each platform is clearly a 
difficult problem.

Apart from the bug in the Mac version of fontNames(), there may be problems, 
which I cannot yet pin down, with using custom fonts in Windows as well. A 
stack which works in the IDE crashes as a standalone, the error dialog 
returning a seemingly irrelevant line for the source of the error so likely it 
is in the engine somewhere and almost certainly to do with fontNames. 
Furthermore even in the IDE there may be a problem with stop using font file, 
as it does not seem to clear the font cache after multiple use, which means 
fontNames() returns stale values.

Finally of course there is fontStyles(), which has been dead for years on the 
Mac, and even when it did work returned only plain, italic, bold, bold-italic 
instead of the actual available font style variations — and even if it did 
would be useless because you can’t set such styles within LC. A vast number of 
modern fonts are just inaccessible from LC.

Neville Smythe


___
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

fontNames issue

[Marty Knapp via use-livecode]

I've had 3 customers who use the Windows version of my app who've had the same 
issue. I've traced it down to the line:

put the fontNames into tFontList

It returns this error and then quits:

465,110,1
241,110,1,LoadFontMenu (the handler name that's trying to get the fontNames
353,0,0,stack (then the path to the stack where "LoadFontMenu" is called)

110 is the line "put the fontNames into tFontList"

Anybody out there seen this before? Of course I can't duplicate the error here 
and customers are only willing to do so much. I'm wondering about a permissions 
issues somewhere in the path to the Fonts folder or a corrupted font cache.

Would this show up in an error log somewhere on Windows?

Marty
___
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

Fonts and Property Inspector / fontNames / fontStyles Different on Every Platform

[Ralph DiMola via use-livecode]

LC 9.6 GM

Win 10. I have 3 Arial fonts installed.

 1) "Arial" with 4 styles (plain, bold, italic, bold-italic)
 2) "Arial Narrow" with 4 styles (plain, bold, italic, bold-italic)
 3) "Arial Black" with 1 style (plain)

 In the IDE:
 Via the PI "Arial Narrow" and "Arial Black" are not accessible.
 "Arial Narrow" (or Black) are not in seen in LC's fontNames or fontStyles 
functions either. I guess that's why they are not in the PI.

 One can select "Arial Narrow" (or Black) by typing the full font name into the 
PI or set via script.
 This appears to be a LC Windows IDE limitation with a work-around... OK I can 
deal with that.

 MS Word shows all 3 fonts.

 If you set the font name of a field to empty(PI or Script) then the font of 
the higher objects are inherited. This is displayed in the  PI in italic(as 
expected). In my environment I have no fonts specified all the way up to the 
stack so "Segoe UI" (displayed in the PI in  italic) is used.

 Set the font to "XXYYYZZ" then some unknown sans font is used. What font is 
this? How does LC choose a font when a field is set to a font that is not 
installed?

 Font observations by platform.


 Win 10 using fontNames() and fontStyles():

 "Arial" has 4 styles (plain, bold, italic, bold-italic)

 No mention at all of:
 "Arial Narrow"
 "Arial Black"


 Android using fontNames() and fontStyles():

 "Arial" has 4 styles (plain, bold, italic, bold-italic)
 But also shows
 "Arial Bold" with 1 style (bold)
 "Arial Italic" with 1 style (italic)
 "Arial Bold Italic" with 1 style (bold-italic)

 "Arial Narrow" 1 styles (plain)
 "Arial Narrow Bold" with 1 style (plain)
 "Arial Narrow Italic" with 1 style (plain)
 "Arial Narrow Bold Italic" with 1 style (plain)

 "Arial Black" with 1 style (plain)

-

 iOS using fontNames() and fontStyles():

 "Arial" has 1 style (plain)
 "Arial Bold" with 2 styles (plain, bold)
 "Arial Italic" with 2 styles (plain, italic)
 "Arial Bold Italic" with 3 styles (plain, bold, italic)

 "Arial Narrow " has 1 style (plain)
 "Arial Narrow Bold" with 2 styles (plain, bold)
 "Arial Narrow Italic" with 2 styles (plain, italic)
 "Arial Narrow Bold Italic" with 3 styles (plain, bold, italic)

 "Arial Black" with 2 styles (plain, bold)

-

 Mac OS using fontNames() and fontStyles():  (the same as iOS except for the 
bold italic)

 "Arial" has 1 style (plain)
 "Arial Bold" with 2 styles (plain, bold)
 "Arial Italic" with 2 styles (plain, italic)
 "Arial Bold Italic" with 4 styles (plain, bold, italic, bold-italic)

 "Arial Narrow " has 1 style (plain)
 "Arial Narrow Bold" with 2 styles (plain, bold)
 "Arial Narrow Italic" with 2 styles (plain, italic)
 "Arial Narrow Bold Italic" with 4 styles (plain, bold, italic, bold-italic)

 "Arial Black" with 2 styles (plain, bold)



 This is so inconsistent I can't even critique it.
 How do the rest of you deal with this craziness?

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net


___
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

Re: Philosophical questions about the fontNames

[Bob Sneidar via use-livecode]

Also, there are two major types of vector based fonts: TrueType and OpenType. 
OpenType is a Microsoft format, but the same font file can be used for Windows 
and Mac. 

TrueType gets a little tricky. TrueType fonts made for Windows will also work 
for Mac. TrueType made for Mac must be CONVERTED to work with Windows. There 
are free utilities that will do this conversion for you. I use dFontSplitter 
for Mac, but I'm sure there are others. 

HTH
Bob S


> On Mar 13, 2020, at 06:05 , Pi Digital via use-livecode 
>  wrote:
> 
> Hi
> 
> If you need a specific font to work because of look, scale, print, etc I 
> suggest using a font editor app to copy the font you require, rename it to 
> something unique (the name is embedded so just changing the file name changes 
> nothing) and then embed it into your app in LC Standalone Settings. This is 
> the only sure fire way of ensuring what you see in the dev environment is 
> what the user will see on their xyz machine/device/printout. 
> 
> Sean Cole
> Pi
> ___
> 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


___
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

Re: Philosophical questions about the fontNames

[Pi Digital via use-livecode]

Hi

If you need a specific font to work because of look, scale, print, etc I 
suggest using a font editor app to copy the font you require, rename it to 
something unique (the name is embedded so just changing the file name changes 
nothing) and then embed it into your app in LC Standalone Settings. This is the 
only sure fire way of ensuring what you see in the dev environment is what the 
user will see on their xyz machine/device/printout. 

Sean Cole
Pi
___
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

Re: Philosophical questions about the fontNames

[Mark Waddingham via use-livecode]

On 2020-03-12 17:23, Paul Dupuis via use-livecode wrote:

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!


Heh - its been an interesting learning exercise for us both - both 
technically and process-wise :)


I would stress here that this is just a reminder where failing to 
provide an adequate use-case when asking for something, or indeed 
posting a bug report about long-standing behavior which you believe 
should be changed is critically important.


The thing is if you focus on a very specific technical detail as being 
the problem, and describe it as just that it 'robs' the person reading 
of it any context in which to make any sort of judgement from a wider 
point of view and perhaps short-circuit digressions into rabbit holes :)


The main thing is that your code is going to be simpler as a result of 
this!


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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

Re: Philosophical questions about the fontNames

[Paul Dupuis via use-livecode]

On 3/12/2020 3:24 PM, Richard Gaskin via use-livecode wrote:
With more substantial content (web authoring, printed materials, etc.) 
the user cares very much, and the likelihood of ever wanting the 
OS-specific default font is low, so assigning your own default font 
explicitly would work well (even better for some apps, let the user 
define a default).


So while I do support your request to extend "effective" to apply here 
(notwithstanding the considerable effort the team would need to do to 
figure out what the values of the OS constants refer to), I also 
recognize it's not a common use case.  Worth supporting, IMO, but of 
low priority.


Now, after Mark's explanation, I get it. I'll definitely go back to 
explicitly specifying default fonts by platform. As you know, if you do 
that right, because of LiveCode's inheritance, you really only need to 
do it for a few objects on startup.


I really did go down a rabbit hole. I saw the new (something) font 
names, look at what I thought they were for and thought I could make 
code cleaner by using them. Now I know, that is not the case for my 
specific application. For other people or for some future App of mine 
they may be ideal.


And, I agree with you. Of all the bugs and enhancement Curry and I have 
submitted in the past 6 month, making 'effective' work in this case 
would be near the bottom of my priority list.



And yes, I expect we'll always be stuck with pain points in 
cross-platform UI work that NO development environment will ever make 
truly seamless because the OS vendors themselves try to differentiate 
their products by their appearance and the way the UI works (among many 
other factors).


I can still wish it wasn't so though...

I am working on a new tool requested by a customer. The crunching and 
analysis of the research data coding is simple compared to the UI which 
will probably take me 10 times as long to code and get to look and 
function "right" on macOS and Windows.


___
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

Re: Philosophical questions about the fontNames

[Richard Gaskin via use-livecode]

Paul Dupuis wrote:
> I *do* find that cross-platform UI design and implementation to still
> be the hardest thing to do in LiveCode (on a relative scale of course,
> since LiveCode overall is easy)
>
> I would just like to be able to say in a preferences box for my app
> that I am deploying to this platform and that platform and have the
> LiveCode IDE or engine (or both) figure out what fonts and what sizes
> everything should be to comply with the ever changing OS vendor HIGs!

For the most part you do, now that the team added the "(*)" textFont 
directives.


Your case is one where I would advocate extending "effective" to apply. 
I understand Mark's comments and generally support them, but like they 
say, exceptional circumstances require exceptional solutions.  The 
semantic difference between object inheritance and OS inheritance is 
real, but far more subtle than a hundred other things already in the 
language, and likely lost on most new users anyway.  "Give 'em the pickle".


But even here, it's a relatively narrow intersection of needs:

Most user-written content is either a sort of form or something more 
substantial.


With forms, the user neither knows nor care what the font is, they just 
want to type.


With more substantial content (web authoring, printed materials, etc.) 
the user cares very much, and the likelihood of ever wanting the 
OS-specific default font is low, so assigning your own default font 
explicitly would work well (even better for some apps, let the user 
define a default).


So while I do support your request to extend "effective" to apply here 
(notwithstanding the considerable effort the team would need to do to 
figure out what the values of the OS constants refer to), I also 
recognize it's not a common use case.  Worth supporting, IMO, but of low 
priority.



> I constantly run into things like we make a button with a label that
> fits on one platform and then on another the label is too long or a
> filed is sized to display x lines on this platform  but on that
> platform the line sizes are different! G! It really is infuriating
> at times.

And not even the IDE gets it right all the time, if you run Gnome with 
its large default font size.


I've given a lot of thought to how I might make tooling to take care of 
the implications of xplat font metrics on layouts.  And after thinking 
about it a very long time, I thought better of it. :)  Way too much 
work, and how I might decide to handle things with one control in one 
app will inevitably vary from how I'd handle it elsewhere.


There are probably underlying design patterns we could identify for such 
things, and make tooling for those.  But even then there will be edge 
cases, so we're either limiting layout options to a specific set of 
patterns, or raising expectations to a level that cannot be met.



Personally, I don't mind so much. I make tooling where I can, and 
hand-craft where not.  All the while I see my counterparts using other 
tools working even harder just for a single platform.  With LC as my 
not-so-secret weapon, I eat them for lunch.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com



___
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

Re: Philosophical questions about the fontNames

[Paul Dupuis via use-livecode]

On 3/12/2020 12:22 PM, hh via use-livecode wrote:

Indeed, the current implementation of
(Default),(Menu),(Message),(Styled Text),(System),(Text),(Tooltip)
is not very useful.

For example (System) at size 13 on MacOS 10.15 is on Windows 10
at about (System) at size 12. So one needs nevertheless a platform
switch.



I *do* find that cross-platform UI design and implementation to still be 
the hardest thing to do in LiveCode (on a relative scale of course, 
since LiveCode overall is easy)


I would just like to be able to say in a preferences box for my app that 
I am deploying to this platform and that platform and have the LiveCode 
IDE or engine (or both) figure out what fonts and what sizes everything 
should be to comply with the ever changing OS vendor HIGs!


I constantly run into things like we make a button with a label that 
fits on one platform and then on another the label is too long or a 
filed is sized to display x lines on this platform  but on that platform 
the line sizes are different! G! It really is infuriating at times. 
I would love the IDE to help, even by things like showing a bounding box 
for a button label that takes all platforms checked in the standalone 
setting into account. Fit Width seems to be platform specific.


(And yes, I know that is just shifting a huge burden from me to LiveCode).

Sorry, just using this thread to rant about UI building woes.

___
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

Re: Philosophical questions about the fontNames

[Klaus major-k via use-livecode]

Hi Mark,

> Am 12.03.2020 um 17:47 schrieb Mark Waddingham via use-livecode 
> :
> ...
> A couple of weeks ago (or maybe longer?)

yep, about four weeks ago.

> 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 ;) ].

Well, yes, I only seemed to!

A little WTF in the subject (I am not an american!) is definitively no 
indication of me
being "hot-under-the-collar-about-whatsoever", THAT will look (and sound) 
differently. 8-)
I was only very curious what had happened.

OK, thanks for listening, please carry on...

> ...
> 
> Hope this helps,
> 
> Mark.

Best

Klaus

--
Klaus Major
https://www.major-k.de
kl...@major-k.de


___
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

Re: Philosophical questions about the fontNames

[Bob Sneidar via use-livecode]

Another approach might be to find a font or subset of fonts that looks the same 
on all platforms and use that. You may have to pay for the font(s) but you gain 
consistency. 

Bob S


> On Mar 12, 2020, at 10:23 , Paul Dupuis via use-livecode 
>  wrote:
> 
> 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.


___
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

Re: Philosophical questions about the fontNames

[Paul Dupuis via use-livecode]

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

Re: Philosophical questions about the fontNames

[Mark Waddingham via use-livecode]

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,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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

Re: Philosophical questions about the fontNames

[Richard Gaskin via use-livecode]

Thanks for chiming in, Mark.  Would it be helpful to have a bug report 
on this, or should I wait to see what you find in your code review?


--
 Richard Gaskin
 Fourth World Systems


Mark Waddingham wrote:

On 2020-03-11 22:36, Richard Gaskin via use-livecode wrote:

Querying the fontNames includes:

(Default)
(Styled Text)
(Menu)
(Text)
(Message)
(Tooltip)
(System)

These are not font names, but constants the engine accepts so that we
can have good-looking, HIG-savvy UIs on multiple platforms.

But they're not font names.  They're not fonts at all.  They're engine
directives.

So should they be included in the fontNames?

(Yes, I know I can exclude them. I've been doing this a while, I can
do lots of things.  But if a newcomer wants to make a Fonts menu or
list she also needs to know the filter command, and why she needs to
use it to filter out things that aren't fonts. #learnability)


Haha - I noticed that at the top of Richmond's screenshot on the forums 
and I had the same thought... I also had a sneaky suspicion you would 
also comment on it!


I am inclined to agree with you - those font names are added explicitly 
after fetching the list of font names from the system - so there isn't a 
deeply technical reason why they are there.


I'll need to dig back to see if there is any internal discussion about 
it from when the theme support was added. After all, it is useful for 
the IDE to have those in the list, but it is also easy for it to add 
them in its own code!


For all intents and purposes, they should never appear in a 
'user-settable' font list in any non-UI editing type application - so 
the impact of changing it is probably next to zero.


Warmest Regards,

Mark.



___
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

Re: Philosophical questions about the fontNames

[hh via use-livecode]

Indeed, the current implementation of
(Default),(Menu),(Message),(Styled Text),(System),(Text),(Tooltip)
is not very useful.

For example (System) at size 13 on MacOS 10.15 is on Windows 10
at about (System) at size 12. So one needs nevertheless a platform
switch.



___
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

Re: Philosophical questions about the fontNames

[Paul Dupuis via use-livecode]

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

Re: Philosophical questions about the fontNames

[Mark Waddingham via use-livecode]

On 2020-03-11 22:36, Richard Gaskin via use-livecode wrote:

Querying the fontNames includes:

(Default)
(Styled Text)
(Menu)
(Text)
(Message)
(Tooltip)
(System)

These are not font names, but constants the engine accepts so that we
can have good-looking, HIG-savvy UIs on multiple platforms.

But they're not font names.  They're not fonts at all.  They're engine
directives.

So should they be included in the fontNames?

(Yes, I know I can exclude them. I've been doing this a while, I can
do lots of things.  But if a newcomer wants to make a Fonts menu or
list she also needs to know the filter command, and why she needs to
use it to filter out things that aren't fonts. #learnability)


Haha - I noticed that at the top of Richmond's screenshot on the forums 
and I had the same thought... I also had a sneaky suspicion you would 
also comment on it!


I am inclined to agree with you - those font names are added explicitly 
after fetching the list of font names from the system - so there isn't a 
deeply technical reason why they are there.


I'll need to dig back to see if there is any internal discussion about 
it from when the theme support was added. After all, it is useful for 
the IDE to have those in the list, but it is also easy for it to add 
them in its own code!


For all intents and purposes, they should never appear in a 
'user-settable' font list in any non-UI editing type application - so 
the impact of changing it is probably next to zero.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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

Re: Philosophical questions about the fontNames

[Mark Waddingham via use-livecode]

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.

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."

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!).

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?

Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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

Re: Philosophical questions about the fontNames

[Paul Dupuis via use-livecode]

On 3/11/2020 6:48 PM, J. Landman Gay via use-livecode wrote:

On 3/11/20 5:36 PM, Richard Gaskin via use-livecode wrote:

Querying the fontNames includes:

(Default)
(Styled Text)
(Menu)
(Text)
(Message)
(Tooltip)
(System)

These are not font names, but constants the engine accepts so that we 
can have good-looking, HIG-savvy UIs on multiple platforms.


But they're not font names.  They're not fonts at all.  They're 
engine directives.


So should they be included in the fontNames?

(Yes, I know I can exclude them. I've been doing this a while, I can 
do lots of things.  But if a newcomer wants to make a Fonts menu or 
list she also needs to know the filter command, and why she needs to 
use it to filter out things that aren't fonts. #learnability)




Maybe we need the "effective fontnames".



On 3/11/2020 6:48 PM, J. Landman Gay via use-livecode wrote:

On 3/11/20 5:36 PM, Richard Gaskin via use-livecode wrote:

Querying the fontNames includes:

(Default)
(Styled Text)
(Menu)
(Text)
(Message)
(Tooltip)
(System)

These are not font names, but constants the engine accepts so that we 
can have good-looking, HIG-savvy UIs on multiple platforms.


But they're not font names.  They're not fonts at all.  They're 
engine directives.


So should they be included in the fontNames?

(Yes, I know I can exclude them. I've been doing this a while, I can 
do lots of things.  But if a newcomer wants to make a Fonts menu or 
list she also needs to know the filter command, and why she needs to 
use it to filter out things that aren't fonts. #learnability)




Maybe we need the "effective fontnames".



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.





___
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

Re: Philosophical questions about the fontNames

[J. Landman Gay via use-livecode]

On 3/11/20 5:36 PM, Richard Gaskin via use-livecode wrote:

Querying the fontNames includes:

(Default)
(Styled Text)
(Menu)
(Text)
(Message)
(Tooltip)
(System)

These are not font names, but constants the engine accepts so that we can have good-looking, 
HIG-savvy UIs on multiple platforms.


But they're not font names.  They're not fonts at all.  They're engine 
directives.

So should they be included in the fontNames?

(Yes, I know I can exclude them. I've been doing this a while, I can do lots of things.  But if 
a newcomer wants to make a Fonts menu or list she also needs to know the filter command, and 
why she needs to use it to filter out things that aren't fonts. #learnability)




Maybe we need the "effective fontnames".

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com


___
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

Philosophical questions about the fontNames

[Richard Gaskin via use-livecode]

Querying the fontNames includes:

(Default)
(Styled Text)
(Menu)
(Text)
(Message)
(Tooltip)
(System)

These are not font names, but constants the engine accepts so that we 
can have good-looking, HIG-savvy UIs on multiple platforms.


But they're not font names.  They're not fonts at all.  They're engine 
directives.


So should they be included in the fontNames?

(Yes, I know I can exclude them. I've been doing this a while, I can do 
lots of things.  But if a newcomer wants to make a Fonts menu or list 
she also needs to know the filter command, and why she needs to use it 
to filter out things that aren't fonts. #learnability)


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
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

AW the fontnames and special names like (Menu)

[Paul Dupuis via use-livecode]

A confirmed bug:

https://quality.livecode.com/show_bug.cgi?id=22564

On 2/4/2020 12:27 PM, Paul Dupuis via use-livecode wrote:

The fontnames() function returns certain special font names like:
(Default)
(Styled Text)
(Menu)
(Text)
(Message)
(Tooltip)
(System)

How do I find out what fonts these really are on a given platform. The 
effective textFont does not seem to work.


For example the following code on Windows 10,

set the textFont of fld 1 to "(Text)"
put the effective textFont of fld 1

outputs "(Text)" when I would have expected it to output "Segoe UI"

Is this a bug?

___
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



___
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

Re: the fontnames and special names like (Menu)

[Paul Dupuis via use-livecode]

I filed this as a bug: https://quality.livecode.com/show_bug.cgi?id=22564

On 2/4/2020 12:27 PM, Paul Dupuis via use-livecode wrote:

The fontnames() function returns certain special font names like:
(Default)
(Styled Text)
(Menu)
(Text)
(Message)
(Tooltip)
(System)

How do I find out what fonts these really are on a given platform. The 
effective textFont does not seem to work.


For example the following code on Windows 10,

set the textFont of fld 1 to "(Text)"
put the effective textFont of fld 1

outputs "(Text)" when I would have expected it to output "Segoe UI"

Is this a bug?

___
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



___
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

Re: the fontnames and special names like (Menu)

[Paul Dupuis via use-livecode]

Exactly, but this does not answer my question, which is:

if I set the textFont of an object , say a button to "(Menu)" and the 
look at the effective textFont of that same object, I get "(Menu"), so 
how do I find out what the actual font really is?


For example, the default field font on Windows 10 is "Segoe UI", but if 
I set a the textFont of a fld to "(Text)" and the get the effective 
textFont of that same field, I get "(Text)" when I would expect to get 
"Segoe UI".



On 2/4/2020 12:37 PM, dunbarx--- via use-livecode wrote:

Here is some unhelpful information from the dictionary:
The list of font names includes a set of special-purpose names which automatically select 
the matching font for the platform. You can use these to request "the font used for 
buttons" without having to hard-code platform-specific font names. These fonts are:
- (Text) - the font used for fields and other controls with editable content
- (Menu) - the font used for menu items
- (Message) - the font used for buttons, labels and other communication 
from the app
- (Styled Text) - the font used by default for rich text
- (System) - the font for controls not covered by another category
- (Tooltip) - the font used for displaying tooltips
- (Default) - selects one of the UI fonts automatically based on the 
control type


-Original Message-
From: Paul Dupuis via use-livecode 
To: How to use LiveCode 
Cc: Paul Dupuis 
Sent: Tue, Feb 4, 2020 12:28 pm
Subject: the fontnames and special names like (Menu)

The fontnames() function returns certain special font names like:
(Default)
(Styled Text)
(Menu)
(Text)
(Message)
(Tooltip)
(System)

How do I find out what fonts these really are on a given platform. The
effective textFont does not seem to work.

For example the following code on Windows 10,

set the textFont of fld 1 to "(Text)"
put the effective textFont of fld 1

outputs "(Text)" when I would have expected it to output "Segoe UI"

Is this a bug?

___
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
___
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



___
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

Re: the fontnames and special names like (Menu)

[dunbarx--- via use-livecode]

Here is some unhelpful information from the dictionary:
The list of font names includes a set of special-purpose names which 
automatically select the matching font for the platform. You can use these to 
request "the font used for buttons" without having to hard-code 
platform-specific font names. These fonts are:   
   - (Text) - the font used for fields and other controls with editable content 
   - (Menu) - the font used for menu items
   - (Message) - the font used for buttons, labels and other communication from 
the app
   - (Styled Text) - the font used by default for rich text
   - (System) - the font for controls not covered by another category
   - (Tooltip) - the font used for displaying tooltips
   - (Default) - selects one of the UI fonts automatically based on the control 
type


-Original Message-
From: Paul Dupuis via use-livecode 
To: How to use LiveCode 
Cc: Paul Dupuis 
Sent: Tue, Feb 4, 2020 12:28 pm
Subject: the fontnames and special names like (Menu)

The fontnames() function returns certain special font names like:
(Default)
(Styled Text)
(Menu)
(Text)
(Message)
(Tooltip)
(System)

How do I find out what fonts these really are on a given platform. The 
effective textFont does not seem to work.

For example the following code on Windows 10,

set the textFont of fld 1 to "(Text)"
put the effective textFont of fld 1

outputs "(Text)" when I would have expected it to output "Segoe UI"

Is this a bug?

___
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
___
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

the fontnames and special names like (Menu)

[Paul Dupuis via use-livecode]

The fontnames() function returns certain special font names like:
(Default)
(Styled Text)
(Menu)
(Text)
(Message)
(Tooltip)
(System)

How do I find out what fonts these really are on a given platform. The 
effective textFont does not seem to work.


For example the following code on Windows 10,

set the textFont of fld 1 to "(Text)"
put the effective textFont of fld 1

outputs "(Text)" when I would have expected it to output "Segoe UI"

Is this a bug?

___
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

Re: fontNames

[Bob Sneidar via use-livecode]

Mud is much clearer. ;-)

Bob S


On Feb 3, 2017, at 19:20 , Fraser Gordon via use-livecode 
> wrote:

So, no, because LiveCode doesn't provide a way to get the "display name" of the 
font used for these.

But yes, because the font really *is* "(Message)" because that's the only name 
for it that LiveCode can actually use.

I hope that's about as clear as mud for you ;)

Fraser

___
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

Re: fontNames

[Phil Davis via use-livecode]

A masterful explanation! Thanks Fraser -
Phil


On 2/3/17 7:20 PM, Fraser Gordon via use-livecode wrote:

On 2017-02-03 21:03, Phil Davis via use-livecode wrote:

I'm currently fiddling around with fonts. I see that the list 
returned by 'the fontNames' contains some 'placeholder' values, 
namely these:


   (Default)
   (Menu)
   (Message)
   (Styled Text)
   (System)
   (Text)
   (Tooltip)

Is there a way to find out what font is used when a field's textFont 
is set to "(Default)" or some other placeholder value?
Yes and no - the font that is being used for, say, "(Message)" has a 
name that will be returned if you ask the macOS system for the font 
for push buttons and then ask what the name of that font is - it might 
be "San Francisco" on recent versions of macOS, for example. When I 
originally added these pseudo-fonts in LC8, that's exactly what asking 
for 'the effective textfont of...' would give you. Unfortunately, it 
turns out that the font you get when you try to request the macOS 
system fonts by name is *not* the same font as when you ask the 
'official' way (which means that setting the textFont of a control to 
its effective textFont actually changes the font!).


So, no, because LiveCode doesn't provide a way to get the "display 
name" of the font used for these.


But yes, because the font really *is* "(Message)" because that's the 
only name for it that LiveCode can actually use.


I hope that's about as clear as mud for you ;)

Fraser

___
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



--
Phil Davis


___
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

Re: fontNames

[Fraser Gordon via use-livecode]

On 2017-02-03 21:03, Phil Davis via use-livecode wrote:

I'm currently fiddling around with fonts. I see that the list returned 
by 'the fontNames' contains some 'placeholder' values, namely these:


   (Default)
   (Menu)
   (Message)
   (Styled Text)
   (System)
   (Text)
   (Tooltip)

Is there a way to find out what font is used when a field's textFont 
is set to "(Default)" or some other placeholder value?
Yes and no - the font that is being used for, say, "(Message)" has a 
name that will be returned if you ask the macOS system for the font for 
push buttons and then ask what the name of that font is - it might be 
"San Francisco" on recent versions of macOS, for example. When I 
originally added these pseudo-fonts in LC8, that's exactly what asking 
for 'the effective textfont of...' would give you. Unfortunately, it 
turns out that the font you get when you try to request the macOS system 
fonts by name is *not* the same font as when you ask the 'official' way 
(which means that setting the textFont of a control to its effective 
textFont actually changes the font!).


So, no, because LiveCode doesn't provide a way to get the "display name" 
of the font used for these.


But yes, because the font really *is* "(Message)" because that's the 
only name for it that LiveCode can actually use.


I hope that's about as clear as mud for you ;)

Fraser

___
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

Re: fontNames

[Phil Davis via use-livecode]

Hi Craig,

Maybe those new 'fonts' debuted in LC 7. I see what you're talking about 
in LC 6.7.10, then in 8.0.2 I see the additional ones. I don't have LC 7 
installed anywhere and don't want to take the time, and none of the 
release notes for 6 / 7 / 8 mention it (that I can see), so... guess I'm 
moving on. It isn't a showstopper for me, just a curiosity more than 
anything.


Thanks -
Phil


On 2/3/17 6:31 PM, dunbarx via use-livecode wrote:

I fear I am becoming more and more orphaned around here, languishing in v.6x.

For what it is worth, the fontNames returns only a list of fonts, one per
line, in my world. Is it a v.8 thing?

Craig Newman



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/fontNames-tp4712188p4712189.html
Sent from the Revolution - User mailing list archive at Nabble.com.

___
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



--
Phil Davis


___
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

Re: fontNames

[dunbarx via use-livecode]

I fear I am becoming more and more orphaned around here, languishing in v.6x.

For what it is worth, the fontNames returns only a list of fonts, one per
line, in my world. Is it a v.8 thing?

Craig Newman



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/fontNames-tp4712188p4712189.html
Sent from the Revolution - User mailing list archive at Nabble.com.

___
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

fontNames

[Phil Davis via use-livecode]

I'm currently fiddling around with fonts. I see that the list returned 
by 'the fontNames' contains some 'placeholder' values, namely these:


   (Default)
   (Menu)
   (Message)
   (Styled Text)
   (System)
   (Text)
   (Tooltip)

Is there a way to find out what font is used when a field's textFont is 
set to "(Default)" or some other placeholder value?


I'm using LC 8.1.2 on Mac OS X 10.11.6.

Thanks -
Phil Davis

--
Phil Davis

___
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