Hide Forgot
Description of problem: CUPs help indicates the following (from doc/help/network.html): sanitize_title=no - Specifies that the job title string should not be restricted to ASCII characters. sanitize_title=yes - Specifies that the job title string should be restricted to ASCII characters. The default is sanitize_title=yes. The above indicates that NON-ASCII characters are restricted (replaced with "_"), but in reality all characters that are not ASCII alphanumeric or space are restricted (for example: ?, $, =). The relevant section of backend/lpd.c (~line 480): if (sanitize_title) { /* * Sanitize the title string so that we don't cause problems on * the remote end... */ char *ptr; for (ptr = title; *ptr; ptr ++) if (!isalnum(*ptr & 255) && !isspace(*ptr & 255)) *ptr = '_'; } Either the code or the documentation should be corrected since the documented operation is misleading. Possible patch to operate as documented: --- backend/lpd.c.orig 2013-07-24 10:15:51.102608626 -0500 +++ backend/lpd.c 2013-07-24 10:16:17.495839026 -0500 @@ -493,7 +493,7 @@ char *ptr; for (ptr = title; *ptr; ptr ++) - if (!isalnum(*ptr & 255) && !isspace(*ptr & 255)) + if (!isprint(*ptr & 255)) *ptr = '_'; } Version-Release number of selected component (if applicable): specific: cups-1.4.2-50.el6_4.4.x86_64 All versions of cups from 1.4.2-current are affected. How reproducible: Always Steps to Reproduce: 1. Set "Loglevel debug" in /etc/cups/cups.conf 2. Restart CUPS 3. Print test document to any LPD network printer: lpr -Ptestprinter -J TEST=TEST ./test.txt Actual results: In debug output (/var/log/cups/error_log): "JTEST_TEST" Expected results: In debug output (/var/log/cups/error_log): "JTEST=TEST" Additional info: Work around by setting sanitize_title=no in LPD printer URI if the remote end can handle it.
The code went in several years before the documentation (2003, 2007), so I'm inclined to think it's the documentation that's wrong.
That could certainly be the case. If it's updated to indicate what actually happens, that would be sufficient. There may be legacy equipment that doesn't handle non-alphanumeric characters in the document title/job name/etc, which could explain why it operates as it does. In my case I had a legacy platform that required the NAME=VALUE to be passed as part of the LPD communication, and I was lead astray thinking that only non-ASCII characters were stripped. (This was one of several items I was trying to match up when troubleshooting and comparing legacy-to-legacy vs RHEL6-to-legacy LPD communications.)
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate, in the next release of Red Hat Enterprise Linux.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2015-1346.html