StrawberryPerlをインストールして環境を構築

　まず、無料のPerl環境、StrawberryPerlをインストールして環境を構築しました。当初Windows10のBash on Ubuntu on Windowsに処理を投げようとしたり、ActivePerl使おうとしたりで四苦八苦しましたが、Bash on Ubuntu on WindowsだとXojo内からシェル経由でコマンド投げようとするといろいろ支障が出てきて動かなかったり（一応このあたりに知見はあるようなんですが手に負えず）、ActivePerlはXMLパーサーモジュールのインストールこれどうすりゃいいのよだったりして結局StrawberryPerlに落ち着きました。これ素晴らしいです。インストーラ普通にあるしCPAN普通に使えるし。セットアップはこのあたりを参考に。

実行ファイルと同じフォルダにPerlのファイルをコピーする指定

　Macではアプリ自体実はフォルダなので、アプリ内のフォルダにPerlのスクリプトをコピーしていたのですが、Winではそういう扱いにならないようなので実行ファイルと同じ階層にコピーする指定をします。で配布時には親フォルダごと渡す。まあ一般的なやつですね。ビルド設定のWindowsのところでビルドステップに「ファイルのコピー」を追加してやり、ウィンドウにコピーするファイルをドラッグアンドドロップしてコピー先に「Contents Folder」を指定すればいいようです。なおサブディレクトリ作ってそこにコピーする指定もできる模様。

XojoからPerlにシェル経由で処理を投げて実行

　あとはXojoからPerlにシェル経由で処理を投げるだけですが、Macとはフォルダの階層が異なるのと、StrawberryPerlの場合はBashではなくコマンドプロンプトに処理を投げることになるためパスやパイプ（コマンド連続実行）の記法が異なることに注意が必要なようです。具体的にはパスはシングルクォートではなくダブルクォートで囲まないとエラーになりますし、パイプに使う記号は「;」ではなく「&」です。なおXojo内でFolderItemのパスを「.NativePath」でString値として取得するとシングルクォートで囲まれた形でパスの文字列が返ってきてしまうので、変換してやらないと処理が通りません。ということでコードは以下のような感じ。

　シングルクォートをダブルクォートに変換するメソッドは以下のような感じ。なお引数pathStringをString型で定義していて、戻り値もString型で返す感じ。

　ここもうちょいスマートな感じで処理できればなと思うんですけどね。正規表現でゴリゴリ変換ってすごく泥臭い。

IDMLを使った自動組版処理の初歩的実験

　InDesignから書き出せるファイル形式のひとつにIDML（InDesign Markup Language）というものがあります。これはInDesignの通常の記録ファイルと完全な互換性はないのですが、ほとんどの内部情報を保ったまま下位バージョンで開けるようになるため、やむを得ず下位バージョンでデータを開くような場合に使われたりしています。で、このIDMLは実はZIPのパッケージファイルで、解凍すると中にXMLファイルや画像ファイルが階層化されて収納されているのが確認できます。
　であるならば、

1. あらかじめ決められた名称で差し替え部分のテキストを作ったInDesignのデータを作り
2. それをテンプレートとしてIDML形式で書き出し
3. IDMLをテンポラリ領域にプログラムで解凍し
4. 別途差し替え用のテキストデータを（CSVなどで）読み込んで、解凍したIDML内テキストに対して置換処理を行い
5. 置換処理完了後のIDMLをリネームして出力する

　というような手順で簡単な自動組版処理ができるのではないかなと考えました。

普通に再圧縮してもダメ

　まず最初にこの手順を手動でやってみたのですが、どうやら普通にZIP形式で再圧縮してもInDesignで読み込めないようです。ちょっと調べてみるとこちらのフォーラムに情報が。
　なるほど、mimetypeを非圧縮の状態でZIPファイルの先頭に置かなきゃダメと。要はEPUBと同じですね。話が早い。

　ということで作ってみたコードが以下。macのターミナル画面で

perl csv2idml.pl CSVファイルのパス IDMLテンプレートファイルのパス 最終出力先フォルダのパス

　と入力すれば動くはず。ああ、CSVを扱うためのモジュールとしてText::CSV_XSを使ってますのでCPANから入れる必要があります。このあたり参考にどうぞ。

