iPhoneX 全画面対応

iPhone Xが発売されて数カ月が立つが、iPhone Xはこれまでと違う独特のアスペクトレシオを持ち、アプリもそれなりの対応が必要になる。
当方の開発環境はこれまでMac OS X 10.11 El Capitan および Xcode 8だったが、iPhone Xの対応はXcode 9以降となる。さらにXcode9の動作環境はmacos X Sierra以降なので、iPhone Xエミュレータを試すには開発環境をアップグレードしないといけない。
開発環境を更新するのはリスキーなので、VMWare Fusionでmacos X Sierra環境を作り、その上でXcode9のiPhone Xエミュレータを動かしてEBPocket for iOSの動作確認を行い、対応できたものと思って安心していた。（→iPhone X の解像度の問題 - hishidaのblog）
ところがiPhone Xの実機で全画面で動作させるには、Xcode9でビルドおよび提出が必要であり、Xcode8以前でビルドしたアプリをiPhone Xで実行すると上下に黒い枠が表示されることがわかった。
いずれはXcode9以上でないとアプリの提出が認められなくなるので、重い腰を上げてXcode9対応を行うことにした。

1.まずMac OS Xを 10.11 El Capitanから10.12 macos X Sierraにアップグレードする。これ自体は特に問題は無い。
2.次にXcode9.2をインストールし、Xcode8時代のプロジェクトをコンパイルしてみると、早速コンパイルエラーの山となった。

• Xcode8以前に作成したxibが全てコンパイルエラーになる。プロパティのbuild for でiOSのバージョンを指定する必要があるらしい。一つ一つ"iOS 7.0 and later"を指定して再コンパイル。
• 10.11以前のXcodeプロジェクトをコンパイルすると、Code signing error が出る。

Command /usr/bin/codesign failed with exit code 1
Code signing fails with error 'resource fork, Finder information, or similar detritus not allowed'

Technical Q&A QA1940: Code signing fails with error 'resource fork, Finder information, or similar detritus not allowed'
上のURLに書かれているように、次のコマンドを実行することで解決。

xattr -cr プロジェクトディレクトリ

3.これで大丈夫と思いきや、iOS11で実行するとUIScrollViewのcontentInsetがずれるという凶悪な問題が発生。
iOS11 で UIScrollView の contentInsetがずれる問題
上記URLとは違う解決方法だが、結局、次の方法でiOS11のcontentInsetの自動調整を抑止し、さらに表示位置をiOSのバージョン毎に調整することで解決。

MainWindow.xibのRootViewControllerで下記設定を行なう
Adjust Scroll View Insets : チェックを外す ←勝手なcontentInsetの自動調整を止める
Under Top Bars : チェックをつける←NavigationBarの高さが変わっても潜り込まずにbarの下に表示される

iOS6からiOS7になるときにもNavigationController Barの下にUITableViewが潜り込むという問題が起きたが、その時の対処が不完全であったことが、iOS11になって表面化したらしい。
やはりお前らのiOS7対応は間違っている(解説編)
ただ今回のやり方が合っているのかどうかはわからない。そのうち「おまえらのiOS11対応は間違っている」と言われるかもしれない。
一時はもうAppStoreに提出できないのではないかと思って悩んだが、最終的には無事Xcode9でiPhone X対応版を提出することができた。

一つの問題点として、Xcode9でビルドすると、TargetOSの下限がiOS8になってしまう。ただしiOSは大多数のユーザが最新のOSに速やかにバージョンアップするので、実際は問題は無いだろう。
iOSはメジャーバージョンアップごとに破壊的修正が入るので、開発者にとっては大変である。

iPhone X の解像度の問題

「EBPocket が iPhone Xに対応していない」というご意見を頂いたので、Xcode 9 のエミュレータで確認したところ、横画面のときに検索一致リストと本文の横幅がイビツになっていることがわかった。次のスクリーンショットのように、本文の方が幅が狭くなっている。本当は横位置の時は本文の幅を広く取りたい。

これはiPhone X だけアスペクトレシオが2:1と縦長であることが原因だ。

デバイス名	画面サイズ	画面解像度	アスペクト比
iPhone X	5.8 inch	2436 x 1125	2:1
iPhone 8 Plus/ 7 Plus/ 6s Plus/ 6 Plus/	5.5 inch	1920 x 1080	16:9
iPhone 8 / 7 /6s / 6	4.7 inch	1334 x 750	16:9
iPhone5/5S/5c/SE	4.0 inch	1136 x 640	16:9
iPhone4/4S	3.5 inch	960 x 640	3:2
iPhone3G/3GS	3.5 inch	480 x 320	3:2

