HATHAWA@gecrdvm1.crd.ge.com (Barry Hathaway) (12/19/89)
I'm trying to print Postscript output on an Apple LaserWriter attached to
a Sun workstation. This Postscript output is actually produced on an IBM
mainframe and is sent to the Sun via LPR. The Postscript output defines
fonts using a non-standard (EBCDIC) encoding vector in which characters are
represented by 8-bit character codes. Currently the PRINTCAP file defines
the LaserWriter as:
lp|isolw|lw|apple|ps|postscript|PostScript:\
:lp=/dev/ttya:\
:br#19200:rw:fc#0000374:fs#0000003:xc#0:xs#0040040:mx#0:sf:sb:\
:if=/usr/local/lib/lw/psif:\
:of=/usr/local/lib/lw/psof:\
:gf=/usr/local/lib/lw/psgf:\
:tf=/usr/local/lib/lw/pstf:\
:nf=/usr/local/lib/lw/psnf:\
:vf=/usr/local/lib/lw/psvf:\
:sd=/usr/spool/lw:\
:lf=/usr/spool/lw/log:\
:rf=/usr/local/lib/lw/psrf:\
:cf=/usr/local/lib/lw/pscf:\
:df=/usr/local/lib/lw/psdf:
This definition seems to strip off or ignore the parity bit which results
in garbage being printed.
What is the correct flag settings to use so that all 8-bits are transmitted
to the printer? Will this change have any impact on any other type of
printing?prc@erbe.se (Robert Claeson) (12/19/89)
In article <89352.151243HATHAWA@GECRDVM1.BITNET>, HATHAWA@gecrdvm1.crd.ge.com (Barry Hathaway) writes: > What is the correct flag settings to use so that all 8-bits are transmitted > to the printer? Will this change have any impact on any other type of > printing? Try setting xc#040 in /etc/printcap. It enables the litout mode of the tty driver (no output post-processing). -- Robert Claeson E-mail: rclaeson@erbe.se ERBE DATA AB
woody@rpp386.cactus.org (Woodrow Baker) (12/20/89)
In article <89352.151243HATHAWA@GECRDVM1.BITNET>, HATHAWA@gecrdvm1.crd.ge.com (Barry Hathaway) writes: > I'm trying to print Postscript output on an Apple LaserWriter attached to > a Sun workstation. This Postscript output is actually produced on an IBM > mainframe and is sent to the Sun via LPR. The Postscript output defines > fonts using a non-standard (EBCDIC) encoding vector in which characters are > represented by 8-bit character codes. Currently the PRINTCAP file defines > the LaserWriter as: > > lp|isolw|lw|apple|ps|postscript|PostScript:\ > :lp=/dev/ttya:\ > :br#19200:rw:fc#0000374:fs#0000003:xc#0:xs#0040040:mx#0:sf:sb:\ > :if=/usr/local/lib/lw/psif:\ > :of=/usr/local/lib/lw/psof:\ > :gf=/usr/local/lib/lw/psgf:\ > :tf=/usr/local/lib/lw/pstf:\ > :nf=/usr/local/lib/lw/psnf:\ > :vf=/usr/local/lib/lw/psvf:\ > :sd=/usr/spool/lw:\ > :lf=/usr/spool/lw/log:\ > :rf=/usr/local/lib/lw/psrf:\ > :cf=/usr/local/lib/lw/pscf:\ > :df=/usr/local/lib/lw/psdf: > > This definition seems to strip off or ignore the parity bit which results > in garbage being printed. > > What is the correct flag settings to use so that all 8-bits are transmitted > to the printer? Will this change have any impact on any other type of > printing? O.K. you can set the serial port with setscc to be a full 8 bits wide. The data will get through, EXCEPT CERTAIN control code, ^D ^S ^Q ^T ^C Currently, Adobe in it's infinite wisdon has not seen fit to tell us how to get around this problem.. I seem to get stonewalled by them anytime I reqest info on this. Perhaps you would be better off going paralell, but for some perverse reason, these above control characters still won't go through. In addition, PS uses the "cooked" mode, that is 0x0a 0x0d gets converted to 0x0a. This can also screw you up. Cheers Woody till
prc@erbe.se (Robert Claeson) (12/21/89)
In article <17467@rpp386.cactus.org>, woody@rpp386.cactus.org (Woodrow Baker) writes: > O.K. you can set the serial port with setscc to be a full 8 bits wide. > The data will get through, EXCEPT CERTAIN control code, ^D ^S ^Q ^T ^C > Currently, Adobe in it's infinite wisdon > has not seen fit to tell us how to get around this problem. Yes, they have. The client (ie, the application generating the Postscript code) should not rely on anything else than a 7-bit, no-control-chars data flow. All non-ASCII characters and control characters should be sent in backslash-octal form (ie, \014). The info is in the Red Book. You just have to read it very carefully. -- Robert Claeson E-mail: rclaeson@erbe.se ERBE DATA AB
woody@rpp386.cactus.org (Woodrow Baker) (12/22/89)
In article <1044@maxim.erbe.se>, prc@erbe.se (Robert Claeson) writes: > In article <17467@rpp386.cactus.org>, woody@rpp386.cactus.org (Woodrow Baker) writes: > > > O.K. you can set the serial port with setscc to be a full 8 bits wide. > > The data will get through, EXCEPT CERTAIN control code, ^D ^S ^Q ^T ^C > > Currently, Adobe in it's infinite wisdon > > has not seen fit to tell us how to get around this problem. > > Yes, they have. The client (ie, the application generating the Postscript > code) should not rely on anything else than a 7-bit, no-control-chars data > flow. All non-ASCII characters and control characters should be sent in > backslash-octal form (ie, \014). > > The info is in the Red Book. You just have to read it very carefully. > > -- > Robert Claeson E-mail: rclaeson@erbe.se > ERBE DATA AB Of course, of course, but tell that to some program written before postscript ever came on the scene. Remember, more programs write output to a Diablo printer than postscript printers. If you have 1 printer and it is a postscript printer, you need an emulator perhaps, then what are you gonna do? How do you tell a program that needs to get 8 bits of data out, that it needs to watch for control characters, and preface them with \? Sure, go change the source, IF you have it, and IF you don't have to change 4000 files. But the biggest gotcha of all, is that that funky \xxx comes through the communication routines as just that, "\xxx". The PS input scanner does not (at least what I've seen) do a conversion of the xxx sequence to a binary number, but passes it on as ASCII. Representing hex data i.e. binary data in a printable ascii form is o.k., but it doubles the size of the file. Yes, the info is in the Red book, but my contention is that it is unduly restrictive, we live in an 8 bit world, bytes nolonger have 7 bits. Cheers Woody
prc@erbe.se (Robert Claeson) (12/23/89)
In article <17481@rpp386.cactus.org>, woody@rpp386.cactus.org (Woodrow Baker) writes: > In article <1044@maxim.erbe.se>, prc@erbe.se (Robert Claeson) writes: > > The client (ie, the application generating the Postscript > > code) should not rely on anything else than a 7-bit, no-control-chars data > > flow. All non-ASCII characters and control characters should be sent in > > backslash-octal form (ie, \014). > Of course, of course, but tell that to some program written before postscript > ever came on the scene. Remember, more programs write output to a Diablo > printer than postscript printers. If you have 1 printer and it is a postscript > printer, you need an emulator perhaps, then what are you gonna do? Adobe's green book recommends that such emulation is done on the host and not in the printer. The emulator can then easily emit non-printable-ASCII characters using the octal escape. > How do you tell a program that needs to get 8 bits of data out, that it needs > to watch for control characters, and preface them with \? Sure, go > change the source, IF you have it, and IF you don't have to change 4000 files. You can't, unless the program already emits 7-bit PostScript. I use to use a back-end that converts all 8-bit characters in the PostScript that the application emits into the 7-bit octal form. > But the biggest gotcha of all, is that that funky \xxx comes through the > communication routines as just that, "\xxx". The PS input scanner does > not (at least what I've seen) do a conversion of the xxx sequence to a binary > number, but passes it on as ASCII. Representing hex data i.e. binary data > in a printable ascii form is o.k., but it doubles the size of the file. > > Yes, the info is in the Red book, but my contention is that it is unduly > restrictive, we live in an 8 bit world, bytes nolonger have 7 bits. I agree. I'm an 8-bit junkie myself, and at this site, we only use the ISO 8859/1 8-bit character set. Our whatever-to-postscript converter and PostScript printer driver (still under development) converts everything into the 7-bit form, and, just as you say, the size of a typical file almost gets doubled. BTW, you can't imagine how many UNIX utilities there are that still lives in a 7-bit world, and this is under one of the later System V UNIX'es (Berkeley UNIX is, unfortunately, highly unusable for non-ASCII character sets). -- Robert Claeson E-mail: rclaeson@erbe.se ERBE DATA AB