[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

At 11:30 am +0100 16/9/98, Berthold K.P. Horn wrote:
>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:
>>>>>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.

Not at all: you talked about `Mac text founts'.  Nothing to do with only PS
Type 1 text founts (platform unspecified).  A Mac text fount can be PS Type
1, PS Type 3, TrueType, or straight bitmap.  (and maybe others for all I


>> ... Mac text founts printing on a PS printer.  Precision is very important.
>This has nothing to do with PS printers.

How am I know that?

>  The same issue arises when you
>print to any
>device.  In most text fonts those 15 glyphs are imported from the Symbol

This is a very different matter.  I can't talk about `most'; all I can find
out about is the founts I have here now.

>For non-PS printers this is done by ATM for PST1 fonts, the QD does it for
>TT fonts.

I've not got the list of glyphs concerned.  Were pi and Delta supposed to
be taken from Symbol?  I've just had a look: several Mac system founts have
pi and Delta glyphs that are not taken from Symbol (all the founts I looked
at - not many, because I couldn't be bothered to check exhaustively).

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

What *exactly* do you mean by this *precisely*?  I can see no way of making
any choice in the matter under System 7.6.1 (which isn't particularly
recent), and the glyphs in question are not taken from the Symbol fount.

As far as I can tell, if the fount concerned has the particular glyph in
question, it's used.  There is no user choice that I can see.

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

When I say `fount', I don't mean `ATM compatible PS Type 1 fount only'.  Of
*course* I include TrueType founts when I talk about founts in general.
Not many people mean `ATM compatible PS Type 1 fount only' when they say
`fount'.  Why assume that everyone shares this strange abberation with you?

> And indeed recently Apple has
>been adding
>more glyphs to the system TT fonts

I'm talking about glyphs that have been in these founts for as long as I've
had a Mac at home.  I'm not talking about recent changes.

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

So why did you talk about screen resolution when you meant something
completely different?

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

No TeX can re-encode on the fly.  Some dvi drivers can.  As you must know
by now, at least one Mac dvi driver can re-encode on the fly.  It's called

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

Ah - you mean unreliable, complicated bloatware that ignores Apple's
recommendations for using the API and therefore can be relied upon to screw
up pretty much everything?  btw, I've tried it on my Mac and it won't run
(v1 - v3).

> How do you even
>enter a `control character' into your source file with MS Word or similar

I haven't a clue.  I don't use anything similar to MS Word.

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

I would expect 13 to be a problem.  What's the problem with 9 and 10 (I can
guess about 0)?