Не знаю, CUPS крайний, или LibreOffice4, но если локаль ru_RU.KOI8-R, LibreOffice не печатает. Ошибка в CUPS: D [09/Mar/2014:19:11:53 +0400] Create-Job ipp://localhost:631/printers/hp_LaserJet_1010 D [09/Mar/2014:19:11:53 +0400] Create-Job client-error-attributes-or-values-not-supported: Bad job-name value: Bad UTF-8 sequence. E [09/Mar/2014:19:11:53 +0400] Returning IPP client-error-attributes-or-values-not-supported for Create-Job (ipp://localhost:631/printers/hp_LaserJet_1010) from localhost Если офис запустить в виде "LANG=POSIX libreoffice4.1 --writer", то печатает. Проверялось, правда, на сборке в p7: LibreOffice4-4.1-alt8.M70P.1
Боюсь, придётся мигрировать на ru_RU.UTF-8 (см. тж. enconvmv) -- мне на одном из давних хостов именно из-за OOo пришлось это сделать где-то в районе бранча 5.1 или t6. Облом с печатью тоже из OOo в случае ru_RU.CP1251 мы году в 2007 диагностировали -- там получалась восьмибитка в заголовке PS/PDF, от которой впадал в задумчивость (или выпадал?) ghostcript. Тогда было замечено на том, что документы, содержащие только ASCII в заголовках, печатаются. Был сделан даже специальный пакетик, но когда не так давно вспомнил и попытался найти -- не нашёл в онлайновых архивах (может быть в офлайновых, но это малореально).
(In reply to comment #1) > Боюсь, придётся мигрировать на ru_RU.UTF-8 (см. тж. enconvmv) "Светлое будущее" зовёт ? Вот только что делать, в итоге, с ограничением в 255 символов на имена файлов, если, вдруг, что... В попытке прикинуть переход, на это сразу же и нарвался. Хотя, это единичный случай у меня, обойдусь, но напомнило...
кодировку файловой системы можно делать не такую, как локаль.
С одной стороны можно, с другой - неудобно: может получиться, что символ в имени можно будет задать, а на ФС он не запишется. Хотя мысль интересная сама по себе, в голову не сразу приходит.
(In reply to comment #3) > кодировку файловой системы можно делать не такую, как локаль. Только стоп. В опциях монтирование такое доступно только для fat же ? Плюс ограничение не в самой ФС, а в ядре. Не поможет...
(In reply to comment #1) > Боюсь, придётся мигрировать на ru_RU.UTF-8 (см. тж. enconvmv) В общем, переехал. Но с enconvmv не всё гладко. Если заранее известно, что не надо угадывать кодировку, получается, что лучше convmv: Bug 29891
В новом CUPS есть какие-то патчи на этот счёт. Надо проверить на Сизифе. Но вообще, с не-UTF кодировками всё плохо: довольно много GTK-приложений тоже просто падают. Я из-за этого перешёл на UTF.
Перевесил на CUPS: Bad job-name value: Bad UTF-8 sequence -- это именно job name; надо будет запатчить, чтобы ошибку не выдавало (если не уже)
Вообще, я этой проблемы ни с чем не замечал вроде бы больше. Точно это CUPS виноват, а не LO неправильно имя задания в utf8 конвертирует ?
(В ответ на комментарий №9) > Вообще, я этой проблемы ни с чем не замечал вроде бы больше. Точно это CUPS > виноват, а не LO неправильно имя задания в utf8 конвертирует ? А он не конвертирует. Строго говоря, да, надо бы в соответствующем URL преобразование делать. Но в CUPS объезжать это тоже надо.
Created attachment 6966 [details] Rude patch to fix the problem May be this small patch helps someone to save their nerves. It changes cupsCreateJob function in util.c in minimal manner. It makes 'title' to iconving to reduntant but universal utf-8 code as expected by cupsd.
Чё-то я зарапортовался. Прошу прощения что по ошибке написал комментарий на инглише. Смысл патча в том чтобы преобразовать title который попортил мне кучу нервов в utf-8 из текущей локали. Сто пудов я чего-то не учёл, да и static... . Но хоть так. Сам я ничего помогающего пользователям однобайтовых кодировок в сети не нашёл. А компании апле на них плевать.
(В ответ на комментарий №12) > Смысл патча в том чтобы преобразовать title который попортил мне кучу > нервов в utf-8 из текущей локали. Напарывались: http://freesource.info/wiki/HCL/Periferija/Printery/Canon (pstocapt2fix сходу по архивам не нашёл, если вдруг кому будет нужен -- можно глянуть более внимательно).
Created attachment 6967 [details] pstocapt2fix-0.1-alt2.src.rpm > (pstocapt2fix сходу по архивам не нашёл, если вдруг кому будет нужен -- > можно глянуть более внимательно) find по сусекам отработал и всё-таки выловил :)
На моей машине вообще нет pstocapt2fix. Сдаётся мне что рецепт с подменой локали устарел. Кроме того непонятно зачем тут фигачить на C. Если для замены env "CHARSET=utf8" вполне подойдёт /bin/sh. Странно всё.
(В ответ на комментарий №12) > Чё-то я зарапортовался. Прошу прощения что по ошибке написал комментарий на > инглише. Смысл патча в том чтобы преобразовать title который попортил мне кучу > нервов в utf-8 из текущей локали. Сто пудов я чего-то не учёл, да и static... . > Но хоть так. Сам я ничего помогающего пользователям однобайтовых кодировок в > сети не нашёл. А компании апле на них плевать. Спасибо огромное за патч, очень выручил. Система OpenSuse 42.3, локаль CP1251, cups 1.7.5.
Не смог воспроизвести - все системы перевели на юникод и KOI8-R теперь не нужен.
