Ravinder.Chandhok@GNOME.CS.CMU.EDU (03/10/88)
Does anyone else have problems with files captured via "lwsrv" printing through transcript ? My problem is that the mac leaves ^M as line seperators, which is fine with postscript, but transcript (especially psrev)complains that file has a "non-conforming trailer". If I change the ^M's to ^J's, it works fine. This is sooo trivial and such a pain..... Rob
Ravinder.Chandhok@GNOME.CS.CMU.EDU (03/15/88)
Mark,
Good it hear it wasn't just me having problems with transcript and lwsrv.
Here is what I had to do for each problem:
(1) transcript doesn't deal with ^M's in the postscript files. PostScript
*may legally* contain a ^M as data, but no one does this,as far as I can
tell. Besides, the PostScript doc says if you want to do this, use \000
notation, so it goes through normal data channels.
The fix:
in lwsrv.c::scantoken()
At the end of comment lines, ^M was converted to ^J already. Other places
the check was "isascii()". I changed that section of the code to look like:
/* papif handles it right, but others like transcript don't, so... */
if (echo) { /* do we want to echo this? */
if (c == '\r') /* is this a CR ? */
putchar('\n'); /* Yes, translate to newline */
else if (isascii(c)) /* is it standard ascii? */
putchar(c); /* yes... so echo */
else /* otherwise echo \ddd */
printf("\\%03o",(unsigned char) c);
}
(2) transcript (either pscomm or something) insists on mucking with files
that "conform" to "PS-Adobe-" in such a way that the dictionary doesn't get
output to the printer in the right order IF your local options to transcript
specify page reversal by default. I don't maintain the local version of
transcript, so I had to fix lwsrv.
The fix:
Not that the beginning of the file is what determines the level of
"conformity". The mac advertises it conforms at "PS-Adobe-2.0". After
inserting the laser prep file, transcript claims it no longer conforms (the
indication of this is postscript errors from pscomm). My fix was to prepend
something to the beginning of EVERY JOB that limited lwsrv's liability by
not claiming to conform to Adobe's standard. In routine childjob():
...
sprintf(status,"receiving job for %s",prtname);
/* Ensure we do not advertise we are anything but min. conforming */
printf("%%!PS-Adobe * Captured by lwsrv *\n%% ******");
while (getjob(pf)) { /* while still open... */
...
(3) Printing on non-laserwriter's involves more changes to the prep file.
The fix: define "legal" to be a lnop, and most things print ok on an LPS40.
Although I don't know how to get bitmaps working yet since I can't use the
68000 codes for smoothing....
Rob cck@CUNIXC.COLUMBIA.EDU (Charlie C. Kim) (03/15/88)
(1) The next version of lwsrv has a switch to turn on cr to lf mapping on and off. (-T crtolf) (It also has a -T quote8bit to quote 8 bit characters for Transcript serial printers). (2) psrv - the page reversal filter (used by pscomm) for Transcript is at fault. It improperly assumes that nothing (important) appears between the "%%EndProlog" Document Structuring Conventions command and the first "%%Page" DSC command. Unfortunately, several body DSC commands can occur there. And in particular, the Macintosh LaserWriter driver has a "%%BeginDocumentSetup/%%EndDocumentSetup" group (which really should be a %%BeginSetup/%%EndSetup group according to the documentation that I have) in between with code to setup the macintosh dictionary (laserprep). psrv should be fixed. papif will be able to make use of either psrv or psrev (the user level command which seems to work properly). Transcript's pscomm cannot use psrev since it depends upon psrv's notifing pscomm when output is ready. Sigh, yet another Transcript compatibility option since psrv probably won't get fixed at a lot of places anytime soon. Charlie C. Kim User Services Columbia University
cck@CUNIXC.COLUMBIA.EDU (Charlie C. Kim) (03/15/88)
Woops.. I should mention that the documentation that I am basing things upon is: Adobe Systems Document Structuring Conventions Version 2.0 January 31, 1987 available from Adobe Systems. In particular, section "Body Comments", page 9 defines %%BeginSetup/%%EndSetup. It actually positions those comments as being after the "%%EndProlog" comment and before the first "%%Page" comment. Charlie C. Kim User Services Columbia University
cck@CUNIXC.COLUMBIA.EDU (Charlie C. Kim) (03/16/88)
Final comments on this issue: The new version of TranScript--2.1 has the psrv problem fixed (the obvious one of taking everything up to the first %%Page as the prolog instead of just to the %%EndProlog). The "bug report" was for TranScript version 2.0 (and probably applies to earlier versions as well). Charlie C. Kim User Services Columbia University
frankh@durin.sparta.COM (Frank Halsema) (05/30/90)
I know this subject has been discussed and if pointed to a news archive I will gladly search through it for the answers. My problem is printing from a mac to a transcript printer on a sun. I have set up uab+ and cap+ on a configuration with a single mac and two suns on an ethernet (Net A). The laser printer is attached to the sun serial port and driver using transcript. I am running lwsrv, aufs, atis and uab. Everything works great until I print from the mac. The lwsrv software picks up the file and sends it. But, when the printer gets it I get the error %%[error: invalidaccess: OffendingCommand: def ]%%. I have the lwsrv running on another network (Net B) that uses lwsrv as an apple spooler to an apple laser controlled by papof/papif. It works great (most the time). I am using the LaserPrep from Net B on Net A. I have tried a variety of lwsrv options, and Transcript filters as well as sending the file output from lwsrv to the printer by "cat'ing" directly to the device. All I get is a flashing light on the printer for a while. I appreciate any help !! Thanks !! -- Frank Halsema UUCP: durin!frankh SPARTA, Inc. Internet: frankh@durin.sparta.com 23041 de la Carlota, Suite 400 Laguna Hills Ca, 92653 (714) 768-8161 EXT 339 (714)583-9114 FAX
rapatel@khnphwzhn.njin.net ( Rakesh Patel) (06/01/90)
From your description, it sounds as though you are using the laserprep files generated by the Mac exactly as is. If so, that can create real problems. The best way to generate a proper laserprep file for use with lwsrv is to use a program called "prepfix". "prepfix" is part of the "macps" package. Here is the info on where to get it: From edmoy@violet.berkeley.edu Mon Oct 30 15:08:46 1989 Path: njin!rutgers!tut.cis.ohio-state.edu!ucbvax!agate!violet.berkeley.edu!edmoy From: edmoy@violet.berkeley.edu Newsgroups: comp.sys.mac Subject: New version of macps/prepfix (2.2) Message-ID: <1989Oct30.200846.779@agate.berkeley.edu> Date: 30 Oct 89 20:08:46 GMT Sender: usenet@agate.berkeley.edu (USENET Administrator;;;;ZU44) Reply-To: edmoy@violet.berkeley.edu () Organization: University of California, Berkeley Lines: 29 I've just posted the latest version of macps & prepfix (2.2) to comp.sources.unix and comp.sources.mac and it should also be available by anonymous ftp from sumex-aim.stanford.edu. Here is a brief description: Macps is a Unix program that takes an uploaded PostScript file created on a Macintosh (by typing Command-F at the LaserWriter dialog box) and includes an appropriately modified LaserPrep file so that the result can be sent to a PostScript printer from Unix. Since the Apple LaserPrep files are copyrighted, I've included a program, prepfix, that reads version 4.0 and up LaserPrep files, and edits them so that they are compatible with macps, and are even electronically mailable. CHANGES IN VERSION 2.2 Version 2.2 of macps/prepfix adds support of LaserWriter 6.0, and contains some minor bug fixes. Printing under NeXT 1.0 to the NeXT laser printer works well for LaserWriter 4.0 - 5.2 (except for the inherent problems of printing patterns at 400 dpi), but under LaserWriter 6.0, some things just don't print, and I don't know why (the exact same file prints fine on a LaserWriter). Edward Moy Principal Programmer - Macintosh & Unix Workstation Support Services Workstation Software Support Group University of California Berkeley, CA 94720 edmoy@violet.Berkeley.EDU ucbvax!violet!edmoy