can't add printer in Turkish locale (rejecting attr has no value)

Bug #276884 reported by Kyle Nitzsche on 2008-10-01
4
Affects Status Importance Assigned to Milestone
System Config Printer
Fix Released
Unknown
system-config-printer (Ubuntu)
Undecided
Unassigned

Bug Description

Binary package hint: system-config-printer

In system-config-printer.py, the new printer's "rejecting" attribute is read, but has no value, so program crashes with python errors.

Attached patch fixes this by testing for attribute's existence with try, and if exception, providing a value of False with catch clause.

Tim Waugh (twaugh) wrote :

Patch is wrong. cupshelpers.Printer._expand_flags always sets 'rejecting'.

It suggests that printer.update() is not called when it should be, and that needs to be found. If 'rejecting' is not set, the printer is just invalid.

Just noting that the patch has been tested by different people in
different places and "works". Not saying it is the best fix, but as a
workaround, it enables adding and using printers in the Turkish locale.

Cheers,
Kyle

Tim Waugh wrote:
> Patch is wrong. cupshelpers.Printer._expand_flags always sets
> 'rejecting'.
>
> It suggests that printer.update() is not called when it should be, and
> that needs to be found. If 'rejecting' is not set, the printer is just
> invalid.
>
>

Michael Terry (mterry) wrote :

I've been looking at this. The fix Kyle suggested does help, but as Tim pointed out, doesn't solve the root problem. You still won't be able to print with such a printer (or at least, I couldn't).

The root problem is that the Python lower() method on strings is locale-dependent. When _expand_flags tries to assign attributes, it converts uppercase strings to lowercase attributes. In the Turkish locale, the letter I (eye) is not lowercased, resulting in attributes like 'rejectIng'. This causes problems all over the place.

Background on this can be seen in this thread: http://mail.python.org/pipermail/python-list/2008-January/644769.html and in the Unicode spec, section 5.18.

You can test that this crazy situation is true by the following commands:

$ LANG=en_US.UTF-8 python -c "import locale; locale.setlocale(locale.LC_ALL, ''); print 'TURKISH'.lower()"
turkish
$ LANG=tr_TR.UTF-8 python -c "import locale; locale.setlocale(locale.LC_ALL, ''); print 'TURKISH'.lower()"
turkIsh

What is really wanted is a non-locale-dependent 'lower' function here, which Python apparently does not provide. It's simple to write, but I'm surprised it's not already there.

I've made that change in the code and I *still* can't get it to print, but at least I'm not seeing exceptions. I'm still investigating, but it may be more lower()/upper() goofiness.

Michael Terry (mterry) wrote :

Specifically, my current problem is that printers I create with my patched version seem to be stuck in 'connecting-to-device' mode. If I run system-config-printer in an English locale, I can kind of get it to work (can print test pages via the troubleshooting wizard), but not in all cases...

Michael Terry (mterry) wrote :

This has already been incorporated into Jaunty, as the fix went into upstream about a month ago.

My further problems printing seem specific to the HP printer drivers and furthermore, seem client-side. That is, "LANG=C lpr testfile" works, but "LANG=tr_TR.UTF-8 lpr testfile" does not. So that problem isn't related to system-config-printer.

Changed in system-config-printer (Ubuntu):
status: New → Fix Released
Changed in system-config-printer:
status: Unknown → Fix Released
Michael Terry (mterry) wrote :

Just FYI, I filed a bug about my HP printer problem as bug 348457.

Michael Terry (mterry) on 2009-10-28
tags: added: oem-services
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.