Vista - LPD service SimulatePassThrough ineffective

Printing via enscript or lpr from a Putty Unix SSH client to Vista HP 7310
printer. enscript/lpr produces PostScript output which is sent to Vista's LPD
service, but what's printed are the PostScript codes instead of the properly
formatted document. Q150930 for non-Vista Windows suggested adding
SimulatePassThrough=1 to the registry, which I did, but it is apparently
ineffective on Vista. I noted that the LPD service is supposed to be
deprecated with Vista, but it's configurable, so what's the secret to
printing PostScript from a remote client?

Did you purchase the PostScript personality for this printer?

--
Alan Morris
Windows Printing Team
Search the Microsoft Knowledge Base here:
http://support.microsoft.com/default.aspx?scid=fh;[ln];kbhowto

This posting is provided "AS IS" with no warranties, and confers no rights.

"jonj" <jonj@xxxxxx> wrote in message
news:BB4E32D8-9A9C-440C-A6B8-45E180BB4787@xxxxxx

Not sure what you mean. I've been using this printer for several years
successfully with XP. Previously had it defined on an XP desktop with a SuSE
desktop printing to is using enscript & PostScript, defined on SuSE as a
Samba share, without this problem. It's now wired to my Vista desktop via a
USB port. I have a LAN with an XP desktop and a XP laptop which are both able
to print to this shared printer perfectly; it's just the PostScript coming
from the remote SSH client via enscript or lpr that is not being identified
as such by the LPD service, the exact symptoms that 150930 is supposed to
address.

Please clarify!

Jon

"Alan Morris [MSFT]" wrote:

The printer has to support the Postscript language (personality) in order to
print Postscript other than that the PCL native language on the printer will
print Postscript as straight PCL text.

Unsure what SuSe is.

There is another registry key that the LPD service writes into the printer
registry when an inbound lpr.exe job is transferred to the printer.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Printers\PRINTERNAME\PrinterDriverData\LpdPrinterPassThrough

Set this to 1 for per printer passthrough


The LPD service looks for this string in the print job. Just open the file
generated by enscript (I assume this is the application you are using), it
should be on the first or second line.
%!PS-Adobe-3.0

I confirmed that both keys work and pass straight unformatted pscript data
to the printer. The printer I used is the HP Color LaserJet 9500. The PCL
and the PS personalities are installed.

--
Alan Morris
Windows Printing Team
Search the Microsoft Knowledge Base here:
http://support.microsoft.com/default.aspx?scid=fh;[ln];kbhowto

This posting is provided "AS IS" with no warranties, and confers no rights.

"jonj" <jonj@xxxxxx> wrote in message
news:774120D9-B38B-45E2-9F1D-17BE43EECEAE@xxxxxx

Thanks for working on this, Alan.

"SuSE" is a Linux distro, but at this point is, I believe, irrelevant. My
enscript jobs originate on a Solaris SSH client (enscript -P Vista:HPOffice
<file name>)

I have downloaded and installed the most recent set of Vista drivers for the
Officejet 7310xi series from HP (AIO_CDB_Full_Network_enu.exe), and have no
reason to believe that they now for some reason no longer support PostScript
as they did on XP (but one never knows...). Is there any way to verify this
via printer properties, the registry, or elsewhere?

Setting LpdPrinterPassThrough = 1 for HPOffice had no effect; what's printed
is still "%!PS-Adobe-3.0" as the first line of output. The first 3 lines of
enscript output, for reference, are "%!PS-Adobe-3.0
%%BoundingBox: 24 24 588 768
%%Title: Enscript Output
"

Regards, Jon

"Alan Morris [MSFT]" wrote:

Does the printer configuration page state that a PS module is installed? I
don't think your previous setup was sending PS to the device.

If the config page says it has the PS module installed, is the printer
configured to automatically switch from PCL to PS?

What you are seeing is the PS data getting printed as PCL text. If you
create PCL data on the client with the passthrough settings, will the PCL
data print correctly?

--
Alan Morris
Windows Printing Team
Search the Microsoft Knowledge Base here:
http://support.microsoft.com/default.aspx?scid=fh;[ln];kbhowto

This posting is provided "AS IS" with no warranties, and confers no rights.

