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

[Lars Hellström <Lars.Hellstrom@math.umu.se>]

Berthold K.P. Horn wrote:
>At 06:25 AM 98/09/15 +0100, Rebecca and Rowland wrote:
>
>>>The fonts themselves are identical.
>
>>Not in my experience they're not.
>
>You are wrong.  The Font Manipulation Package for example includes MACtoPFA
>and
>PFBtoMAC which convert between Mac and PC Type 1 formats making it easy to
>verify
>that, for example, any font in the Adobe Type Library has the same internal
>information
>on the Mac as it has on the PC.  You can take the Mac font file and
>automatically
>create a PC font file that is byte-for-byte identical to the one you get
>from Adobe for PC.
>Going in the other direction, again you get byte -for-byte equality except
>for the
>addition of the icon, version and bundle resources which show you the nice
>slanted
>`A' (or other) icon.  Of course, none of that affects the rendering of the
>glyphs in any way.
>
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"
(well, perhaps he would allow PS Type 3 fonts as well), 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.

>>>Adobe text fonts have 228 `standard'
>>>glyphs.  You can convert the actual font file from Mac to PC format back
>>>and forth without losing anything.  The text font does have all those
>>>glyphs --
>>>on any platform.   A stand-alone PS driver like DVIPS can trivially get at
>>>all 228 if it wants to (if DVIPS could understand the Macintosh Type 1 font
>>>file format).
>
OzTeX's implementation of DVIPS do understand it. I do not know about the
one in CMacTeX. Are there any other implementations of DVIPS in OS's that
can mount file systems in which files can have resource forks? If not, then
I see no reason for other DVIPSs to understand it; they can't access the
relevant part of the file anyway.

>>It's a nice theory; what about the point that Mac founts often have glyphs
>>that don't exist in normal founts (encoded or otherwise): things like pi,
>>sigma, delta, rabbit, apple, candle, and so on?
>
>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, but they
do exist in the bitmapped NFNT fonts, which is what is usually seen on the
screen.

> On the Mac, 15
>`mathematical' symbols are imported from the Symbol font into text fonts:
>
>% notequal, lessequal, greaterequal, approxequal, partialdiff, integral
>% summation, product, pi, infinity, Delta, Omega, radical, lozenge, apple
>
>As a result these look identical, no matter what font you select.  Hence are
>essentially a useless artifact that wastes 15 slots in the Mac standard roman
>encoding.

My point was that although this is the common case, it is not something the
OS forces you to do. If your PS font contains these glyphs, you can set up
the FOND resource so that they are actually used. As the PS fonts usually
do not, you have the option to substitute glyphs from another font for the
missing ones, but you are not forced to use it.

/Lars Hellström

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