unix to win 2000 bianry file printing

  • Thread starter Thread starter Bill
  • Start date Start date
B

Bill

I am trying to print bar code labels on an Intermec 3400 bar code
printer attached to a serial port on a Windows 2000 PC. The print file
is generated on an AIX 4.3 box and the AIX spooler sends the job to the PC.

The PC is running 3rd party lpd software.(I've tried OmniComm's AlphLPD
and Esker's TUN lpd, with the same result). The job is sent to a Generic
Printer. The label printer either advances a single blank label or does
nothing.

However, if I take the windows printer off line and send the spool file
in winnt/system32/spool/PRINTERS to the printer via the lpr command
using the -ol option the label prints out as it should. Without the -ol
option I get the same result as with sending the job to the Windows spooler.

I have a similar setup on a PC running NT which works fine, so I'm
wondering if something changed in Windows 2000. It appears as if the
windows driver is not passing the file along as a raw file, although the
Print Processor that is selected is the default WinPrint->RAW.

Any help or suggestions for further research are appreciated.

Thanks.

Bill Kurland
Shakespeare & Co.
 
When the print is sent from the UNIX (AIX) computer, two files are sent - a
control file and a data file. The Windows LPD service uses the information
in the control file to determine how to process the content of the data file
(see below for details). If the UNIX computer sends the "f" control code,
Windows will add formatting to the file while it is being sent to the
printer.

When you "print" the spool file, you specify the "o l" option that tells the
LPD service to NOT format the data but to treat it as RAW.

If you can influence what the UNIX computer sends in the control file so
that it does not send "f", but does send "o l", it might print correctly.

See if any of these help:

1. http://support.microsoft.com/default.aspx?scid=kb;en-us;150930 - how to
configure LPD in Windows server to essentially ignore LPR control commands
and always treat the print stream as RAW for all printers

2. http://support.microsoft.com/default.aspx?scid=kb;en-us;168457 - how to
configure LPD in Windows server to essentially ignore LPR control commands
for specific printers and always treat the print stream as RAW for all
printers

3.
http://www.microsoft.com/resources/...00/server/reskit/en-us/core/fnbe_prn_creq.asp
contains this statement:

Print Services for Unix sets the print data type when it sends the document
to the spooler. This is derived from the control command included in a print
job from an LPR client. It might be necessary to change the default data
type at the client to avoid processing PCL or PostScript print jobs as TEXT
when they are actually RAW. For more information about the data types, see
"Print Processor" earlier in this chapter.

If the control command is f or p, the data type is TEXT, and the spooler
edits the document file to print correctly. If the command is l, the data
type is RAW and no editing is done. If the command is o, the document is
already formatted in PostScript code and is assigned the RAW data type.

Some UNIX systems usually send the f command by default, resulting in the
following symptoms:
The output includes PCL or PostScript code.
Extended characters are printed incorrectly.
The printer's default font is used.
An extra page is printed at the end.

4. http://support.microsoft.com/default.aspx?scid=kb;en-us;132460 - contains
this statement:

Different UNIX LPR clients often have different configuration options. For
example, to change the control command, you may need to change a value in a
printcap file, change a model script, modify an LP or LPR command line, or
change settings through a graphical interface.

Some UNIX LPR clients are not configurable. For example, the IBM AIX LPR
client always sends the "f" control command.

5. http://support.microsoft.com/default.aspx?scid=kb;en-us;867519

--
Bruce Sanderson MVP Printing
http://members.shaw.ca/bsanders

It is perfectly useless to know the right answer to the wrong question.
 
Back
Top