Xref: utzoo comp.sys.mac.programmer:16495 comp.sys.mac.system:1034
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker!mit-eddie!uw-beaver!zephyr.ens.tek.com!tektronix!reed!barry
From: barry@reed.UUCP (Barry Smith)
Newsgroups: comp.sys.mac.programmer,comp.sys.mac.system
Subject: Re: QuickDraw problem with drawing certain fonts
Summary: Blue Sky response; it's a bug
Keywords: QuickDraw fonts bugs
Message-ID: <15305@reed.UUCP>
Date: 6 Aug 90 22:17:42 GMT
References: <1990Aug1.154901.14781@ra.src.umd.edu> <1990Aug1.200516.16644@Neon.Stanford.EDU> <1990Aug2.163757.19572@ra.src.umd.edu> <1990Aug3.010400.28725@Neon.Stanford.EDU>
Reply-To: barry@reed.UUCP (Barry Smith)
Distribution: na
Organization: Blue Sky Research, Portland OR
Lines: 70

I'm the owner of Blue Sky Research, the "font manufacturer" in question.
(We're the publishers of Textures, a TeX system for Macintosh, and the
fonts being discussed are bitmap fonts (FOND/NFNT) produced by Metafont
and our own tools.)  I hope I'm not misquoting anyone in the following
discussion.

First, the question of "point sizes": the particular font in question is
Knuth's CMEX10 math extension font, where the "10" indicates a "design
size" of 10pt (points).  It's scaled by one "magstep", or factor of 1.2,
and rendered at 300 dpi.  If we take the design size to be the nominal
point size, then Apple would probably say this should be a 48pt Macintosh
NFNT (10 * 1.2 * 4.0); we do the calculation a little differently 
(10 * 1.2 * 300 / 72) and arrive at a 50pt NFNT. [Does anyone else have
difficulty with Apple's blithe statements that LaserWriter fonts are
(exactly) four times the size of screen fonts?]

Is it not apparent to anyone with any typographic familiarity that the
nominal point size has no necessary correlation with the actual measure? 
And further, that the reference point and advance width have no necessary
correlation with the bounding box of the character image?  Apple system
software, on the other hand, has recurring problems with drawing
zero-width characters, and with characters whose bounding box does not
fall entirely between the reference point and the advance width.

Second, the question of "allowable point sizes": Here, the references are
somewhat less than authoritative.  Ben Hekster points out Inside Macintosh
I-228, that says "The maximum [font height] is 127 pixels" (Ben makes some
other comments that I'll cheerfully ignore; I've read the book before).
IM-1 of course makes no reference at all to either FONDs or NFNTs, and
describes limitations of the 64K ROMs.  Although I certainly have no
written reference from Apple that explicitly removes this limitation, I
can say (1) we have literally hundreds of fonts with combined ascent and
descent in excess of 127 that display correctly; (2) I have had recent
contact with MACDTS about another bug that involves fonts with nominal
point sizes in excess of 127 wherein the fonts draw correctly except that
QuickDraw masks the point size to 7 bits, so that, e.g., a 187 point font
is handled as a 59 point font; MACDTS says this is a bug, and makes no
claim that 187 point fonts "aren't supposed to work"; (3) I'm sure that
our customers will understand the difference between "It doesn't work
because of bugs in Apple system software" and "It doesn't work because of
limitations in Apple system software"; and (4) of all the Apple
documentation, that related to fonts has to be the most poorly organized
and incomplete portion; the most useful document in my possession about
Apple FOND/NFNT structure was written by Adobe Systems.

Now, Marc Kaufman says some useful things about font height tables and
their (undocumented) limitations/bugs, although (1) our fonts do not
include font height tables; the table to which he refers was constructed
by the Apple Font/DA Mover; and (2) I'll be happy to provide any
interested parties with another sample font, the 42 point version of
CMEX10, which contains no characters in excess of 127 pixels tall, and a
very short program that demonstrates that QuickDraw fails to draw some of
these characters in certain circumstances, while drawing them correctly in
others. In this particular case, it appears that characters fail to draw
when they have a certain relationship to the boundary of the drawing
window. [!]

Mr. Kaufman says some other things I'll take issue with: (1) he says "the
operational definition of well formed is that QuickDraw renders the font
properly", which seems to place the burden of working around any QuickDraw
bugs entirely on the font manufacturer's shoulders; (2) "Blue Sky is lucky
to have even a subset render properly", which is too silly for words; and
(3) he advises our customers to obtain PostScript versions of the font(s)
[which we would be happy to sell them, by the way, although at 300 dpi
they are inferior to the Metafont-generated bitmaps], and to use Adobe
Type Manager.  Would anyone now care to discuss bugs in ATM?


Barry Smith, Blue Sky Research
barry@reed.edu, AppleLink D0387