Font Name properties

[J-G]

It's quite easy to display the name of a font in use in the Typeface of the Font but this has negative conotations when the font is a 'Symbol' Font. Not only those in a non 'Roman' (Latin) alphabet but also specific Symbol fonts such as Music Notation and 'Dingbats'. I suspect that it's also posible that there may be other properties to indicate (say) Cyrillic, Greek, Mandarin etc.

I've been looking for a way (without success) to determine whether a selected font is a 'Symbol Font'.  Using the TFontDialogue I can see a reference to 'Script' which generally shows as 'Western' but 'Symbol' is also present.

Regrettably, checking the properties of Font,  'Script' does not appear.

Can anyone point me to a property of  Font  that indicates if it is a Symbol Font?

If I can determine this, I can affect a change to the display font to make the name readable.
 

[dsiders]

It's quite easy to display the name of a font in use in the Typeface of the Font but this has negative conotations when the font is a 'Symbol' Font. Not only those in a non 'Roman' (Latin) alphabet but also specific Symbol fonts such as Music Notation and 'Dingbats'. I suspect that it's also posible that there may be other properties to indicate (say) Cyrillic, Greek, Mandarin etc.

I've been looking for a way (without success) to determine whether a selected font is a 'Symbol Font'.  Using the TFontDialogue I can see a reference to 'Script' which generally shows as 'Western' but 'Symbol' is also present.

Regrettably, checking the properties of Font,  'Script' does not appear.

Can anyone point me to a property of  Font  that indicates if it is a Symbol Font?

If I can determine this, I can affect a change to the display font to make the name readable.
 

Code: Pascal  [Select][+][-]

1. TFont.CharSet  = SYMBOL_CHARSET

works for me.

[creaothceann]

Instead of showing the name of the font in the font itself (lik Word?), you could show the names in the default font and second preview area with some example text.

[J-G]

Code: Pascal  [Select][+][-]

1. TFont.CharSet  = SYMBOL_CHARSET

works for me.

And for me !  👏🏼  😁  Thanks @dsiders.

I had to do a bit of 'fiddling' to get it fully working - well it's not quite 'Fully' working because it seems that some 'Symbol Fonts' aren't marked in this way - and, as I anticipated, I've now come across a 'Japanese' variant so I may well have to test for the CHARSET not being 'Western' - or whatever the term might be ??

For some reason just setting the name of the font of the name TLabel was insufficient, I had to create a dummy label to which I could assign a 'font' and when a Symbol Font was detected, assign the TLabel.font to that.

The important thing is that it 'works'.

[J-G]

Instead of showing the name of the font in the font itself (lik Word?), you could show the names in the default font and second preview area with some example text.

That's certainly an option that I had considered but rejected on the spurious grounds of being a 'cludge' 

[J-G]

I now have a list of the Font Enumeration Constants so I can formulate a more 'rounded' test.

This project was intended to be a quick revision of an old one but has taken on a life of its own   -   It seems that whenever I think I've done as much as I can, another opportunity for improvement rears its head     it's "Grown like Topsy" as Harriet Beecher Stowe put it !

[J-G]

Just reporting back after some further research.

The assesment of the ***_CHARSET is by no means perfect but regrettably the imperfection seems to be down to those who create the vast number of fonts that there are available.  I have some 17k and that is by no means exhaustive.

I have found that fonts which have been created correctly - ie. have the TFont.CharSet property correctly set - are ameanable to having that property inspected. I've also discovered that rather than testing for the Font Enumeration Constant name I can get a number returned from a call to TFont.charset. It seems that 'SYMBOL_CHARSET' returns '2', 'SHIFTJIS_CHARSET' (Japanese) is '128', 'OEM_CHARSET' is '255'  etc.  though probably more important 'Normal' fonts return '0' which means that I can check for TFont.charset = 0 and if not, 'IsSymbol' can be set to [True] and that can be used to decide whether to use the native font typeface or a readable default face.

Fonts which are 'Symbols' but not defined as such   -  ie. they return '0' incorrectly  -  fail this test of course and so get displayed in their native face. There seems no way to get around this, even the TFontDialogue listing shows the native face.

A prime example of a font family being poorly created is OCR  -  OCR A is marked as [Symbol] whilst OCR A BT is marked as [Western]  ??  Neither are really 'Symbol' fonts so it seems that such definition is a 'moveable feast' 🤷‍♂️

[H₂SO₄]

Dingbat fonts are nothing but a legacy hack from pre-Unicode times for inserting symbols into word processors; if you view the linked Wikipedia article you'll notice multiple tables containing glyphs that were adopted as Unicode code points, giving them both semantic meaning and independence from any specific typeface.

With that being said, you'd be shocked to learn just how complex text rendering really is. Without even getting into rasterization or text shaping, creating a proper (TrueType) font to render isn't simple at all between mountains of legacy cruft, redundancy, and convention over structure (aka vibe-based requirements). There's no universally standardized way to indicate whether a given font is a dingbat font; in fact, there isn't even a single universally standardized font description format in the first place.

If I were you I'd simply not even acknowledge the existence of these fonts. If the user chooses Wingdings as the interface font, then that's entirely on them.

[J-G]

With that being said, you'd be shocked to learn just how complex text rendering really is.
[…]
If I were you I'd simply not even acknowledge the existence of these fonts. If the user chooses Wingdings as the interface font, then that's entirely on them.

As it happens I would not be 'shocked to learn'  -  I already Know !

Having had involvement in letterpress printing - and consequently Lead Type Composing - some 65 years ago and a continued interest/use of computing to create 'print ready' files, including a small dabbling in Font Creation; there is little about the difficulties that can beset anyone attempting to codify 'Glyphs' that would surprize or shock me 😲   -   The terms 'Kerning', 'Leading', 'Ascender', 'Serif' etc. are very familiar to me.

I cannot ignore the existence of any font since providing a detailed exposition of the Glyphs available in any Font on a users system is precicely what the program is designed to do