Bug 198702 - print/cups: unable to print when a job name is not in UTF-8
Summary: print/cups: unable to print when a job name is not in UTF-8
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: FreeBSD Office Team
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-03-19 12:09 UTC by emz
Modified: 2018-03-18 09:43 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description emz 2015-03-19 12:09:58 UTC
Since 1.7.x it's unable to send print jobs which contain invalid UTF-8 symbols, like jobs containing KOI8-R symbols, for example. And these job names are often created automatically, like LibreOffice does, for example.

Since FreeBSD doesn't fully support UTF-8 and developing UTF-8 capable environment is still in process, lots of peaople can step onto this.

Symptom:

===Cut===
D [19/Mar/2015:16:49:05 +0500] [Client 16] POST /printers/Mita HTTP/1.1
D [19/Mar/2015:16:49:05 +0500] cupsdSetBusyState: newbusy="Active clients", busy="Not busy"
D [19/Mar/2015:16:49:05 +0500] [Client 16] No authentication data provided.
D [19/Mar/2015:16:49:05 +0500] [Client 16] 2.0 Create-Job 23
D [19/Mar/2015:16:49:05 +0500] Create-Job ipp://localhost:631/printers/Mita
D [19/Mar/2015:16:49:05 +0500] Create-Job client-error-attributes-or-values-not-supported: Bad job-name value: "job-name": Bad name value "акт работ февраль 2015" - bad UTF-8 sequence (RFC 2911 section 4.1.2).
E [19/Mar/2015:16:49:05 +0500] [Client 16] Returning IPP client-error-attributes-or-values-not-supported for Create-Job (ipp://localhost:631/printers/Mita) from localhost
D [19/Mar/2015:16:49:05 +0500] [Client 16] Content-Length: 248
D [19/Mar/2015:16:49:05 +0500] [Client 16] cupsdWriteClient error=0, used=0, state=HTTP_STATE_POST_SEND, data_encoding=HTTP_ENCODING_LENGTH, data_remaining=248, response=0x80313f380(IPP_IDLE), pipe_pid=0, file=-1
D [19/Mar/2015:16:49:05 +0500] [Client 16] Writing IPP response, ipp_state=DATA, old wused=0, new wused=0
D [19/Mar/2015:16:49:05 +0500] [Client 16] bytes=0, http_state=0, data_remaining=0
D [19/Mar/2015:16:49:05 +0500] [Client 16] Waiting for request.
D [19/Mar/2015:16:49:05 +0500] cupsdSetBusyState: newbusy="Not busy", busy="Active clients"
===Cut===

Workaround: make a job name with latin1. In LO, for example, this can be done by saving a file with a latin filename.
Comment 1 Tijl Coosemans freebsd_committer 2016-03-11 14:53:48 UTC
I'll assign this to office@.  I believe this is a bug in LibreOffice.  It should not create print jobs with non-UTF8 characters in job-name.
Comment 2 ml 2017-04-03 09:52:11 UTC
It just happened to me while trying to print a PDF document with Okular (graphics/okular), so it's not (only) a problem with LibreOffice.
However I'm not sure it's a cups' bug either.
Should I file a separate PR?
Comment 3 emz 2017-04-03 16:15:14 UTC
It doesn't happen to me since I switched to the UTF-8 locale, FreeBSD has full support of it. So I guess this bug is less important now.
Comment 4 ml 2017-04-05 17:54:52 UTC
What do you mean with "I switched to the UTF-8 locale".
Could you outline what you exactly did to solve this?
Thanks.
Comment 5 Mark Linimon freebsd_committer freebsd_triage 2017-07-19 11:55:32 UTC
Port was renamed.  Assign to new maintainer.
Comment 6 Tijl Coosemans freebsd_committer 2017-07-20 12:36:47 UTC
Back to office@.  It's an application bug, not a bug in cups.
Comment 7 Li-Wen Hsu freebsd_committer 2018-03-17 09:45:59 UTC
Hi, cloud you check if this issue still exists in 6.0.2 and newer supported versions of FreeBSD?  Thanks!
Comment 8 emz 2018-03-18 09:43:17 UTC
I think it can be closed, because UTF-8 is now fully supported as the system charset, so there is no need to stick to the KOI8-R. At least I switched long ago, the problem doesn't exist for me. It still can exist for those who still use KOI8-R, but I doubt there are any; so in case there are - they should reopen this bug.