Bug 50609 - remote unix (lpd) postscript does'nt work
Summary: remote unix (lpd) postscript does'nt work
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: printconf (Show other bugs)
(Show other bugs)
Version: 7.3
Hardware: i386 Linux
Target Milestone: ---
Assignee: Crutcher Dunnavant
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2001-08-01 16:02 UTC by Gene Czarcinski
Modified: 2007-04-18 16:35 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-08-02 07:30:40 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Gene Czarcinski 2001-08-01 16:02:11 UTC
Description of Problem:
Defined a remote Unix lpd printer.  Unfortunately, output is the text
listing of the postscript

How Reproducible:

Steps to Reproduce:
1. Using printconf-gui, define a remote unix lpd printer
2. For printer type, select HP 4050 Postscript.
3. exit to save changed (another problem)
4. restart lpd
5. printsomething using a2ps

Actual Results:
text of the generated prostscipt

Expected Results:
the printed page in "a2ps format".

Additional Information:

Comment 1 Gene Czarcinski 2001-08-01 17:12:44 UTC
printconf in beta3/Roswell has a "traceback problem" if just "Postscript" is
selected for a printer type.  This is fixed in 0.3.6 from rawhide and when just
"Postscript" is selected for a remote Unix lpd then everything works OK.

However, if HP->4050->Postscript is selected, it still does not work BECAUSE
when that is selected, some "@PJL" commands are inserted into the from of the
file.  When the file gets to the print server, it does not see the expected
"%!PS-Adobe" as the first list and treats the whole thing as text.

While the "@PJL" commands are a nice touch, I believe it will cause more
confusion and problems for users than it is worth.

Comment 2 Glen Foster 2001-08-01 20:23:45 UTC
This defect is considered SHOULD-FIX for Fairfax.

Comment 3 Crutcher Dunnavant 2001-08-01 20:34:00 UTC

What sort of spool is the remote machine running? Trying to track this down.
There are interaction issues here. Are double filtering (filtering locally, and
then again on the remote machine)? If you are, all remote clients should be
printing to Postscript, because the remote printer is the =server=, and it is
looking for postscript.

Comment 4 Gene Czarcinski 2001-08-01 20:59:45 UTC
The remote printer is running rhl 6.2 with LPRng and ifhp (filtering) ... yes,
there is double filtering.  What I did to configure worked with 7.1 (selecting
the HP 4050 printer).  It is the new features in 7.2 that give the trouble.

Now that I understand what is going on it is simple to specify only "Postscript"
on the local rather than "HP-4050-Postscript".  However, I believe that this
will be confusing to other folks.  Maybe an up-front option for "remote lpd
printer" and a 2nd option for "remote Unix lpd printer server" (which would only
have the simple options such as Postscript, PCL, etc).

Comment 5 Crutcher Dunnavant 2001-08-02 02:47:51 UTC
oh no, now I've gone cross eyed.

I would still like to know if this is /actually/ the problem. Can you set up a
raw, unfiltered spool on the remote queue, and a filtered spool on your local
client, and send it that PJL job? I'd like to know if this is just borken.

Comment 6 Gene Czarcinski 2001-08-02 07:30:35 UTC
I believe I actualy did this test already which is how I found the problem.

The actual interface to the printer is an HP JetDirect (ethernet) interface.

If I define the JetDirect interface (ip address plus "raw" as the queue name) as
the remote Unix LPD "system" and use the HP->4050->Postscript selection,
everything works fine.

If I define the print server managing this printer (ip address plus "lp" queue)
as the remote Unix LPD system and use the HP->4050->Postscript selection, then I
get text of the postscript.

Is this what you need or do you want me to change the server definition?

Comment 7 Crutcher Dunnavant 2001-08-02 20:09:59 UTC
yep. thats what I wanted to know. Good.

Double filtration is a problem, but there isnt really a good way to warn people
about it. Grr. oh well.

Comment 8 Gene Czarcinski 2001-08-02 20:24:50 UTC
How about something in the release notes??

This won't help folks who don't read them but it is something.

Note You need to log in before you can comment on or make changes to this bug.