Re: How can I check for the existence of a glyph in TeX?

["Berthold K.P. Horn" <bkph@ai.mit.edu>]

At 06:40 PM 98/09/15 +0200, Lars Hellström wrote:

>As I believe someone pointed out a few days ago, Bertholds argumentation is
>completely based on his assumption that "font" equals "PS Type 1 font"

Are there any others :-)?  Actually the argument holds for properly
constructed 
TrueType fonts as well. And, are there any others beyond PST1 and TTF :-)?

>(well, perhaps he would allow PS Type 3 fonts as well), 

No.  PS Type 3 fonts are not useful because ATM doesn't understand them.

>and given that assumption he is right that a Mac LWFN contains the same
information 
>as the corresponding .pfa or .pfb. I believe most people on this list
would not
>accept such a limited definition of "font", however. Without this
>assumption, his argumentation does not hold.

What other `fonts' common to Mac and Windows are you talking about then?

>>Mac text fonts do not actually have any of those glyphs.

>This is usually not true. The glyhps does not exist in the PS fonts, so
>they are mapped in from Symbol when printing is to a PS printer, 

which is what I said right :-)?

>but they do exist in the bitmapped NFNT fonts, 

If the NFNT bitmap does not match the actual font it is wrong.  
And if it does what is the point of talking about the NFNT?

>which is what is usually  seen on the screen.

Not in my case.  I try and avoid bitmaps.  You can't reencode them.  
It's too bad they are needed at all because of the low screen resolution on 
the Mac (72 dpi).  I generally let ATM do all the rendering.  My philosophy
is that the scalable outline is the ground truth, and everything else better
match that -- character shapes, glyph complement and metrics.

>PS: The reason I didn't claim you could use all 256 character positions is
>that I have experienced some problems when trying to use characters given
>ASCII codes 0-31 (OzTeX doesn't print these). I don't know if it's OzTeX
>itself (I believe older versions did print them) or some extension to the
>OS, such as the Adobe Type Manager, which causes this. It is not the OS (in
>this case Quickdraw) itself however, as it has no problem printing the
>command-key symbol (ASCII code 17 in Chicago, frequently seen in menus).

Most applications on the Mac and in Windows have trouble with char code 0 -
31.
However, ATM imposes no such restrictions.  The Mac OS makes a few of the
`control character' codes useless (depending on OS version) including 13.
For TrueType fonts, 0 - 31 are off limits except for NT which implements the 
TT spec correctly.

Regards, Berthold.

Berthold K.P. Horn
Cambridge, MA		mailto:bkph@ai.mit.edu