======= Bugs and Workarounds for Use With PSCRIPT.DRV Version 3.52 ========

                            July 16, 1992

A Little History:

Windows 3.1 shipped with new PostScript driver, version 3.5. This
driver was made necessary by the addition of TrueType fonts. While
you can use earlier drivers with Windows 3.1, you'll run into trouble
as soon as you try to use a TrueType font.

The first version of 3.5 had problems, including one problem that was
sufficiently serious that Microsoft had a replacement driver (version
3.51) up on CompuServe *before* Win 3.1 actually shipped. Many of us
have been using PSCRIPT.DRV version 3.51 for some time now, but it
still has problems.

Some of those problems are:

         * Poor support for TrueType
         * Problems with the Mirror image and Invert switches
         * Problems with sizing and scaling of EPS files in Ventura
         * Inadequate support for Linotype imagesetters
         * Incorrect resolution options for Linotype imagesetters
         * Problems with whether certain PS fonts were deemed
           resident on the imagesetter or not

If you've used version 3.51 and experienced no problems, don't be
amazed. Most of the problems only happen when you send output to an
imagesetter. Which means that most users won't notice the problems.
For some of us, of course, this has meant wasting a lot of money.

Microsoft recently posted two new files on MSL-1, the download area.
Both files contain PSCRIPT.DRV version 3.52. LINO.EXE also includes
WPDs (Windows Printer Driver files) for a variety of Linotype
imagesetters. The Linotype machines now supported include:

         * L100
         * L200/230
         * L300/PostScript version 47.1 (17 fonts)
         * L300/PostScript version 49.1 (35 fonts)
         * L330
         * L530

Current Problems:
The new PSCRIPT.DRV still exhibits some problems. These problems are
the source of some debate between Microsoft and other vendors.
Microsoft is suggesting (persuasively) that some vendors hard-coded
their way around problems with earlier versions of PSCRIPT.DRV. In
other words, now that the problems have been fixed, the vendor
work-arounds are being exposed.

I have spent a lot of time testing for certain problems. John
Cornicello has spent a lot of time testing for other problems. He is
a PageMaker user, I am a Ventura user. We both use Corel Draw, and
between us also have access to every other draw program available (on
both platforms) except Arts & Letters. We have produced scads of test
pages from laser printers, and wasted a lot of film and RC paper in
testing. 

We have tested the following problems:

   PageMaker:
   If Mirror image and Invert are checked (in the Options/Advanced
   dialog) the PageMaker-created images will properly Mirror and
   Invert, but the EPS file will not. It will invert, but not mirror.

   Workaround:
   Do not specify Mirror image and Invert. Set those on the recorder
   or pass the instruction to the RIP with the imagesetter utilities.

   Corel Draw!:
   Setting the Film Negative checkbox in the Print dialog of Corel
   Draw will conflict with Mirror image and Invert in the PSCRIPT 
   driver. If both are set the file will generate an error and will
   not print. If only the Corel checkbox is set you will produce a
   correct film negative. If only the driver is set, I *believe*
   you will get a film negative (I was getting fed up with the Mirror
   image and Invert problem at this point, and stopped testing.)
   
   Workaround:
   You have two options: you can set the checkbox in the Corel Print
   dialog (and set the imagesetter to normal), or you can leave the 
   checkbox cleared and set the imagesetter to mirror image and invert.
   In either case I strongly suggest that you stay away from the 
   Mirror image and Invert checkboxes in the Options/Advanced dialog 
   in PSCRIPT.DRV. There are too many other instances in which they
   cause odd things to happen.
   
   Ventura Publisher:
   (I identified problems with Ventura and PSCRIPT.DRV using both
   Ventura Publisher and Ventura Separator. Though this looks pretty
   hairy, the workaround is really quite simple.)
   
   Problem 1: When imaging a page with an EPS file, the page prints
   normally, except that the EPS file prints at about 50% of the size
   it should. The EPS file begins (the lower left corner is) in the 
   right place, but the artwork is scaled incorrectly.
   
   Workaround:
   I originally thought that this problem was directly related just
   to the WPD for the Linotype L300/PostScript version 49.3. I was
   mistaken. The problem turns out to be related to the *resolution*
   setting in PSCRIPT.DRV. If you have the resolution set for higher 
   than 1270, you will get odd-sized images. If you reduce the res-
   olution setting in the driver to 1270 or 635, the image will turn
   out properly.
   
   **IMPORTANT** I originally posted a file suggesting that the
   "incredible shrinking EPS file" problem was only happening in
   the L300/PostScript version 49.3 driver. That is not the case.
   The problem is with the resolution setting, and occurs in *any*
   driver. It is only apparent in the Linotype drivers because they
   are the only ones that make a resolution higher than 1200 avail-
   able.
   
   Problem 2: When imaging a page using Ventura Separator and with
   Mirror image and Invert set, the EPS file is mirrored and inverted,
   but the type disappears.
   
   Workaround: What's actually happening is that the type is being 
   inverted (changed to white) but the background isn't (so it stays
   white). The solution is to *not* check Mirror image and Invert.
   
