BDXLドライブを購入。
今までジャンクのスリムBDドライブを BufferloのDVSM-PCS58U2の中身と交換して遣っていたけれど、DVDドライブとしてしか認識されず。……いや、ついこの間までBD-REなりを焼こうとしなかったので。
ごく最近録画をするようになったので、バックアップが必要になり、BD-REを買って試したらあれ？ となってしまったという。
……そういや、CD-RWがまだ大量にあるけど、どうしますかね？ まあ、CD-RとDVD-Rだったらまだ配布用途があるし、DVD-RWはデータやりとりでまだ需要がある。でもCD-RWはCD-Rで毎回焼くと無駄になるインストールメディア用くらいかなと……。
仕方ないので、BaffaloのBRXL-PT6U2V-BKDを購入。人によっては再生ソフト付きだろうけど、BSDとLinuxな上に外部ディスプレイはRGBとDVIだったりする。そもそもBDMV再生ならBDプレーヤーがあるし。一応、BDXL対応だけど、私の使用メディアは二層まで。
ということでxfburnとかK3Bで焼いてみたものの、手元のBDP-150ではUnknown disk扱い……何故？
32 bitアプリを入れていた
Debianは一度環境を整えてしまえば、後は非常に安定する。例えば、WindowMaker環境をUbuntuなどで構築・維持するというのは非常に苦労するわけで、あの手のディストリビューションはお仕着せの環境を遣うものだ、と思うべきだろう。ただ、DebianとかFreeBSDは環境を整えるまでが少々手間なわけで、何を遣いたいか明確な人以外にはお勧めできないものになってしまっている。
Debianにおいては、Ubuntuなどと違ってマルチメディア関係のソフトウェアに様々な制限がある。一番大きいのはライセンスや、取り込まれているバージョンが古いことなどがあげられる。そのためDebian Multimediaなどをaptのsource.listに入れたりすることが多い。
環境整えるまでの間のトラブルとしては、i386を入れてしまったとか、余計なドライバーが邪魔をしたとかがある。
つい先週この手のことにハマってしまったので、メモしておく。
症例1 tsMuxerGUIの場合
普通にDebian Multimediaからapt-getで導入した。
% tsMuxerGUI
tsMuxerGUI: error while loading shared libraries: libQtGui.so.4: cannot open shared object file: No such file or directory
ん？ libQtGuiが見つからない？ libqtgui4は入っているから、ライブラリのパスの問題と思い、通してみる。
% set LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu:$LD_LIBRARY_PATH
% tsMuxerGUI
tsMuxerGUI: error while loading shared libraries: libQtGui.so.4: wrong ELF class: ELFCLASS64
ELFのクラスが違う？ ……もしかしてamd64じゃない？ と調べると導入されていたのがi386版でamd64版がないという。そこで
# apt-get install libqtgui4:i386
% tsMuxerGUI
としたら時間がかかったものの、動作しましたとさ。
症例2 OpenGLの場合
Debian MultimediaからShotcutを導入して動かそうとしたところ、キャプチャーボードのドライバーないのと、OpenGLが有効にならない旨のメッセージが出て止まる。
キャプチャーボードについては最新のソフトウェアを導入して解決も、OpenGLについては、GLXがどうこうというメッセージ。
……AMD A8なのにnVIDIAのドライバーとかが入ってて悪さしてた。関係するパッケージをことごとく削除しましたとさ。
FSViewerのバッチ当て
WindowMaker環境でのファイルマネージャーはGNUstepとの親和性から、GWorkspaceが一般に用いられている。
従来はFSViewerが広く用いられてきたものの、現在のDebianのパッケージからは外されている。まあ、Debian Archive (https://mirrors.mediatemple.net/debian-archive/debian/pool/main/f/fsviewer/)から拾ってきて、インストールすればいいけれど、最終版の一つ前(0.2.5)だったりする。
ということで（？） ソースコードからビルドしてみる。
まずはSlackBuildsからfsviewer-app-0.2.6.tar.bz2とfsviewer.tar.gzを拾ってくる。 slackbuilds.org このうちfsviewer.tar.gzはSlackBuildのファイルだけれども、この中のtitlebar.diffとwingsfix.diffが重要で、前者はFSViewerでタイトルバーが表示されない問題を解決するためのパッチ。
こいつらを遣ってconfigureとmakeしてみる。
GTK3アプリでのスクロールバー問題
私の環境はWindowMaker+GNUstepである。要はNeXTライク。
となるとその他のアプリケーションでも似た外観にしたいというのが人情である。
まずはGTKということでテーマを探してみると、OneStepBackとGTK-GNUstepというテーマが見つけることができた。
しかし、GTK-GNUstepはGTK2用なので、まずはOneStepBackをつかってみることにした。
テーマの追加方法？ Debianの場合はこいつらを解凍して/usr/share/themesに、FreeBSDなら/usr/local/share/themesに置けば良い。
テーマの切り替えは設定ファイルを書き換える方法だと、
- GTK2は~/.gtkrc-2.0
- GTK3は~/.config/gtk-3.0/settings.ini
のgtk-theme-nameの行を編集すれば良い。GUIでやりたいのならlxappearanceを遣うと楽である。最終的にはGTK2はGTK-GNUstep、GTK3はOneStepBack、そしてアイコンテーマをGNUstep Iconにした。
……スクロールバーに反映されない。と思ったら、テーマのディレクトリーのアクセス権(OneStepBack/gtk-3.0)だった。しっかし動きが変なのも確かなので、いろいろいじってみる。
スクロールバーの移動を画面単位にする
NeXTだとスクロールバーの場所をクリックするとその場所に移動するので、私には違和感がないものの、Windowsとかに慣れている人は一画面単位のスクロールの方が使い勝手が良いらしい。この場合は~/.config/gtk-3.0/settings.iniの[Settings]の中に以下を追加する。
[Settings]
gtk-primary-button-warps-slider = false
GTK3のスクロールバーのオーバーレイ表示を止める
~/.profileに環境変数を設定する。
export GTK_OVERLAY_SCROLLING=0
~/.config/gtk-3.0/gtk.cssに次を追加する。
.undershoot.top, .undershoot.right, .undershoot.bottom, .undershoot.left { background-image: none; }
スクロールバーの矢印を表示する
矢印のあるテーマを使用していれば問題ない。標準で矢印がないテーマについては~/.config/gtk-3.0/gtk.cssに次を追加する。
.scrollbar {
-GtkScrollbar-has-backward-stepper: 1;
-GtkScrollbar-has-forward-stepper: 1;
}
GTK2だと~/.gtkrc-2.0に次のような感じになる。
GtkScrollbar ::has-backward-stepper=1
GtkScrollbar ::has-forward-stepper=1
GNUStepを日本語化する方法
私のUNIXはNeXT（正確に言えばOPENSTEP for Mach）が最初だった関係で、Workspaceの操作性に慣れていることから、UNIX系OSではWindowMaker+GNUStepという環境を構築している。
GNUStepの国際化はだいぶ進んできており、日本語フォントを指定すれば日本語を表示もできるし、XIM経由で入力もできる。
ただ、ロケールを日本にしても、リソースがないのでメニューやらメッセージが日本語にならない。私の知る限り、日本語のリソースが最初から用意されているのは、Jishyo.appくらいである。 （ちなみにOpenBSDだとリソースを用意しても、ロケールが切り替わらないという問題がある。全体的にOpenBSDの国際化はFreeBSDやNetBSD、Linuxに比べて劣っている。）
こうなると、自分でリソースを作成することになる。
GNUStepの用意している国際化方法はUNIX向けソフトウェアで広く用いられるgettextと異なり、次の三つの方法がある。
- Resource/Japanese.lproj/Localizable.stringsを作成する。
- Resource/Japanese.lproj/*.nibを作成する。
- Resource/Japanese.lproj/*.gormを作成する。
最初の二つはNeXTから引き継いだ方法で、最後のgormの書き換えはGNUstep特有の方法である。nibやgormの場合はIBやGORMで直接書き換えることになる。ただ、nibやgormにメッセージをべた書きするのは推奨されておらず、行儀が悪いプログラムとされる。そのため、一般にLocalizable.stringsだけでローカライズできるように設計することが求められる。
つい先日、GNUMail向けにLocalizabsle.stringsを作成した（http://savannah.nongnu.org/support/?109386）ので紹介する。
まず、ソースコードからLocalizabsle.stringsの元を作成する。ソースコード（*.m）があるディレクトリーにて、次のコマンドを実行する。
% make_strings -L English *.m
ここでできたLocalizabsle.stringsの書式は、
"Yes" = "Yes";
というように左に元のメッセージ、右にローカライズしたメッセージを書く形となっている。したがって、メッセージを日本語にするには、
"Yes" = "はい";
というように書き換えればよい。これをアプリケーションのResource/Japanese.lproj/の中に置けば、日本語化することができる。
PDFの煮るなり焼くなりのメモ
処理別でPDFの扱い方を備忘としてまとめてみた。対象はQPDFとかPDFTK、MuPDF-tools、Poppler-utils、Ghostscript、libtiff-toolsといったものが入っている環境か。シェル環境があると便利なので*BSD/LinuxやWindowsでもCygwin、MinGWといったものを入れていると良い。
暗号化解除
% qpdf --decrypt in.pdf out.pdf
暗号化解除といっても、読み込みパスワードがかかっていない場合は制限していないのと同じでこれだけで何でもできるようになる。
PDFバージョン変更
% qpdf --force-version=1.4 in.pdf out.pdf
フリーソフトにおいては、PDFバージョンが1.4（Acrobat 5）以前にしか対応していないものがある。強制的にバージョンを1.4にすることで読み込みができるようになることが多い。
結合
% pdftk in1.pdf in2.pdf output out.pdf
Javascript除去
簡単に挙げられる方法としては、三個。
- Javascriptが動くブラウザー上でJavascript版のPDFDesigner (http://www.petitmonte.com/pdfdesigner/)で読み書きする
- Windowsやwine上でPDFPDFPDF.comなどのPDFDesignerシリーズのソフト(http://papy.world.coocan.jp/)で読み書きする
- Windows上でiTextFrontで読み込み書き出す（MSJVMの関係でwine上では動かない）
もし、iTextに親しんでいるなら、スクリプトを書く方法もある。なお、PDFJavascriptRemoverというiText関係のソフトがあるものの、扱い方がわからず。
テキストの抽出
もしPDFがLibreOfficeとか各種DTPソフトで作成されたものであるとか、OCRがかかっていて透明化テキストがついているとかであれば、Poppler-utilsで抽出できる。OCRが必要な場合はここでは対象外。
% pdftotext -enc UTF-8 in.pdf
画像の抽出
一括して抽出する場合はMuPDFのツール利用が簡単である。
% mutool extract input.pdf
もう一つは、Poppler-toolsのpdfimagesで
% pdfimages -png in.pdf out // PNGで抽出する場合
% pdfimages -j in.pdf out // JPEGで抽出する場合
% pdfimages -tiff in.pdf out // TIFFで抽出する場合
で抽出できる。pdfimagesの標準はpbm形式なので、上記のように標準的な形式で抽出するか、ImageMagickで変換すると扱い易くなる。
画像のPDF化
ImageMagickとpdftkを併用する、マルチページTIFFを作成してPDFに変換するといった各種の方法がある。
元のデータが200 ppiの反転した白黒のpbmをImageMagickとpdftkで変換する場合はこんな感じ。
% mogrify -units PixelsPerInch -density 200x200 -negative -format pdf in*.pbm
% pdftk in1.pdf in2.pdf output out.pdf
ImageMagick自体はマルチページの画像PDFを扱うことができるので、
% convert -units PixelsPerInch -density 200x200 -negative -format pdf in*.pbm out.pdf
で変換することもできるが、恐ろしくメモリーを消費するので推奨しない。
元データがTIFF（昔スキャンしたヤツとか）でマルチページTIFF経由でPDFに変換する場合は、libtiff-toolsを入れて
% tiffcp in1.tif in2.tif tmp.tif
% tiff2pdf tmp.tif -o out.pdf
という具合で良い。なお、このケースだと圧縮をかけていないので、モノクロならtiffcpで-c g4や-c g3とか、カラーならtiff2pdfのところで-jオプションをつける。
フォントの抽出
PDFではフォントを埋め込んでいることがあり、MuPDFやFontForge、PDF FontDecorder (http://papy.world.coocan.jp/p5.html#s3)には抽出機能がある。
一括して抽出する場合は画像抽出の時と同じオプションで、画像もフォントも一緒にできる。
% mutool extract input.pdf
漢字の字書的データの在処
漢字の読みのデータを簡単にまとめてみた。まずはテキストデータとして入手できるものを記載。
Public domain相当なもの
Unihan database (http://www.unicode.org/Public/UCD/latest/ucd/Unihan.zip)
Unicode consortiumによるCJKV統合漢字のための基礎データで読みや字義、画数、部首、各国の文字コードとの対応表、大型辞書への索引、使用頻度、四角号碼、倉頡輸入法といった情報を含んでいる。
読みデータとしては、中国語後期中古音（唐代音、Tang）と中国語北方語（Mandarin）、粤語（Cantonese）、日本語（音訓別）、朝鮮語（Korean）、ベトナム語（Vietnamese）。ただし精度は低く日本語においては間違いが結構ある（日本語の間違いについてどなたかまとめていませんかね？）。
粤語においては、現在は粤拼（JyutPing、あるいはLSHK方式、香港語言学学会拼音方案とも）表記で、Unicode 4.0.1までは改Yale式表記、Unicode 4.1から5.1までがLSHKのPhrase Boxによる粤拼（フリーでなかった）、Unicode 5.2以降は粤拼でpublic domain相当となっている。
JIS X 0208:1997附属書6と7、11、JIS X 0213:2000附属書6と11
これらのJISは著作権保護の対象外。JIS X 0213:2000の附属書11の音訓索引については、JISX0213 InfoCenter (http://www.jca.apc.org/~earthian/aozora/0213.html)よりテキストデータを入手できる。SKKのJIS X 0213辞書の元データとなっている。
附属書6は用例を含んでおり、かなり有用なデータであるものの、テキスト化はされていない。
GPL, MITなど
漢字データベースプロジェクト (http://kanji-database.sourceforge.net/index.html?lang=ja)
説文解字注や宋本廣韻、學生字典といったデータが配布されている。
Creative Commons
MJ文字情報一覧表 (http://mojikiban.ipa.go.jp/1311.html)
情報処理推進機構(IPA)による文字情報基盤 文字情報一覧表のデータ。戸籍統一文字や住基統一文字といった、要は汎用電子コレクションに収録された文字の情報のデータベース。
独自ライセンス
KanjiDic2 (http://www.edrdg.org/kanjidic/kanjd2index.html)
Jim Breen氏を中心にまとめている非日本語話者のための日本語の漢字の字書。EDICT/JMDictが非日本語話者のための日本語辞書であるのに対応している。概ねCreative Commonsであるものの、一部著作権が留保されており、特にSKIPコードについてはnon-freeである。
Non-free
KO字源 (http://wagang.econ.hc.keio.ac.jp/zigen/)
電脳瓦崗寨で公開されているデータ。原文は著作権切れであるので素のテキストについてはpublic domainであるものの、XML化に伴う構造化情報はnon-free。
FreeBSDでのwifi設定
時間が開いてしまいました。
今まで有線運用だったFMV-Lifebook(FMV-R8290、FreeBSD/amd64 11.1)に180円のCardBusな無線LANカードを入れてました。こんなやつ。
FreeBSDからはathとして認識。
まずは/etc/rc.confから。
wlans_ath0="wlan0"
ifconfig_wlan0="mode 11a country J5 WPA DHCP"
ここでmode 11a country J5を入れているのは11a(2 GHz)での使用チャンネルの設定のため。
そしてアクセスポイントの切り替えにはwifimgrを遣うので、pkgかportsで入れる。接続先が一つとかコマンドで切り替えたいならwpa_supplicantとifconfigでできる。
もし、WPA−PSKのバスフレーズに引用符を用いている場合は、wpa_passphraseでSSIDだけ引数に入れて、パスフレーズをstdinから入力して雛形を作成する。
% wpa_passphrase SSID > wpa.txt
できたファイルの中のpskのところは16進表記なので、これをwifimgrのパスフレーズの欄に入力すれば接続できる。
マルチディスプレイ環境での液晶タブの調整
デスクトップのDebianをStretchに上げたら、Xの液晶タブの設定がおかしくなったという。原因は単純だったけど、設定方法を備忘のためメモ。
私の環境は同じ大きさのディスプレイをDVIポートとアナログVGAにそれぞれつないでいて、上下に並べてる。xrandr的には、こんな感じ。
% xrandr --output DVI-0 --below VGA-0
ここで、DVI-0はWacom DTU710（液晶タブレット）で、VGA-0はMITSUBISHI RDT173LM。液晶タブレットが下。ディスプレイの名前はOSやドライバーにより異なるので、引数なしでxrandrを実行して確認。
このような場合で、DTU710の画面とスタイラスの座標を合わせるのは、今はxinput。3×3の変換行列で座標系を割り当て。かつてはxorg.confとかhalで??-wacom.confをいじくっていました。
% xinput set-prop "Wacom DTU710 Pen stylus" --type=float "Coordinate Transformation Matrix" 1 0 0 0 0.5 0.5 0 0 1
ここで「Wacom DTU710 Pen stylus」はXに認識されているデバイス名（スタイラスとか消しゴムとか）。名前は引数なしでxinputを実行すると出てきます。結論から言うと、Xのバージョンが上がった際にこの名前が「Wacom DTU710 stylus」から「Wacom DTU710 Pen stylus」に変更されたために、動かなくなったということでした。
ちなみに元に戻す場合は、以下の通り。
% xinput set-prop "Wacom DTU710 Pen stylus" --type=float "Coordinate Transformation Matrix" 1 0 0 0 1 0 0 0 1
さて、この手のフロート型のポインティングデバイスでは、座標があっていればそれに越したことはないものの、大抵ズレているので座標合わせが必要となります。こういう場合は、xinput_calibratorで座標のズレがどれくらいか測定します。
まずは両方の画面を同じ表示にして、一旦元に戻します。
% xrandr --output DVI-0 --same-as VGA-0
% xinput set-prop "Wacom DTU710 Pen stylus" --type=float "Coordinate Transformation Matrix" 1 0 0 0 1 0 0 0 1
その後にxinput_calibrator。
% xinput_calibrator --output-type xorg.conf.d
Warning: multiple calibratable devices found, calibrating last one (Wacom DTU710 Pen eraser)
use --device to select another one.
Calibrating standard Xorg driver "Wacom DTU710 Pen eraser"
current calibration values: min_x=0, max_x=34080 and min_y=0, max_y=27660
If these values are estimated wrong, either supply it manually with the --precalib option, or run the 'get_precalib.sh' script to automatically get it (through HAL).
--> Making the calibration permanent <--
copy the snippet below into '/etc/X11/xorg.conf.d/99-calibration.conf' (/usr/share/X11/xorg.conf.d/ in some distro's)
Section "InputClass"
Identifier "calibration"
MatchProduct "!!Name_Of_TouchScreen!!"
Option "MinX" "20"
Option "MaxX" "33687"
Option "MinY" "221"
Option "MaxY" "27196"
Option "SwapXY" "0" # unless it was already set to 1
Option "InvertX" "0" # unless it was already set
Option "InvertY" "0" # unless it was already set
EndSection
Change '!!Name_Of_TouchScreen!!' to your device's name in the config above.
xinput_calibratorの出力形式にはxinputもあるのですが、私の環境ではうまく動かないので、xorg.conf.d形式で出力しています。
ここで重要なのは、
current calibration values: min_x=0, max_x=34080 and min_y=0, max_y=27660
と
Option "MinX" "20"
Option "MaxX" "33687"
Option "MinY" "221"
Option "MaxY" "27196"
の部分。この値を元に変換行列を作成します。
x_1=(max_x-min_x)/(MaxX-MinX)=1.0122672052752
x_2=0
x_3=MinX/MaxX=0.00059370083415
y_1=0
y_2=0.5*(max_y-min_y)/(MaxY-MinY)=0.512696941612604
y_3=0.5*(1-MinY)/MaxY=0.49593690248566
z_1=0
z_2=0
z_3=1
この値をxinputの引数にして、テスト。x_1とy_2の値が幅と高さ、x_3とy_3の値が原点（左上）からのオフセット量になります。で調整するとこんな感じ。
% xinput set-prop "Wacom DTU710 Pen stylus" --type=float "Coordinate Transformation Matrix" 1.011 0 0.0006 0 0.513 0.495 0 0 1
% xinput set-prop "Wacom DTU710 Pen eraser" --type=float "Coordinate Transformation Matrix" 1.011 0 0.0006 0 0.513 0.495 0 0 1
Debian Stretchと日本語入力
Debian Stretchがリリースされたので、まずはVAIO Pを更新。さすがにデスクトップは一部変なハードがあるので、後から。
……思ったよりすんなり入りました。外部リポジトリーが入っていないせいか。
まあ、ソフトウェア構成としても、
くらいなので、変なものはそうないわけで。GNUstep環境という時点で標準からは外れますけど、慣れだし。
各種IMのJISキーボード環境での親指シフト(nicola)環境は相変わらず。
- scim/ibus/fcitx-anthy: 問題なし。
- ibus/fcitx-skk: 以前書いたとおり。「fj（変換開始）」「a（=う）」「s+親指右（=じ）」「d+親指左（=な）」→まず「▽う」が表示された後「▽じ」、「▽な」と表示され、変換バッファに複数の仮名が入らない。正しい動きなら「▽うじな」。
- ibus-kkc: 「fj」を抜いて上と同じ入力をすると、「aう」が表示されたあと、「as雨」（変換キーが親指右でなく変換キーとして働いているらしく「う」が変換されて「雨」になったり、「asうし」になったりする）、「as雨dな」となる。叩いているキーとかなが両方入力される上に、ibus-skkやibus-anthyで働いていた変換キーの親指右が働かない。
- fcitx-kkc: ibus-kkcにほぼ同じ。
- mozc: oyainput使用のこと。
ibus/fcitx-skkとibus/fcitx-kkcは同じロジックを遣っているので、同じような動きをしています。どこに投げたらよいのやら。
まあ、この機械自体、文字入力はほとんどEmacsとddskk+skk-nicolaだけで完結しているけれど、Firefoxなどでibus/fcitx-skkをskk-nicola感覚で入力しようとすると、本当に困ってしまうわけで。現在実用なのはscim/ibus/fcitx-anthyしかない、というのはどうにかなりませんかね。
辞書形式の話。
電子辞書（ICじゃなくてCD-ROMとかで供給される方）について、書いてみる。
日本語環境において辞書ソフトウェアはMacを除いてあまり普及していないのが現状。Macの辞書.appはNeXTからの伝統ですな。一応EPWING/JIS X 4081という規格があることはあるけれど、字種がJIS X 0208（技術的に言えばJIS X 0213の第1面）の枠内だけという欠点があって、日本語（の一部）と、英語くらいしかまともに扱えない。
外字地獄とか何らかの代用表記を我慢すればそれ以外もできないことはないけれど、外字の文字数が94×94×2（half/wide width）しかないので、私の扱う言語、具体的には中国語（繁体字・簡体字）、広東語（繁体字）の世界だとGB 2312は何とかなるとしても、CNS 16443やBig5には文字が足りない。まあ、小学館日中・中日辞典のように、JIS X 0208にある字種以外を外字にするやり方ならBig5は何とか入るけど、CNS 16443は合計8面もあるのでどうしようもないわけで。ましてやUnicodeのCJKV統合漢字なんぞ無理。
しっかし、外字地獄なんて遣う側からはやってられないのですわ。
そもそも外字をUnicodeに変換する機能があるソフトウェアなんてEBWin/EBMac/EBPocketとかEmacs+Lookupくらいでして、遣う側も面倒、辞書を作る・変換する側も大変という。
じゃあ、EPWING/JIS X 4081をUnicode化すれば良いというかも知れないけれど、確かに
- ONESWING
- FreeUWing (http://green.ribbon.to/~ikazuhiro/dic/freeuwing.html)
というものが存在しているものの、ONESWINGはメーカー囲い込み、FreeUWingは公開されている辞書が存在せず、かつEmacs+Lookupでしか扱えない。
これ以外で、データを作成できる辞書形式となると、
- PDICU
- StarDictとXDXF
- MDict
- LeXML
といったものがあるけれど、PDICUは実質Windows用でテキストデータのみ（Wineで頑張る？）、StarDictはテキストデータのみ、MDictは画像や音声データも扱えるけれど、日本語圏では作成方法が知られていない、LeXMLは中間形式という問題があるわけで。
独自形式でない、汎用な辞書形式が欲しい。……Macの辞書.app形式？ いやはや。
市販Nicola（親指シフト）キーボード
市販されている・いた専用のNicolaキーボードとしては、いずれもPS/2接続で、
- FMV-KB211
- FMV-KB611 / OAKB-193 / FMVTW-KBS / FMV-KB613
- FMV-KB661
- Rboard
があります（とりあえずFMR/FM-TOWNS/OASYS/FACOMとか、かつてのSONY NEWSとかは考えない）。これらは後述する106キーボードにNicolaの刻印をしたものと異なり、内部的にキーコードを変換する機能を持っています。ただ、FMV-KB611/613/661は特殊で、611モードと211モードの両方を持っています。
これらをBSD/Linuxで使用する場合、（FMV-KB611/613/331ではFMV-KB211モードにして、）JIS仮名入力できるIMでモードずれを手動で修正しながら入力することになります。
一方、JISキーボードにNicolaを刻印したキーボードは意外とあり、
- FMV-KB231
- FMV-KB232
- FKB-8579USB
- FKB-7628-801 (Thumb Touch)
- ライフラボ社製親指シフト表記付きUSBライトタッチキーボード
- FMVのノートPCのNicolaモデル
などがあります。これらは内部的には106/109キーボードですので、通常のJISキーボードと同様に、BSD/Linuxだとキーボードエミュレーション機能付きのIM（例えばscim/ibus/fcitx-anthyなど）やキーボードエミュレーター（oyainput、かつてはQ's Nicolatter for X）、Emacs内限定でskk-nicolaを使うことになります。
FMV-KB231なんて見た目FMV-KB211とそっくりですが、親指シフトキーを押しても変換や無変換キーのコードが出力されます……。
BSD/LinuxにおけるNicola（親指シフト）入力の現状
私はNicola（親指シフト）入力なのでそのつもりで。
PC-UNIX環境でNicola入力する場合、以下の方法があります。
a. JISキーボード（後述のThumb Touchなども同様）: キーボードエミュレーション機能付きのIM（例えばscim/ibus/fcitx-anthyなど）やキーボードエミュレーター（oyainput、かつてはQ's Nicolatter for X）、Emacs内限定でskk-nicolaを使う
b. FMV-KB211系: IMをJIS仮名入力に設定して、手動でモードずれを直して使う
c. FMV-KB611/613/661系: FMV-KB211と同様にする（Windowsであれば専用モードを扱えるのだけど）
まず、普通はPS/2接続のNicolaキーボードなんて持ってないでしょうから、a.となるでしょうか。
私はa.とb.の両方です。デスクトップではFMV-KB211をuim-anthyで使っていますし、ノートではscim-anthyとEmacs上でskk-nicolaを使用しています。多言語環境が必要だと、Emacsで暮らす時間が長くなる……（でもFMV-KB211でEmacsを使うとそれはそれで厄介）。
ちなみに、libkkc系だとfcitx-kkcとibus-kkc、libskk系だとscim-skkとfcity-skk、ibus-skkにNicola機能が付いていますが、現状まともに動きません。scim-anthyかibus-anthy、fcitx-anthyを使いましょう（ただ、Debian Jessieのi386版でscimを使用すると、WindowMakerの右クリックメニューが動かなくなる）。
ibus-skkの例: 「f+j（変換開始）」「a（=う）」「s+親指右（=じ）」「d+親指左（=な）」→まず「▽う」が表示されたあと「▽じ」、「▽な」と表示され、変換バッファに複数の仮名が入らない。