これまでは短辺側の幅が必ず本文の幅だったが、iPhoneXだと横位置の時は、検索一致リスト側を短辺の幅にしないといけない。修正後はこんな感じ。

エミュレータでしか検証していないので不安だが、とりあえず修正版を提出してみた。

P.S.
当方の開発環境は未だにOS X El CapitanおよびXcode8だが、どうやらXcode8でビルドして提出すると、iPhone X の全画面にならず、上下に黒い領域が表示されるらしい。Xcode9 はmacOS Sierra以上の対応なので、Xcode9 で本番用のプログラムをビルドして提出するには、メインのMacbook proをmacOS Sierraか High Sierra にアップデートし、Xcode9をインストールしなければならない。環境を完全にバックアップする必要もあるので、たぶん1日がかりの仕事になる。対応にはまだしばらく時間がかかる模様。

EBStudio リニューアル計画(6) EBStudio2 for Mac

EBStudio2のWindows版は12/1にリリースし、Vectorによる販売、および優待アップグレードも始まっています。
EBStudio2
お待ちかね？のEBStudio2 for Macも、本日より公式HPにて配布を開始。Windows版とライセンスキーは共通なので、Windows版を購入された方はMac版もフル機能が使用できます。
Mac版のEPWING辞書圧縮ユーティリティEBShrink for Macも同梱しており、EBMac と組み合わせれば、Mac OS XだけでEPWINGの辞書作成、辞書の圧縮、閲覧まで完結させることができます。
今後の予定では、任意のXMLからの変換を可能にするという作業が残っています。つまりXMLのどの要素を見出しやキーワード、装飾に使用するかというセマンティックを定義できるようにするということ。
ここまでできればEBStudio2のリニューアル計画は終わりになりますが、ちょっと疲れているので、あとは休み休み進めたいと思います。

lingvo辞書の要望について

EBPocket/EBWin4もlingvo辞書の要望をいただいていますが、こちらはちょっと手強そうなので、サポートが可能かどうかは今のところはっきりしません。lingvoはロシアのABBYY社の辞書フォーマットで、ソース形式のDSL形式とコンパイル形式のLSD形式があります。LSD形式は非公開ですが、LSDからDSLへの逆コンパイラが公開されているのと、DSL形式にネイティブ対応しているGoldendictのソースが参照できる(ただしGPLなので流用不可)ので、これらを参考にすれば、原理的には対応は可能。問題は解析と開発にかかる時間コストが妥当かどうかですね。
解析資料を誰かが文書化していて、StarDictやMDictと同程度の開発時間で対応できそうなら脈がありますが、今の所分かっている資料では、解析にかかる時間が大きすぎて、私が個人的に割ける時間が限られていることを考えると、厳しいと言わざるをえません。
妥協案としては、DSL形式だけサポートして、初回起動時にインデックスを自前で作るという手がありますが、ストアで売られているlingvoの辞書はLSDだけなので、ユーザの希望とは違うと思います。

EBStudio リニューアル計画(5) 今後の予定

すでにHPで告知済みですが、EBStudio2のリリースについて、次のように決めさせていただきました。

• EBStudio 1.70 は2017/11/30をもって販売終了。
• EBStudio2は2017年12月に販売開始(予価1000円+税)。
• 既存のユーザの方は、優待アップグレードを実施(500円)。
• EBStudio2の開発意向発表を行った2017年9月以降に購入された方は、希望者は無償アップグレード
• Mac OS X版は来年リリース。ライセンスキーはWindows版と共通とする。
• 「ライセンスキーを入力しない場合は前方一致検索だけ作成できる」という仕様は以前と同じ。

無償アップグレードを期待しておられた方には大変申し訳ありませんが、旧ソースからのリファクタリングに多大な時間を要しており、新アプリを開発するぐらいの作業量がかかっているので、ご理解いただければ幸いです。

なお、旧　EBStudioとの互換性に関しては、次の大型辞書での変換で確認しており、各種変換ツールキットで変換したEBStudio用HTMLは、ほぼ変換できると考えています。

• マイぺディア
• 世界大百科事典
• 小学館スーパーニッポニカ2003
• 大辞泉
• 岩波仏教辞典
• グランドコンサイス(DTONIC)
• LDOCE4
• Collins COBUILD
• 学研Super日本語大辞典

EBStudio リニューアル計画(4) CSVファイルからの変換

