31-Jul-2024
[lpd-modokiの実験]

lpd-modoki、lpdが動いているフリをするプログラムである以上は超漢字以外のOSから飛んできたジョブを受け付けることもできるはずですよね。という訳で試してみました。

Linux機(emeraude)で動いているCUPSのweb console(http://CUPSが動いているマシンのIPアドレス:631)から、管理→プリンターの追加を選択し、

その他のネットワークプリンター
LPD/LPRホストまたはプリンター
接続
lpd://lpd-modokiの動いているIPアドレス/キュー名(任意)
名前と説明と場所
適切なものを設定(名前はlp -d <名前で設定した文字列>となるので記述しやすいものがお勧め)、共有はoffで問題無し
使用するプリンタのメーカーとモデル
HP DeskJet 955C, CUPS+Gutenprint(hpcupsだとうまく動きません)

というプリンタを追加します。あとはOpenBSD機(framboise)でlpd-modokiを動かして印刷イメージを受信したものPDF化したものを置いておきます。PDFプリンタの機能はCUPSが持っている以上他のマシンにPCLなイメージを投げてGhostPCLでPDF化する理由は一切無いんですけど…とりあえずCUPSもlpd-modokiも文句を言わずに動いているようなので、きちんとlpdが動いているフリをすることができていると判断します

ちょっとよく分からないのが、/etc/printcap(実体は/run/cups/printcapにある)の中身。test@framboise|lpd-modoki test:rm=emeraude:rp=test@framboise:…/etc/cups/printers.confを参照することが前提となっている記述という気がします。56.7kg(22:55)

27-Jul-2024
[こんなことやってる場合じゃないんですけど]

欲しいもんは欲しい、ということでlpdもどきなるコードを書いてみました。README.mdの使用例にあるように、lpd-modoki -a 192.168.0.1 | gpcl6 -dNOPAUSE -sDEVICE=pdfimage24 -sOutputFile=output.pdf -で超漢字から送られてきたPCLな印刷イメージをGhostPCLでPDF化できます。well-known portを使うのでrootでないと実行できないという問題はありますけどね。

超漢字と組み合わせて使うことを前提にしているので、印刷ジョブが終了したらはいおわりという作りになっています(なので本来は不要だと思うのですが、超漢字側からのセッション終了を待つような処理が入っています…実際、これが無いと動作が怪しいです)。印刷を何度も繰り返す場合はシェルスクリプトなどを併用して対応してください。

あともう一つ。14-Jul-2024のtcpdumpのログには妙な点があります。control fileは81byteと主張しているのに対し、実際はcontrol fileの終端である0x0aの後に0x00が付加されて、82byte送られてきているのです。正しい(?)対策方法は各種lpdのコードを見るべきなのでしょうが、command/subcommandに0x00が来た場合は無視するというお手軽な方法で回避しています。

とりあえず動く物は手に入ったので、後は使いながら必要に応じて改良するとしましょう。56.6kg(23:15)

22-Jul-2024
[えー…]

21-Apr-2024以来のJMH(船舶向け天気図)の受信(21-Jul-2024)。前回よりもさらに画質が悪いんですけど…

tjmh-202407210229.jpg

13988.5kHzで受信していますが、受信する前に7795kHzを聞いてみても同様(信号強度がイマイチ)な感じでした。1〜2時間くらい前だったらもう少し綺麗に受信できていたので、地球のご機嫌と理解しています。いつかまた、綺麗に受信できる日が来ると良いんですけどねえ…55.3kg(23:35)

21-Jul-2024
[1B/V3を仮想マシンで動かしてみようとしているんだけど]

1B/V3起動用のFDDイメージがbochsでなければ動かないようなので、インストール時だけbochsを使うという手順を踏まないと駄目そうな感じです。インストール済みのHDDイメージさえできてしまえばとりあえずqemu-system-i386(8.2.1, OpenBSD-7.5/amd64)では動くみたいなんですけどね。という訳でまずはbochsでのインストールから。

・HDDイメージの作成

面倒なのでqemu-img create -f vmdk 1bv3.vmdk 1g。bximageを使うなら、1. Create new floppy or hard disk image→hd→vmware4→1024→1bv3.vmdk。

ファイル名とディスクのサイズはお好みで、ただし1B形式の区画は約1GBが上限なので多くても意味ないです。VMware形式にしているのは、CHS情報を持っているのでbochsの設定が楽というただそれだけの理由。

・bochsの設定

1. Restore factory default configuration→3. Edit options→12. Disk & Boot optionsから、

として、Main Menuへ戻ったら念のため設定内容を4. Save options to...→1bv3.cfgで保存。あとは6. Begin simulationで仮想マシンを起動。

・インストール

※bochsでは、ゲストOS側でマウスを使用する場合はbochsのマウスアイコンをクリック、ホストOS側に戻す場合はCtrl-マウス中ボタンという操作を使用します※

マウスをゲストOS(1B)側に切り替え、右クリック→小物→ハードディスク登録でハードディスク登録小物を起動し、あとは画面の指示に従うだけですが…FDDイメージの切り替えは以下の手順を

  1. マウスをホストOS側に切り替える
  2. bochsのFDDアイコン(A)をクリックして×を付ける
  3. bochsのCONFIGアイコンをクリックしてBochs Runtime Optionsに切り替える
  4. 1. Floppy disk 0: (FDDイメージに関する情報)→フロッピーFDDイメージのファイル名→1.44M(デフォルト)→yes(ライトプロテクトの設定)→inserted
  5. 9. Continue simulation

インストールに必要とするFDDイメージの数だけ繰り返す必要があります。修行か?と思うくらい面倒なので覚悟してください…Windows3.1をインストールするよりかは楽だと思いますが。

インストール処理の完了後、マウスをゲストOS側に切り替えて、「本体の電源スイッチを切ってください。または再起動を選んでください。」のメッセージが表示されるところまで進めたらbochsのPowerアイコンを押してbochsの動作を終了させます。再度インストールするのも手間ですので、ここで一旦ディスクイメージのコピーを取っておくと良いかもしれません。

あとは、qemu-system-i386 -rtc base=localtime -hda 1bv3.vmdkでこんな感じ。

20240721a.png

なお、qemu-system-i386における解像度800×600の設定は[6A]のみ使用可能です(他の設定では表示できないので、P2V/V2V等の際は注意してください)。VirtualBoxでの動作も簡単に調べてみたものの、動かないようです。qemu-system-i386(9.0.0, Windows11/64bit)で-accel whpxを指定すると


PS C:\Users\uaa\Desktop> & 'C:\Program Files\qemu\qemu-system-i386.exe' -accel whpx -rtc base=localtime -hda 1bv3.vmdk
WHPX: setting APIC emulation mode in the hypervisor
Windows Hypervisor Platform accelerator is operational
whpx: injection failed, MSI (0, 0) delivery: 0, dest_mode: 0, trigger mode: 0, vector: 0, lost (c0350005)

(qemu:11836): Gtk-WARNING **: 19:55:06.065: Could not load a pixbuf from icon theme.
This may indicate that pixbuf loaders or the mime database could not be found.
qemu: WHPX: Unexpected VP exit code 6
PS C:\Users\uaa\Desktop>
     

「・・・1Bにようこそ・・・」が表示されてしばらくした後にUnexpected VP exit code 6が表示されてqemuが落ちるので、Hyper-V絡みではないかという気はします。55.8kg(03:50)

14-Jul-2024
[イマドキのLinuxは]

CUPSが標準なので、昔ながらのlpdを使いたいという場合はかなり苦労するようです。とりあえずDebianの場合、Enable CUPS-LPD on Server 16.04 LTSにあるように/lib/systemd/systemにcups-lpd.socketcups-lpd@.serviceを配置して、systemctl start cups-lpd.socket; systemctl enable cups-lpd.socketとすれば一応lpd互換のサーバは立ち上がります。ただし、これに加えてsystem-config-printerで

この二つにチェックを入れておく必要があります。

実際にプリンタへデータ送信するのもアレだなーということでcups-pdfによるPDF printerを用意し、これに対するデータ送信を行ったログをtcpdumpで取ってみました。スプールのディレクトリにはデータが来ているものの(拡張子は適当に付加しています)、流石にPDF化まではしてくれないようです。印刷出力データが保存される実身とスプーラ内のファイルのMD5は一致していましたので、スプーラまでは正しくデータが届いていると考えて良さそうです。

Line Printer Daemon Protocol (RFC1179)を見ながらログを追うと、こうでしょうか?(→はlpdへの送信、←はlpdからの受信を意味します)

  1. →(5byte) 02 50 44 46 0a
    (Receive a printer job, "PDF")
  2. ←(1byte) 00
  3. →(26byte) 02 38 31 20 63 66 41 30 30 32 5f 5f 5f 30 2e 75 61 61 2e 6f 72 67 2e 75 6b 0a
    (sub command:Receive control file, 81bytes, "cfA002___0.uaa.org.uk")
  4. ←(1byte) 00
  5. →(82byte) 48 5f 5f 5f 30 2e 75 61 61 2e 6f 72 67 2e 75 6b 0a 50 6e 6f 62 6f 64 79 0a 6c 64 66 41 30 30 32 5f 5f 5f 30 2e 75 61 61 2e 6f 72 67 2e 75 6b 0a 55 64 66 41 30 30 32 5f 5f 5f 30 2e 75 61 61 2e 6f 72 67 2e 75 6b 0a 4e 6e 65 74 70 72 69 6e 74 0a 00
    (Host name "___0.uaa.org.uk", User identification "nobody", Print file leaving control characters "dfA002___0.uaa.org.uk", Unlink data file "dfA002___0.uaa.org.uk", Name of source file "netprint")
  6. ←(1byte) 00
  7. →(29byte) 03 35 39 32 35 38 20 64 66 41 30 30 32 5f 5f 5f 30 2e 75 61 61 2e 6f 72 67 2e 75 6b 0a
    (sub command:Receive data file, 59258 bytes, "dfA002___0.uaa.org.uk")
  8. ←(1byte) 00
  9. →(1byte) 1b
    (1st byte of print data)
  10. →...
    (2nd byte〜last byte)
  11. ←(1byte) 00

control fileのサイズが81byteとなっているのに対して、付随するペイロードのサイズが82byteとなっている点がよく分からないのですが、LF(0x0a)まで読み飛ばすようにすれば良いのでしょうか。なんとなく、この辺まで分かればそれっぽい物が作れそうな気がしているのですが(気のせいかも?)、お仕事が忙しいので一旦ここで置いておきます。56.3kg(21:55)

27-Jul-2024補足:cups-lpdの用意しない印刷キュー宛にジョブを投げた場合にどうなるかというログも取ってみました。command 02(Receive a printer job)に対してはNAK(0x01)を返し、エラー終了となっていますね…

11-Aug-2024補足:超漢字の設定をLPDPではなくLPDP(簡易)とした場合のログも取ってみました。control fileを投げず、細切れにしたdata fileを多数投げるような動作になっているのですが…RFC1179的にこの動作ってアリなんだろうかという疑問を感じます。

07-Jul-2024
[超漢字で作成したものを]

TADviewを使ってPDF化していたのですが、なんかTADviewが使えなくなってしまったようなのでどうにかしないといけません。

簡単に試してみたところ、HP DeskJet 955C向けの印刷データを実身に書き出し、これをGhostPCLで処理するとPDF化できるようです。04-Sep-2010の路線図らしきものをWindows版のGhostPCLを用い、.\gpcl6win64.exe -dNOPAUSE -sDEVICE=pdfimage24 -sOutputFile="output.pdf" input.pclで変換してみました(-sOutputFileで指定するファイル名は""で括る必要があり、モノクロならpdfimage24の代わりにpdfimage8とすると良いでしょう)。プリンタへ送信するイメージ(画像)データをPDF化することになるので、文字列検索が効かないという問題がありますがこれについては諦めてください。

超漢字側の印刷品質を通常/高速/高密度と変えてみましたが、通常と高速の違いはあまりよく分かりません。なんとなくですが、高密度一択という気がします。また、印刷データの含まれる実身を仮想マシンから実マシンに移すのが結構面倒なので、lpdへ飛んできたデータをファイルに保存するようなツールが欲しくなります。どこかにありそうな気がしますけど…それともlpdの設定をいじってファイルに保存する方が早いでしょうか?(可能なのか??)57.2kg(05:25)