ar12@prism.gatech.EDU (REGISTER,ANDREW H) (03/02/91)
I got the ATM fonts from cica and installed them in win3 (all 117 of them). I
then wrote a macro in W4W to go through the font list and create a table entry.
When I printed it, some of the fonts printed pretty crazy. Although they appear
correctly on the screen, on an Apple Laserwriter II NTX Uncial was displaced up
half a line, Arnold Boecklin prints using a courier face, (so does brush script
and dingbats). All the eras have no space for space. Post Antiqua has filled in
B and D. I could go on but I will not.
This is not a complaint!!!!!! I *love* the extra fonts.
What I would like to know is what is happening here. I thought that the ATM uses
the same files to generate the screen version as the printer uses to generate the
printer version. All of them show up correctly on the screen (well almost) and
they print correctly to a hp laserjet II w/o postscript.
Some one said that ATM is a newer rendering technology than that in the II NTX.
Are the technologies not backward compatible?
Toodles
Andy
--
Andy Register Internet: ar12@prism.gatech.edu Bitnet: aregiste@gtri01.bitnet
-- Sometimes the Bears Win, Sometimes the Bulls Win --
-------- But the Pigs *Always* Lose -------- (author unknown)rob@aeras.uucp (Rob Rogers) (03/05/91)
In article <23147@hydra.gatech.EDU> ar12@prism.gatech.EDU (REGISTER,ANDREW H) writes: > >I got the ATM fonts from cica and installed them in win3 (all 117 of them). I >then wrote a macro in W4W to go through the font list and create a table entry. >When I printed it, some of the fonts printed pretty crazy. Although they >appear correctly on the screen, on an Apple Laserwriter II NTX Uncial >was displaced up half a line, Arnold Boecklin prints using a courier >face, (so does brush script and dingbats). All the eras have no space >for space. Post Antiqua has filled in B and D. I could go on but I will not. > >This is not a complaint!!!!!! I *love* the extra fonts. > >What I would like to know is what is happening here. >I thought that the ATM uses the same files to generate the screen >version as the printer uses to generate the printer version. >All of them show up correctly on the screen (well almost) and >they print correctly to a hp laserjet II w/o postscript. > >Some one said that ATM is a newer rendering technology than that in the II NTX. >Are the technologies not backward compatible? > >Toodles >Andy What sizes were you printing? ATM will not build a font from the postscript file if the bitmapped file already exists. That could explain the difference between screen and printer. Take out all but 10 point bitmapped, then size your stuff to 18 or so and take a look. As for printing courier, 5 to 1 gets you ATM can't find the printer font, and if it can, the printer memory is full (did you print all the fonts at the same time?) As far as I know, all known postscript routines are downward <> upward compatable. -- Rob Rogers Art Director, ARIX Computer Corporation {mips|sun|wyse|jade}!aeras!rob <> rob@aeras.UUCP <> 73377.1017@compuserve.com <> GEnie=R.ROGERS10 <> AOL=MacGun
ar12@prism.gatech.EDU (REGISTER,ANDREW H) (03/06/91)
In article <1991Mar4.221620.4128@aeras.uucp>, rob@aeras.uucp (Rob Rogers) writes: > > What sizes were you printing? ATM will not build a font from the > postscript file if the bitmapped file already exists. That could explain > the difference between screen and printer. Take out all but 10 point > bitmapped, then size your stuff to 18 or so and take a look. > As for printing courier, 5 to 1 gets you ATM can't find the printer font, > and if it can, the printer memory is full (did you print all the fonts at > the same time?) > > As far as I know, all known postscript routines are > downward <> upward compatable. First let me address this. You can turn bitmapping off. This was done. But even with bit-mapping on, the printer will use the post-script stuff. The bit-map only applies to the screen. Second, there is a parameter in the atm.ini file that you can change to allow small fonts to be rendered correctly. Third, the problem is not with printer memory. Even if you send only that particular font with nothing else you still get courier. As for not finding the printer font, I don't think there is such a thing in post-script. (at least not like in the hp world) The font file is an algorithm to build the font. ATM and the printer both use the same algorithm file so if it shows up on the screen but does not print then somewhere there is an incompatability. Now for some input from folks that know a bunch more about this stuff than I do. Berthold from MIT sent the following advice (* edited *) (*) A few of these fonts come from a Mac and so use control-M as line terminator instead of control-J (which is what the PS interpreter looks for). If such files are shipped to the printer over some links, such as LocalTalk, then the PS `readline' will get limitchecks, because the lines are too long. (Over serial lines this works, since on serial lines control-M is replaced by control-J). (*) ATM only reads as much of the file as it needs - so if there is junk at the end, or incorrect closing of save/restore or begin/end context, it doesn't matter - but it does matter when you send the file to a printer. So while ATM for PC is crawling with bugs and generally very fragile, in some instances it is actually more `robust' than a printer's interpreter. (*) It really helps to download an error handler (such as ehandler.ps) so you can get error messages. Otherwise the font may be sent down, get and error and you will never know. Subsequent calls to the font fail and Courier is substituted. Thanks Berthold!! I was going to include one additonal message but I have misplaced it. (Apologies to the sender) I will try to paraphrase. It seems that there are different methods for filling fonts in the post-script definition. You can begin filling from either the left or the right. If the font algorithm is not robust then filling from one side will fill in places that filling from the other will not. This most likely explains why some fonts fill in the P and D on the printer but do not fill under ATM. (I think I got this mostly correct) Toodles Andy -- Andy Register Internet: ar12@prism.gatech.edu Bitnet: aregiste@gtri01.bitnet -- Sometimes the Bears Win, Sometimes the Bulls Win -- -------- But the Pigs *Always* Lose -------- (author unknown)