[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[plamo:33902] Re: hplip-3.22.2



こじまさん  コメントありがとうございます。

> Plamo では別に closed-source な binary blob を
> 拒否するつもりはないんで,使えるものならパッケージに含めていただいて
> 問題ないですよ.

上記の件は了解しました。今後、他のパッケージングのときに検討項目に入れまする。

↓の件、詳しく書くと長くなりそうだったので解説省いてしまったんですが、
> > そのため先のバージョンでは印刷の際 cupsのJOBが "filter failed"になり印刷できない
> > 場合があります。

HPLIPをソースからコンパイル(パッケージ作成の過程)するとき、--disable-imageProcessor-build を
指定しないと たとえ make install DESTDIR=$P みたいな指定をしても libImageProcessorライブラリを
A) システムディレクトリ(/usr/lib)にコピーしてしまいます。(おいおい..)
B) にも拘らず libImageProcessorライブラリはパッケージに含まれない。(なんでやねん)

結果的に
・コンパイルした当人のPCには /usr/lib/ に libImageProcessorライブラリが存在し
・パッケージには libImageProcessorライブラリが提供されない
・なので、パッケージをインストールしたユーザーの環境には libImageProcessorライブラリが存在しない
という状況になります。
このときコンパイルされる hpcups (/usr/lib/cups/filter/ にインストールされます)は
libImageProcessorライブラリを必要とするバイナリになってます。

作成者(わたし)がパッケージインストール後に印刷確認すると印刷OK。
(hpcupsがlibImageProcessorライブラリを認識してるから印刷OK)
一方、ユーザー環境にはlibImageProcessorライブラリが無いわけで、印刷すると cupsのジョブが
"filter failed"のステータス表示で印刷エラーになります。
filterエラーなのでレンダリングがうまく行かず ghostscript -> PRINTER へデータが送信されないため
プリンターはうんともすんとも言わずに印刷失敗となります。
※ もしユーザーが古いバージョンのHPLIPをインストールしていて既にlibImageProcessorライブラリを持っている
  場合は、印刷できる気がする。

で、他のディストロ(ArchとかGentoo, Debianとか 含むslackware)はどうしてるかというと、
libImageProcessorを無効にするパッチ(以前より Debianから出てました)を適用して
--disable-imageProcessor-build オプション付けてパッケージングしてます。 
そうするとソースの Makefile.am から ImageProcessor作成関連のコードが削除され、
C) libImageProcessorライブラリは生成されない&システムディレクトリへの変更は為されない
D) 当然パッケージにはlibImageProcessorライブラリは含まれない
E) hpcupsはlibImageProcessorライブラリを必要としないバイナリとして生成される
となります。

ちなみに、libImageProcessorライブラリが無いhpcupsからの印刷で印刷品質に問題感じたことはないです。
わたしもそんなに詳しくないですが、経験からの理解は以上です。

あべ

-- 
=========================================
JW (ABE Shin-ichi) <shin1.abe@xxxxxxxxx>
=========================================


Follow-Ups
[plamo:33903] Re: hplip-3.22.2, KOJIMA Mitsuhiro
References
[plamo:33900] hplip-3.22.2, ABE Shin-ichi
[plamo:33901] Re: hplip-3.22.2, KOJIMA Mitsuhiro

[検索ページ] [メール一覧]
Plamo ML 公開システム