本を読む

読書やコンピュータなどに関するメモ

XKBのキー配列でCtrlとCapsを入れかえ、変換と無変換をShiftにする

 最近のLinuxのデスクトップ環境では、キーをXKBという機構で管理しています。最近、新規でLinuxデスクトップ環境をセットアップしたので、ついでに自分のキーカスタマイズ方法をメモしておきます。カスタマイズ内容は、タイトルのとおり、CtrlキーとCapsキーを入れかえるのと、変換キーと無変換キーをShiftキーにすることです。

 まず設定ファイルのディレクトリを作ります。

$ mkdir -p ~/.xkb/{keymap,symbols}

 使っているキーコンポーネント名をファイルに保存します。

$ setxkbmap -print > ~/.xkb/keymap/mykbd

 symbolsディレクトリの下に新規ファイルを作ります。ここでは仮に「henkan」とします。

$ vi ~/.xkb/symbols/henkan

 無変換キーに左Shiftキーを、変換キーに右Shiftキーを割り当てるには、以下のような内容を書き込んで保存します。

partial modifier_keys
xkb_symbols "thumb_shift" {
    replace key <MUHE>  { [ Shift_L ] };
    replace key <HENK> { [ Shift_R ] };
};

 キーコンポーネント名を保存したファイルをテキストエディタで開きます。だいたい7行ぐらいだと思います。

