Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!kth.se!cyklop.nada.kth.se!news
From: d88-pfo@dront.nada.kth.se (Peter Forsberg)
Newsgroups: comp.os.os2.misc
Subject: Re: Printing to a File:  Answer and Question
Message-ID: <D88-PFO.91Apr7162413@dront.nada.kth.se>
Date: 7 Apr 91 14:24:15 GMT
References: <9686@mentor.cc.purdue.edu>
Sender: news@nada.kth.se (Mr News)
Followup-To: comp.os.os2.misc
Organization: Royal Institute of Technology, Stockholm, Sweden
Lines: 47
In-reply-to: lairdkb@mentor.cc.purdue.edu's message of 5 Apr 91 17:31:10 GMT

In article <9686@mentor.cc.purdue.edu> lairdkb@mentor.cc.purdue.edu (Kyler Laird) writes:

   But I poked around and found what I had been hoping for all along.  It seems
   that the spooler saves the .SPL files in a format ready to be sent directly
   to the printer.  I had assumed that a more generic format would be used so
   that multiple, different printers could service the same queue and each
   receive the file in their own format.  I was wrong.

I wouldn't rely on this always being the case (in future versions od OS/2 and/
or with other printer drivers.

   [Stuff deleted...]

   Many publishers (me!) resist spending $50K+ on typesetting equipment.  
   Instead,
   for their final prints they use a service bureau.  These businesses usually
   take Postscript data (from disk or dialup).  Unfortunately, Ventura for OS/2
   doesn't save to Postscript files.  With Ventura for Gem, I could select a
   filename as my output device.  By capturing the .SPL file, I can duplicate
   this function.

   Problem:
   I can't select NONE or any nonexistant physical port (LPT2:, LPT3: - haven't
   wanted to bother with COM?:) for output of the printer driver.  This means
   that I am forced to send to LPT1: after taking the printer off line.
   If I do select one of these ports, the application using the printer crashes
   with an error.

   Any ideas?

I would think that the best way to do this is to write an OS/2 device monitor,
which would be able to capture the raw output to the printer, just before it
goes out to the port. You could hook the monitor up for one of your non-
physical printer ports, let it dump the output to a file, and NOT pass it on
to the printer port (as you don't have any!).

I have written such a beast, which does some additional processing though,
and it wasn't at all that much work.

   --kyler

/ Peter Forsberg
--
_______________________________________________________________________________
Peter Forsberg 		      Royal Institute of Technology, Stockholm, Sweden.
Internet: d88-pfo@nada.kth.se
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~