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

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

I know I should be smart  enough to get out of the way when R&R shows up, 
since he shouts even louder than I do, but who said I was smart :-)?

At 05:34 AM 98/09/16 +0100, Rebecca and Rowland wrote:

>[snip]
>>>>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 :-)?

>No, you said that Mac text founts do not actually have any of those glyphs.
>You didn't say anything about the restricted case of using a subset of Mac
>text founts printing on a PS printer.  Precision is very important.

OK, let us be precise then: PS Type 1 text fonts typically do not contain
those 15 glyphs,
and they are imported from the Symbol font.  Which I think is what I said.
By the
way, I am perfectly aware that PST1 text fonts *can* contain those glyphs
if they 
want to: Lucida Bright fonts do for example!   However, most of the 90,000
plain
vanilla text fonts in Type 1 format do not.  Most of the TrueType fonts I
looked at do 
not have those glyphs either (other than those from MS and recent Apple
fonts).

> ... Mac text founts printing on a PS printer.  Precision is very important.

This has nothing to do with PS printers.  The same issue arises when you
print to any
device.  In most text fonts those 15 glyphs are imported from the Symbol
font.  
For non-PS printers this is done by ATM for PST1 fonts, the QD does it for
TT fonts.

By the way, only recently has the system provided the user with a choice
regarding 
whether to use glyphs imported from Symbol or glyphs in the font itself -
if they exist.

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

>What about FOND resources?  

Yes, what about FOND resources?  
Certainly the metrics in the FOND resource should match the metrics of the
actual font.

>Anyway, some Mac founts *do* contain those glyphs I mentioned.  Geneva is
one, I think.  
>Chicago certainly has some strange glyphs.

You are talking about TrueType fonts now. And indeed recently Apple has
been adding 
more glyphs to the system TT fonts - just as MS has added the full WGL4 set
to theirs,
which brings them up to over 640 glyphs per font.  Of course, these won't
do you much 
good on a Mac, since it uses a cmap  (type 0) in the TT font that can only
address the 
first 256 glyf programs...(Obviously this will have to change if/when the
Mac goes to Unicode).

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

>Oh for God's sake!  Get real!  That 72 dpi is an OS assumption of the
>screen resolution.  No current Mac is forced to use 72dpi, alright?  If you
>use 72dpi as the logical resolution, you get true wysiwyg.  Current Mac
>screens are obviously not restricted to 72dpi.  Macs can have high screen
>resolution.  And FWIW, when Macs were launched, that same `low resolution'
>of 72dpi was considered very high resolution.

>Why not try and be accurate for once?

The default *logical* dpi for Mac is 72dpi and for Windows is 96dpi (large
fonts)
or 120dpi (small fonts).  The actual physical resolution depends on screen
size and
video board settings.  The OS has no way of telling what size screen you
are using,
hence the `logical' in `logical dpi' as opposed to `physical'.

And yes, fortunately you can go to higher resolution, which is great
because that 
means you can rely on ATM to do the rasterization and don't need NFNTs.  
In fact, the Lucida Bright and MathTime fonts for example,
do not have any real NFNTs, depending entirely on ATM for rasterization.
Which makes life potentially easier for a Mac TeX system that can reencode 
fonts in the fly --- should there ever be such a beast!

>[snip]
>>Most applications on the Mac and in Windows have trouble with char code 0
- 31.

>Do they really?  What applications on the Mac are you thinking of?

I don't know:   How about something basic like MS Word :-)?  How do you even
enter a `control character' into your source file with MS Word or similar
application?
Actually, even in applications that let you enter `control characters' (and
that don't
use them internally for formating information) you will find that some of
the character
 codes  0, 9, 10, 13 are problematic:.  For a while now,  e.g. the Mac OS
insists that 
char code 13 is a line terminator and can't be a printing glyph.  
Just like some software insists that 32 is a space and can't be a printing
glyph.

Regards, Berthold.


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