hp-setup and hp-toolbox fail with foreign charsets

Asked by Malte Wetz

I had an Officejet Pro L7580 (connected via Ethernet) to install on Kubuntu 8.04 (jplip 2.8.2) and it didn't work. hp-setup could not automatically find the correct PPD (although the file /usr/share/ppd/hpijs/HP/HP-OfficeJet_pro_l7500-hpijs.ppd was present and readable). I manually chose the PPD and after entering queue names for printer and fax, hp-setup told me »Printer queue setup failed. Please restart CUPS and try again.« Restarting CUPS and trying again lead to the same result.

After some searching, I looked into the debugging output. hp-setup said »hp-setup[12312]: debug: addPrinter() returned (1, client-error-bad-request)« and the CUPS log corresponded: »client-error-bad-request: Unsupported character set "iso-8859-15"!«
So I found the reason of my problems. hp-setup could not communicate with CUPS using my locale. Whenever it tried (by querying the PPDs or installing the printer), CUPS rejected it.

Setting LC_ALL=C helped and hp-setup installed the printer smoothly.

Of course, with hp-toolbox it's the same. Using my default locale it tells me that there are no printers installed. Starting it via »LC_ALL=C hp-toolbox« and suddenly the printer is found.

(See also: https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/203944)

I'm not sure if this is the fault of hplip or cups (though lpr and other tools work fine). But perhaps you might want to take a closer look at it. Maybe hplip should override LC_ALL by default when talking with CUPS.
Even if CUPS is to blame, this message may be helpful to those having the same problem.

Question information

Language:
English Edit question
Status:
Answered
For:
HPLIP Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Aaron Albright (albrigha-deactivatedaccount) said :
#1

This does seem to be a problem with HPLIP. We are working to make some changes to better support foreign charsets.

Sorry for any inconvenience and thanks for your support and suggestions.

Aaron

Revision history for this message
jiu (jacques-charroy) said :
#2

Are there any known workarounds?

Revision history for this message
Johannes Meixner (jsmeix) said :
#3

CUPS is to blame because since CUPS 1.3.4
the cupsd accepts only UTF-8 encoded stuff.

There are no workarounds except to use
a plain ASCII locale or a UTF-8 locale, see also
https://bugs.launchpad.net/hplip/+bug/162196

The fix is that all programs which communicate
with the cupsd must use a UTF-8 encoding for
the strings which they send to the cupsd.

Can you help with this problem?

Provide an answer of your own, or ask Malte Wetz for more information if necessary.

To post a message you must log in.