ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) (07/26/90)
The Spring 1990 issue of MacTech Quarterly had an interesting comparison of the relative virtues of the font handling schemes in PostScript versus Apple's TrueType system. The funny thing was, the author of the article, Bill Woodruff, is a self-confessed PostScript fan[atic?]--to the extent that the editor promised a future article promoting the opposing viewpoint--but it didn't read that way to me at all. I should admit up front that I'm not familiar with Adobe's hinting scheme--I *still* haven't got hold of a copy of the Type 1 Font Format book--but I do have a copy of the TrueType documentation. Anyway, one of the points of the article was that the hints in Adobe PostScript fonts merely identify important features of each character outline, and leave it to the interpreter (and imaging engine) to perform the appropriate transformations to preserve legibility at low resolutions. This is described as a "high level" approach, as opposed to the "assembly language" scheme of TrueType, which embeds explicit tweaking instructions in the outline description. The article goes on to say that Adobe has been steadily improving its hinting software since 1984. To take advantage of the improvements, you don't need to upgrade all your existing fonts--just your PostScript implementation. This is contrasted with TrueType, where you'd need new versions of your fonts, since these need to have the hinting algorithms built-in. Does anybody else spot what's wrong with this? It seems to me that most current implementations of PostScript takes the form of ROMs inside a printer or typesetter. Upgrading such a beast is far from a straightforward, low-cost job, judging from past experience. By contrast, for people with lots of fonts, most of those will be on disk rather than in a ROM, so upgrading them will be, at worst, a matter of returning the old original disks together with the upgrade charge. In these days of non-copy-protected software, you can continue working with copies of the originals until the new versions arrive. Some vendors don't even want the old disks back--the fact that they've got a record of you as a registered user is enough for them. Of course, for those proud owners of NeXT machines with Display PostScript interpreters included in the system software, things may work rather differently... What do other people think of the relative advantages of PostScript versus TrueType? There were a few other points mentioned in the article, but they didn't strike me as being as crucial as the above one. For example, the rarity of font designers, and the headaches they have to go through to support yet another font format. I thought Apple designed TrueType to make it as easy as possible for everybody else in the world to convert their fonts to this format. Comments, anyone? Lawrence D'Oliveiro fone: +64-71-562-889 Computer Services Dept fax: +64-71-384-066 University of Waikato electric mail: ldo@waikato.ac.nz Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00 To someone with a hammer and a screwdriver, every problem looks like a nail with threads.
domo@tsa.co.uk (Dominic Dunlop) (07/26/90)
[Loadsa postings on the net from NZ and Australia recently. Hi folks. What happened? Anyways...] In article <1100.26af57d3@waikato.ac.nz> ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: >The Spring 1990 issue of MacTech Quarterly had an interesting comparison >of the relative virtues of the font handling schemes in PostScript versus >Apple's TrueType system. >Anyway, one of the points of the article was that the hints in Adobe >PostScript fonts merely identify important features of each character >outline, and leave it to the interpreter (and imaging engine) to perform >the appropriate transformations to preserve legibility at low >resolutions. This is described as a "high level" approach, as >opposed to the "assembly language" scheme of TrueType, which embeds >explicit tweaking instructions in the outline description. >Comments, anyone? OK. Why is a high-level approach almost always better than a low-level approach? Because a high-level approach can better accommodate new technologies simply by labelling the low-level aspects of any technology, whether new or old, as somebody else's problem. Suppose I have one of HP's spiffy new printers with Resolution Enhancement Technology. The low-level hints in a TrueType font are likely to be aimed at making ``dot/no dot'' decisions, and so cannot take advantage of an engine which can shrink dots and slightly vary their horizontal placement. High-level hints in PostScript fonts leave details of implementation to the interpreter, and a suitably clever interpreter (if Adobe or a clone maker should come up with one -- and that's quite a big if) could correctly drive RET, and so produce slightly better-looking results than TrueType. I'd guess that similar considerations would apply to anti-aliasing of character edges on grey- scale monitors by using shades of grey rather than straight black-white transitions. A PostScript RIP behind the screen should (assuming enough MIPs and memory to cook up fonts at a bearable speed) be able to do this. Would TrueType? Possibly talk of MIPs hints (pun intended) at Apple's and Microsoft's reason for going low-level. Most of the installed base of Macs and PCs has little power to spare for working out how to respond to a hint: better and cheaper to tell the poor little machine exactly what to do -- even at the cost of future problems or sub-optimal performance. Course, I could be wrong. TrueType hints may do all this. Comments anyone? -- Dominic Dunlop
capslock@wet.UUCP (Allen Crider) (07/28/90)
In article <1100.26af57d3@waikato.ac.nz> ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: > > >Does anybody else spot what's wrong with this? It seems to me that >most current implementations of PostScript takes the form of ROMs >inside a printer or typesetter. Yes I know what you mean. The important upgrades in Adobe's interpreters is more CPU horsepower. I have gone through all Linotype's RIPS from 'one' to the RIP IV. I'm waiting for Linotypes emerald rip. What I'm saying is CPU power is increasing as fast as the upgrades to Adobe's interpreters. >...By contrast, >for people with lots of fonts, most of those will be on disk rather >than in a ROM, so upgrading them will be, at worst, a matter of >returning the old original disks together with the upgrade charge. Extremely expensive for vendor and user alike. Software vendors want to be sure you own a legit copy of their fonts, so they have large databases and people to use them. They have to mail you a letter announcing the amazing new upgrade. They have to make new disks and documention. I just got an upgrade for PageMaker 4.0 on the Mac. $150. >Of course, for those proud owners of NeXT machines with Display >PostScript interpreters included in the system software, things >may work rather differently... <sigh> I'm looking at 18 point Courier as I type this. It is a bitmapped font. Display PostScript needs anti-aliasing. >What do other people think of the relative advantages of PostScript >versus TrueType? TrueType is not a complete page description language. TrueType does not know how to image a circle, or halftone a 24-bit image. TrueType depends on the host for its CPU, memory, operating system and disk storage. Besides, why buy another font library? TrueType doesn't offer enough of an advantage for me to consider switching. TrueType has been delayed long enough for me to comfortably call it VAPORWARE. I cannot use it now unless I find an Alpha System 7. I guess this is because Apple wants to be sure it works on a five-year-old Mac. Apple has lost years of their advantage vis-a-vis MS-DOS by going ahead with this project. I suspect they could have bought Adobe Systems for the true cost of TrueType. I'm glad they didn't.
chrisg@microsoft.UUCP (Chris GUZAK) (07/30/90)
In article <1990Jul26.135834.9874@tsa.co.uk> domo@tsa.co.uk (Dominic Dunlop) writes: >Possibly talk of MIPs hints (pun intended) at Apple's and Microsoft's >reason for going low-level. Most of the installed base of Macs and PCs has >little power to spare for working out how to respond to a hint: better and >cheaper to tell the poor little machine exactly what to do -- even at the >cost of future problems or sub-optimal performance. ummm... my 20MHz 386 can churn out more mips that the 68k in my printer. When it comes to putting power where it can be used, I'd rather pay for it in my desktop machine (where it is much cheaper) than in my printer. I'd also like my font engine there as well, that way I get nice stuff on the screen as well as on paper. >Dominic Dunlop Chris Guzak
roger@grenada.UUCP (Roger Corman) (08/01/90)
According to Adobe, low level hinting (hinting code in the fonts) was tried
early in the company's history. They abandoned it and chose high-level
hinting (hinting code in the rendering engine) for two main reasons.
The first was that the amount of time and expense required to create each
font was great--it wad have taken an unacceptable amount of time to develop
a decent library of fonts. The code in each font had to be modified
and debugged. Their experiences lead one to suspect that it will take
awhile for a large number of TrueType fonts to become available. True,
it is probably easy to convert other font outline formats to this format,
but not so easy to create *quality* fonts with low level hinting.
The second reason had to do with the future of the font technology. In
order to get better rendering results, the low-level hinting
method probably would require upgrading the fonts themselves (where the
rendering hints are). With Adobe's approach, improved rendering
engines can get better results with the same old font libraries. Printers
being mechanical, and tied to microprocessor technology, are likely to
be upgraded every few years, with newer and better rendering engines.
Customers expect this. Customers don't expect to have to buy new fonts.
The high-level hinting approach appears to give Adobe fonts more long term
value.
I ought to add what I consider another reason that high-level hinting is
good for Adobe. Now that Adobe has, under market pressure, opened up their
font formats such that the information in them can be readily understood,
the key rendering technology is still in a black box (PostScript and ATM
rendering engines).
Which type of hinting is better for you and me? Whichever allows us
the most fonts of the best quality for the lowest price (obviously). I
personally expect it will be *years* (if ever) before the number of quality
fonts now available in Adobe format are available in TrueType format.
Roger Corman
Island Graphics
Santa Rosa, CA
(707)523-4465
{uunet,ucbcad,sun}!island!rogerbarnett@grymoire.crd.ge.com (Bruce Barnett) (08/03/90)
In article <862@grenada.UUCP> roger@grenada.UUCP (Roger Corman) writes: >The second reason had to do with the future of the font technology. In >order to get better rendering results, the low-level hinting >method probably would require upgrading the fonts themselves (where the >rendering hints are). With Adobe's approach, improved rendering >engines can get better results with the same old font libraries. Printers >being mechanical, and tied to microprocessor technology, are likely to >be upgraded every few years, with newer and better rendering engines. >Customers expect this. Customers don't expect to have to buy new fonts. >The high-level hinting approach appears to give Adobe fonts more long term >value. A good example of this is the new HP LaserJet III, which is 300 DPI, but uses variable size dots to get effectively 600 DPI. I doubt TrueType will look as nice as PostScript fonts on this device. Also - Font designers say it takes a year to design a decent font. I don't know how long it would take to convert it into the proper data for PostScript or TrueType, but I doubt it's trivial. How can you design low level hints in the fonts, when the output can be on 72, 200, 300, 600, 1200, or 2400 DPI machines? Do you only load the "hints" for the output devices you will drive? Getting a 10 point font to look decent on a 72 dpi screen is easy. Getting a 5 point font to look good on paper is something else. Given a screen that has QuickDraw/TrueType and a PostScript printer and typesetter, what will people do to get good output? Will they have to buy a QuickType (that's QuickDraw and TrueType) Laser Printer and Typesetter? (Bad answer - why buy more equipment?) Will QuickType be converted into PostScript? (Another Bad Answer - it won't be WYSIWYG) Will TrueType fonts be downloaded into the typesetter? (Another Bad Answer - I doubt TrueType will look as good as PostScript at 1270 or 2400 dpi). -- Bruce G. Barnett barnett@crd.ge.com uunet!crdgw1!barnett
chewy@apple.com (Paul Snively) (08/04/90)
In article <BARNETT.90Aug2171900@grymoire.crd.ge.com> barnett@grymoire.crd.ge.com (Bruce Barnett) writes: > A good example of this is the new HP LaserJet III, which is 300 DPI, > but uses variable size dots to get effectively 600 DPI. > > I doubt TrueType will look as nice as PostScript fonts on this device. This is indeed probably a good example of where "low-level" hints don't work too well. > Also - Font designers say it takes a year to design a decent font. > I don't know how long it would take to convert it into the proper data > for PostScript or TrueType, but I doubt it's trivial. It probably isn't, but on the other hand, the font-studly developers will probably have some very sophisticated tools for constructing/modifying/converting etc. fonts between the formats. (Let's put it this way: if they don't, we're in a world of hurt.) > How can you design low level hints in the fonts, when the output > can be on 72, 200, 300, 600, 1200, or 2400 DPI machines? Do you only > load the "hints" for the output devices you will drive? Don't let the term "low-level" fool you. TrueType fonts are still mathematical descriptions of curves, and this applies to the hints as well. They're still resolution independent. > Given a screen that has QuickDraw/TrueType and a PostScript printer > and typesetter, what will people do to get good output? If they use PostScript fonts, the PostScript engine will render them; if they use TrueType fonts, the new driver will download the TrueType rendering code and that will be used. Either way, it still works. > Will they have to buy a QuickType (that's QuickDraw and TrueType) > Laser Printer and Typesetter? (Bad answer - why buy more equipment?) This won't be necessary. > Will QuickType be converted into PostScript? > (Another Bad Answer - it won't be WYSIWYG) Right again, which is one reason it's not being done. > Will TrueType fonts be downloaded into the typesetter? > (Another Bad Answer - I doubt TrueType will look as good > as PostScript at 1270 or 2400 dpi). Well, that remains to be seen, doesn't it? :-) __________________________________________________________________________ Paul Snively Macintosh Developer Technical Support Apple Computer, Inc. chewy@apple.com Just because I work for Apple Computer, Inc. doesn't mean that I believe what they believe, or vice-versa. __________________________________________________________________________
macman@wpi.wpi.edu (Chris Silverberg) (08/04/90)
In article <862@grenada.UUCP> roger@grenada.uu.net (Roger Corman) writes: >Which type of hinting is better for you and me? Whichever allows us >the most fonts of the best quality for the lowest price (obviously). I >personally expect it will be *years* (if ever) before the number of quality >fonts now available in Adobe format are available in TrueType format. A couple years perhaps. But it will happen. Bitstream has already committed itself to fully supporting the TrueType format, and other companies are sure to follow. ._._._._._._._._._._._._._._._._._._.._._._._._._._._._._._._._._._._._._._. Chris Silverberg AOL: Silverberg Worcester Polytechnic Institute GEnie: C.Silverberg INTERNET: macman@wpi.wpi.edu SYSOP: Main Street U.S.A. BBS FIDONET: 322/575.1 508.832.7725 (1200/2400)
cory@three.MV.COM (Cory Kempf) (08/09/90)
chewy@apple.com (Paul Snively) writes: >If they use PostScript fonts, the PostScript engine will render them; if >they use TrueType fonts, the new driver will download the TrueType >rendering code and that will be used. Either way, it still works. Does this mean that the fonts will be down loaded as the curve equations, and a postscript program will be sent along to convert the equations into bitmaps? Or are the bitmaps going to be generated on the Mac and then downloaded to the printer/typesetter (expensive, especially on something like a 1200 dpi device)? +C -- Cory Kempf I do speak for the company (sometimes). The Enigami Co. 603 883 2474 email: cory@three.mv.com, harvard!zinn!three!cory
chewy@apple.com (Paul Snively) (08/14/90)
In article <406@three.MV.COM> cory@three.MV.COM (Cory Kempf) writes: > chewy@apple.com (Paul Snively) writes: > > >If they use PostScript fonts, the PostScript engine will render them; if > >they use TrueType fonts, the new driver will download the TrueType > >rendering code and that will be used. Either way, it still works. > > Does this mean that the fonts will be down loaded as the curve equations, > and a postscript program will be sent along to convert the equations into > bitmaps? Or are the bitmaps going to be generated on the Mac and then > downloaded to the printer/typesetter (expensive, especially on something > like a 1200 dpi device)? My understanding (I'm not a gnarly printing dude, so don't quote me on this!) is that the curve equations will be downloaded to the printer along with machine code to do the rendering. So the printer will still do the rendering, but will do it as fast as its processor can. __________________________________________________________________________ Paul Snively Macintosh Developer Technical Support Apple Computer, Inc. chewy@apple.com Just because I work for Apple Computer, Inc. doesn't mean that I believe what they believe, or vice-versa. __________________________________________________________________________
hammen@ddsw1.MCS.COM (Robert Hammen) (08/14/90)
In article <9724@goofy.Apple.COM> chewy@apple.com (Paul Snively) writes: >> Does this mean that the fonts will be down loaded as the curve equations, >> and a postscript program will be sent along to convert the equations into >> bitmaps? Or are the bitmaps going to be generated on the Mac and then >> downloaded to the printer/typesetter (expensive, especially on something >> like a 1200 dpi device)? >My understanding (I'm not a gnarly printing dude, so don't quote me on >this!) is that the curve equations will be downloaded to the printer along >with machine code to do the rendering. So the printer will still do the >rendering, but will do it as fast as its processor can. From our "experiments" with System 7.0, this is exactly what seems to be the case. When a TrueType font is called for the first time, a message pops up in the status window saying "Downloading font scaling code." This is the better way to do things (who would want to wait while your Mac generated bitmaps at 3386 dpi and shipped them down the network to your imagesetter?). We'll just have to see how fast this font-scaling code is compared to the PostScript font rasterizer. Another question is compatibility. We've got a bunch of PostScript clones in-house for testing purposes, and they both failed to work with the font scaling code (and the more ironic thing is that one of them uses the Bauer PS clone that's the basis for Microsoft's TrueImage!). It's very important for this code to work on non-680x0-based controllers, now that Adobe has introduced many of these. ///////////////////////////////////////////////////////////////////////////// / Robert Hammen | Technical Editor | Personal Publishing Magazine / / 191 S. Gary Ave. | Carol Stream, IL 60188 | (708) 462-2414 / / hammen@ddsw1.mcs.com | 76702.1135@compuserve.com | GEnie: R.HAMMEN / /////////////////////////////////////////////////////////////////////////////
dorner@pequod.cso.uiuc.edu (Steve Dorner) (08/14/90)
An unnamed source [:-)] at Apple writes: >the curve equations will be downloaded to the printer along >with machine code to do the rendering. So the printer will still do the >rendering, but will do it as fast as its processor can. Uck. Uck! UCK! UUUUUCCCCCKKKKK!!!!! More d**n controller-dependent junk. I guess my NeXT printer won't be rendering "TrueType" fonts. Nor will any other PostScript printer that uses a different controller (such as the ones that use RISC chips). Adobe ought to be pleased with this decision; their PostScript driver is looking better and better. -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: {convex,uunet}!uiucuxc!dorner
cmf@obie.cis.pitt.edu (Carl M. Fongheiser) (08/15/90)
In article <1990Aug14.124450.7262@ddsw1.MCS.COM> hammen@ddsw1.MCS.COM (Robert Hammen) writes: >Another question is compatibility. We've got a bunch of PostScript clones >in-house for testing purposes, and they both failed to work with the font >scaling code (and the more ironic thing is that one of them uses the Bauer >PS clone that's the basis for Microsoft's TrueImage!). It's very important >for this code to work on non-680x0-based controllers, now that Adobe has >introduced many of these. Yeah, and non-680x0 controllers have been out for years. The DEC PrintServer 40 is based on a MicroVAX, and it's been out for around 3 years now. Carl Fongheiser cmf@unix.cis.pitt.edu
chewy@apple.com (Paul Snively) (08/16/90)
In article <1990Aug14.142056.720@ux1.cso.uiuc.edu> dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: > >the curve equations will be downloaded to the printer along > >with machine code to do the rendering. So the printer will still do the > >rendering, but will do it as fast as its processor can. > > Uck. Uck! UCK! UUUUUCCCCCKKKKK!!!!! More d**n controller-dependent junk. > I guess my NeXT printer won't be rendering "TrueType" fonts. Nor will any > other PostScript printer that uses a different controller (such as the > ones that use RISC chips). Well, all this really means is that different devices will probably require different drivers. What a shock--this is already the case. > Adobe ought to be pleased with this decision; their PostScript driver is > looking better and better. I think their new PostScript driver sounds pretty cool, too. Keep in mind that it's not like the use of alternative font-rendering mechanisms is mutually exclusive--folks will be able to choose whatever best suits their purposes. __________________________________________________________________________ Paul Snively Macintosh Developer Technical Support Apple Computer, Inc. chewy@apple.com Just because I work for Apple Computer, Inc. doesn't mean that I believe what they believe, or vice-versa. __________________________________________________________________________
cory@three.mv.com (Cory Kempf) (08/22/90)
chewy@apple.com (Paul Snively) writes: >In article <406@three.MV.COM> cory@three.MV.COM (Cory Kempf) writes: >> Does this mean that the fonts will be down loaded as the curve equations, >> and a postscript program will be sent along to convert the equations into >> bitmaps? Or are the bitmaps going to be generated on the Mac and then >> downloaded to the printer/typesetter (expensive, especially on something >> like a 1200 dpi device)? >My understanding (I'm not a gnarly printing dude, so don't quote me on >this!) is that the curve equations will be downloaded to the printer along >with machine code to do the rendering. So the printer will still do the >rendering, but will do it as fast as its processor can. MACHINE CODE???? This sounds like a solution that will only work with Apple's Laserwriter (or other 68k based systems). What about all of the non-Apple postscript devices? What about the non-68k based postscript engines? Tell me it isn't so!!! (actually, at the moment, I am kinda glad that I didn't buy a postscript printer) +C -- Cory Kempf I do speak for the company (sometimes). The EnigamI Co. 603 883 2474 email: cory@three.mv.com, harvard!zinn!three!cory
chewy@apple.com (Paul Snively) (08/25/90)
In article <438@three.mv.com> cory@three.mv.com (Cory Kempf) writes: > >In article <406@three.MV.COM> cory@three.MV.COM (Cory Kempf) writes: > > >> Does this mean that the fonts will be down loaded as the curve equations, > >> and a postscript program will be sent along to convert the equations into > >> bitmaps? Or are the bitmaps going to be generated on the Mac and then > >> downloaded to the printer/typesetter (expensive, especially on something > >> like a 1200 dpi device)? > > >My understanding (I'm not a gnarly printing dude, so don't quote me on > >this!) is that the curve equations will be downloaded to the printer along > >with machine code to do the rendering. So the printer will still do the > >rendering, but will do it as fast as its processor can. > > MACHINE CODE???? This sounds like a solution that will only work with > Apple's Laserwriter (or other 68k based systems). What about all of > the non-Apple postscript devices? What about the non-68k based postscript > engines? Geez, relax, will ya? What this means is that different devices will probably require a different driver (gee, what a shock. That already seems to be true). Or maybe the folks in printing land will see if the device has a 680x0 and will use machine code if so, otherwise downloading rendering code in PostScript. The truth is that _I don't know_ if any of this is correct; this is what I seem to remember from the cobwebs. Printing ain't my job, a fact for which I thank God every day. __________________________________________________________________________ Paul Snively Macintosh Developer Technical Support Apple Computer, Inc. chewy@apple.com Just because I work for Apple Computer, Inc. doesn't mean that I believe what they believe, or vice-versa. __________________________________________________________________________
blarsen@spider.uio.no (Bjorn Larsen) (08/29/90)
In article <9931@goofy.Apple.COM> chewy@apple.com (Paul Snively) writes: > Geez, relax, will ya? What this means is that different devices will > probably require a different driver (gee, what a shock. That already > seems to be true). False. I run a printer spooler that accepts PostScript code from PCs, VAX/VMS, Unix, NOS/VE and Macs. It spools output to a big variety of PostScript printers; most with Adobe RIPs: Apple LaserWriter, LN03R, LPS-40, LPS-20, Agfa Matrix SlideWriter, QMS 100 ColorScript, TI MicroLaser, Linotronic 100/RIP3, and others. In general I can send PostScript code generated on a Mac to any device. Just a few programs demand special attention: - the Apple LaserPrep file is badly written. I have prepared custom versions of this for the various RIPs, and my spooler strips the original ProcSet and adds one suited for the target printer. - the Apple LaserWriter driver doesn't care to document the use of fonts (using DocumentFonts/DocumentNeededFonts), so I have to do a RE-search through the document for font invocations, and add the right comments before handing the PS file to the font downloader. A drag, but it works. - Freehand 2.0 insists on using letter/a4 operators without checking if they are defined or not. I use the ProcSet-substitution for that as well. - Fullwrite Professional 1.1 starts one of it's ProcSets with %%BeginProcSet as required, but ends it with %% End of Fullwrite ProcSet so as to implement my ProcSet substitution, I have to recognize that as a legal way to end a ProcSet. Ugh. Apart from these minor things (which my spooler fixes for me), I am able to print from any Mac to any make of PostScript printer. No matter what the hardware in the RIP consists of. So yes, PostScript has acheived it's goal about being device independent. And all in all - most PostScript generating software does a decent job about being printer-independent. -- Bjorn Larsen University of Oslo, Norway Bjorn.Larsen@usit.uio.no
cortesi@infmx.UUCP (David Cortesi) (08/29/90)
In article <9931@goofy.Apple.COM> chewy@apple.com (Paul Snively) writes: >In article <438@three.mv.com> cory@three.mv.com (Cory Kempf) writes: >> MACHINE CODE???? >Geez, relax, will ya? What this means is that different devices will >probably require a different driver (gee, what a shock. That already >seems to be true). Absolutely not true. We have printers from TI, Imagen, QMS, and Printware, and we drive them all from the identical UNIX spooling daemons. These include Adobe-license RIPS of different change levels and at least one clone (Printware's PrintScript). We shove at them the output of FrameMaker (on Sun and NeXT), Eroff, and Wingz (Sun and NeXT) and they print it all, plus EPS clip art from Adobe Illustrator on the Mac. To me it is pure magic how you can hook up any arbitrary PostScript printer to a serial port and start pouring documents through it with *no* configuration except to set the baud rate. It would be totally unacceptable to have to maintain separate spooling or driving code for each make of printer. That would be a major step backward.
chewy@apple.com (Paul Snively) (08/31/90)
In article <5079@infmx.UUCP> cortesi@infmx.UUCP (David Cortesi) writes: > In article <9931@goofy.Apple.COM> chewy@apple.com (Paul Snively) writes: > >In article <438@three.mv.com> cory@three.mv.com (Cory Kempf) writes: > >> MACHINE CODE???? > >Geez, relax, will ya? What this means is that different devices will > >probably require a different driver (gee, what a shock. That already > >seems to be true). > > Absolutely not true. We have printers from TI, Imagen, QMS, and Printware, > and we drive them all from the identical UNIX spooling daemons. These > include Adobe-license RIPS of different change levels and at least one > clone (Printware's PrintScript). We shove at them the output of FrameMaker > (on Sun and NeXT), Eroff, and Wingz (Sun and NeXT) and they print it all, > plus EPS clip art from Adobe Illustrator on the Mac. I believe that; I was referring to the Macintosh drivers. PostScript definitely does its job of being independent well; it seems to be the QuickDraw to PostScript conversion that can be problematic. __________________________________________________________________________ Paul Snively Macintosh Developer Technical Support Apple Computer, Inc. chewy@apple.com Just because I work for Apple Computer, Inc. doesn't mean that I believe what they believe, or vice-versa. __________________________________________________________________________
dorner@pequod.cso.uiuc.edu (Steve Dorner) (09/01/90)
In article <9995@goofy.Apple.COM> chewy@apple.com (Paul Snively) writes: >I believe that; I was referring to the Macintosh drivers. PostScript >definitely does its job of being independent well; it seems to be the >QuickDraw to PostScript conversion that can be problematic. Yes, because Apple insists on putting hardware dependencies, including 68000 programs in hex, in its LaserPrep. (Does anyone else feel a sense of deja vu in this thread?) To have such built into TrueType (if it is) would pose a big problem for everyone with non-Apple printers. Perhaps that is exactly what Apple has in mind. Like I said before, I'm ordering Adobe's Mac PostScript printer driver as soon as they release it. I suggest anyone with non-Apple printers and Macintoshes do the same. -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner
wilkins@jarthur.Claremont.EDU (Mark Wilkins) (09/03/90)
In article <1990Aug31.194241.27316@ux1.cso.uiuc.edu> dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: >In article <9995@goofy.Apple.COM> chewy@apple.com (Paul Snively) writes: >>I believe that; I was referring to the Macintosh drivers. PostScript >>definitely does its job of being independent well; it seems to be the >>QuickDraw to PostScript conversion that can be problematic. > >Yes, because Apple insists on putting hardware dependencies, including >68000 programs in hex, in its LaserPrep. (Does anyone else feel a sense >of deja vu in this thread?) To have such built into TrueType (if it is) >would pose a big problem for everyone with non-Apple printers. Perhaps >that is exactly what Apple has in mind. > >Like I said before, I'm ordering Adobe's Mac PostScript printer driver >as soon as they release it. I suggest anyone with non-Apple printers >and Macintoshes do the same. >-- >Steve Dorner, U of Illinois Computing Services Office >Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner Actually, I think that Mr. Snively is wrong on this one. One of the big features of the System 7 PostScript driver which was pushed real hard is that the postscript output is: a) Device independent. (They even are going so far as changing the icon so that it no longer resembles an Apple laser printer) b) Self-contained. (I.E. No LaserPrep) c) Can be sent to a file in a supported, consistent manner for downloading or fiddling. It is inconceivable that given the particular design requirements the PostScript driver people have set for themselves that they'd be downloading M68000 code to the printer. -- Mark Wilkins wilkins@jarthur.claremont.edu
shiva@well.sf.ca.us (Kenneth Porter) (09/06/90)
Bjorn Larsen writes: > I run a printer spooler that accepts PostScript code from > PCs, VAX/VMS, Unix, NOS/VE and Macs. > > It spools output to a big variety of PostScript printers; most > with Adobe RIPs: Apple LaserWriter, LN03R, LPS-40, LPS-20, > Agfa Matrix SlideWriter, QMS 100 ColorScript, TI MicroLaser, > Linotronic 100/RIP3, and others. Is this spooler commercial, freeware, local, or what? Bjorne, you mention that you do ProcSet substitution. This begins to sound like the sexy "Document Managers" mentioned in the Structuring Comments document and Glenn's Green Book. Just what all can it do? Does it parse and use PPD's? Does it handle document font requests? What platforms does it run on? And while I'm at it, what other spoolers are available for various platforms? I use Pipeline's devps stuff (the same people who produce the PostScript Language Journal), heavily customized to fit my needs. It doesn't do document management, but I did add a filter to auto-sense various kinds of PostScript files (%!, MS Word, Word Perfect 4.2) and translate those that don't match using a text-to-PostScript utility provided by Pipeline. If the "-l" switch was given to lpr, my auto-sense routine complements its decision, to allow printing of non-standard PostScript files and to allow me to get listings of a conforming PostScript source. I also added back-channel capture to a Sunview window, so I could see my error messages in realtime. The devps product is primarily for converting dvitroff to PostScript, which I don't use since dvitroff doesn't come with Suns. The spooler is a small part of the product, and essentially consists of filters to put in printcap. These include one to convert CAT files to dvi (I couldn't get this part to work; probably something weird about Sun 386i COFF-format font files, I use thack instead), two to convert text to PostScript, and a script to read the arguments passed from lpd to dispatch to the appropriate filter. The latter is what goes in printcap, aliased to different names (ps.if, ps.tf, ps.nf). The rest of the package is a variety of handy utilities for such things as printing font samples, getting AFM files back from the printer, and overlaying ghosted text across a page. The original package runs about $300 for source. It's not for users who don't feel comfortable with hacking around with printcap, serial ports, and shell scripts. I think Legatto sells a Sun binary all integrated and ready for use for roughly the same amount. What do you get with TranScript for $1800 (source from Adobe, or binary from Sun)? At the time I was researching it, it didn't sound like enough to warrant a 6x price difference.
chewy@apple.com (Paul Snively) (09/08/90)
In article <8257@jarthur.Claremont.EDU> wilkins@jarthur.Claremont.EDU (Mark Wilkins) writes: > Actually, I think that Mr. Snively is wrong on this one. One of the big > features of the System 7 PostScript driver which was pushed real hard is > that the postscript output is: > > a) Device independent. (They even are going so far as changing the icon > so that it no longer resembles an Apple laser printer) > > b) Self-contained. (I.E. No LaserPrep) > > c) Can be sent to a file in a supported, consistent manner for downloading > or fiddling. > > It is inconceivable that given the particular design requirements the > PostScript driver people have set for themselves that they'd be downloading > M68000 code to the printer. My comments weren't meant to apply to the driver sending PostScript to any particular PostScript device; they were meant to apply to the case of rendering TrueType on a device that doesn't have TrueType in ROM. Again, what seems to be the case is that if it has an '0x0, machine code gets downloaded, otherwise PostScript gets downloaded (I think). The point is that everything just works, which is what everyone keeps asking for. __________________________________________________________________________ Paul Snively Macintosh Developer Technical Support Apple Computer, Inc. chewy@apple.com Just because I work for Apple Computer, Inc. doesn't mean that I believe what they believe, or vice-versa. __________________________________________________________________________
hammen@ddsw1.MCS.COM (Robert Hammen) (09/08/90)
If you print TrueType fonts to a PostScript printer with System 7, you see the message "Downloading font scaling code" flash by in the printer status window. Previous discussions on the net have centered on whether or not this code is being sent down as 68000-based machine code or not. Two interesting results I found when attempting to find out just what was going on. 1) I printed a test to a Qume CrystalPrint Publisher II. The printer uses a PostScript clone, and uses a Weitek RISC chip for its controller. It took 45 minutes to an hour for it to generate a waterfall that an NTX printed in about five minutes. 2) I printed a test to an Abaton LaserScript. This printer uses the Bauer PostScript clone that is the basis of Microsoft's TrueImage PDL. The page would not print because the language currently doesn't support the eexec operator. 3) I printed a test to a NewGen Turbo/PS 480. This RIPS PS clone uses an Intel RISC chip for a processor. The page printed in about 10 minutes. The next two tests I will run will be on a software-based PS interpreter (the Hyphen clone RIP) and a Linotronic 300/RIP 4. ///////////////////////////////////////////////////////////////////////////// / Robert Hammen | Macintosh enthusiast & publishing guru, looking for a job / / hammen@ddsw1.mcs.com | 70701.2104@compuserve.com | GEnie: R.HAMMEN / /////////////////////////////////////////////////////////////////////////////