josip@ra.src.umd.edu (Josip Loncaric) (08/01/90)
I have had a bizarre problem with a font of special math symbols which came with my Textures program (from Blue Sky Research, currently v1.2). Certain characters in CMEX10 font at 50pt (prints as 12pt size on 300dpi devices) are not rendered on the screen or printed properly. I could not discover anything wrong with the font, or the Textures program which has served me well for over two years. In fact, the culprit seemed to be Mac's QuickDraw; and this is confirmed by the following explanation I got from Blue Sky Research: In article <15235@reed.UUCP> barry@reed.UUCP (Barry Smith) writes: ........... >The problem is, as far as we can determine, due to errors in >the Macintosh system software, specifically the QuickDraw >graphic display language. In certain cases, especially with >larger point sizes, fonts that contain characters that differ >from ``normal'' placement are drawn incorrectly or >incompletely. We have seen this problem with several fonts, at >a variety of sizes and on a wide selection of devices; >different versions of the system software will sometimes >display varying examples of the problem. > >Some examples from fonts CMEX10 and CIRCLE may help explain >the sort of characters that are involved with this problem. >In the font CMEX10, the \TeX\ math extension font, the >characters are entirely descent with no ascent (they hang >below the reference point on the type baseline), and in some of >the characters (e.g., the integral signs) the character image >is wider than the character advance width, or, in other words, >some characters may overhang the reference point of the >adjacent character. In the CIRCLE font used in \LaTeX, the >reference points and character widths of the circle sections >are placed so as to make alignment easy; this results in some >character images that are entirely to the left of their >reference points. Yet another type of problem can be caused >by characters that have a zero advance width, or ``no width'', >such as the slash used for negation of various math symbols. > >It is our belief that our fonts are well-formed, and that the >problems you (and we) are experiencing are entirely due to >errors in the Apple system software. We have made various >people at Apple aware of these problems on several occasions >in the past three years. I can only hope that these problems >will be corrected in a future release of the Apple software, >and offer any assistance you may desire should you wish to >pursue this problem with Apple yourself. > >If you have access to a PostScript laser printer, please be >aware that problems of this sort do not occur on PostScript >printers, in our experience. > >--- >Barry Smith, Blue Sky Research >barry@reed.edu What I'd like to know is the following: (1) How come Apple has not yet fixed this known problem? Will it ever be fixed? (2) Does anyone offer a QuickDraw substitute which eliminates this problem with character drawing? Sincerely, Josip Loncaric <josip@ra.src.umd.edu> -- Josip Loncaric / SRC / U. of Maryland, College Park, MD 20745
kaufman@Neon.Stanford.EDU (Marc T. Kaufman) (08/02/90)
In article <1990Aug1.154901.14781@ra.src.umd.edu> josip@ra.src.umd.edu (Josip Loncaric) writes: >I have had a bizarre problem with a font of special math symbols which came >with my Textures program (from Blue Sky Research, currently v1.2). Certain >characters in CMEX10 font at 50pt (prints as 12pt size on 300dpi devices) are >not rendered on the screen or printed properly... >In article <15235@reed.UUCP> barry@reed.UUCP (Barry Smith) writes: > ........... ->The problem is, as far as we can determine, due to errors in ->the Macintosh system software, specifically the QuickDraw ->graphic display language. In certain cases, especially with ->larger point sizes, fonts that contain characters that differ ->from ``normal'' placement are drawn incorrectly or ->incompletely... ->It is our belief that our fonts are well-formed, and that the ->problems you (and we) are experiencing are entirely due to ->errors in the Apple system software... >What I'd like to know is the following: >(1) How come Apple has not yet fixed this known problem? Will it ever be fixed? I don't want to be an apologist for Apple's Quickdraw, but I find myself confused by this thread of articles. I have already responded to the use of 0x20 as a graphic character, but the above quotes leave many questions. First, is it the case that CMEX10 *NEVER* prints correctly? If so, why in the world was it released, and how can the vendor claim that the font is "well formed"? Quickdraw does strange things sometimes, but I would claim that the operational definition of "well formed" is that Quickdraw renders the font properly. If there are SOME applications that render the font properly, and SOME applications that do not, then I would be more apt to point an extremity at the Application -- I would not be surprised to find that some do not deal properly with the full glory of Quickdraw fonts. Even if the FONT is correct, is the FOND properly formed? Would the font manufacturer care to post a subset font that fails to draw but is declared to be "well formed" for the edification and amusement of Usenet readers? [you only need to post a half dozen of the problem characters -- we aren't going to steal your entire typeface...]. Be sure to post the FONT and the FOND as a proper Font/DA Mover file. Marc Kaufman (kaufman@Neon.stanford.edu)
josip@ra.src.umd.edu (Josip Loncaric) (08/02/90)
In article <1990Aug1.200516.16644@Neon.Stanford.EDU> kaufman@Neon.Stanford.EDU (Marc T. Kaufman) writes: >In article <1990Aug1.154901.14781@ra.src.umd.edu> josip@ra.src.umd.edu (Josip Loncaric) writes: >>I have had a bizarre problem with a font of special math symbols which came >>with my Textures program (from Blue Sky Research, currently v1.2). Certain >>characters in CMEX10 font at 50pt (prints as 12pt size on 300dpi devices) are >>not rendered on the screen or printed properly... > >>In article <15235@reed.UUCP> barry@reed.UUCP (Barry Smith) writes: >> ........... >>>The problem is, as far as we can determine, due to errors in >>>the Macintosh system software, specifically the QuickDraw >>>graphic display language. In certain cases, especially with >>>larger point sizes, fonts that contain characters that differ >>>from ``normal'' placement are drawn incorrectly or >>>incompletely... > >>>It is our belief that our fonts are well-formed, and that the >>>problems you (and we) are experiencing are entirely due to >>>errors in the Apple system software... > >>What I'd like to know is the following: > >>(1) How come Apple has not yet fixed this known problem? Will it ever be fixed? > >First, is it the case that CMEX10 *NEVER* prints correctly? If so, why in the >world was it released, and how can the vendor claim that the font is "well >formed"? Quickdraw does strange things sometimes, but I would claim that the >operational definition of "well formed" is that Quickdraw renders the font >properly. If there are SOME applications that render the font properly, and >SOME applications that do not, then I would be more apt to point an >extremity at the Application -- I would not be surprised to find that some do >not deal properly with the full glory of Quickdraw fonts. Even if the FONT is >correct, is the FOND properly formed? > >Marc Kaufman (kaufman@Neon.stanford.edu) A brief clarification: CMEX10 prints correctly in all sizes when using PostScript-based printers. Sizes smaller than 50pt (=12pt on 300dpi devices) are rendered correctly by QuickDraw (and Textures application). The 50pt size and larger have problems with certain large characters (86pt size has more problematic characters than 50pt) when rendered via QuickDraw. Again, the "0x20=space" anomaly is not the problem, since other character codes are affected as well. Finally, ResEdit correctly renders all 50pt characters in its edit window, where QuickDraw is not used to draw character glyphs, while the "normal size" views on the right (where QD is apparently used) fail to show characters. My theory (confirmed by Textures developer) is this: Apple's published specs on FOND/FONT resource interpretation do not correspond to what QuickDraw does. These "undocumented features" are bugs, plain and simple. Apple, please fix this.... and if anyone on this net has a QD replacement which interprets FOND/FONT resources correctly, please let me know.... -- Josip Loncaric / SRC / U. of Maryland, College Park, MD 20745
kaufman@Neon.Stanford.EDU (Marc T. Kaufman) (08/03/90)
>In article <1990Aug1.154901.14781@ra.src.umd.edu> josip@ra.src.umd.edu (Josip Loncaric) writes: ->I have had a bizarre problem with a font of special math symbols which came ->with my Textures program (from Blue Sky Research, currently v1.2). Certain ->characters in CMEX10 font at 50pt (prints as 12pt size on 300dpi devices) are ->not rendered on the screen or printed properly... ->In article <15235@reed.UUCP> barry@reed.UUCP (Barry Smith) writes: -> ........... -->The problem is, as far as we can determine, due to errors in -->the Macintosh system software, specifically the QuickDraw -->graphic display language. In certain cases, especially with -->larger point sizes, fonts that contain characters that differ -->from ``normal'' placement are drawn incorrectly or -->incompletely... -->It is our belief that our fonts are well-formed, and that the -->problems you (and we) are experiencing are entirely due to -->errors in the Apple system software... OK folks. Mr. Loncaric was kind enough to send me a copy of the 50pt CMEX10 font. Here is what is going on: The font ascent is 38, descent is 147, giving a total bitmap height of 185 lines. Apple has, to my knowledge, always maintained that fonts must be no larger than 127 lines to render correctly. DTS tells me this often, and says "wait for system 7" (whatever that means). Blue Sky partially compensates for this by supplying a font height table, which gives a line offset and number-of-lines to draw for each character, since some are really small characters that are displaced (e.g. superscript parens). Character numbers 32-45, 115, and 128, however have a number-of-lines field that is bigger than 127. Quickdraw doesn't draw those, apparently thinking that the (8-bit) field is signed. It is possibly true that this field should be treated as unsigned, however there is no place in the (current) Apple documentation where this is claimed. Even though this is called a "50 point" font, by inspection it is really a 185 point font, which is larger than Apple officially supports. *I* claim that the font is NOT well-formed, by Apple's rules, and that Blue Sky is lucky to have even a subset render properly. My advice to Mr. Loncaric, and other TeX users, would be to obtain a Postscript version of the font, and use ATM, which is not subject to the 127 point limitation. Marc Kaufman (kaufman@Neon.stanford.edu)
heksterb@apple.com (Ben Hekster) (08/03/90)
> OK folks. Mr. Loncaric was kind enough to send me a copy of the 50pt CMEX10 > font. Here is what is going on: > > The font ascent is 38, descent is 147, giving a total bitmap height of 185 > lines. HOW can ANYONE call an ascent-38, descent-147 font a 50-point font!? The very FIRST page of the Font Manager chapter in Inside Macintosh [IM I-217] clearly states that "the font size measures the distance between the ascent of one line of text and the ascent line of the next line" which, in Figure 1 is shown to be the ascent plus descent plus leading, therefore in this case, at least a 38 + 147 = 185-point font. Also on [IM I-217], "The [font size] may range from 1 point to 127 points" Then, on [IM I-228] "The maximum [font height] is 127 pixels." Excuse me, but how can anyone in the business of making fonts not read the most basic information on them, exceed the specifications and then start complaining and blaming QuickDraw (meaning: the Font Manager) for it not working? IM was not written for nothing, you know. ____________________________________________________________ Ben Hekster Installer Dude | "Give me all Macintosh System Software | the storybook told me AppleLink: heksterb | The faith and the glory Internet: heksterb@apple.com | 'till my kingdom comes" BITNET: heksterb@henut5 | --Hymn, Ultravox
dorner@pequod.cso.uiuc.edu (Steve Dorner) (08/03/90)
In article <9567@goofy.Apple.COM> heksterb@apple.com (Ben Hekster) writes: >HOW can ANYONE call an ascent-38, descent-147 font a 50-point font!? The >very FIRST page of the Font Manager chapter in Inside Macintosh [IM I-217] >clearly states that [deleted] Fonts and points predate Inside Macintosh by several hundred years, a fact you seem to have overlooked. Not being a "type weenie", I can't say for sure, but I could imagine that the point size of a font full of weird and wonderful glyphs might relate more to what size of "normal" font should be used with it than its observed leading. That is, if this weird font looks best with 50pt Times, then it is reasonable to call the font 50pt, no matter what "size" it is by other measures. >Excuse me, but how can anyone in the business of making fonts not read >the most basic information on them, exceed the specifications and then >start complaining It is PRECISELY someone in the business of making fonts who is likely to ignore Apple's provincial definitions of the same. Whether that is the fault of the fontmaker (for ignoring restrictions they should have obeyed) or Apple (for making the restrictions in the first place) is debatable. And complaining is certainly in order, if the problem is keeping real users from doing useful work, as it seems to be. -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: {convex,uunet}!uiucuxc!dorner
josip@ra.src.umd.edu (Josip Loncaric) (08/03/90)
In article <9567@goofy.Apple.COM> heksterb@apple.com (Ben Hekster) writes: >> >> The font ascent is 38, descent is 147, giving a total bitmap height of 185 >> lines. > >HOW can ANYONE call an ascent-38, descent-147 font a 50-point font!? ... ANSWER: Knuth can (read TeXbook, p.432), and he is (I think) using standard typesetting terminology... > .... (explanation of how font height=ascent+descent+leading must be <= 127 deleted) Thanks for your comments - Apple's original QD spec for the Mac circa '84 had limited the size of fonts to 127 scan lines for all eternity, it seems. So what do the desktop publishers with QD-based printers (a la LaserWriter IISC) do when thay cannot render any symbols taller than about 30pt without resorting to non-Apple technology (ATM)? (I prefer bitmapped fonts anyway, they look better, and I can afford the disk space). How do we preview output at dot-for-dot magnification without screen fonts of suitable height? The FONT resource spec apparently allows character heights greater than 127 scan lines, but current QD does not. Does anyone else (apart from myself and BSR) think this is unreasonable? Another quirk (bug?) of QD is that characters which extend beyond their advance width are not rendered properly at the end of a line. For more situations in which QD fails to behave reasonably, see Barry Smith's posting in comp.sys.mac.system .... Josip Loncaric <josip@ra.src.umd.edu> These opinions are mine, all mine, .... -- Josip Loncaric / SRC / U. of Maryland, College Park, MD 20745
barry@reed.UUCP (Barry Smith) (08/07/90)
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
josip@ra.src.umd.edu (Josip Loncaric) (08/07/90)
In article <15305@reed.UUCP> barry@reed.UUCP (Barry Smith) writes: > >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). (... comments on other specific QuickDraw font rendering bugs ...) I agree with Mr. Smith - in particular, the 127pt limitation on character height should not apply to Mac II (see Inside Macintosh Vol. V, page V-185, where it says that on Mac II "the largest practical font" is "255 points"). Of course, if one does not use a character height table (where heights are packed into 1-byte wide fields), even taller characters can be described by the FONT resource. The fact that QuickDraw cannot interpret correctly even the characters which are less than 255 points tall (but more than 127) means that QD does have bug(s) in rendering characters. From all I have learned about this problem, the burden for fixing it seems to lie with Apple. My main point is that real users are suffering because of QuickDraw character rendering bugs, and that Apple should take a second look at its code. I am not the only user of Macintosh with this problem, over here we have several departments using several dozen Mac IIs to prepare papers and technical reports, and since I begun talking to people, a lot of them have reported similar problems, especially in previewing output on screen at dot-for-dot magnification. This is an important problem for a computer which supposedly is intended for DTP use. Apple should fix it, and please do not tell me that TrueType will solve all of our problems. I need a solution yesterday, not in a couple of years. <josip@ra.src.umd.edu> -- Josip Loncaric / SRC / U. of Maryland, College Park, MD 20745
meuchen@grad2.cis.upenn.edu (Paul Eric Menchen) (08/08/90)
In some article (this wasn't done automatically-my rn system is being buggy) dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: >In article <9567@goofy.Apple.COM> heksterb@apple.com (Ben Hekster) writes: >>HOW can ANYONE call an ascent-38, descent-147 font a 50-point font!? The >>very FIRST page of the Font Manager chapter in Inside Macintosh [IM I-217] >>clearly states that [deleted] > >Fonts and points predate Inside Macintosh by several hundred years, a >fact you seem to have overlooked. Not being a "type weenie", I can't >say for sure, but I could imagine that the point size of a font full of >weird and wonderful glyphs might relate more to what size of "normal" font >should be used with it than its observed leading. That is, if this >weird font looks best with 50pt Times, then it is reasonable to call the >font 50pt, no matter what "size" it is by other measures. No point was overlooked. A "type weenie" of several hundred years ago would tell you that if the greatest ascender in a face went 38 points above the baseline and the greatest descender went 147 points below, the face was at least 185 pt. Originally, the point size was the verticle height of the face as set in metal. So that all the type would line up when the metal was flush on the top and bottom, it would have to accomodate the largest ascender and descender. Also note that I could leave some blank space if I wanted. My biggest ascender goes 10 pts above the baseline and the largest descender goes 5 below, but for artistic reasons I think there should always be a little more line spacing (don't confuse with leading yet-the lead strips could be added later, but I want the space there no matter what, unless the user actually cuts the metal) so I add two more point worth of metal than normal. I would now call this 17pt so the typesetter knows how many lines he can fit on a page. Other complaints removed. Paul Eric Menchen meuchen@grad1.cis.upenn.edu