lprによるutf-8エンコーディングのサポート

介してプリンタにテキストファイルを送信しようとしたときlprからxterm、コンテンツは原形をとどめないほど破損している、の原因は、最終的にファイルのエンコーディングに追跡しました。代わりにiconv（例：）を使用してテキストを処理するとiconv -f utf-8 -t ascii//TRANSLIT、ファイルは正常に印刷されます。私が遭遇したもう1つの提案は、ドキュメント形式（例：）の設定ですlpr -o document-format=text/utf8が、これはエラーを返しますlpr: Unsupported document-format "text/utf8"。lprコマンドによるエイリアスを付けて、による処理を含めることもできますiconvが、CUPS/ lprシステムでのネイティブutf-8サポートのより一般的な方法はありますか？

編集：私のOSはDebian 8で、ウィンドウマネージャーはopenbox（デスクトップ環境なし）です。MacOS XとDebian7 / Gnome3システムから問題なくこのファイルを印刷できます。

現在のシステムでは、文字エンコードをUTF-8からASCIIに変更した後でも、改行文字はによって考慮されないlprため、行が連結され、用紙のマージンに達するまで印刷されます。iconvMacOS Xでの再コーディングと音訳の後でも、印刷は正常に機能します（したがって、改行の問題は現在のシステムに固有です）。

同じことがpapsでも行えます。

#!/bin/bash
#This script converts UTF-8 txt to postscript
paps | lpr
Sometimes you need to specify the prinqueue;

#!/bin/bash
# This script converts UTF-8 txt to postscript
paps | lpr -P lj

Papsはcupsのテキストトップよりもはるかに優れています。

HPLIPを外部依存関係と見なすかどうかはわかりませんが、CUPSからの直接の推奨ドライバーを以下に示します。

CUPSプリンタードライバー：HP4650

そして、これがDebian Repo：HPLIPSのパッケージ情報です

このように、Thasihは、システムはpapsなどのツールを使用せずにドキュメントをラスタライズする方法を認識していないと述べています。hplipパッケージをインストールしhttp://localhost:631、推奨ドライバーを使用するように構成すると、問題が解決します。詳細については、DebianWikiのSystemPrintingエントリを参照してください

私は同じ問題を抱えており、以下のハウツーでそれを修正することができました：

http://www.bsmdevelopment.com/Reference/Tech_20130004.html

本当に美味しいです。FreeMonoやCourierのようなテキスト/プレーン印刷用のフォントを選択することもできます。

乾杯、

次のようなものが必要です：

text/plain              application/postscript  33      texttops

あなたの中/etc/cups/mime.convsのファイル。それで、私がすべきことは、texttopsフィルターを修正することだと思います。Debianでは、これはです/usr/lib/cups/filter/texttops。これは、texttopdfフィルターとpdf2psコマンドを使用するシェルスクリプトです。texttopdf / pdf2psの呼び出しをで置き換えることもできますがpaps、引数が同じではないことに注意してください。最小値（テキストが標準入力に提供され、psの結果が標準出力に送信されるため）は、次の行だけになります。

paps

ただし、オプションを追加することもできます。例：

paps --font='Monospace 10'

注：私は試していません。ただの憶測...