"jonj" <jonj@xxxxxx> wrote in message
news:A9FC2164-5E1A-4DCD-87F2-F3F8BA10ECB6@xxxxxx

Well, now we're getting somewhere, sort of. You're right, the HP Officejet
7310xi does -not- support PostScript, just PCL3, PCL3 GUI, and PCL10.

However, I took PS out of the equation and just printed a simple 3-line text
file using LPR on the client, and after a considerable delay at the printer,
one page of weirdness followed by an unknown number of blank pages (I hit
"cancel" on the printer at this point).

The source file ("y") on the client looks like:

/*
** Name: lk_handle_ivb -
**
*/

Is printed from the client with "lpr -P <hostname>:HPOffice y"

and what comes out on the first print page (after a long delay) looks
something like

/*
** Name: lk_handle_ivb -

**

*/

Some of the printer configuration stuff (from the Windows Printer Test Page):

Printer name: HPOffice
Port name(s): USB001
Data format: RAW
Share name: HPOffice
Driver name: UNIDRV.DLL
Data file: HPO7300T.GPD
Help file: UNIDRV.HLP
Driver version: 6.00
Environment: Windows NT x86
Monitor: PCL hpz311hn

These results with both "passthoughs" set to 1 still. I tried setting them
both to zero, same result.

Regards, Jon

"Alan Morris [MSFT]" wrote:

Well, the "what comes out on the printer", below, didn't come out right in
the reply - here it is with caret's inserted where there are blanks on the
printed sheet:

/*
^^** Name: lk_handle_ivb^^^^^^^^^^-
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^**
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^*/

"jonj" wrote:

The long delay is the windows firewall.

Change the print processor to winprint instead the HP print proc or create a
new printer for you LPR jobs and set this to winprint.

Does your LPR client have an option for file type?

Attempt using the lpr client in Windows (from a Windows machine) and verify
you can get the expected output.

Usage: lpr -S server -P printer [-C class] [-J job] [-o option] [-x] [-d]
filename

Options:
-S server Name or ipaddress of the host providing lpd service
-P printer Name of the print queue
-C class Job classification for use on the burst page
-J job Job name to print on the burst page
-o option Indicates type of the file (by default assumes a text
file)
Use "-o l" for binary (e.g. postscript) files
-x Compatibility with SunOS 4.1.x and prior
-d Send data file first

--
Alan Morris
Windows Printing Team
Search the Microsoft Knowledge Base here:
http://support.microsoft.com/default.aspx?scid=fh;[ln];kbhowto

This posting is provided "AS IS" with no warranties, and confers no rights.

"jonj" <jonj@xxxxxx> wrote in message
news:8930C243-1B0B-404C-AD5B-709D33276A6D@xxxxxx

Responses in-line...

"Alan Morris [MSFT]" wrote:
It's consistently 5 minutes. The printer does a form-feed immediately and
the print job enters and exits the print queue window and the little display
on the HP flashes "printing" but 5 minutes go by before the (bad) page
prints. It's somewhat curious that if I render the print job on the client
using enscript (creating PS output) rather than lpr (creating text), even
though it prints garbage, it prints it immediately without this delay!
Did that, created a new (shared) printer with winprint as the processor,
same results.
Fairly antiquated, specified as a "filter_option". From the "man" page for
lpr (Solaris):

If filter_option is not specified and the printer can
interpret PostScriptO, inserting `%!' as the first two
characters of file causes file to be interpreted as
PostScript.

The following filter options are supported:

p Use pr to format the files. See pr(1).

l Print control characters and suppress page breaks.

t file contains troff (cat phototypesetter) binary data.

n file contains ditroff data from device independent
troff.

d file contains tex data in DVI format from Stanford.

g file contains standard plot data produced by plot(1B)
routines.

v file contains a raster image. printer must support an
appropriate imaging model such as PostScript in order
to print the image.

c file contains data produced by cifplot.

f Interprets the first character of each line as a stan-
dard FORTRAN carriage control character.

Tried this from both the host Vista machine and from a LAN-attached XP
machine to the Vista share, same results as doing lpr remotely from Solaris;
5 minute delay from initial form-feed to printing corrupted output. Tried
both the default output type (text) and "-o l", same result.

Jon