2017-11-12

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/の中に置けば、日本語化することができる。

2017-09-03

PDFの煮るなり焼くなりのメモ

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

2017-09-02

漢字の字書的データの在処

辞書日本語入力

　漢字の読みのデータを簡単にまとめてみた。まずはテキストデータとして入手できるものを記載。

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。

2017-08-27

FreeBSDでのwifi設定

FreeBSD ハードウェア

　時間が開いてしまいました。

　今まで有線運用だったFMV-Lifebook(FMV-R8290、FreeBSD/amd64 11.1)に180円のCardBusな無線LANカードを入れてました。こんなやつ。

CONTEC FLEXLAN-DS540
Atheros AR5212
IEEE 802.11a/b/g対応

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のパスフレーズの欄に入力すれば接続できる。

2017-07-09

マルチディスプレイ環境での液晶タブの調整

Debian ハードウェア

　デスクトップの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

2017-06-25

Debian Stretchと日本語入力

Debian 日本語入力

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しかない、というのはどうにかなりませんかね。

2017-06-10

辞書形式の話。

辞書日本語入力

　電子辞書（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形式？　いやはや。

2017-06-07

市販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とそっくりですが、親指シフトキーを押しても変換や無変換キーのコードが出力されます……。

2017-06-06

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+親指左（=な）」→まず「▽う」が表示されたあと「▽じ」、「▽な」と表示され、変換バッファに複数の仮名が入らない。

2017-06-04

理想的な環境

　自分にとって必要な環境は

BSD（次善でLinux）
WindowMaker+WDM
GNUstep環境
Emacs
Nicola（親指シフト）入力できること
EPWINGを引けること
TeX
周辺機器（ペンタブ、特殊キーボード）に対応していること

といったことだろうか。まあ、wmakerとかGNUstepはNeXT（というかOPENSTEP for Mach、私はUNIXはこっちから入った）の名残みたいなものであるし、親指シフトはFM-TOWNSをつかっていたから。

　こいつらを全部成り立たせようとすると大変で、実質的にはFreeBSDかDragonflyBSD、NetBSD、Linux（私の場合はDebian）になってしまう。

FreeBSDはほぼほぼ満足といえ、usb4bsdのおかげでWACOMのタブレットがつかえなくなってしまった。後、古い機械でACPIまわりでPANICになるのと、インストーラーCDを途中で認識しなくなる類のバグはなんとかしてほしい。IPX/SPXサポートの中止のときもひどいことになったり……。
DragonflyBSDはFreeBSDと同様。しかしi386で動かないのが辛い。
OpenBSDは国際化まわりが劣る。一例を挙げると、GNUstepの国際化機能が働かない。後はPackageが少なく、EBViewとか、日本語IMとか。
NetBSDは良いのだけど、pkgsrcの整備状況か。pkgsrcは良い仕組みといえ、バイナリーパッケージが整備されていない。皆pkgsrcしているの？
Debianは一度環境を作ってしまえば楽で、パッケージも充実している。とはいえ、私自身BSDの方が好き・しっくり来るので、こいつでないと動かない機種（例: VAIO P）とか周辺機器（例: 液晶タブレット）、ソフトウェア（例: mars_nwe）という事情がないと入れない。

　正直、FreeBSDがまともならそれに越したことはないのですが……。Darwin？　人柱確定だし、そんなの入れるくらいならMacOSにしますって。

2017-06-04

はてな版について

　泊何水です。初投稿です。

　はてな版は主にシステム関係のメモ書きになると思います。