Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!rice!sun-spots-request
From: advsys!graham@relay.eu.net (Graham Underwood)
Newsgroups: comp.sys.sun
Subject: Re: Using Transcript software on /dev/mcpp0
Keywords: Miscellaneous
Message-ID: <5967@brazos.Rice.edu>
Date: 21 Mar 90 14:14:30 GMT
Sender: root@rice.edu
Organization: Sun-Spots
Lines: 34
Approved: Sun-Spots@rice.edu
X-Refs:  Original: v9n83
X-Sun-Spots-Digest: Volume 9, Issue 90, message 10

In article <5875@brazos.Rice.edu> you write:
>X-Sun-Spots-Digest: Volume 9, Issue 83, message 11

>Here's the problem:  I'm using Sun's Transcript software with a QMS-PS810
>laser printer attached to /dev/ttyb on a Sun 4/280 running SunOS 4.0.3
>with all the relevant bug fixes.  Users are complaining that it takes too
>long to print 1MB postscript plot files.  So I figure, "Why not use the
>ALM-2 parallel port, since the QMS-PS810 also has a parallel port?"

I dont know much about transcript, but I have some experience of writing
print filters for postscript printers. The problem could well be caused by
the different behaviour of the printer on RS232 and parallel. 

On RS232 you can send ^T and the printer will respond with a status
message in the form `%%[ status: busy ]%%'. The filters can therefore
parse these and print out useful messages on the console like `paper out'.
On parallel there is no such feature.  If transcript is written assuming
RS232 behaviour you are in trouble.

What I did was disable all ^Ting if the interface was parallel and it
works fine, only you dont get any status messages back - and yes it is
faster.  Doesn't help you much for transcript though.

An alternative approach is to connect via RS232 AND parallel and use the
RS232 for the ^Ts - again not much help for transcript.

If you want an unbiased opinion, the best solution would be to buy some
decent printer software !  If you want a really unbiased opinion ask one
of our sales staff.

Graham

graham@advent.co.uk
..!ukc!advsys!graham