| Summary: | Epson inkjet status doesn´t work | ||
|---|---|---|---|
| Product: | [Unmaintained] kdeprint | Reporter: | Michael Stather <kontakt> |
| Component: | general | Assignee: | KDEPrint Devel Mailinglist <kde-print-bugs-null> |
| Status: | CLOSED NOT A BUG | ||
| Severity: | normal | CC: | jlayt |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Michael Stather
2005-10-20 15:38:37 UTC
Confirmed here in kubuntu. This appears to happen if the cups DeviceURI is usb://EPSON/xxxxx. This feature does work if the the DeviceURI is manually changed to a /dev/ path. This is not a KDEPrint bug. It is in the external "escputil" utility (to which KDEPrint only provides a GUI frontend). Maybe escputil does not support the non-"/dev/usb/lpX" paths supported by more recent versions of CUPS. I really enjoy using and seeing the way kdeprint has progressed over the years. It has made printer setup and administration infinity easier. I do have disagree with passing "higher level" path information to helper apps. It seem like a lot of extra work/overhead for a special purpose applications to need to parse HAL device properties (AFAIK) just to get back to a device's raw file path. If this "higher level" path is from HAL, it is missing a udi. This would cause the look-up for a unique "raw" path to fail when there were two or more identical printers plugged into the same machine/cups server which is common in a business environ. My point is that it be more unix-like behavior for helper apps like escputil to be able to focus on getting consistent info from various hardware instead of worrying about figuring out the device's path first. -Ian Closing old Resolved status bug. |