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