|
Bugzilla – Full Text Bug Listing |
| Summary: | SuSEConfig.tetex cannot handle every resolution correctly | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE LINUX 10.0 | Reporter: | Dennis Lubert <plasmahh> |
| Component: | Other | Assignee: | Johannes Meixner <jsmeix> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | werner |
| Version: | RC 1 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | maint:released:11.2:28189 | ||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
Klaus? Why does lpoptions reports such a resolution? Good question. But need myself more information to dig more easily into it: Dennis: which printer is configured at your machine? Please do (as root): grep ljet4 /etc/cups/ppd/* Dennis: I scanned my whole /usr/share/cups/model directory and didn't find any such weird resolution. Is this a PPD file / printer driver, which comes with SUSE Linux? This is my bug because the broken resolution is in a PPD of the manufactuere-PPDs package: /usr/share/cups/model/manufacturer-PPDs/hp/HP_LaserJet_3200.ppd.gz In fact this is of course a bug of HP because their PPD is broken: The Adobe PPD specification section 5.9 reads: ------------------------------------------------------------------------- ... must be either a string of the form 300dpi or of the form 300x300dpi or it can be Unknown ------------------------------------------------------------------------- Werner, your script must be prepared to get the resolution of the form [0-9][0-9]*dpi or [0-9][0-9]x[0-9][0-9]*dpi or "Unknown". Nevertheless it is a good idea to fall back to a fallback-resolution (e.g. 600dpi) if you cannot get a valid resolution because the user can always install whatever kind of PPD file (e.g. from the manufacturer's driver CD for the printer) where I cannot fix it. A typo: I meant "[0-9][0-9]*x[0-9][0-9]*dpi" I'm now using
shopt -s extglob
reg='?(\*)@(+([0-9])|+([0-9])x+([0-9]))dpi'
case "$1" in
$reg) cur=${1%%+([[:alpha:]])}
esac
cur="${cur#\*}"
shopt -u extglob
New manufacturer-PPDs submitted right now to STABLE. There "600x600x2dpi" was simply replaced by "600x1200dpi" which is possible because "600x1200dpi" is not used elsewhere in the PPDs. Same problem with HP's PPDs in the hplip package. Submitted fixed hplip package right now to STABLE. Ah, I did not realize that the Resolutions come directly from the installed printer drivers. I have turboprint drivers installed to use advanced features and resolutions of my printer, the /etc/cups/ppd/tp0.ppd looks like this in some parts: *DefaultResolution: 600x600x1dpi *Resolution 300x300dpi/1 - 300dpi: "<</turboprintResolution(300x300dpi)>>setpagedevice" *Resolution 600x600dpi/2 - 600dpi: "<</turboprintResolution(600x600dpi)>>setpagedevice" *Resolution 600x600x1dpi/3 - 1200dpi: "<</turboprintResolution(600x600x1dpi)>>setpagedevice" *Resolution 600x600x2dpi/4 - 4800dpi: "<</turboprintResolution(600x600x2dpi)>>setpagedevice" I don't know if the SuSEConfig.tetex should know (and/or) calculate that it is really 1200/4800, in case anyone else uses turboprint or other customized resolutions... Thanks for the comment! This shows, that it really is not sufficient when I fixed the Suse packages because you got them from elsewhere (see comment #4). Update released for: hplip Products: openSUSE 11.2 (debug, i586, x86_64) |
The /sbin/conf.d/SuSEConfig.tetex script bails out here when the ${cur} variable in line 144 contains something like "600x600x2" (The full lpoptions -l output here is : "Resolution/Print Quality: 300x300dpi 600x600dpi *600x600x1dpi 600x600x2dpi") This causes the script to abort and not execute some of the other things it needs to do, which sometimes is annoying ;)