josip@ra.src.umd.edu (Josip Loncaric) (07/23/90)
I have a strange problem with a font of math symbols which came with Textures
v1.0 program. The font is bitmapped, size is 50 points (prints as 12pt on
laser printers), and characters include some quite large parenthesies (for
matrices) and square root signs (see Knuth's TeXbook, pg.432, showing layout
for "cmex10" math extension font).
Large (i.e. tall) characters ("(" at hex 0x20 for example) sometimes do not
show up on the screen or the printout. For a given method, the problem is
repeatable, but different ways of displaying the character sometimes succeed.
I've tried ResEdit, Textures, Word, and SampleIt!, but cannot figure out what
is going on. For example, ResEdit will show the character (at least the visible
portion) in its enlarged window, but the character will not show up in
normal view.
Some information about FONT: type is 0xD001, defining characters from 0x0 to
0x80, widMax is 0x4B, kernMax is -1, nDescent is 0, fRectWidth is 0x48,
fRechHeight is 0xB9, ascent is 0x26, descent is 0x93, and leading is 0x2. Could
tall characters be causing problems for the Font Manager? Note that while
FONTs can be designed with sizes of up to 127 pts, this 50-pt font includes
characters much taller than 127pts. Is there a fix?
Josip Loncaric
SRC/UMD
<josip@ra.src.umd.edu>
--
Josip Loncaric / SRC / U. of Maryland, College Park, MD 20745kaufman@Neon.Stanford.EDU (Marc T. Kaufman) (07/24/90)
In article <1990Jul23.161753.13159@ra.src.umd.edu> josip@ra.src.umd.edu (Josip Loncaric) writes: >Large (i.e. tall) characters ("(" at hex 0x20 for example) sometimes do not >show up on the screen or the printout. For a given method, the problem is >repeatable,... 0x20 is a poor choice for a visible graphic character. 0x20 is "SPACE" in most normal character sets. I would not be surprised to find that "spaces" are handled specially in the output algorithms, I would guess that really smart ones supress printing it altogether. Other codes you want to stay away from are 0x09 (Tab) and 0x0d (Carriage Return). I just checked 32 fonts that I have, and NONE of them attempt to put visible graphics (including the "missing character") at any of the three places mentioned above. Marc Kaufman (kaufman@Neon.stanford.edu)
josip@ra.src.umd.edu (Josip Loncaric) (07/26/90)
In article <1990Jul24.035846.18950@Neon.Stanford.EDU> kaufman@Neon.Stanford.EDU (Marc T. Kaufman) writes: >In article <1990Jul23.161753.13159@ra.src.umd.edu> josip@ra.src.umd.edu (Josip Loncaric) writes: > >>Large (i.e. tall) characters ("(" at hex 0x20 for example) sometimes do not >>show up on the screen or the printout. For a given method, the problem is >>repeatable,... > >0x20 is a poor choice for a visible graphic character. 0x20 is "SPACE" in >most normal character sets. I would not be surprised to find that "spaces" >are handled specially in the output algorithms, I would guess that really >smart ones supress printing it altogether. > Several people have pointed this out to me, and perhaps I should have been clearer. Hex x20 is not the only "missing" character, so are all of the others 0x20 thru 0x2B, and 0x73. Of course, this is a math font full of special symbols and there is no reason to suppose that 0x20 should be a space. However, you are right, Mac does make this assumption (I've checked a 12pt version of my font, and character 0x20 does not show up although others do). Obviously the output driver must handle this as a special case. The point I want to make is that presence of characters 0x21-0x2B and 0x73 in smaller point size font shows the problem lies elsewhere. There must be some kind of limitation on character height... this is suggested by the fact that 86pt version of this font is "missing" even more symbols... finally, if Mac is designed to give users flexibility of using all kinds of fonts, hardcoding 0x20 into the operating system as "space" does not seem very smart to me... Josip Loncaric <josip@ra.src.umd.edu> -- Josip Loncaric / SRC / U. of Maryland, College Park, MD 20745
barry@reed.UUCP (Barry Smith) (07/26/90)
From a letter to Mr. Loncaric: Thank you for your comments on our Textures software. I'm afraid that I can not offer much assistance with the printing and display of the mathematical fonts at large sizes, although I may be able to explain the cause of the problem. 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
kaufman@Neon.Stanford.EDU (Marc T. Kaufman) (07/26/90)
In article <1990Jul26.050218.22469@ra.src.umd.edu> josip@ra.src.umd.edu (Josip Loncaric) writes: >... finally, if >Mac is designed to give users flexibility of using all kinds of fonts, >hardcoding 0x20 into the operating system as "space" does not seem very >smart to me... [I can't speak to the missing "big" characters, except to say that they must be renderable SOMEWHERE, or they would not have been put in the font in the first place] About the space. We really can't tell whether the 0x20 character is blank or has a graphic just by looking at the FOND, or width table, or anything else available to the average text handling program. When setting TEXT, it is often necessary to be able to distinguish the space character, so that trailing blanks can be supressed for right justification, and so that extra space can be added for full justification. Once you have made the decision that 0x20 is to be treated specially for that purpose, you can't very well use it for special graphics. There are 230+ characters available for graphic use in an Apple font. If that isn't enough, you can go to 2-byte characters as the Asian fonts do. BTW: even the 2-byte fonts stay away from 0x20 graphics. And you can make up as many different 230 character fonts as you like, and mix them all in a document. The only situation in which I would agree with your comment on the use of 0x20 is on a monospaced display (can you say PC?), where there is no particular advantage to being able to adjust interword spacing. Even there, TEXT editors would likely pick 0x20 as a word-break character (rather than, say, 0x41). Summary: attempting to use 0x20 as anything OTHER than a "space" does not seem very smart to me... Marc Kaufman (kaufman@Neon.stanford.edu)
josip@ra.src.umd.edu (Josip Loncaric) (07/31/90)
In article <1990Jul26.071001.12724@Neon.Stanford.EDU> kaufman@Neon.Stanford.EDU (Marc T. Kaufman) writes: >In article <1990Jul26.050218.22469@ra.src.umd.edu> josip@ra.src.umd.edu (Josip Loncaric) writes: > >>... finally, if >>Mac is designed to give users flexibility of using all kinds of fonts, >>hardcoding 0x20 into the operating system as "space" does not seem very >>smart to me... > ( explanation of why text editors need space characters deleted ) > >Summary: attempting to use 0x20 as anything OTHER than a "space" does not seem >very smart to me... > >Marc Kaufman (kaufman@Neon.stanford.edu) I apologize for offending your sensibilities... but we are talking about two different things. I can see why a text editor may need to know about space characters, and your point is well taken, but there is no reason why QuickDraw ought to know about them. QuickDraw should just do what it is told to do. Any intelligence about space characters should be contained in the application which cares about them, because another application need not give a damn. Anyway, you are also right in pointing out that character codes over 0x80 are available for defining special characters. Yes, it causes some pain to shuffle standard TeX character codes for about 23Mb of fonts, but it could be done. However, as I pointed out earlier, this is NOT the problem I've experienced. In fact, I believe Textures performs a similar procedure, and most character codes 0x20 ARE displayed properly (although QuickDraw probably cannot be given credit for that). My problem, as a note from Barry Smith of Blue Sky Research explained, is that QuickDraw has known bugs, which Apple has done nothing about over the past three years. And finally, I am NOT a PC user. I've used and liked the Mac since it was introduced. It is precisely the graphical orientation which makes Macs so great to work with. However, character images (what gets shown) and what they mean (e.g., word separation) are two completely different concepts. Yes, an application which wants to use character code 0x20 as something other than space can override QuickDraw, but it should not have to. Just my opinion, but many other people would agree, I think. Enough said. Josip Loncaric <josip@ra.src.umd.edu> -- Josip Loncaric / SRC / U. of Maryland, College Park, MD 20745