*BIG PROBLEM*
   Problem 3: When imaging a page using Ventura Separator, a scanned
   bitmap image does not print with the screen angles properly set. 
   The screens are all angled at 45 degrees, and a moire pattern
   appears.
   
   This problem was reported by a Swiss user. It requires further 
   research, but the user insists that the problem is repeatable. 
   Because it's a big TIFF image, it takes a lot of time to repeat,
   so testing is a pain.
   
   Microsoft told me that the root of the problem is how the printer
   driver addresses specific pixels on the page. Important: so long 
   as you're working with vector-based art, this won't affect the 
   quality of your output. This will make a BIG difference in the
   quality of bitmap art you produce.
   
   The PostScript driver uses an internal coordinate system to iden-
   tify where each bit in a bitmap is to go. This is how your bitmap
   can proof to a laser printer (at 300 dpi) and then image on an
   imagesetter (at 1200 dpi or higher) and show the bits in the same
   place on the page.
   
   When sending the bitmap to the imagesetter, though, the printer
   driver needs to know exactly where on the page to set the bit. 
   Which means it needs to know the resolution of the device at which
   it points. (This is why the resolution dropdown listbox is on
   the Options/Advanced dialog. If you're using vector art [EPS
   drawings] the resolution setting should make no difference. It makes a 
   big difference if you're using TIFFs.)
   
   A nasty problem emerges with high-resolution printers: the in-
   ternal coordinate system of the printer driver uses Integer variables.
   The largest Integer variable is 32,768. Since the PostScript driver
   can write to a page that is 18" wide the driver chokes: 18"
   times 2540 dots per inch equals 45,720 pixels. Which is too
   big to describe as an integer.
   
   Ideally, according to Microsoft, applications recognize the prob-
   lem and automatically adjust the resolution. Some, say they, 
   deal with the problem more gracefully than others. There are 
   two important points here: 
   
      First, Ventura doesn't deal with the problem gracefully.
      You'll get funky looking images.
      
      Second, PSCRIPT.DRV will have problems with *any* high-
      resolution bitmapped image, regardless of which application
      produces it. Many people believe (as I do) that high-quality
      color work requires an output resolution of greater than 3000
      dpi. PSCRIPT.DRV simply can't handle numbers that big. What
      it has to do is discard every other scan line in order to 
      get a small enough image. Needless to say, that's not good
      news.
      
   Does this mean you should rush right out and buy a Macintosh?
   I don't know. I don't know if this internal coordinate problem
   is endemic to PostScript or to Microsoft's driver. It sounds
   as though it's a PostScript problem, so using a Mac won't
   change things. I'll try to learn more.
      
Conclusions:
First: Whether you are using PageMaker, Corel Draw, Ventura Publisher,
or any other application, leave Mirror image and Invert *cleared* in 
the Options/Advanced dialog. Set mirror imaging and inversion at the
imagesetter--let it do the thinking, don't try to think for it.

Second: If you are using Ventura Publisher (or Ventura Publisher with
Ventura Separator) use an output resolution of 1200, 1270, or less.
Do *not* use resolution settings of 2540 or higher, regardless of 
which imagesetter you're targetting for output. If you're sending 
type and vector art, the resolution setting in the driver dialog 
"machts nichts." 

Third: If you are sending bitmapped images to the imagesetter you
will see an image degradation problem. Depending on your choices
for printing (press, paper, screen ruling, etc.) you may notice the
problem or not. If you're doing high-quality color work I think 
you're going to have a problem. (Frankly, I'm not ready to go on 
the warpath about this--I don't think "desktop color" is ready
for prime time [although this may be why] in any case. If you're 
doing high-quality color work use DTP to size the windows for your
images, but have the photos stripped in from high-end scanners.)

I will continue researching this issue (and the question of whether
EPS files from all draw apps are affected by the problems). If you
would like help, or have any questions, please contact me via 
CompuServe Mail at 71507,1212. I'll try to help as best I can.

John Murdoch
CIS: 71507,1212
VNet: #2 @ 2157