Bug 51268 - send EOT flag cannot be checked permanently in printtool
send EOT flag cannot be checked permanently in printtool
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: printconf (Show other bugs)
7.1
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
Aaron Brown
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-08-08 16:59 EDT by killpack
Modified: 2007-04-18 12:35 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-01-10 11:16:14 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description killpack 2001-08-08 16:59:03 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.3-12 i686)

Description of problem:
I run printool (or printconf-gui) When I am creating a new printer or
editing an existing one, I cannot get the "send EOT"  flag to stay checked.

I check the box and then hit the "OK" button.  But when I go back to edit
the printer the flag is still unchecked.

When I looked in the /etc/alchemist/namespace/printconf/local.adl file, the
flags section is empty.  My local.adl file looks like this...  (gunzipped)

---------------- local.adl file ---------------------------
<?xml version="1.0"?>
<adm_context VERSION="0">
  <id NAME="local" SERIAL="997293745">
    <null/>
    <null/>
    </id>
  <datatree>
    <printconf TYPE="LIST">
      <print_queues TYPE="LIST">
        <lp0 ATOMIC="TRUE" TYPE="LIST">
          <queue_type TYPE="STRING" VALUE="LOCAL"/>
          <filter_type TYPE="STRING" VALUE="MAGICFILTER"/>
          <alias_list ANONYMOUS="TRUE" TYPE="LIST">
            <alias TYPE="STRING" VALUE="lp"/>
            <alias TYPE="STRING" VALUE="salt"/>
            </alias_list>
          <queue_data TYPE="LIST">
            <local_printer_device TYPE="STRING" VALUE="/dev/lp0"/>
            </queue_data>
          <filter_data TYPE="LIST">
            <mf_type TYPE="STRING" VALUE="MFOMATIC"/>
            <flags TYPE="LIST">
              </flags>
            <printer_id TYPE="STRING" VALUE="69824"/>
            <gs_driver TYPE="STRING" VALUE="Postscript"/>
            <foomatic_defaults ANONYMOUS="TRUE" TYPE="LIST">
              <option_default TYPE="LIST">
                <name TYPE="STRING" VALUE="Duplex"/>
                <type TYPE="STRING" VALUE="enum"/>
                <default TYPE="STRING" VALUE="DuplexNoTumble"/>
                </option_default>
              </foomatic_defaults>
            </filter_data>
          </lp0>
        </print_queues>
      </printconf>
    </datatree>
  </adm_context>
------------------------- end local.adl file ----------------------

How reproducible:
Always

Steps to Reproduce:
1.open printtool (or printconf-gui)
2.create a new printer
3.name: lp0
4.queue type: local printer
5.printer device: /dev/lp0
6. Printer driver: HP - color laser jet 4500 (I have the same results if I
choose a plain vanilla Postscript printer)
7. Driver options: check the send EOT box
8. Hit the "OK" button
9. Select the printer for edit
10. On the Driver options page, the send EOT box should still be checked
	

Actual Results:  the "send EOT" box was unchecked

Expected Results:  the "send EOT" box should be checked

Additional info:

I have an HP color laser jet 4500 with duplex printing.
Single page jobs that I queue up take ~7 minutes to print - I believe it is
because the printer is waiting for the EOT, and when it doesn't recieve it,
it times out and prints the page.  But 2 page jobs will print immediately.

I am using the following rpms.
printconf-gui-0.2.12-1
printconf-0.2.12-1
LPRng-3.7.4-23

A workaround would be helpful (ie. what is the line that I could put in my
local.adl to make it send the EOT - if there is one.)
Comment 1 Tim Waugh 2002-03-06 08:32:25 EST
This is fixed in the current version (in rawhide), and very possibly in
7.2+updates as well.

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