$ vi ~/.xkb/keymap/mykbdf

 こんな感じで変更します。

        xkb_symbols   { include "pc+jp+inet(evdev)      };
                ↓
        xkb_symbols   { include "pc+jp+inet(evdev)+ctrl(swapcaps)+henkan(thumb_shift) };

 「henkan(thumb_shift)」は、symbolsディレクトリの下に作ったファイル名と、そのファイルでxkb_symbolsで定義した名前です。

 設定を読み込みます。

$ xkbcomp -w0 -I$HOME/.xkb ~/.xkb/keymap/mykbd $DISPLAY

 「$HOME」と書いているのは、「-I」の直後の「~」はシェルが展開してくれないためです。

 なお、IMフレームワークにiBus使っていると、IMを切りかえたときに、カスタマイズされたキー配列がクリアされます。これは、iBusではIMがキー配列と結びついているための必然です。

 iBusではなくFcitxを使っていて、半角/全角キーによりIMをオン/オフしたときにも、キー配列がクリアされてしまう場合があります。これはGNOMEとiBusの統合機能が有効になっていて、iBus方式のキー配列管理がされているからです。Fcitxでこのようになる場合には、統合機能を無効にします。

$ gsettings set org.gnome.settings-daemon.plugins.keyboard active false

カナ英数字のJIS X 4061ソートをRubyGemsに

 仕事で使い回していた、Rubyでカナ英数字をJIS X 4061(日本語文字列照合順番)順にソートする単純なルーチンを、ライブラリに切り出してまとめました。ついでに自分が使いやすいよう、RubyGemsにリリースしました。

  •  実は初RubyGemsです。

     ユースケースとしては、たとえば書籍の索引データをソートするときに使います。JIS X 4061では、“カ”=“ガ”とか、“ヤ”=“ャ”とか、句読点 < 記号 < 数字 < 英字 < カナとかいった比較順序が決められています。ざっくりいうと、Excelのソート順です。

     なお、漢字から読みを生成して比較する機能はありません。あと、自分のユースケースをカバーできればいいので、JIS X 4061のフルセット対応は狙っていません。

    cpdfがpdftk代替として高機能だけど自分の用途には使えなかった

     PDFから一部のページを抜き出したり、反対に複数のPDFを1本にまとめたりするのに、コマンドラインツールのpdftkを便利に使っています。

     ただ、pdftkがGCJ(GNU Compiler for Java)で作られていて、そのGCJがメンテナンス終了になっていたりという状況です。最近のCentOSやmacOSでは、動かなかったり、動かすのに苦労したりするようです。

     調べてみると、cpdf(Coherent PDF)というツールがpdftkのようなことができて、高機能なようです。そこで、試してみました。

     先に結論をいうと、タイトルのとおりです。

    ライセンス

     「自分の用途には使えなかった」理由は、ライセンスです。cpdfは、無料で使えてソースも公開されていますが、フリーソフトウェアではありません。アカデミック目的での利用や、個人でのお試しはOKですが、仕事目的で使うのはNGとされています

     機能はよかったんですけどね。

    インストール

     cpdf-binariesリポジトリに、Linux用(64bit、32bit)、macOS用、Windows用のバイナリが用意されています。ダウンロードして実行権を付け、実行パス中のディレクトリに置くだけです。

     依存ライブラリは少ないようですね。

    $ ldd ~/bin/cpdf
            linux-vdso.so.1 =>  (0x00007ffe523db000)
            libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3f83be9000)
            libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3f839e5000)
            libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3f8361b000)
            /lib64/ld-linux-x86-64.so.2 (0x00007f3f83ef2000)

     そのほか、OCamlのopamでビルドしてインストールする方法もあるようです。

    使い方

     PDFファイルの結合はこんな感じ。

    $ cpdf a.pdf b.pdf -o out.pdf

     一部のページを抜き出すにはこんな感じ。

    $ cpdf a.pdf 1-5,8 -o out.pdf

     ページ指定にendとかoddとかevenとかallとか使えるのはpdftkっぽいですね。

     ページの回転も指定できます。

    $ cpdf a.pdf -rotateby 90 -o out.pdf

     PDFファイルの情報を表示する機能もあります。

    $ cpdf -info a.pdf

     使われているフォントも調べられます。

    $ cpdf -list-fonts a.pdf

     そのほかにも、ページサイズ操作とか暗号化とか、さまざまな機能があるようです。

    日経xTECHのRSSを生成するスクリプトを作った

     IT系ニュースサイト「日経ITpro」が「日経xTECH」にリニューアルされました。それにともない、RSSフィードが廃止されたようで、どこにも見当りません。これでは自分には不便すぎるので、指定した記事一覧ページから勝手にRSS(Atom)を生成するスクリプトを作りました。

     nokogiriとRSS::Makerをつないでいるだけの、30行ぐらいのRubyスクリプトです。

     たとえば、ITカテゴリーのニュースのRSSを生成するには以下のように実行します。

    $ ruby xtech2rss.rb http://tech.nikkeibp.co.jp/news/index_it.html > xtech_itnews.xml

    追記2018.2.25:その後、日経xTECHで公式にRSSフィードを公開したようです。

    Pocketの連続再生が便利

     以前書いたように、私はAndroid端末のPocketアプリで音声読み上げ(TTS)を愛用しています。

     ちょっと前になりますが、2017年10月のアップデートで、Pocketの音声読み上げのインターフェイスが一新されました。再生中はモーダルダイアログが表示されるものから、画面下にバーが表示されるものになり、記事表示と独立して再生されます。再生スピードや声の高さなども以前より柔軟になったようです。

     一番便利なのは、連続再生の機能が付いたことです。記事一覧の画面でツールバーのヘッドフォンのアイコンをタップすると、上の記事から順に連続で読み上げてくれます。また、記事を開いた状態で音声読み上げを呼び出すと、そこから下の記事を順に読み上げてくれます。私はたとえば台所で料理や皿洗いをしながら記事を聞くので、濡れた手で操作しなくてすむのが想像以上に便利でした。

     ただ、使っている限りでは、常に全記事での順序となるようです。私の場合、音声読み上げ向けの記事に「tts」タグを付けているので、タグの記事一覧を順に読み上げてくれる機能があればもっと便利なのにと思います。

    PocketのTTSの連続再生

    Ubuntu 17.10リリース記念オフラインミーティングで発表した

     「Ubuntu 17.10リリース記念&Ubuntu Weekly Recipe 500回記念オフラインミーティング17.12」に参加して、5分程度の発表をしてきました。

    ibus-skkをなんとかすっぺ会議 from emasaka

     「パッチを書いても送り先がないんですよね」というだけの話です、はい。

    濁点問題

     こんにちは。これは編集者アドベントカレンダーの12月4日の記事です。

     この記事では、濁点問題という極めてちっちゃい話題を取り扱います。なにせ1文字の片隅ですし。

     編集者の一般的な仕事についてのちゃんとした話題は、ほかの方々の記事にご期待ください。私も期待しています。

    百聞は一見にしかず

     濁点問題を理解するために、まずはMicrosoft Wordの画面キャプチャーをご覧ください。

    濁点問題サンプル

     赤丸で囲んだ2つの文字は、同じ「が」という文字に見えます。しかしこれは、「が」と「が」という異なる文字です。スペルチェックの波線が付いているほうが「が」です。

    この記事は何ではないか

     濁点問題というと、比較的詳しい方には、ファイル名の問題と思われがちです。iOS 10でのKindleアプリの不具合なども問題になりましたし。が、ここで扱うのはファイルの内容(テキスト)のほうの問題です。

     ファイルのテキストの問題も、原理としてはファイル名の問題と同根です。ただ、テキストのほうの問題は認知度が低くて見過ごされがちです。また、正規化されないという問題により、一括処理したときにトラブルを起こす可能性があります。

    私が意識したころ

     私がこの問題に遭遇したのは、2015年のことでした。Macを使っている著者様から送られてきた原稿テキストの中で、濁点や半濁点が付いていた文字のうち、テキストエディタの文字列検索にヒットしない文字があるという現象があったのです。ちょっと調べてみると、微妙に違う文字になっているようです。

     それからちらほらと、Macで書かれたMicrosoft Wordファイルやテキストファイルの中で、同様の現象を目にするようになりました。

     私の主な仕事範囲は、IT系出版物です。いまIT関連の文章を商業出版物に書くような技術者の方には、Macが高い普及率を誇ります。編集者にとっては、あらかじめ注意しておきたいポイントです。

    どこで起こるか

     この問題は、Unicode文字集合による現象です。そのため、Shift JISなどJIS文字集合ベースの文字コードのテキストでは起こりません。

     Microsoft OfficeのようなUnicodeベースのアプリケーションや、UTF-8などUnicodeベースの文字コードで書かれたテストファイルで起こりえます。

    Unicodeの濁点や半濁点

     Unicodeには濁点や半濁点の表しかたが2種類あります。想像しやすいのは、「が」を「が」という1文字として表す方法ではないでしょうか。この形式を「合成済み文字」と呼びます。

     もう1つの方法は、「が」を「か」と「゛」(相当)の2文字の組み合わせで表現する方法です。この「゛」の部分には、単体で使う濁点ではなく、組み合わせ専用の文字を使います。この形式を「結合文字列」と呼びます。

     文書中の濁点や半濁点を合成済み文字に揃えるのを「NFC(Normalization Form Composition)」正規化と呼びます。反対に、結合文字列に揃えるのを「NFD(Normalization Form Decomposition)」正規化と呼びます。NFD正規化されたUnicodeを、通称で「UTF8-MAC」と呼ぶこともあります。

     ちなみに、細かくいうとNFCやNFDは濁点と半濁点の正規化だけではありません。が、とりあえずここでは濁点と半濁点だけに話を留めておきます。

    Macと結合文字列

     Windowsを使っていると、外で作られた文書を除けば、意図していないところで結合文字列が入力されることはありません。

     しかし、Macでは意図せずに結合文字列が使われることがあります。最初にちょっと触れたファイル名などはその一つです(HFS+ファイルシステムの場合)。

     ファイル名にとどまらず、Macではテキスト中にも意図せずに結合文字列が使われることがあるようです。挙動を見て推測した限りでは、Webブラウザーなどほかのアプリケーションから、テキストエディタやワードプロセッサにテキストをコピー&ペーストすると、そこで結合文字列が使われるように見えます。実験したわけではないのであくまで推測ですが。

    困ること

     テキスト中に結合文字列が混じって何より頭の痛い点は、正規化されていないことです。普通に日本語入力した文字列は合成済み文字で入力されます。そこに、コピー&ペーストで結合文字列が入ると、テキスト全体ではNFCでもNFDでもない非正規化状態となります。

     それが直接トラブルとなるケースに、検索や置換があります。テキストエディタの機能で「ユーザー」を「ユーザ」に(あるいはその逆に)置換したつもりが、結合文字列の「ザ」が入っていた部分はヒットしないと、表記不統一となってしまいます。

     また、Microsoft Wordでは、よくも悪くも合成済み文字と結合文字列が同じように表示されます。しかし、アプリケーションによっては結合文字列だと表示が違う(「か」と「濁点」がわずかに離れて表示される)という場合もあります。印刷機でどうなるかは怖いので試したことはありません。

     なにより、同じはずの文字が2通りの異なる文字として入っているのは、気持ち悪いですよね。

    NFC正規化する(コマンド編)

     さて、テキストを一気にNFC正規化する方法を見てみましょう。

     私はLinuxデスクトップを主に使っています。Linuxデスクトップでは、さまざまなコマンドを使ってテキストを処理できるのが強みです。最近では、Windows 10のWSLでもまったく同じことができるでしょう。なお、ここではWSLやコマンドを使う準備については割愛します。

     Linuxのコマンドにはテキストの文字コードを変換するものがあり、そこでNFC正規化もやってくれます。Macでも同じだと思いますが、試していないので念のため。

     文字コードを変換するコマンドにnkfがあります。nkfは、変換元と変換先の文字コードを指定して実行します。この文字コードとして「utf8-mac」(NFD正規化されたUTF-8)が指定できます。

    $ nkf --ic=utf8-mac --oc=utf-8 source.txt > dest.txt

     ただし、nkfでは「utf8-mac」は変換元にのみ指定できます。つまり、NFC正規化のみです。

    NFC正規化する(エディタ編)

     テキストエディタにNFC正規化やNFD正規化の機能が備わっている場合もあります。

     私が日頃使っているGNU Emacsには、リージョン(選択範囲のようなもの)をNFC正規化する「ucs-normalize-NFC-region」と、NFD正規化する「ucs-normalize-NFD-region」の2つのコマンドがあります。

     そのほかのエディタにも同様の機能があるかもしれませんが、よく知りません。

    ワープロでは?

     案件によっては、Microsoft Wordなどのワープロ文書で原稿をやりとりすることがあります。Googleドキュメントで文書を共有して作業することもあるでしょう。

     ワープロ文書でも結合文字列が入っていることがあります。フォーマットを保ったまま(プレーンテキストにせずに)NFC正規化をかける機能が欲しいところですが、私の調べた限りではなさそうです。

     Microsoft WordやLibreOffice Writerなどのワープロや、Googleドキュメントでは、マクロ言語(外部DSL)を使って1文字ずつ見ていけば変換できそうな気もします。ただ、そうしたマクロ言語はいちど文書に組み込まなければ使えないのが面倒なところです。

     一つの試みとして、Microsoft Wordの.docxファイルを処理するdocx-normarize-nfcというプログラムを試作してみました。20行未満の簡単なPythonスクリプトです。これは、.docxファイルをZIPアーカイブとして開き、文書本体のXMLテキストを開いてNFC正規化し、ZIPアーカイブに書き戻すというものです。

    注意

     少し触れたように、NFC正規化は濁点や半濁点だけの処理ではありません。

     たとえば「神」をNFC正規化すると「神」になります。これは変換ツールによって挙動が異なるようで、nkfで試すと「神」のままでしたが、GNU Emacsのucs-normalize-NFC-regionで試すと「神」になりました。

     私の主な仕事範囲であるIT系出版物では、文字や文字コードの本でなければ問題になるケースは少ないですし、むしろこのような正規化をかけたほうがいいかもしれません。ただ、固有名詞については注意したほうがいいでしょう。

    まとめ

     Macから来た文書は、濁点や半濁点に注意しましょう。

     | HOME |  »

    Categories

    Recent Entries

    Recent Comments

    Recent Trackbacks

    Appendix

    emasaka

    emasaka

    フリーター。
    連絡先はこのへん

    Monthly


    FC2Ad