Bug 147292 - Fails importing (attached) .PPD correctly, claims success
Fails importing (attached) .PPD correctly, claims success
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: system-config-printer (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-02-06 10:12 EST by Olov Johansson
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version: 0.6.129-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-05-12 07:19:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
B4300.ppd (55.01 KB, application/octet-stream)
2005-02-06 10:14 EST, Olov Johansson
no flags Details

  None (edit)
Description Olov Johansson 2005-02-06 10:12:28 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041111 Firefox/1.0

Description of problem:
system-config-printer fails to import the attached PPD-file.

Problem:
The PPD has Macintosh-style lineendings (0x0d instead of 0x0a). The
parser in queueTree.py expects unix or windows newlines (thus views
the PPD as one line long).

(For the record: Installing the same PPD via CUPS webinterface
http://localhost:631/ works fine.)


Solution/Patch:
in queueTree.py, exchange the line: f = file (filename)
with: f = file (filename, 'rU')


From python library reference:
"In addition to the standard fopen() values mode  may be 'U' or 'rU'.
If Python is built with universal newline support (the default) the
file is opened as a text file, but lines may be terminated by any of
'\n', the Unix end-of-line convention, '\r', the Macintosh convention
or '\r\n', the Windows convention. All of these external
representations are seen as '\n'  by the Python program. If Python is
built without universal newline support mode 'U' is the same as normal
text mode. "


Version-Release number of selected component (if applicable):
system-config-printer-0.6.116.1.1-1

How reproducible:
Always

Steps to Reproduce:
1. Open system-config-printer, import the attached PPD.
2. Dialog claims "PPD imported" 


Actual Results:  Trying to add a printer reveals that Oki B4300 isn't
in list.    

Expected Results:  Either:
1) (preferred) A PPD with macstyle newlines should be possible to
import, see solution in full description.
2) The installer shouldn't claim "PPD imported" when it didn't parse
the file (specifically Manufacturer and ShortNickName) correctly.


Additional info:
Comment 1 Olov Johansson 2005-02-06 10:14:45 EST
Created attachment 110703 [details]
B4300.ppd
Comment 2 Matthew Lenz 2005-03-23 17:56:39 EST
I can confirm the same problem with a PCL ppd sent to me by the Ricoh
development team.  If I copy the PCL ppd for the printer to the
/usr/share/cups/model directory, restart cups and then add and configure the
printer via the cups web interface I can print just fine to the printer.  If
import the ppd via the system settings / import ppd it does not print properly
(dumps unfiltered postscript data to the printer) to the printer.  Ricoh is
preparing an install document for linux that can't use this import feature cuz
it just plain doesn't work properly.
Comment 3 Tim Waugh 2005-03-30 10:35:03 EST
Fixed in CVS.  Thanks.

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