XSL-FOのwriting-mode

writing-modeの実装は、いろいろ大変なようだな……。
Apache FOPとRenderX XEPでのwriting-modeの対応を見てみた。

Apache FOP

[Apache FOP Compliance Page]
writing-modeには対応していない。

いちおう、writing-mode="lr-tb"、"rl-tb"、"tb-rl"なんかを受け付けるけど……。
"rl-tb"は、座標系の原点が左上から右上に、そしてX方向が逆になる。レンダリングされた文字列が鏡に映したようにひっくり返る。
"tb-rl"は描画の向きを時計回りに90度寝かせる(XSL-FO的には反時計回りに-90度か?)。だから、時計回りに90度回転させた文字が、上から下に並ぶということになる。
座標の変換やってる(であろう)"CTM.java"ってのを見たら、アフィン変換で座標を写像しているだけみたいだ……。すごい力業だな。
さらに、"rl-tb"を指定したエリアの子エリアに"lr-tb"を指定したとしても、親エリアと同じ"rl-tb"のまま。"CTM.java"で、アフィン変換用の行列を表現するクラスCTMが定義されている。クラスCTMには、CTMオブジェクトの積を得るメソッドがある。もしかして、親エリアと子エリアのCTMオブジェクトの積を求めてるんじゃ……。それで、"rl-tb"エリアの子が"lr-tb"の場合、得られるCTMオブジェクトは、"rl-tb"のCTMオブジェクトと同じものになってるのでは?*1 "rl-tb"の子エリアに、さらに"rl-tb"を指定すると、"lr-tb"指定とおなじものになるんだが、"rl-tb"のCTMオブジェクトどうしの積の結果、"lr-tb"のCTMオブジェクトと同じものが得られるから、やっぱCTMオブジェクトの積を求めてるんだろうね。
あるエリアのwriting-mode記録して、親と子のwriting-modeを比較して……とか処理するのを嫌って、座標変換の行列の積を求めるって処理にしてるのだろうか?
アフィン変換でwriting-modeってこと自体が、すごい無理矢理な実装だと思うけど、でもwriting-modeに正式対応してるなんて書いてないから、この処理にあまり文句はつけまい。
あと、バッドノウハウの部類になるものではあるけど、"rl-tb"指定エリアの子エリアに、さらに"rl-tb"指定して"lr-tb"に戻すっていうの、わかって使うぶんにはいいかもね。
他のXSL-FO処理系には渡せないものになるけど。

RenderX XEP

[XEP User Guide - Appendix A. XSL-FO Conformance]

writing-modeプロパティに関しては、次の記述がある。日本語縦書きに必要な"tb-rl"などには対応していない。

Only "lr-tb" and "rl-tb" values are supported. All other values are treated as "lr-tb."

でもまあ、"lr-tb" と "rl-tb" に関しては、ちょこちょこいじった感じ、それなりに、きちんと実装されている感じはする。
まあ、"rl-tb"でアラビア文字とか扱ってみたわけじゃないから、細かいところでおかしな処理してるかもしれんけど、そこまでは試してない。

*1:このへん、想像。あまり細かいところまでは読んでない。