SKK-JISYO.lisp
NL名古屋 - connpassでSKK辞書の話をした。 要約すると、特定の文字をエスケープするだけでEmacsLispが必要になってつらいという話だった。
Transiruで発表したので、発表時の音声等はこちらで聞ける。終盤早口になってしまったので恥かしい。声優吹き替えオプションが欲しい。
原稿
前提
自己紹介
こんにちは。 mzpです。 タイトルにあるように日本語入力システムとLispについて話したいと思います。日本語のNと、LispのLでNLです。
何の話?
一言で日本語入力システムといってもたくさんの種類がありますし、Lispにもたくさんの種類がありますね。
ので、具体的に言うと、今日はSKKとEmacsLispの話をします。LispといってEmacsLispを持ちだすのは微妙な気がしますが、まあLispと名乗ってるわけですしOKでしょう。
SKKとは
このSKKについてですが、これはだいぶ独特な日本語入力システムです。通常の日本語入力システムがやるような作業を利用者におしつけることで、高速かつ高精度の日本語変換を実現しています。
入力例
分かりづらいと思うので、入力例を見てみます。例として「今日は雨です」と入力してみる場合です。
普通の日本語入力システムでは「きょうはあめです」と入力したのち、スペースを押して、変換候補を表示します。お馴染みですね。
SKKでは、漢字変換を始める前にShiftを押します。
Kyou
そして、複数の単語をまとめて変換することはできないので、ここでスペースをおして候補を表示します。
ひらがなはそのまま入力すればOKです。特に変換は必要ありません。
ha
また漢字なのでShiftを押します。
Ame
そして、スペースを押して候補を表示し、確定させます。
そして、またひらがなはそのまま入力します。
desu
SKKの特徴
このように
- 単語ごとでしか変換できない
- 漢字に変換するかどうかを自動で判断しない
といった特徴があります。
一見使いづらいだけのように見えますが、変換する単語を完全に自分で制御できるので、慣れれば離れられなくなる中毒性があります。
SKKの実装
中毒性が高いソフトウェアのため、現在では様々なプラットフォームで利用できます。
- Windows: SKKFEP、CorvusSKK
- Mac: AquaSKK
- iOS: FlickSKK
- Linux: iBus-SKK, UIM-SKK, SCIM-SKK
- Vim: skk.vim
- Emacs: ddskk
このAquaSKKとFlickSKKは僕がメンテしてます。
SKKの歴史
元となったSKK(通称: 本家SKK)は、1987年に、東北大学教授(当時)佐藤雅彦によって開発されました。
この本家SKKは、Emacs上のプログラムとして開発されました。 つまりEmacsLispを用いて開発されていました。
いやー、Emacsはすばらしいソフトウェアですね。 実にすばらしい。
辞書ファイル
とEmacsを十分に褒めたところでつらい話をはじめます。
ひらがなを漢字に変換するためには、ひらがなと漢字の対応表が必要になります。この対応表は辞書と呼んでいます。
そしてこの辞書ファイルが闇を貯めこんでいます。
辞書ファイルの書式
辞書ファイルはテキストファイルになっており、各行が以下のような書式になっています。
なごや /名古屋;愛知/那古屋/
左から順に「見出し語」「変換候補」「アノテーション(要するに補足情報)」となっています。変換候補間は/で区切られていて、アノテーションとは;で区切られています。
自然な感じがしますね。
エスケープ
しかし、この書式をじっと見てると、いくつか使えない文字があることが気づきます。そう、変換候補として「;」や「/」を含むことができないのです。
例えば「owata」の変換候補として「(^o^;)/」 とかを登録したい場合はどうしたらいいでしょう。
対応方法1: エスケープ
いくつかの対応方法が考えられます。 例えば、文字列リテラルのように\でエスケープすればよさそうですね。
owata /\\(^o^\;)\//
対応方法2: 別の文字への置換
あるいは別の文字に置換してしまうのもいいでしょう。
例えば、"[ASCIIコード]"のような記法を採用すると、;のASCIIコードは0x3b、/は0x2fなので以下のようになります。
owata /\(^o^[3b])[2f]/
対応方法3: 全角文字
あきらめてよく似た文字を使うことで誤魔化してもいいです(?)。
owata /\(^o^;)//
いやよくないでしょ...。
正解
みなさんだったらどうしますか?ちょっとだけ考えてみてください。
....
考えましたね。 ではSKKがどうしたかを見てみましょう。
owata /(concat "\(^o^\059)\057")/
S式の文字列リテラルを使ってエスケープする、が正解でした〜。
まじかよ...って感じですね。
その他の便利機能
日本語入力システムを使ってると、いろいろ便利な変換したくなってきます。
例えば、
- todayを今日の日付に変換したい
- nowを今の時刻に変換したい
- 5feetをメートルに変換したい
- 元号を変換したい
などです。
これらはすべてEmacsLispを使って実現できます! すごい!
まじかよ...って感じですね。
さらにすごいことに以下のような変換もEmacsLispで実現されています。
- 画面幅いっぱいの線
まじかよ...って感じですね。
実装
Lispの実装 これらの機能は使う分にはまだいいんですが、実装者としては悪夢です。
つまりSKKを実装するには、EmacsLisp処理系を実装しなければいけません。 より具体的に言うと、AquaSKKとFlickSKKはボクがメンテしていく上で、ボクがEmacsLisp処理系を実装しなければいけません。
まじかよ...って感じですね。
SKK-JISYO.lisp
なげいていてもしょうがないので、現実を確認してみましょう。
実は「今日の日付」のような複雑なEmacsLispの式を含む変換候補は、通常の辞書とは別で管理されています。余談ですが、この別に管理されている辞書はLisp辞書と呼ばれていますが、このLisp辞書って単語もだいぶ愉快ですね。
そのため通常の辞書だけを利用すると割り切ってしまえば、フルセットのEmacsを実装者するのは避けれます。通常の辞書に残っているEmacsLispの式はconcatによる文字のエスケープだけなので、これに対応するだけで十分です。
実装状況
SKKの各実装がこれにどのように対応しているか見てみましょう。
AquaSKK/FlickSKK
AquaSKK/FlickSKKは割り切った対応をしています。外部の辞書ファイルに含まれるconcatについては何もしません。つまり変換するとこんな変換結果がでてきます。(例: dosv)
そして、ユーザが入力した内容した結果については、別の文字列に置き換えることでエスケープしています。先ほど述べた別の文字への置換のような形式です。
owata /\(^o^[3b])[2f]/
後者はともかくconcatがでてくるのは微妙なので直したいとは思っています。
ibus-skk/scim-skk
ibus-skk/scim-skkは、concatのみの実装をしていてソツがない感じになっています。
CorvusSKK
一方、CorvusSKKはここの実装をがんばっていて、いくつかの関数もサポートしています。すごいです。
その他
Lispの話はこれくらいですが、実は辞書ファイルにはまだいくつかの闇が存在しています。
辞書の並び順
これまでは辞書の各行の話をしてきましたが、これらの行は見出し語をキーとしてソートされています。いわゆる辞書順です。辞書ですからね。
このときの比較関数としてはEmacsLispの string< が使われます。....またEmacsLispか。
そしてこのstring<は文字コード順で文字列を比較します。 はい、ぞわぞわしてきましたね。
なんの文字コードだよ、って感じですね。SKKでは伝統的にはEUC-JPが使われますが、最近はUTF-8を使うことも多いです。というかボクは使っています。
UTF-8の比較というとアレがありますね。 濁点問題です。NFCとNFDという2種類の形式があります。濁点を合成された文字としてもつか、分解された文字としてもつかの違いです。
世の中的にはNFCを使うことが多いんですが、ボクのメンテしているApple系のプラットフォームだとNFDが主に使われてたりします。
どちらが正しいとか優れているとかはありませんが、並び順には影響するので注意深く扱う必要があります。ボクはドハマりしました。
きっついですね。
辞書のライセンス
SKKの辞書ファイルはGPLで配布されています。 フリーなソフトウェア!! 自由!!
...こういうデータファイルがGPLっていうのはどういう扱いなんでしょう。
wikipediaから引用すると、GPLはおおむね以下のことを許諾するライセンスです。
- プログラムの実行
- プログラムの動作を調べ、それを改変すること(ソースコードへのアクセスは、その前提になる)
- 複製物の再頒布
- プログラムを改良し、改良を公衆にリリースする権利(ソースコードへのアクセスは、その前提になる)
改変の許可と再配布はいいとして、実行というのは何になるんでしょうね。 あとテキストを読み取ってアレコレするのは動的リンク扱いで派生物扱いになったりするんでしょうか。
謎です。
AquaSKK/FlickSKKのメンテナとしてのポジショントークは、同梱であってリンクではない。そのためGPLである辞書ファイルを読み取ってあれこれするプログラムはGPLである必要性はない、です。
別にアンチGPLというわけではなくて、AppleのAppStoreとGPLの相性が悪いので、俺の書いたコードはGPLではない、ということにしとかないと色々と都合が悪いんです。
まとめ
4コマ漫画の画像管理✨
NEW GAME! のコマ検索 - みずぴー日記で作っていたソフトウェアのうち、画像以外の部分を公開した。
レポジトリ
https://github.com/mzp/EagleJumpSystem
検索機能
NEW GAME! のコマ検索 - みずぴー日記で述べたように
- 台詞
- 登場キャラクター
によって該当するコマを検索できる。
入力補助機能
検索機能を実現するために、各コマにはメタデータ(台詞、登場キャラクター)を入力する必要がある。 このメタデータの入力を補助する機能もいくつか実装した。
コマ分割
ページを取り込む際に、画像をコマごとに分割する。これはゆゆ式を無限に楽しみたかった話 〜 ゆゆ式 Advent Calendar 2014 20日目 〜 - non117's diaryのツールをほぼそのまま利用している。
テキストの自動認識
Google CloudVisionAPIによりコマ中のテキストを自動で認識する。
ただし利用には別途APIキーの取得が必要である。APIキーの取得方法はCloud Vision APIの使い方まとめ (サンプルコード付き)が分かりやすかった。
キャラクターの半自動認識
ある程度の量のキャラクターの分類を手動で行なえば、残りの画像については機械学習により自動でタグづけが行なえる。
ただし、登場回数の少ないキャラクターは学習データが少ないので、そこは手動でタグをつける必要がある。また、顔認識をした上でキャラクターの分類をしているため、「手のみ登場している」といったコマについては対応できない。
この部分のコードはTensorFlowでアニメゆるゆりの制作会社を識別する - kivantium活動日記をかなり参考にしている。
その他
既知のバグ
もしくは面倒で直してない箇所リスト。
- コマごとの分割の際に、まれに0バイトの画像が生成される。 今は、定期的に手動で
find . -size 0 -exec rm {} \;
を実行して削除しているが、そもそも生成されないようにしたい。 - 素朴なデータの格納方法をしているため、画像が増えるとどんどん遅くなっていく。
名前
レポジトリ名のEagleJumpSystemはNEW GAME!に登場するイーグルジャンプ社に由来する。
📱Zoi for iPhone
NEW GAME! のコマ検索 - みずぴー日記の成果を用いて、iPhoneからNEW GAME!のコマ検索を行なえるようにした。
経緯
ニコニコでやっているアニメの一挙放送を見ると、PCの前に4〜6時間ほど拘束される。 そのときに、なんとなくXcodeを立ちあげてコードを書きはじめてしまった。
桜Trick、一挙放送みながらiOSアプリつくってたら、だいぶ便利な感じがでてきた。 pic.twitter.com/UIzmPc98DF
— mzp (@mzp) February 21, 2016
機能
コマのインクリメンタル検索
NEW GAME! のコマ検索 - みずぴー日記に各コマのセリフを入力済みなので、それを移植してインクリメンタルに検索できるようにした。
またUIActivityViewControllerを用いたアプリ間連携も行なえる。
Spotlight対応
App Searchに対応したため、Spotlightから検索ができる。
Spotlightのインデックスに登録するタイミングは、悩んだが、
- 初回起動時
- 明示的に再インデックスを指示した時
の2つにした。 最初は、初回起動時のときのみにしていたが、インデックス処理でエンバグしたときの対応が面倒だったので、再インデックスボタンを追加した。
インデックスへの追加はApp Search プログラミングガイド: 検索の基本にあるコードをほぼそのまま使っている。
func add(items : [ZoiJson.Item], complete: () -> ()) { let si = items.map { self.searchableItemFor($0) } CSSearchableIndex.defaultSearchableIndex().indexSearchableItems(si) { error in if error != nil { print(error?.localizedDescription) } else { complete() } } private func searchableItemFor(item : ZoiJson.Item) -> CSSearchableItem { let attributeSet = CSSearchableItemAttributeSet(itemContentType: kUTTypePNG as String) attributeSet.title = item.script if let image = ZoiImage.image(item) { attributeSet.thumbnailData = UIImagePNGRepresentation(image) } return CSSearchableItem(uniqueIdentifier: item.path, domainIdentifier: "zoi", attributeSet: attributeSet) }
newgame:// 対応
ぐらばくさんが提案していた、newgame:// をカスタムURLスキームとして取り込んだ。(参考: ぐらばく on Twitter: "newgame://3/65/2/2 もいい https://t.co/hC6t3KxYj0")
https://twitter.com/mzp/status/702863419226005505
newgame://巻数/ページ番号/列/行
というフォーマットだが、目次等の存在により書籍のページ番号と先頭からページ数は一致しないので、そこは補正した。 また、ページ内の何コマ目なのかは保持しているが、何列目かは保持していないので、そこの補正も行なっている。
func toPath(url : NSURL) -> String? { if let vol = url.host, let paths = url.pathComponents, let page = Int(paths[1]), let col = Int(paths[2]), let row = Int(paths[3]) { let pageStr = NSString(format: "%03d", page + 2) let pos = (col - 1) * 3 + row return "data/vol\(vol)/vol\(vol)_\(pageStr)_\(pos).jpeg" } else { return nil } }
OnDemandResource対応
Testflightにアップロードしようとしたが100MBを越えてしまった。そこで、OnDemandResourceを利用し、必要になったタイミングで画像を取得するようにした。
OnDemandResourceの使い方はオンデマンドリソースでiOSアプリを軽くする - Qiitaを参考にした。
またOnDemandResourceで取得した画像を、ImageViewに非同期で設定するために https://github.com/Haneke/HanekeSwiftを用いてる。標準ではOnDemandResourceからの取得はできなかったので、独自のFetcherを作った。
import Foundation import Haneke class OnDemandResource { func fetch(fail : NSError? -> Void, succeed : Void -> Void) { let request = NSBundleResourceRequest(tags: Set(arrayLiteral: "zoi")) request.conditionallyBeginAccessingResourcesWithCompletionHandler() { resourceAvailable in if resourceAvailable { succeed() } else { request.beginAccessingResourcesWithCompletionHandler() { error in if error == nil { succeed() } else { fail(error) } } } } } } class OnDemandFetcher<T : DataConvertible> : Fetcher<T> { private let resource = OnDemandResource() private let getValue : () -> T.Result? init(key: String, @autoclosure(escaping) value getValue : () -> T.Result?) { self.getValue = getValue super.init(key: key) } override func fetch(failure fail: ((NSError?) -> ()), success succeed: (T.Result) -> ()) { resource.fetch(fail) { if let result = self.getValue() { self.main { succeed(result) } } else { self.main { fail(nil) } } } } override func cancelFetch() {} private func main(f : () -> ()) { dispatch_async(dispatch_get_main_queue(), f) } } // 使い方 let fetcher = OnDemandFetcher<UIImage>(key: self.item.path, value: UIImage(named: "zoi.png")) self.image.hnk_setImageFromFetcher(fetcher, placeholder: UIImage(named: "placeholder.jpeg"), format: Format<UIImage>(name: "original"))
📷 Live Photo生成、その後
📷 mov/jpegからのLive Photo生成 - みずぴー日記でmov/jpeg から Live Photo生成をできるようにしてから、いくつかの進展があった。
縦MVの発見
デレステにて縦画面MVを実現する方法が発見された。 これにより、iPhoneの画面サイズに適した動画が、簡単に得られるようになった。
GUIの作成
banjunによりGUIが作成された。(参考: movファイルからLive Photoを生成するLoveLiverにGUIをつけた - ツバメになったバリスタ)
https://github.com/mzp/LoveLiver/releases
これによりCLI版で面倒だった
- Live Photoにしたいシーンの選択
- 3秒間の動画の切り出し
- JPEG画像の準備
- Photos.app へのD&D
といった手間がなくなり、Live Photoを量産できるようになった。
Live Photoの量産
上記2つにより、大量のLive Photoが作られるようになった。
毎晩、iCloud Photo Sharing経由で新作が届く。
NEW GAME! のコマ検索
NEW GAME!の全コマをインクリメンタルに検索できるツールを作った。*1
経緯
NEW GAME! 3巻を読んだためNEW GAME熱が上ったので、ゆゆ式を無限に楽しみたかった話 〜 ゆゆ式 Advent Calendar 2014 20日目 〜 - non117's diaryのツール*2を移植し、コマ分割およびアノテーションの付与を行なった。
最初はコマの分割だけのつもりだったが、気がついたら各セリフの入力とキャラのタグづけも行なってしまった。 入力には一週間くらいかかっている。
アノテーションの付与が完了したので、各コマを検索するツールを作成した。
機能
セリフによるインクリメンタル検索
セリフによってコマをインクリメンタルに検索できる。また、該当のコマが単行本のどのあたりに登場しているのかも表示する。
また、すべてのセリフを入力しているため、セリフがないコマの検索もできる。
キャラ指定の検索
特定のキャラを指定した検索もできる。複数指定すれば、同じコマ内に登場しているコマを検索できる。
例えば、「ひふみ」と「ねね」にチェックをいれれば、この二人が同じコマに登場したのは一度しかないことが確認できる。
ページ指定の検索
特定のコマを見つけたあと、同じページにあったコマの検索もできる。 これを利用することで、「プリンを食べたねねっちの表情」といったコマを見つけることができる。
所感
気をぬくと青葉さんの幻覚が見える...
— mzp (@mzp) February 1, 2016
💫Tumblotte 0.1.0
💫Tumblrクライアントを作りはじめた - みずぴー日記 で書いたTumblrクライントをリリースした。
テキスト主体のブログを書きやすくすることを目指している。 そのためMarkdownのライブプレビュー機能などを実装しているが、Reblog機能などは実装していない。
機能
- Tumblrへの投稿・更新
- Markdownのライブプレビュー
- 既存の投稿記事の取得
- 投稿先のブログの切り替え
- 投稿した記事をWebブラウザで開く
前回から、基本的には変わっていない。エラー処理などをだいぶまともにした。
実装していない機能
自分があまり使わないので実装してない。必要になったら実装する。
- MacOS X以外のサポート
- Text以外の記事
ダウンロード
https://github.com/mzp/tumblotte/releases/tag/0.1.0
前回からの変更点
dmgの作成
インストールするときに使うdmgを作った。以下のような /Applications
へのコピーを促すような背景画像も作成した。
コード署名の追加
*.app
を作るときにコード署名をするようにした。
細かい修正
自分で使っていて気になった部分をいくつか修正した。
- 常にライブプレビューを行なうとレスポンスが悪いので、300ms以上キー入力がなかったときにプレビューを更新するようにした。(debounce)
- メインメニューの項目を整理した。
- ライセンスとしてMITライセンスを採用した。
⌨AquaSKK 4.3.4: US配列におけるAZIKの動作改善
US配列 + AZIKにおいて、x[
で 「
の入力を行なえるようにした。
ダウンロード
https://github.com/codefirst/aquaskk/releases/tag/4.3.4
変更内容
US配列 + AZIKでは [
がかなモードの切り替えに使われる。 そのため、[
に割り当てられている 「
の変換が行なえない。
ddskkでは x[
で 元の [
を代用できるようにして、この問題を解決していた。(参考: SKK Manual: AZIK)
AquaSKKでもこの方式を採用することにした。
余談
🎍新年
Copyright(C) 2014-2016 という部分を更新したので、新年を迎えた感じになった。
状態遷移機械
変換の動作は、専用の状態遷移機械記述ライブラリで定義されている。 このライブラリに関するドキュメントは Generic State Machine Library for C++ しか残っておらず、苦労した。
分かったことをメモしておく。