Captで苦戦中ですがよろしくお願いします
hatochan
皆のデスクトップ環境がWindowsからLinuxに取って代わるのを夢見て
10年の月日が流れました。いまだに道半ばですが、いつの日か実現する
ことを信じていろいろしています。
いまは、Canon Captが印刷できなくなり、それで苦戦している最中です。
細かな情報をこちらにあげさせていただきますので、よろしくお願いします。
対象環境：openSUSE 11.3, Slackawre 13.1（ともにサポート外）
CAPT Printer Driver for Linux Ver2.20 2011//1/20リリース
修正点
●プリンタードライバー Ver2.00からVer2.20への変更点
・64bit用のRPMインストールパッケージを追加しました。
・LBP3100において、特殊印字処理Bに対応しました。
・LBP3600/3300/5300/3500/3310,LBP9100Cにおいて、給紙トレイ用紙サイズの
チェックに対応しました。
・排紙方法の選択肢で“指定しない”を“ グループ”に変更しました。
・ドライバーUI設定時、他のPDLに依存させない対策を行いました。
・PDLの非依存化にともない、インストールパッケージモジュールの構成を変
更しました。
・ドライバーUIのメイン画面にて、印刷ページを印刷範囲と印刷指定の2つの
グループに分割しました。
・ドライバーUIの詳細設定画面にて、フィルタオプションTABの削除を行いま
した。
・LBP3210,LBP3000,LBP3200,LBP-1120,LBP-1210において、給紙/印刷品質TAB
の削除を行いました。
・トナー濃度のスケールコントロールをコンボボックスまたはスピンボタン
に変更しました。
・ドライバーUIの詳細設定画面において、スクロール表示ができるように変
更しました。
Naruhiko Ogasawara
はとちゃん、ようこそいらっしゃいまし。
手元でビルド試してないので、それは後ほどとして、
まず、/etc/cups/cupsd.conf をひらいていただいて、
LogLevel Debug (この行は変更)
FileDevice Yes (この行は追加)
としてセーブし、cupsd をリスタートしてください。
それでエラーログが出るようになればしめたもので、
ログを送ってください。
もしそれでうまくいかないようなら、今度は、
localhost:631 で (CUPS 1.4 系なら) 管理タブ→
プリンターの管理→「管理」プルダウンメニューの
「プリンターの変更」→「その他のネットワークプ
リンター」のうちどれか→URI に
file:///tmp/test.prn
を入れて、あとはどんどん先に進めてください。
これで印刷してみて、/tmp/test.prn はどうなりま
すか？ ちゃんとできますか？
できるようなら、今度はさっきの要領で、
socket:/<プリンタのアドレス>:9100
として、まずは /tmp/test.prn を lpr かなにかで
投げてみてください。これで印刷できるようなら、
CAPT の専用のバックエンドがおかしいですね。
今はちょっと時間が取れないので、こんな感じで。
では。
--
Naruhiko Ogasawara (nar...@gmail.com)
でんすけ
SuSEの環境は最近触っていないというか、CANONの製品は生理的に好きでは
ないので普段からあまり利用していない事もあって一般論を話します。
まずは技術解説(CANON社)
-> http://web.canon.jp/technology/canon_tech/explanation/capt.html
これによると例ではWin環境なのですが、PC側のWinシステムで印刷イメージを
作成(レンダリング)して、これを何らかの手法でプリンタ装置へ転送するようです。
はとちゃんの場合にはLinuxシステムになるのでレンダリングはCUPSの配下に
実装されるか、Ghostscriptのレンダリング・フィルタの何らかでレンダリングして
CUPSの印刷キューにスケジュールされる形態になるのかな？
でもって、もうちょっとぐぐってみると
Ubuntu 10.4
-> http://nabe.blog.abk.nu/CanonCAPT_on_Ubuntu
というページがあります。
目標とするディストリビューションがSuSEなのでYaSTでの操作を提示しないと
解りにくいのだとは思いますが、CUPSとしては「内部での動作として行う事」
として参考になるページなのではないかと思います。
このページを見ると、少なくても印刷形式としては ccpd というツールに対して
CNCUPSLBP3xx0CAPTJ.ppd という ppdファイルで予め出力パターンを定義し
デーモンを起動しておき、ここに印刷データを投入すると出力データがスプール
データとして溜まっていき、適当なタイミングで印刷装置へ転送されていくという
感じになるのだと思います。
ただ、ppdファイルは、装置によって多少は修正が必要になるのかもしれません。
＃詳細は見ていないので不明
少なくても桁ずれとか、行ずれ程度で印刷できれば、ドライバの動作としては
うまくできていると思います。
＃実際は、ここから先の桁・行位置の調整が一番面倒なんですけどね。
最後に同じツールを利用しているのであれば、これらのツールの名前がSYSLOG
などのログを通して観察できると思いますので、不都合のある場合にも、これを
ベースに再度議論をして頂ければさらに先に進めるのではないかと思います。
あまり、良いコメントにはなっていませんが最初のきっかけになればと思います。
以上
＝＝＝
でんすけ / Masaharu DENSUKE NAGATA
densuke...@gmail.com
hatochan
エラーログの取得ができました。
cupsd.confの変更で取得ができました。
でも、ものすごく長いです...。
error.log.0は、一度error.logを消して起動してからのものです。
そこで、KDEのプリンタ設定(YaST2)で「テストページを印刷する」を実行したところ
error.logまでログが増えてしまいました。ざらっとみたところ、Dはデバッグでしょうか、
Iはインフォメーションかな。それらはあるのですが、Eのエラーはないようです。
https://docs.google.com/leaf?id=0Bx-XdKhJhCZQMGI1MGFmOTYtMGIwZC00MWMxLThjMGEtNTkzOTlmMjExMzg0&hl=ja
https://docs.google.com/leaf?id=0Bx-XdKhJhCZQZjYzYjk2ZWUtMjdhOC00OTg0LWI3YjEtMjFiYzQxYTUyNWU4&hl=ja
Naruhiko Ogasawara
2011年3月27日10:18 hatochan <810...@gmail.com>:
> はとちゃん＠小江戸らぐです。
どもです。
> そこで、KDEのプリンタ設定(YaST2)で「テストページを印刷する」を実行したところ
> error.logまでログが増えてしまいました。ざらっとみたところ、Dはデバッグでしょうか、
> Iはインフォメーションかな。それらはあるのですが、Eのエラーはないようです。
ですねぇ。
CAPT バックエンドはちゃんとエラーログを吐いてくれないのかな。
あんまり解決策になってないですが、
- CAPT バックエンドを使うのをやめて、たとえば
socket://<デバイスのネットワークアドレス>:9100
に印刷を流してみたらどうですか？
- openSUSE-ja ML の方で、別のトラブルが起きてた人が 11.4 に
したら解決した、という報告があったので、時間が取れれば上げ
てみてもよいかもしれません。ただ機器も現象も違うので、効果
があるかどうかは不明です……。
[以上]
--
Naruhiko Ogasawara (nar...@gmail.com)
でんすけ
気になるログは以下の所です。
「error.logの最後の方」
D [27/Mar/2011:10:06:19 +0900] Get-Jobs ipp://localhost/printers/LBP3300
D [27/Mar/2011:10:06:19 +0900] Returning IPP successful-ok for
Get-Jobs (ipp://localhost/printers/LBP3300) from localhost
D [27/Mar/2011:10:06:19 +0900] cupsdAcceptClient: 12 from localhost:631 (IPv6)
D [27/Mar/2011:10:06:19 +0900] cupsdReadClient: 12 POST / HTTP/1.1
D [27/Mar/2011:10:06:19 +0900] cupsdAuthorize: No authentication data provided.
D [27/Mar/2011:10:06:19 +0900] cupsdReadClient: 11 POST / HTTP/1.1
D [27/Mar/2011:10:06:19 +0900] cupsdAuthorize: No authentication data provided.
D [27/Mar/2011:10:06:19 +0900] cupsdReadClient: 12 1.1 CUPS-Get-Printers 1
D [27/Mar/2011:10:06:19 +0900] CUPS-Get-Printers
D [27/Mar/2011:10:06:19 +0900] Returning IPP successful-ok for
CUPS-Get-Printers (no URI) from localhost
D [27/Mar/2011:10:06:19 +0900] cupsdReadClient: 11 1.1 Get-Jobs 1
普通のダメダメな所では、最初のIPPリクエストを受け取った後に、速攻で後にある cupsdAuthorise
に飛びますが(当然ですけどダメで終わる)、ここでは一旦 IPv6での接続に成功してデータを POST
しているか若しくは、しようとしているように見えます。
さらに後ろの方ですけれど、ここも気になります。
D [27/Mar/2011:10:06:19 +0900] Purge-Jobs ipp://localhost/printers/LBP3300
D [27/Mar/2011:10:06:19 +0900] cupsdIsAuthorized: requesting-user-name="root"
D [27/Mar/2011:10:06:19 +0900] Discarding unused job-completed event...
I [27/Mar/2011:10:06:19 +0900] [Job 1] Job purged by user.
D [27/Mar/2011:10:06:19 +0900] [Job 1] Unloading...
D [27/Mar/2011:10:06:19 +0900] Discarding unused job-completed event...
I [27/Mar/2011:10:06:19 +0900] [Job 2] Job purged by user.
D [27/Mar/2011:10:06:19 +0900] [Job 2] Unloading...
D [27/Mar/2011:10:06:19 +0900] Discarding unused job-completed event...
I [27/Mar/2011:10:06:19 +0900] [Job 3] Job purged by user.
D [27/Mar/2011:10:06:19 +0900] Discarding unused printer-state-changed event...
D [27/Mar/2011:10:06:19 +0900] cupsdSetBusyState: Active clients
I [27/Mar/2011:10:06:19 +0900] All jobs on "LBP3300" were purged by "root".
D [27/Mar/2011:10:06:19 +0900] Returning IPP successful-ok for
Purge-Jobs (ipp://localhost/printers/LBP3300) from localhost
D [27/Mar/2011:10:06:19 +0900] PID 25249
(/usr/lib/cups/filter/pstocapt2) was terminated normally with signal
9.
D [27/Mar/2011:10:06:19 +0900] PID 25250 (/usr/lib/cups/backend/ccp)
was terminated normally with signal 9.
D [27/Mar/2011:10:06:19 +0900] cupsdReadClient: 11 1.1 Get-Jobs 1
ここから推測できるのは、レンダリングデータをプリンタ装置に送ろうとしてIPP通信をやろうとしている
けどその結果、今度はrootで認証をかけようとしているんだけど、「ダメよん」とか言われているような
感じに見えたりしていて、Jobが断ち切られているように思えます。
＃でも、こっちはIPv6では接続していないように見えますね。
まあ、認証に「root」とか使うのもどうかと思うけど、システムの構成を見直した方が手取り早いの
かもしれませんね。
でも１つ正しいと思えるのは、いくつかのリクエストが溜まっていて、それなりにリクエストは処理され
そうになっているのでフィルタの出力までは行っているように思えます。
なにはともあれ、Jobは１、２、３、…って行っているし、リモートへの接続にも行こうとしているので
そこまでは正常とCUPSは認識しているんじゃないかな？
その点を考慮して見直しをするとよい事があるかもしれませんね。
--
でん / Masaharu "DENSUKE" NAGATA
E-Mail: densuke...@gmail.com
Naruhiko Ogasawara
> でんすけです。
どもです。ログ抽出してもらったおかげで、ちょっとは有意義なコメントが
出せるかしら。
> 「error.logの最後の方」
> D [27/Mar/2011:10:06:19 +0900] Get-Jobs ipp://localhost/printers/LBP3300
> D [27/Mar/2011:10:06:19 +0900] Returning IPP successful-ok for
> Get-Jobs (ipp://localhost/printers/LBP3300) from localhost
> D [27/Mar/2011:10:06:19 +0900] cupsdAcceptClient: 12 from localhost:631 (IPv6)
> D [27/Mar/2011:10:06:19 +0900] cupsdReadClient: 12 POST / HTTP/1.1
> D [27/Mar/2011:10:06:19 +0900] cupsdAuthorize: No authentication data provided.
> D [27/Mar/2011:10:06:19 +0900] cupsdReadClient: 11 POST / HTTP/1.1
> D [27/Mar/2011:10:06:19 +0900] cupsdAuthorize: No authentication data provided.
> D [27/Mar/2011:10:06:19 +0900] cupsdReadClient: 12 1.1 CUPS-Get-Printers 1
> D [27/Mar/2011:10:06:19 +0900] CUPS-Get-Printers
> D [27/Mar/2011:10:06:19 +0900] Returning IPP successful-ok for
> CUPS-Get-Printers (no URI) from localhost
> D [27/Mar/2011:10:06:19 +0900] cupsdReadClient: 11 1.1 Get-Jobs 1
>
> 普通のダメダメな所では、最初のIPPリクエストを受け取った後に、速攻で後にある cupsdAuthorise
> に飛びますが(当然ですけどダメで終わる)、ここでは一旦 IPv6での接続に成功してデータを POST
> しているか若しくは、しようとしているように見えます。
おお、見落としてました。
しかしこちらは localhost のプリントキューの問い合わせのようなので、
今回の不具合とは関係ないのかなと思います。
> さらに後ろの方ですけれど、ここも気になります。
<snip>
ちょっと上まで見ると、
> D [27/Mar/2011:10:06:19 +0900] cupsdAuthorize: No authentication data provided.
> D [27/Mar/2011:10:06:19 +0900] cupsdAcceptClient: 16 from localhost:631 (IPv6)
> D [27/Mar/2011:10:06:19 +0900] cupsdReadClient: 16 POST /admin/ HTTP/1.1
> D [27/Mar/2011:10:06:19 +0900] cupsdAuthorize: No authentication data provided.
> D [27/Mar/2011:10:06:19 +0900] cupsdReadClient: 16 1.1 Purge-Jobs 1
> D [27/Mar/2011:10:06:19 +0900] Purge-Jobs ipp://localhost/printers/LBP3300
> D [27/Mar/2011:10:06:19 +0900] cupsdIsAuthorized: requesting-user-name="root"
> D [27/Mar/2011:10:06:19 +0900] Discarding unused job-completed event...
> I [27/Mar/2011:10:06:19 +0900] [Job 1] Job purged by user.
root なのは cupsd 配下のコマンドが root 権限で起動されるからですかね。
だから、これは問題ないと思います。
で、cupsdAuthorize で No authentification data provided. といわれてます。
2回呼ばれてるのは、見る限りだと IPv4 と IPv6 両方を確認してるんでしょうね。
でもソースを見る限りだと、別に認証情報がなくてもスルーしてるように見えるん
ですよねぇ～～。
その後 cupsdReadClient は IPP で Purge-Job イベントを投げてるんですね。
だから Job がエラーもなく捨てられるのはあたりまえ。だって要求してるのは
こちら (CUPS scheduler 側) なのだから……。
そいで頑張って CUPS のソース追ってたんですが、これがむちゃんこ汚くて、
ちょっと挫折しました。
ということで Canon さんのドライバソース取ってきてこれを眺めてます。
多分詰まってるのは CAPT バックエンドなので
cndrvcups-capt-2.20/backend/ccp.c かなと。
つか、このソースそんなに長くないので、関数のエントリポイントにデバッグ
メッセージ埋め込んでコンパイルしてみたら、なんかわかるかも。
手元に openSUSE 環境があるんであれば、やってみるんですが……。
> なにはともあれ、Jobは１、２、３、…って行っているし、リモートへの接続にも行こうとしているので
> そこまでは正常とCUPSは認識しているんじゃないかな？
私もそう思います。
ジョブ生成までは多分問題なく終わっていて、バックエンドに問題があると。
だから CAPT バックエンドを捨てて Port9100 で印刷してみては？ ということを
先に書きましたです。
でんすけ
でんすけです。
> しかしこちらは localhost のプリントキューの問い合わせのようなので、
> 今回の不具合とは関係ないのかなと思います。
>
ええと、ちょっとキューの作りが解っていないので可能性として書いていますので想定としては
こんな感じをイメージしています。
【なんかのアプリ】
↓ <実はローカルループバック>
【ローカルのスプール】
↓ <定義によってリモートのハードウェア>
【どっかのリモートプリンタ】
結局の所、最初のレンダリングをした後のキューを何処に置くのかといった事や、どのような手順で
転送するのかは別次元の話なので、レンダリング・スプールは自分の所で行い、でもデバイス（プリンタ)
はリモートにあって…とかいう定義はできるのかな？と思っていました。
その辺の整理が大事なのかな？と思い、まとまっていないのであればまとめる事が近道なのかなと
いうのが前の発言の趣旨です。
> root なのは cupsd 配下のコマンドが root 権限で起動されるからですかね。
> だから、これは問題ないと思います。
>
それは辺ですよね。
rootで実行されても、受け取りを誰から許可するのかは別だと思いますよ。
さらに、認証をホスト外部からrootでも許可を受けるというのは、SE-Linuxでも使わない限り
最悪の状態ではroot奪取を考慮した動きを想定していないとしか思えません。
少なくても cupsユーザの cupsグループ程度にはしておくのが良いのではないかと思います。
それはそうとして…
> で、cupsdAuthorize で No authentification data provided. といわれてます。
> 2回呼ばれてるのは、見る限りだと IPv4 と IPv6 両方を確認してるんでしょうね。
> でもソースを見る限りだと、別に認証情報がなくてもスルーしてるように見えるん
> ですよねぇ～～。
多分そうなのかな？とも思います。「No authentification,,,」が正しいと仮定して、v4でもv6でもダメを
検出していて、宛先として排出先が無い状態なのにJobエラーになっているのに正常にキューから排出
しようとしているように見え、最終的に宛先に出せないので最後のクローズ処理であるパージが行われて
いるように思えるのです。
つまり、エラーになっても正常動作になって処理を続行しているように見える部分が変の根源であるように
思えます。
普通、通信エラーなんだからデータをパージするんではなくて異常回復動作(促進）を施す動きへシフト
するのが標準的な物の考え方だと思いますけど。
> その後 cupsdReadClient は IPP で Purge-Job イベントを投げてるんですね。
> だから Job がエラーもなく捨てられるのはあたりまえ。だって要求してるのは
> こちら (CUPS scheduler 側) なのだから……。
>
ということで、IPPが宛先との調停がNoであるにも関わらず、なぜデータを送信し始めたとかのログを
残さずにパージに行くのかが本質のように見えます。
スケジューラは何処かでエラーが返されない限り「正常だ！」と思うだろうから、普通にパージするだろう
けど、ならばなぜ「異常」を見つけられないのだろう。
その辺が不思議でならない。
> そいで頑張って CUPS のソース追ってたんですが、これがむちゃんこ汚くて、
> ちょっと挫折しました。
>
> ということで Canon さんのドライバソース取ってきてこれを眺めてます。
> 多分詰まってるのは CAPT バックエンドなので
> cndrvcups-capt-2.20/backend/ccp.c かなと。
> つか、このソースそんなに長くないので、関数のエントリポイントにデバッグ
> メッセージ埋め込んでコンパイルしてみたら、なんかわかるかも。
> 手元に openSUSE 環境があるんであれば、やってみるんですが……。
>
ccp.c の方が遙かに怪しいと思います。
ちょっと時間がとれないのでソースは読む時間が取れませんが限りなく気になる存在です。＞ ccp.c
ではでは。
Naruhiko Ogasawara
でんさん、コメントありがとうございます。
> 【なんかのアプリ】
> ↓ <実はローカルループバック>
> 【ローカルのスプール】
> ↓ <定義によってリモートのハードウェア>
> 【どっかのリモートプリンタ】
>
> 結局の所、最初のレンダリングをした後のキューを何処に置くのかといった事や、どのような手順で
> 転送するのかは別次元の話なので、レンダリング・スプールは自分の所で行い、でもデバイス（プリンタ)
> はリモートにあって…とかいう定義はできるのかな？と思っていました。
しています (リモートプリンタ、の定義が不明瞭ですが、ここでは lpr や IPP などのレベ
ルの高いプロトコルを使っている場合、とします。USB などで物理的に直結されている
場合、)。
しかしはとちゃんの問題だと、ローカルホストで動いている cupsd (cups scheduler) に
投げ込んで、capt バックエンド経由でネットワーク越しにあるプリンタに印刷していると
いうシナリオ……でしたよね？＞はとちゃん
> rootで実行されても、受け取りを誰から許可するのかは別だと思いますよ。
いやもちろん、リモートホストからの印刷であれば認証は必要です。
けど、cupsd が自身のバックエンドに投げるときには、認証は特に必要ないはずです。
チラ見しかしてないのですが、認証チェックをやるコードはリモートホストかローカルか
で処理を分岐しているみたいです。
で、ソースをちらっと眺めたところによると、CUPS ってもともとは「IPP をサポートする
印刷システム」として作られた関係上、内部的には IPP 以外のバックエンドも IPP の
エラーを模倣しているように読めます……が、なにせネットブックで読むにはあまりにも
しんどいソースなので間違いかもです。
とゆことで、本来は認証が不要なケースでも IPP 認証をダミーで取りにいくのかな？
と思ってます。
# 頼むからもっと関数を分割してくれ、Michael＞＜；
> つまり、エラーになっても正常動作になって処理を続行しているように見える部分が変の根源であるように
> 思えます。
>
> 普通、通信エラーなんだからデータをパージするんではなくて異常回復動作(促進）を施す動きへシフト
> するのが標準的な物の考え方だと思いますけど。
に投げても「他のバックエンドだと正常なんだし、ドライバベンダーに聞けば？」と言わ
れて終りになるんですよね、大抵のケースでは。
だから、その方向での検証は、ちょっと意味が乏しいかなぁと思ってます。
> ccp.c の方が遙かに怪しいと思います。
> ちょっと時間がとれないのでソースは読む時間が取れませんが限りなく気になる存在です。＞ ccp.c
とりあえずソースパッチだけは時間が取れたら作りますか。
ビルドは環境を持ってるはとちゃんにお任せするとして。
ではでは。
kentaro hatori
実はこの週末に、でんすけさんに教えていただいたソースからのライブラリの
ビルドもしてみました。結果的には同じでした。
で、全部のビルドをしてみようと、必要なパッケージをダウンロードしてやって
みたところ、commonは成功したのですが、captが失敗します。
原因は、statusuiのconfigureがうまくいっていないところで、次のようなエラー
が表示されます。
./configure: line 11819: syntax error near unexpected token `1.2.0,'
./configure: line 11819: `AM_PATH_GTK(1.2.0, ,'
openSUSE11.4には、/usr/share/aclocalにgtk.m4はなくて、AM_PATH_GTK
に関する記述はないですが、gtk-2.0.m4には、AM_PATH_GTK_2_0という
ものはありました。でも、シンタックスエラーですから、AM_PATH_GTKはどこかで
認識はしていて、パラメータの記述が間違っているということですよね。
AM_PATH_GTK_2_0にしてみても、ダメでした。
また、cupsのログに次のようなものがありました。
E [27/Mar/2011:12:39:08 +0900] [Job 4] ccp recv_packet error, exit
E [27/Mar/2011:12:39:08 +0900] [Job 4] ccp send_data error, exit
これがどこで表示されているのかを見てみると、次のソースあたりかなぁ
と思うのですが、これが僕の限界です。
grep -r "recv_packet error, exit" *
backend/ccp.c: fprintf(g_log_fp, "ERROR: %s recv_packet error, exit\n",
grep -r "send_data error, exit" *backend/ccp.c: fprintf(g_log_fp,
"ERROR: ccp: send_data error, exit\n");
backend/ccp.c: fprintf(g_log_fp, "ERROR: %s send_data error, exit\n",
これもcaptのソースです。
バックエンドが怪しいというのは、当たりのような気がします。
2011年3月28日10:06 Naruhiko Ogasawara <nar...@gmail.com>:
> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> フリーデスクトップ印刷友の会
> free-desktop...@googlegroups.com
> http://groups.google.com/group/free-desktop-printing-ja?hl=ja
>
Naruhiko Ogasawara
> で、全部のビルドをしてみようと、必要なパッケージをダウンロードしてやって
> みたところ、commonは成功したのですが、captが失敗します。
> E [27/Mar/2011:12:39:08 +0900] [Job 4] ccp recv_packet error, exit
> E [27/Mar/2011:12:39:08 +0900] [Job 4] ccp send_data error, exit
capt のソースは個人マシンにあるので、あとで眺めてみます。
> grep -r "recv_packet error, exit" *
> backend/ccp.c: fprintf(g_log_fp, "ERROR: %s recv_packet error, exit\n",
>
> grep -r "send_data error, exit" *backend/ccp.c: fprintf(g_log_fp,
> "ERROR: ccp: send_data error, exit\n");
> backend/ccp.c: fprintf(g_log_fp, "ERROR: %s send_data error, exit\n",
となると、どうしても capt バックエンドが必要なの？ という質問になるんですが。
というのも、capt バックエンドって多分 statusui 向けに通信する部分があるだけ
だと思うので、Port 9100 (socket://<プリンタのN/Wアドレス>:9100) でも印刷に
は支障がないと勝手に想像してるんですが、どうなんでしょうか？
試して見られました？
手元に環境がないのでどうにも UI の説明がしにくいですが、はとちゃんなら
「プリントキューのデバイス URI を上のように変更する」で分かっていただける
かな？
capt のエラーについては時間が取れたらもうちょっと追って見ます。
[以上]
kentaro hatori
えーエラーですが、デバッグモードにしたcupsd.confを元に戻して
再起動したら表示されました。デバッグモードにしたときは、全然
表示されなかったんです。何でなんだろう...。
で、バックエンドなんですが、具体的にどうやるのかが分からなくて
現在に至っています。これまでのインストールは、Canonから
ダウンロードして、ドキュメントにあるとおりのインストールを
しただけという、まったくユルい状態で申し訳ありません。
ひょっとしてLBP-3300に接続しているプリンタサーバNB-C2とかが
原因とか思って、そのファームウェアが古いからかなぁと閃いた
のですが、バージョンは1.5と最新のものでした。
2011年3月29日9:30 Naruhiko Ogasawara <nar...@gmail.com>:
Naruhiko Ogasawara
> はとちゃん＠小江戸らぐです。
どもです。
> えーエラーですが、デバッグモードにしたcupsd.confを元に戻して
> 再起動したら表示されました。デバッグモードにしたときは、全然
> 表示されなかったんです。何でなんだろう...。
？？なんじゃそりゃ。
なんか根本的にヘンですなそりゃ……。
> で、バックエンドなんですが、具体的にどうやるのかが分からなくて
> 現在に至っています。これまでのインストールは、Canonから
> ダウンロードして、ドキュメントにあるとおりのインストールを
> しただけという、まったくユルい状態で申し訳ありません。
ありゃま。それは失礼。
じゃあ、ちゃんと説明しないとですねぇ。
ところで根本的なことを聞いてなかったですが、接続形態はローカル？
ネットワーク？ ネットワークだとばかり思ってたので確認してなか
ったんですが、LBP3300 って NIC オプションなんすね……。
ので無駄骨になるかもしれませんが、まぁ一般的な知識でもありますし、
ネットワークである場合を想定してバックエンドの変更法を書いておき
ます。
事前に、/etc/cups/printers.conf をバックアップしておきましょう。
まずは Web ブラウザを起動して http://localhost:631 を開けまして、
「プリンター」タブを押下、リストされてるプリンターのなかから
今回問題になってる LBP3300 (かな？) の「キュー名」のリンクをクリ
ック。
するとプリンター名と状態のすぐ下にプルダウンメニューが二つあるの
で、「管理」の方から「プリンターの変更」を選択。
ここで認証ダイアログが開くので、ユーザ名 root でパスワードは root
のパスワードを入れると、「LBP3300の変更」という画面が出て、ラジオ
ボタンが一杯でた画面になると思います。
そこで「その他のネットワークプリンター」の中から「AppSocket/HP
JetDirect」という奴を選んで「続ける」をクリック。
次の画面に「接続：」というテキストフィールドがあるはずなので、
そこに：
socket://<プリンタのネットワークアドレス>:9100
とタイプして、「続ける」を押します。
あとは「続ける」を連打しつづけて、最後「LBP3300の追加」という
画面で、一番下にある「プリンターの変更」ボタンを押下すれば完了
です。
これで、JetDirect という一番原始的なプロトコル(?)が使えるよう
になりました。
なお JetDirect というのはポート 9100 番に UDP でデータを馬鹿投
げするというもので、HP が最初に出した JetSend (だったかな？)
というプリンターネットワークコントローラで実装されたものです。
まぁ作る側も楽だしいろいろ便利なんで、あっちゅーまに業界標準に
なりましたとさ。
データさえちゃんとできていれば、これで印刷できないってのは、ち
ょっと考えにくいです。
でんすけ
> ？？なんじゃそりゃ。
> なんか根本的にヘンですなそりゃ……。
>
backend/ccp.c を見てみました。でないと議論がすすまないでしょうから。
でもって思ったのが ofd というディスクプリタ関連の実ファイルに関しては
変極まりっているって感じですねぇ。 小笠原君もみてくれませんか？
1. connection しようとするんですけど、定形処理の関数の中では
ファイル名称がNULLポインタか、文字列かで既定の物とそうで
無いものを切り分けるが、基本的に固定で既定の文字列である
”localhost" しか渡していない。だから宛先は自分安殿のみになる。
２. 自ホストでは対応するポートが開設されていないので、コネクション
タイムアウトになるのが必定なんでは。 でもってキャンセル指示が
出るとエラーメッセージを表示したいが現状では表示しなくなる。
正しく表示できる時のエラーメッセージはperror() あたりで行う様で
すが、判断ミスで経路が成り立っていなさそうという訳。
うまく行けば標準エラー出力（２＞って奴)に出るのだとおもふ。
それから、ccp.cではofdを初期化する部分が２つあります。
一つはmain() です。でもこれはコメントアウトしてあります。
もう一つは connect_sock() で、ここでオープンするソケットの宛先が該当
するプリンタの port 9100 (JetDirectプロトコル) なり、ippサーバに向いて
いないといけないのではないでしょうか？ captに対応した宛先って意味です。
それとJetDirectプロトコルとCAPTは違うようです。
CAPTは、転送をブロック単位で見ていて頭に８バイトのヘッダがあり、この
うちの後ろ４バイトがデータの長さになるようです。JetDirectは単純にデータ
の垂れ流しなので長さとかブロック管理とか、恰好の付く事は何もありません。
だからデータの作り方とか、転送方法とかにも注意した方が良いでしょう。
＃落ち着いて ccp.c を読めば、そんな事が解ります。
このあたりが、真実だとするとリモートへの出力は多分永遠にダメ
っぽそうなんだけど。 本当に印刷できているのかな＞CAPTバックエンド
Naruhiko Ogasawara
> でんすけです。
どもです。
引用順前後しちゃいますが。
> それとJetDirectプロトコルとCAPTは違うようです。
私もちょっと混用していたので交通整理します。
ちょっと長くなりますがご容赦。
前提ですが。
多くのプリンタというのは一般の周辺機器と異なり、ハードウェアを
ホストコンピュータから「ドライブ」されるわけではありません。
なんらかの通信手段 (IEEE 1284(俗にいうセントロ)、USB、N/W)
などで描画やプリンタ自身の周辺機器 (給排紙トレイや両面、ステ
ープルやパンチ) などを支持するデータを流し込まれて、プリンタは
それを解釈して印刷したりなんだりするわけです。
この印刷データのことをPDL (Page Description Language) と呼
んだりするわけです。
で、データ (PDL) を作る人がいわゆるプリンタドライバ。
データを流す人が、Windowsではポートモニタとか言われる人なの
ですが、CUPSだとバックエンドといいます。
大抵のネットワーク接続プリンタの場合、Port 9100 や lpr や IPP
や SMB といった既存のプロトコル (Port 9100 は「プロトコル」と
呼ぶほどのもんじゃないですが) を使うので、それらについては、
システム側で標準のポートモニタ／バックエンドが用意されてます。
# ということで、ぼくのようなプリンタドライバ屋さんは、通信周りの
# ことをほとんど意識しません。つか、ぶっちゃけ知りません(苦笑)
さて CAPT というのは、このスレッドの頭のほうで説明されていた
ように、印刷アーキテクチャの名称であるとともに、PDL (というには
相当レベルの低い、解釈が簡単なデータフォーマット) の名称でも
あるようです。
ので CAPT という「通信プロトコル」があるわけではなくて、Linux
版の CAPT ドライバモジュールに一緒に入っている専用バックエン
ドのことを、私は「CAPT バックエンド」と呼んでました。
で、CAPT バックエンドが実際にどの通信プロトコルをサポートして
いるのかは私は知らないのですが、CAPT 印刷アーキテクチャ自体
はプロトコルの縛りをうけないのではないかと推察しています。
というのは、Windows 版の CAPT ドライバにはネットワーク用の
専用ポートモニタが存在せず、Windows の標準 TCP/IP ポートを
利用しているからです (インストーラで入れたわけではなくて、ドラ
イバの構成とインストール手順書を読んだだけの判断ですが)。
ではなぜ CAPT バックエンドなるものを Linux 版では用意している
かというと、これは多分ステータスモニター用なんではないか、と
想像する次第です。単なる印刷では必要ないはずの「プリンタから
の値の読み込み」を行っているのがその薄弱な証拠です。
CAPT のパッケージにも StatusMonitor とかなんとかってモジュー
ルありますしね。
ので、CAPT 独自の転送プロトコルというのが仮にあったとしても、
それは使わないで、Port 9100 (JetDirect) で印刷できるんじゃない？
それで試してみては？ というのが、ぼくの提案でした。
さておき、本題は実のところあまりコメントすることはありません。
> backend/ccp.c を見てみました。でないと議論がすすまないでしょうから。
ソースを読まないと「議論がすすまない」とは思いません。
もし ccp を使わないでも印刷できればそれに越したことはないし、
仮に我々がバグを見つけても、それを報告して commit されるかは
実のところ分からないわけですから。
とはいえ、一応技術者っぽい人なので、興味はありますから、ぼくなり
にソースじゃない方から調べてみました。
# うーん、やっぱり各社の実機が欲しいのぅ……。
# オープンな周辺機器ドライバ開発にはオープンなテストラボとかが、
# やはり必須な気がするでありますよ。
まぁさくっとググっただけなんですけど、
http://nabe.blog.abk.nu/CanonCAPT_on_Ubuntu
ここらへんを見ると、
・ccp というバックエンドは ccpd という localhost で動作するデーモンに
処理を投げるだけ
・実際に機器と通信を行っているのは ccpd デーモン
ということですわ。なんてこったい＞＜；
ちゃんとマニュアル見てれば、気づいたはずなのに……ごめんなさい。
つことで、
「もしかして ccpd がちゃんと動いてなくね？」
「動いてるとしたら、一部だけ詰まってたりしてね？」
ということに疑問は変わる……のかな？
とゆことではとちゃんにお願いです。
0. そもそも接続形態はネットか USB か教えてください。USB なら
1. は省略してください。
1. さきに示した手順で、CAPT バックエンドでなく、port 9100 を使う
ようにして、印刷できるか試してもらえますか？
それで問題解決なら、それはそれでいいです。
2. もしダメなら、設定を元に戻して (printers.conf を戻せばいいです)、
ccpd デーモンが正しく起きてるか、CPUを100%占有したりしてない
か、確認していただけませんか？
3. ccpd も起きてるし CPU を食いつぶしてるわけでもなければ……
ccpd のソース頑張って読むしかないかぁ。
Naruhiko Ogasawara
別に進展があった訳じゃないんですが、openSUSE 11.4 の環境が
やっと手元でも動くようになったので（ベアメタルじゃないけど）
解析進められそうです、という中間報告。
Naruhiko Ogasawara
盛り上がらないとかいっておきながら人の問題放置してちゃダメですよねー。
んでこの件ですが、CUPS.BUGS に似たような問題がありました。
http://www.cups.org/str.php?L3916
Michael は CUPS のせいじゃないって突っぱねてますけど、いろんな
ディストロ、いろんなドライバーで報告が出てるので、どこかに非互換が出て
いるのは間違いなさそうです。
でもはとちゃんのはデータは生成されていて（？）バックエンドでコケてる
っぽいんですよね。ちょっと違うかも。
まあ、一応忘れたわけじゃありませんよ、という表明でした。
--
Naruhiko Ogasawara (nar...@gmail.com)
Kentaro Hatori
見捨てられなくてよかったです。
いまは、windowsとubuntuで印刷を代用しています。
同じlinux系でできるところとできないところがあるというのが
納得できないのですが、細かなところで各ディストロが弄っていると
いうことなんですね。ubuntuはデスクトップとしての気概が感じられます。