今回新たに、CSVからEPWINGへの変換をサポートした。一般的な利用者がEPWING辞書を自作したいと思った場合は、CSVからの変換が一番簡単だと思う。EXCELやAccessなどで作りためた個人辞書をCSVで保存すれば、EBStudio2 でEPWING辞書に変換できるので、非常に便利だ。
CSV変換の仕様：

• 一行目は見出し行とする
• 項目区切りは、カンマ(,) タブ 縦棒(|)をサポートする
• 文字エンコードは Shift_JIS,UTF-8,UTF-16をサポートする
• テキストウィザードを起動すると、CSVの一行目を読み込み、列ごとに見出し語(headword)、本文(meaning)、かなインデックス(kana)、表記インデックス(keyword)を定義する。見出し語からは表記インデックスも作成する。

ソースのタイプからCSVを選ぶ

Text Wizardを起動し、列ごとに型を指定する

EBStudio2で利用できる入力形式をまとめると：

	Shift_JIS	UTF-16	UTF-8
HTML(EBStudio互換)	○		◎
PDICテキスト	○	◎
PDIC一行形式	○	◎
PDIC	PDIC for Win32	◎PDIC/Unicode
辞郎形式	○
プレインテキスト	○	◎	◎
XHTML(libxml2)	◎	◎	◎
CSV	◎	◎	◎

◎ - EBStudio2で新たに追加したもの

EBStudio リニューアル計画(3) XMLライブラリ

おさらいすると、EBStudioでは次のようにHTMLからEPWINGへの変換をサポートしている。
辞書系のコンテンツ
EBStudioの設計を行ったのは1999年頃だが、辞書や書籍の入力ソース形式をHTMLにしたのは正解だったと思っている。HTMLなら理解が簡単で、プログラマでなくても記述が容易だ。なによりも辞書コンテンツはすでにSGMLなどの何らかのマークアップ言語で記述されていることが多いはずで、HTMLなら既存のマークアップ言語からの変換が簡単だからである。当時はXML1.0が出たばかりで、利用が広がるかどうかはわからなかった。

さてHTMLやXMLを解釈するには構文を解釈するパーサーが必要だが、当時はデファクトといえるパーサーのライブラリがなかった。当時利用できたC言語のXMLパーサーのなかで今日も命脈を保っているライブラリとしてはexpatがあるが、結局EBStudioではexpatは使わずにパーサーを自作した。
実はこのパーサーを自作したことが、EBStudioの欠点の一つになった。その後XML関連の技術はXSLTやXPointerを始め大きく発展したが、EBStudioではこれらが使用できない。きちんとしたHTML/XMLパーサーを搭載したいという構想はずっと持っていた。

Libxml2

今回のリニューアルでは、広く使われているXML CパーサーであるLibxml2を採用した。Libxml2はHTML/XMLの両方がパースでき、DOM,SAX,XSLT,XPointerに対応している。
The XML C parser and toolkit of Gnome
Libxml2のライセンスはMIT Licenseなので商用でも利用できる。ただし、Libxml2と同時に使用する文字コード変換ライブラリであるlibiconvはLGPLなので、商用に使うには問題がある。調べたところ、libiconvの代わりにicuが使用出来ることが分かった。
Kotorel: VC++でxmlを扱おう - libxml2の紹介
ただし、従来の自前のHTMLパーサーも残してあって、どちらのパーサーを使うかを選択できる。なぜなら、EBStudioを前提とした変換ツールキットがネット上に多数存在するので、下位互換性を残しておかないといけないからだ。

JepaX,DicX,LeXMLについて

さてXMLが利用できますと言っても、XMLは拡張可能なマークアップ言語に過ぎなくて、マークアップされた要素が見出しなのか、本文なのか、検索キーなのかを指定しなければならない。
実は日本電子出版協会(JEPA)出版データフォーマット標準化研究委員会が定めた出版物交換用XMLフォーマットJepaXというものがあり、Ver0.9で仕様が止まっているが、出版業界内部では利用されていると聞いている。
このJepaXをさらに辞書向けに改良したDicXという仕様案(イースト株式会社)もあったのだが、DicXはすでにメンテナンスがされておらず、サイトも消滅している。
その後DicXの後継規格として株式会社ディジタルアシストが策定したLeXMLが普及し、出版業界ではデファクトになっている。
JEPA｜日本電子出版協会 LeXMLとは？
EBStudioのリニューアルにあたっては、一応これらの規格との整合性を考えておかないといけない。

新パーサーの考え方