　テスト用のIDMLのファイルとCSVファイルもセットで置いときます。ごく簡単な名刺のテンプレートですがまあテストなので。CSVの氏名はダミーとして自動生成させたものです。

JLREQ 3.1.10 g 分割禁止

　改行による泣き別れを抑止する文字についての記述。
　gは「ルビ」について。ルビ文字と親文字はバラさない。モノルビは親文字単位ではバラしてよい。グループルビは全体を分割禁止する。ルビ自体に関しては後で詳しくやるのでここではこれまで。
　i 添え字。これも添え字と親字の分割は禁止。
　j 注の合印の分離禁止。HTML的にはa要素で合印を囲む形になるか。CSSでwhite-space:nowrapで合印内を分割禁止にできる。

　また、「○○（1）」のようなパターンでCSSを用いて合印とその直前の文字との間を分割禁止にするには、CSS Text Module Level4で論議中のwrap-before:avoidが使えるようになれば可能になるはず。

　あるいは現状で使える方法として、ノーブレークスペース（ ）を入れてもよい。また、U+2060（Word Joiner）も同様の効果を持つはずだが、こちらは一般的な日本語フォントにはコードポイントの割り当てがないようだ。

JLREQ 3.1.11 行の調整処理で​字間を​空ける処理に​使用しない箇所

　文字のアケ処理について書いてある項目。空けすぎてはいけない部分などに関しての記述がある。「行の調整処理の際に，字間を空けて処理する場合，次の字間には空き量を入れることは避ける（分離禁止ともいう）」とある。分割禁止と分離禁止の用語の違いに注意。
　「規定された調整処理では処理できない場合に限り，欧字の単語の字間を空けることを許容する考え方もある」とあるが、欧文組版では組版調整に単語の字間を真っ先に使うのが普通。ここは昔ながらの欧文の字間は3分アキとしてきた日本の活版の慣習が残っている部分か。

　「b. 上記以外では，次も行の調整処理で字間を空ける箇所としては避ける．　1. 始め括弧類（cl-01）及び終わり括弧類（cl-02）の前及び後ろ．」
　ここは表記がちょっと不明瞭か。始め括弧類の後、終わり括弧類の前、ではないか。直後の注で補足してあるが。

JLREQ 3.1.12 行の調整処理例

　ツメ処理、アケ処理の具体的な適用例の記述がある。
　なお、CSS Text Module Level4で議論中の「text-spacing」で「no-compress」を指定すると、justificationでのツメ処理をしない。これを指定しないと文字ツメ処理が行われる。
　このあと3.8で文字ツメに関してはより詳しくやるのでここではここまで。

JLREQ 3.2.1 和文と欧文との混植

　日本語の文章内に欧文の文字を入れる際のバリエーションに関する記述がある。大別すると全角の文字を使っての正立表示、欧文の文字をそのまま入れて横転表示、数字などで使われる縦中横の3種類がある。

JLREQ 3.2.2 横組の和欧文混植に用いる文字

　「なお，欧文間隔は，三分アキを原則とする．」との記述があるのだが、ここは本来はそれぞれ欧文フォントが持つスペースのプロポーショナルな幅に従うべきとの意見が出た。この記述自体は古い日本の活版のルールが起源だと思われる。伝統的なルールの記録という意味でJLREQにこの記述があることは間違っていないが、現時点でそれに盲従すべきでもないと考える。

CSS：数字の字形の種類の指定
　font-variant-numericは数字の字形の指定項目。Old-Style、Tabuler（等幅）、Lining（高さが揃う）などが指定できる。ただし、もちろんフォント側がそのバリエーションを持っている必要はある。minionやGaramond Proなど新しいフォントは情報を持っているはず。例えばCentury OldStyleなどは作られた時期が古いため、こういったバリエーションは持っていない。

JLREQ 3.2.3 縦組の和欧文混植に用いる文字

　「プロポーショナルな文字を用い，全角のスペースに正常な向きにして配置する方法もある．」との記述があるが、「正常な向きにして」はちょっと表現的にどうだろうか。「正立させて」あたりが順当だと思う。雑感だが何を持って正常とするのかという宗教論争に発展しかねないと思う。

