edmoy@violet.berkeley.edu (02/14/88)
I don't know if this has been mentioned before, but has anyone noticed that LW 5.0 doesn't create the Chicago font correctly, either when downloading to the LaserWriter or when creating a PostScript file. The glyphs for the characters 17-20 (command, check mark, diamond and apple) are missing, so these symbols don't appear in the final output. I checked LW 4.0 and it properly creates these glyphs. On the subject of bugs, both 4.0 and 5.0 won't print italicized Chicago either. The 3.x series worked fine. Edward Moy Workstation Software Support Group University of California Berkeley, CA 94720 edmoy@violet.Berkeley.EDU ucbvax!violet!edmoy
leonardr@uxe.cso.uiuc.edu (02/16/88)
milt@mist.cs.orst.edu(Milt Sagan) writes in comp.sys.mac >When a user issues a cmdKey equivalent of copy (paste) for a desk accessory, >does the DA get a parameter block csCode equal to accCopy (accPaste)? > >The DA I'm writing will respond to copy and paste commands when the user >selects them with the mouse. However, when a command key equivalent is >issued I must interrupt a keyDown event in order to respond correctly. >I had expected to receive an accCopy or accPaste. >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >Was I incorrect about my assumption, or is there something I should have >done to inform the system, Desk Manager or whatever, that the DA can handle >key equivalents for the Edit menu commands? > >I'm writing the DA in Lightspeed C so the drvrEMask includes keyDown events >(otherwise I would not be able to respond to such events). My SigmaEdit DA (which is also written in Lightspeed C) also has to detect the Edit command based on the current keydown event and detect it that way. This, however, poses a problem for international use (except that to my knowledge and experience with the int'l system the cmd keys for the Edit menu are still the same). +---------------------------------+-----------------------------------+ + + Any thing I say may be taken as + + Leonard Rosenthol + fact, then again you might decide+ + President, LazerWare, inc. + that it really isn't, so you + + + never know, do you?? + + leonardr@uxe.cso.uiuc.edu + + + GEnie: MACgician + + + Delphi: MACgician + + + + + +---------------------------------+-----------------------------------+
holt@apple.UUCP (Bayles Holt) (02/16/88)
In Article 13801 Edward Moy writes: >I don't know if this has been mentioned before, but has anyone noticed that >LW 5.0 doesn't create the Chicago font correctly, either when downloading >to the LaserWriter or when creating a PostScript file. The glyphs for the >characters 17-20 (command, check mark, diamond and apple) are missing, so >these symbols don't appear in the final output. I checked LW 4.0 and it >properly creates these glyphs. I tried to duplicate the problems you mention in version 5.0 without success. Perhaps you could forward specific info about how to duplicate the problem such as the document, font size, and application you were using. As a initial guess to such behavior I might offer the following explanation and you can judge as to its applicability. Some of the early bitmap fonts were created with different characters in different point sizes. That is, Chicago 12 point might contain the "missing" characters while Chicago 18 point (or some other size) might not. When a document with 12 point Chicago is printed, the LaserWriter driver selects the 18 point font to print (because it prints better at the higher resolution) and ends up without the characters in question. The practice of putting different characters in different point sizes is discouraged, but you can check this out very easily, just see if you have more than one point size of Chicago in your font menu. >On the subject of bugs, both 4.0 and 5.0 won't print italicized Chicago either. >The 3.x series worked fine. The Italic style variation also seemed to work fine for me. Again by way of explanation, the original LaserWriter contained a bug in PostScript where italicizing a bitmap object such as a font character did not work when the character being rendered was exactly the right size for printing and did not require scaling. Again this is easy to test just by setting the point size to some other size and see if the problem goes away. Otherwise... If there are additional comments or questions, you may reply to me directly. --Bayles Holt holt@apple.UUCP APPLELINK: HOLT2