TARKKONEN@cc.helsinki.fi (Lauri Tarkkonen) (11/25/89)
In article <12877@polya.Stanford.EDU>, rokicki@polya.Stanford.EDU (Tomas G. Rokicki) writes: > After seeing yet another sample of *lousy* PostScript generated by an > application (this one Windows Designer), I'm very upset. This particular > application makes *no* effort to comply with any structuring conventions. > It even generates an unprotected call to `a4'. > They are in good company, I tried to use windows generated postscript files as a part of output generated in some other programs, the failure is inevitable, because whoever wrote the windows postscript driver (I hope Microsoft is listnening) has probably by purpose made the driver obsolete, by using commands like "setmatrix", that will for sure destroy the other parts of the page and make the whole exercise obsolete. I think that they deliberately have not followed the structuring conventions and advises given by ADOBE. I guess we should not blame ADOBE for this. The experiments with the DESIGNER created PostScript files have been similar. One could of course patch the PostScript file by hand or by a program, by would it not be reasonable to expect, that a postscript file created by windows or some applications were not obsolete. The code created by these applications is very slow, about 10 to 30 times slower than simnilar pages created by some other programs. Lauri Tarkkonen University of Helsinki
halliday@cheddar.cc.ubc.ca (Laura Halliday) (11/25/89)
Though I haven't seen the PostScript Windows cranks out, I've certainly seen what MS Word 5 cranks out. No fun. Do people have any favourite `acid tests' they use to get some idea of PostScript compatibility? My current one is to download the PostScript file onto our NeXT and let Preview image it. It's the only non-LaserWriter PostScript implementation I have access to, and the results can be useful. ...laura
larry@csccat.UUCP (Larry Spence) (11/25/89)
In article <1529@cc.helsinki.fi> TARKKONEN@cc.helsinki.fi (Lauri Tarkkonen) writes: >In article <12877@polya.Stanford.EDU>, rokicki@polya.Stanford.EDU (Tomas G. Rokicki) writes: >> After seeing yet another sample of *lousy* PostScript generated by an >> application (this one Windows Designer), I'm very upset. This particular >> application makes *no* effort to comply with any structuring conventions. >> It even generates an unprotected call to `a4'. > >They are in good company, I tried to use windows generated postscript >files as a part of output generated in some other programs, the failure >is inevitable, because whoever wrote the windows postscript driver >(I hope Microsoft is listnening) has probably by purpose made the driver >obsolete, by using commands like "setmatrix", that will for sure destroy >the other parts of the page and make the whole exercise obsolete. I think >that they deliberately have not followed the structuring conventions and >advises given by ADOBE. I guess we should not blame ADOBE for this. >The experiments with the DESIGNER created PostScript files have been >similar. One could of course patch the PostScript file by hand or by >a program, by would it not be reasonable to expect, that a postscript >file created by windows or some applications were not obsolete. The >code created by these applications is very slow, about 10 to 30 times >slower than simnilar pages created by some other programs. Be aware that there are at least three flavors of "Windows PostScript": PostScript generated by the Windows PostScript driver. It creates files that are targeted for a particular device that the user chose in his Windows application. Not intended as general EPS files for import into other apps. Microsoft wrote this driver; it's the "official" Windows PS driver. PostScript generated by the Micrografx Windows PostScript driver. MGX includes their own PostScript driver which has some added bells and whistles for their own apps. When other apps try to use the MGX PS driver, there can be some "anomalies." Ideally, in a Windows (or OS/2) environment, there is ONE driver for each device, eliminating this confusion. EPS files generated by a Windows app independently of the Windows device driver. The app spits out an EPS file, as opposed to expecting to be connected to a PS device. These files should import into PageMaker, Ventura, etc., OK. A problem with the Microsoft PS driver is that, since Windows GDI does not support Beziers, using the driver implies that the file must contain humongously long polylines (lineto or rlineto sequences). This is not a problem when the app creates an EPS file on its own, since it can use curveto, rcurveto, etc. Of course, an EPS file isn't really intended to be printed directly, but rather to be imported into an app which will scale and position it on the page when it prints the EPS. -- Larry Spence larry@csccat ...{texbell,texsun,attctc}!csccat!larry