CSS：文字の正立／横転
　text-orientationで指定できる。uprightで正立、sidewaysで横転。段落全体に対して指定もできる。なお、関連する話として、UTR#50で論議されてきた縦書き時の文字の向きの既定値の話がある。これは最近Unicode10.0.0に正式に規格として入った。今後Webブラウザではこれをベースに何も指定しなかった際の文字の正立／横転の向きが決められるものと思われる。ただし、InDesignやWordなど、既存のアプリとの文字の向きの差異はずっと残ると思われる（過去のデータの互換性を考えると簡単に変更はできない）。

CSS：縦中横
　EPUB3策定前後でプロパティ名が目まぐるしく変わった項目。今の正式プロパティはtext-combine-uprightだが、昔はtext-combineでそのあとtext-combine-horizontalになっている。多くのRSでは古いプロパティでも縦中横になるが、今後はtext-combine-uprightを指定しておくのがもちろん正しいと思う。
　なお、text-combine-uprightでは単純に指定範囲を縦中横にする指定、「text-combine-upright:all」以外に、いわゆる自動縦中横の対応として「text-combine-upright: digits 2」といったような指定も可能になっている。ただしまだ数字の縦中横のみが想定されており、アルファベットや小数点はは範囲外。今後の提案と拡張が必要と思われる部分か。

JLREQ 3.2.4 全角のモノスペースの欧字及び​全角の​モノスペースの​アラビア数字の​配置方法

　図100に関連して「全角のモノスペースのアラビア数字の途中に小数点として中点[・] (KATAKANA MIDDLE DOT)を用いる場合は，漢数字の場合と同様に，原則としてその前後をベタ組とする．」とある。これは組版調整ありきで固定された版面をつくるための方法を記録したJLREQの記述としては良くわかるのだが、Webや電子書籍など組版調整が難しい分野でその中点が小数点なのかそうでないのかを自動判別して処理するのは難しそうである。「二、三点」などの場合に用いられる読点のベタ処理も同様。InDesignにはここの処理のために「連数字処理」というチェック項目があるが、組版処理的な弊害もあるため一律に使っておけば良いというものでもなく、難しそう。

JLREQ 3.2.5 縦中横の処理

　Opentypeのフォントは等幅半角字形、等幅3分字形、等幅4分字形などの情報を持っている。これらは縦中横組版の際に綺麗に1文字の幅に数字やアルファベットを収めるために作られたと思われるもので、InDesignでは字形パレットを通じて文字種を切り替えることができる。CSSではまだ十分に整備はされていないが、font-feature-settingsでOpenTypeのプロパティを直接指定すれば切り替わるかもしれない。等幅半角字形のプロパティは「hwid」、等幅3分字形は「twid」、等幅4分字形は「qwid」。ただし表示フォント側がそれに対応する字形の情報を持っていなければ当然適用はされない。ちょっと見てみた感じでは、一般的なAdobe-Japan1規格の日本語フォントでは、数字は等幅4分字形までの情報を持ち、英文字は等幅半角字形までの情報を持っているようだ。その他かな／カナも等幅半角字形にすることができそう。

CSS：縦中横でたくさん文字が入った場合の圧縮ルール
CSS Writing Modes Level 3に 「9.1.3 Compression Rule」として、縦中横でたくさん文字が入った場合の圧縮ルールの規定がある。それによれば、CSSでは全体で1emに収めることを規定している。ここはJLREQとは違うが、後から手動で組版調整ができないWebの特質を考慮すれば妥当と思う。また、表示フォント側にhwid、twid、qwidの情報がある場合はそれを使うことというような規定もある。なければ変形してどうにか1emに押し込む、という方針のようだ。

JLREQ 3.2.6 プロポーショナルな​欧字を用いた​和欧文混植処理

　「b.追込み処理で字間を詰める場合，その処理対象として欧文間隔を優先的に使用し，追出し処理で字間を空ける場合も，その処理対象として欧文間隔を優先的に使用する．」
　ここでは和欧間のスペースは3分という前提なら多少ツメてもよいだろうが、JIS X 4051の規定では和欧間のスペースは4分であるため、それを踏襲するのであれば4分よりもツメるのはツメすぎではないか、という意見が出た。なお現状Webや電子書籍などでは和欧間は自動で空かないが、将来的にはCSSでtext-spacingで自動でアキが入ることが期待される。