ではJepaXとLeXMLをサポートすればいいのかということだが、サポートしても恩恵をうけるユーザはほとんどいないという結論に達した（ディジタルアシストさんは確実に喜ぶと思うけど）。
結局、EBStudio2の新パーサーでも、基本はHTML4.0とXHTML1.0を使用することにした。EPWINGは利用できる書式指定が限られており、HTMLでも十分なことが多いのと、利用者もHTMLに慣れているからだ。
ただし部分的にLeXMLの要素を利用したいケースがどうしてもある。具体的には、辞書の検索インデックスを指定したい場合だ。
EBStudioでは <h1>〜<h6>タグと<dt>タグは検索キーになるという仕様だが、それ以外に本文上は現れない検索インデックスをつけたい場合がある。
DicX/LeXMLには<key>という専用の要素が定義されており、従来のEBStudioでも、HTMLに対する独自の拡張仕様として利用できた。だがこれはHTMLとしては文法違反であり、Libxml2を使うならちゃんと整合性をとらないといけない。
そこで次のようにXMLネームスペースを利用して、XHTMLで記述してもらう。これならXMLとして正当だ。

ああようがん

既存のXMLへの対応

既存のXMLコンテンツがあった場合に、EBStudioで変換したい場合にどうするかだが、今のところは、「XSLTで XHTML に変換してね」、というスタンスだ。
だが、既存のXMLの各要素に対して、個別に [見出し語] [本文] [検索キー] [修飾要素] ... のように意味を割り当てる方法もありえる。これなら既存のXMLをそのまま読ませることが可能なので、たとえばWikipediaのXMLを読ませることもできるかもしれない。
こちらも将来の追加開発で検討したい。

EBStudio リニューアル計画(2) Unicode外字自動割り当て

今回のリニューアルの目玉の一つとして考えているのが、Unicode外字の自動割り当て機能である。
ご存知の通り、EPWINGは規格の制定時期が古いために、文字コードはJIS X 0208(第一水準、第二水準)しか使用できない。それ以外の文字は外字としてビットマップで定義することになる。
EPWING辞書を自作しようとすると、外字のビットマップを作字する手間が避けられない。EBStudioの場合、次のように外字のビットパターンを指定する外字定義ファイルと、外字コードとunicodeのマッピングを定義する外字マップファイルの二つのファイルを用意する必要があった。非常に手間のかかる面倒な作業だ。

外字定義ファイル:

  ##    
  ##    
   #    
   #    
  #     
        
        
        
        
        
        
        
        
        
        
        


        
        
        
        
        
   ### #
  #   ##
 #     #
 #     #
 #     #
 #     #
 #     #
  #   ##
   ### #
        
        


        
        
        
        
        
   ###  
  #   # 
 #     #
       #
       #
       #
 #     #
  #   # 
   ###  
        
        

〜

外字マップファイル:

〜

EBStudioを利用するには、辞書・書籍のソースをEBStudio用のHTMLに変換することと、外字の作成という二つのハードルがあった。実際にはほとんどのユーザは、有志が作成した辞書変換ツールキットの結果をそのまま使っていたのではないかと思う。
今回のリニューアルの目的の一つは、EPWING辞書の自作のハードルを下げることであり、外字作成の手間はどうしても簡略化したかった。
今日ではせっかくUnicodeがデファクトになっているのだから、辞書のソースはUnicodeで記述し、Unicodeの文字集合のビットマップフォントをEBStudioの内部で持てば、外字を作成しなくてもいい。
もちろんUnicodeにない記号を使用したいこともあるので、従来の外字定義ファイル、外字マップファイルも併用できるように残してある。
問題はUnicodeのフォントをどこから持ってくるかだ。OSのフォントを使用することはライセンスの問題でできないので、フリーで使用出来るビットマップフォントとして、電子書体オープンラボで配布されているhexファイルを使用することにした。
/efont/ Electronic Font Open Laboratory

hexファイルとはこのような形式である：

8 16
0020:00000000000000000000000000000000
0021:00000000080808080808080008080000
0022:00006622224400000000000000000000
0023:000000001212127E24247E4848480000
0024:00000000083E4948380E09493E080000

次の画面はPDIC Unicode版の英辞郎から EBStudio 2 で変換したものだが、外字は上記の電子書体オープンラボのフォントから自動作成しており、作字は一切行っていない。発音記号に注目してほしい。

もう一つの目玉の機能として、EBPocketやEBWin4,EBMac用の外字Unicodeマップファイル(.map .plist)も同時に作成される。CATALOGSと同じ場所に外字Unicodeマップを置いておけば、外字をUnicodeで表示するので、何もしなくてもきれいに外字を表示できる。