【Typefi】自動組版 その2

ニッチなんだよね２

いつのまにかCS7ならぬCCまで出てしまいました。

久しぶりに更新しようかなーとか思います。

右流れ組版

ME版の起動

いつの間にか仕事では実際に使用してましたね・・・

InDesign CS6から、ME版の機能がデフォルトで組み込まれています。

ですが、日本語版インストーラーではME版をインストールすることはできません。

実は、日本語版インストールでインストールできるのは英語と日本語なのですが、

英語版をインストールすると、「CJKVはサポートしてねぇから、対応したバージョン入れろよ！」って怒られます。

英語版では、日本語版で作成したファイルを開くことすらできません。

これは、Wikipediaに書いてる情報を信じると・・・

Adobe InDesign日本語版は、日本でのニーズに合わせて大規模な改修が行われており、ことに日本語特有の多様な文字組みルールを実現している点で、「日本語ローカライズ製品」というよりも「日本市場用製品」といえる製品に仕上がっている。

とのことなので、開くことができないのは頷けますねー。

自分の予想では、日本語対応段落コンポーザーだと睨んでいるんですが、調べてはいませんｗ

InDesign Serverでは、使用可能な言語は全てインストールできます。

が、おすすめは「English（International）」です。

InDesign Server自体の情報があまり（特に日本語は）ありませんが、言語特有の問題を起こしにくいというのが理由です。

さて、話しを戻します。

ME版は日本語版でもインストール自体はされています。

ですが、編集言語設定がレジストリに隠されているため、この設定をME版（アラビア語版）に変更しなくては行けません。

※UIの言語設定もありますが、こちらはいじってもあまり意味無いです。

1. InDesignを終了しておく
2. レジストリエディターを起動する
3. HKEY_LOCAL_MACHINE\SOFTWARE\Adobe\InDesign\8.0\Feature Set Locale Setting の値を103にする
4. Windowsを再起動する

これでME版が立ち上がります。

ワークスペース等の情報が別で保存されてしまいますが、日本語版に戻すと元の情報を読み込みます。

ME版の注意点

注意点は色々あるんですが、大きくは↓な感じですかね？

• テキストフレーム自体がME版用のため、使い回しは厳禁
• 段落は段落設定で右寄せ、右流れに変更する
• 多言語複数段落コンポーザーにする

カシダスやらディジット変換やら色々ありますが、これは自動組版をする際の問題（どのようにレイアウトするか）とイコールなので、ME版を使用すること自体では問題は起きにくいかと思います。

英語版やME版のメニューを見ると、日本語版のメニューの多さにビビります。

ME版の問題は、組版以上に言語特有のルールが大きな壁になります。

インド数字・ペルシア数字間における拡張数字の違いや、括弧やハイフン、ピリオドなどに起こるディレクションの問題がそれです。

慣れればいいんですかね？！

タイ語に比べれば可愛いものです！！

※InDesignがタイ語に対応していないため、TypefiもInDesignと同じ状況になります。

Typefiでの組版

やっとこ本題ですね・・・

Typefiでは特に問題なく右流れを組みことが可能です。ほぼ。

ほぼと言うのは自分でチェックができないからです！

まぁ、アラビア語圏の人間ではないですしね・・・

ネイティブの方にチェックはしてもらいますが、やはり何か不安が残ってしまうのは日本人だからなんでしょうか？

それと、左流れと右流れの言語を1つのInDesignファイルにまとめることはおすすめしません。

テキストフレームが右流れ専用というのもそうですが、InDesng上で両側から開始とか気持ち悪い事ができないためです。

できるソフトもあるんですがね・・・

段落スタイル、文字スタイルなどのスタイル系の設定は問題ありませんが、表は問題が起こります。

右流れの言語では、表も右端の列が開始列になるため、自動組版では左右の入れ替えを行わなくてはならない等の問題が起きます。

InDesignでは表のディレクションチェンジが可能なのですが、Typefi上からはその設定を行うことができません。

この場合は別途プラグイン、もしくはJavaScriptなどで表のディレクションチェンジを行います。

【Javascript】クラス化ってどうよ？

すげー久々に更新したりしてみたり。

最近、JavaScriptと仲良しです。
といっても、ブラウザ向けじゃなくて、Adobe向けっていうのがまた変なんですが・・・

InDesign、Illustrator、Photoshop、Acrobat（いじった時間が多い順）とかやってて思ったのが、
クラス化してない人が多いな、と。

JavaScriptはなんちゃって（プロトタイプ）オブジェクト指向なので、クラス化する意味あるのかなーとかずっと思ってたんだけど、やってみると超便利だったっていうことがわかった。

結局、Adobe系のjsについてはデータドリブンな部分がhtmlに比べて少なく、メソッドチェーンが効果を発揮するのは自分でデータセットを準備した後のようなイメージ。

じゃあ、データ揃うまではどうすんの？って話に成るんだけど、関数やらでごまかしても限界があって二度手間、三度手間が発生しちゃう。

かといって、クラス化してるJavaScriptはあまり無かったもんだからさぁ困ったっていう話。

今、サンプルが手元にないので偉そうなこと言えないな・・・

今度アップします。

【Typefi】自動組版 その1

ニッチなんだよね

自動組版という狭い業界に住んでいます。多分、見に来ていただいた方は同業者さんになるのでしょう。

私が所属する組織では自動組版にTypefiというソフトを利用しています。
InDesignのプラグインとして稼働し、inddやindbファイルを出力することが可能です。
ですので、InDesignが対応しているファイル形式を出力することが可能です。

日本では導入しているところが少なく、残念ながら技術交流などがありません。
残念で仕方ありませんので、この場を借りてそういった思いを発散することで日本ユーザーも増えればいーなーとか思っています。

Typefiというソフト自体は、グローバル展開を行なっていて世界中にユーザーがいるそうです。
詳細はTypefi社のホームページで。

聞いた話によると、InDesign CS5で追加された段抜き機能はTypefiのシステムからスピンオフしたそうですよ？

Typefiの特徴

InDesignでテンプレート

こいつの特徴ですが何がすばらしいってなんと、InDesignで自動組版のテンプレートが作成できちゃう！

ということは、テンプレートに関して言えば既存のDTPオペレーターに任せることが可能です。いろいろと制約はありますが。

システム的にタチ位置がどうだとか、ツメがどうだとか、ランニングヘッダーがどうだとか面倒だと思っているそこのアナタ！一見の価値はあるかもです。

拡張可能

プラグインとして稼働するTypefiですが、javascript等での拡張が可能です。

ページ単位や見開き単位でスクリプトを走らせることで、細かな調整が可能になります。

他のプラグインも同時に走らせることも可能かも？

多言語実績

私のところでは20言語ほど行なっていますが、InDesignで可能な言語は対応可能の模様です。

アラビア語などの右流れをやりたいなーと思い、CS6で対応したのでワクワクしてます。

ワード組版

私は使ってませんが、ワードから組版が可能だそうです。

あるのに使わないとか宝の持ち腐れ？

WEB API

組版を行うマシンでWebサーバーが稼働することで自動組版の受付を行なっています。

ただし、独自で拡張可能なようにRESTでのI/Oが可能になっています。

デメリット

やはりあります。ここでは書きませんが、魔法のように自動組版が行えるわけではありません。

もともとはArbortextPrintPublisher(旧名称：3B2)を使っていましたが、やはり精度では追いつけていない所もあります。

こういったものに、トレードオフはつきものですね。

今回はこんなトコロまで。

次回はもうちょっと突っ込んでいきます。

【XSLT】入門編 その１

XSLTはじめます

一年ぶりに更新します。
ヤル気が出てきて自分でもビックリ。

さて、XSLTについて入門として触れていこうかなーとおもいます。

XSLTってなによ？！っていう方は・・・ぐぐってからお越しください、というのもなんですので、wikipediaでも御覧ください。

簡単にいうと、CSSと並ぶhtml(xml)用のスタイルシートです。
見に来てくださった皆様はきっともう知ってらっしゃいますよね？（という体で・・・）

いきなり2.0勧められてもわかんねーよ！っていう方がおられましたらすいませんでした。

私はXSLTは実務で使用しています。
自分なりの答えなので、間違いがありましてもご容赦ください。
（指摘していただけると幸いです）

ちなみにこの入門も2.0準拠で話を進めたいとおもいます。

だってみつからなかったんだもん

ネット、本ともにXSLTに関する資料は少なくはないのですが、実務での使い方や理想的な組み方について触れている資料は、少なくとも自分が探した範囲ではありませんでした。

多分、帳簿計算、データ抽出やデータトリミングに使われることが多く、変換という観点でのデータ全体の再利用方法のアプローチは、DITAなどのドキュメントデータレベルでしか使用されることが少ないのが原因ではないかなーと思っています。

しかも、DITAやDocBookなどの情報は日本語で解説しているページはあまりありません。
まーすごく日本人的だなーとか思っちゃいます。

入門編　その１

さて、入門するにあたって重要なキーワードが3つあります。

1. データモデル
2. コンテキストアイテム（旧名称：カレントノード）
3. ロケーションパス

はい、出ました。
この3つがわかればXSLTが理解できたも同然です。
けっこうマジな話本当です。

では詳細に入っていこうと思います。

１．データモデル

他のプログラム言語にもあるように、XSLTにもデータ型が決まっています。

1.0と1.1は変わらなかったはずですが、2.0になった時に大きく変更されました。

それがこれだ！

頭痛い系ですね。
W3Cにあるものそのまま持ってきただけです。

全体が理解できていると素晴らしいですが、本当に必要なのはこの部分だけです。

XSLTにおいて、このnode群が全てと言っても過言ではありません。

これを1つずつ見て行きたいと思います。

ちなみに緑色のところは関係ありません。

node：ノード

下記の種類を内包する抽象的なデータ型です。

nodeというデータ型がデータ上に存在するわけではありません。

attribute：属性ノード

属性ですね。属性値とは別物ですので注意してください。

hogehoge=""と表記されます。

comment：コメントノード

コメントですね。

<!-- -->という表記になります。

document：ドキュメントノード・ルートノード

ルートノードと呼ばれることもあります。

多くは対象の入力処理ファイル（xml）のことを指します。

element：要素ノード

要素です。

<div></div>または<div />という表記になります。

processing-instraction：処理命令ノード

これがちょっとわかりにくいですが、多くは先頭に書かれている宣言に使われています。

<?xml version="1.0" encoding="UTF-8"?>

ちなみに、phpの宣言も同じように扱えます。

<?php hogehoge ?>

text：テキストノード

実際の文章データです。

これは、>hogehoge<のようにタグで囲われている部分を指しています。

xml上で再現するとこんな感じでしょうか？

<?xml version="1.0" encoding="UTF-8"?>

<!-- コメント -->

<書籍 出版日="2013-02-24">あまぞん</書籍>

↓

document

---

<?processing-instraction ?>

<!-- comment -->

<element attribute="ここはtextではありません">text</element>

---

データモデルを理解しようと進めていくと、あることに気が付きます。
そう、変数がありません。
XSLTではこのデータモデルに載っていないモデルを扱うことはできません。
通常のDOMなどを使用すると、このへんの扱いもコントロールすることが可能ですが、XSLTでは不可能です。

詳細は省きますが、処理を行う際に変換元のxmlも変換するためのXSLTもプロセッサによってパースされてしまい、そのタイミングで既に変数が消滅しているからということになります。

それも合わせて、XSLTでデータを扱う際にはデータモデルに扱いたいデータ型があるかどうかが大前提になります。

２．コンテキストアイテム

XSLTはデータ駆動であり、処理対象であるxmlにそって変換が行われるわけですが、処理されている現在のアイテム（ノード）位置をコンテキストアイテムと言います。

間違えちゃうから気をつけて！

そもそもコンテキストアイテムという言葉は2.0から使用されるようになりました。
じつは、それまではカレントノードと呼ばれていました。
なぜ名称が変更されたかというと、データモデルが増加し、モデルの頂点がItemとなったためです。
そのため使用する関数などにcurrentという名残があります。

カレントアイテムにならなかったのは、データ型がノードだけではなくなり、必ずしも処理対象のxml上に存在するわけではなくなったためです。
最初はピンとこないとおもいますので、データモデルが大きく変更されたためとおぼえておいてください。

XSLTの2.0とそれ以前の資料が混ざってしまい、コンテキストだのカレントだの書かれていますが言ってしまえば”ほぼイコール”ということになります。

以下では全てコンテキストアイテムに統一します。

実際の変換を行なってみると、厳密な型管理を行うにはそれなりに仕込みをしなければなりませんので、実際にはノード群を扱うことが殆どになると思います。


さて、じゃあ結局”コンテキストアイテム”とはなんなんだという話になるんですが、処理上での現在位置ということになります。

表現の一例を出してみます。

正しい表現

• コンテキストアイテムはノード
• コンテキストアイテムは要素、コンテキストアイテムは要素ノード、コンテキストアイテムはdiv要素
• コンテキストアイテムはコメント、コンテキストアイテムはコメントノード

誤った表現

• コンテキストアイテムはdiv→データモデルがどれなのかわかりません。
• コンテキストアイテムはxsl:template要素→変換対象のxml上のアイテムしかコンテキストアイテムになりえません。

XSLTではコンテキストアイテム（現在位置）から何をどうしたいのか、という記述の塊になります。

なので、すべての基準がコンテキストアイテムになる、ということになります。

コンテキストアイテムを変更できるXSLT要素は限られており、コンテキストアイテムの変更は柔軟にはできません。

変更方法については、今回は飛ばします。

３．ロケーションパス

ロケーションパスは、コンテキストアイテムからの相対的な位置を表します。
じゃあ、なんの位置を表すんだよ？ということになると思いますが、それは場所や用途によって変化します。

【XSLT】2.0使っちゃいなよ

すごい久しぶりの更新。

ゆっくりやっていきたいと思います。

今回はXSLTについて。

あまり周りで使われてるのを見ないのでマイノリティ扱いです。

だって、マイノリティですよね？？

XMLの変換では最強（一部処理できない部分を除き）かと思いますが、

得意な言語があればそれで処理してしまうもののようです。

だからこそマイノリティなのですが。

今後、ePubなどの電子書籍に向けた変換サービスでちょっと流行りそうではありますが。

まぁ、それでもマイノリティー┐(´∀｀)┌

仕事の都合でいきなり2.0から習得したもので、1.0とか1.1での不便をあまり感じていない今日この頃ですが・・・

1.0とか1.1での問題につまいづいてたら、2.0へ行ったほうが早いと思います。

それでもダメなものは、XSLTの領分を超えてる問題ですね。

いろんな意味でSaxonさまさまです。

特に正規表現が使えるようになって、テキストノードへの複雑なアクセスが簡単になったのが一番大きいのかな？

2.0機能で自分がよく使うのは↓な感じ

1. variable as="item()*"
2. analyze-string
3. result-document
4. for-each-group
5. function

使ったら面白そうだけど、使ってないのはfor-eachでの整数ループとか。

特に、1の変数へのノード格納はとても大きいかと思われます。はい。

1.0で出来なかった連想配列を、ノードを利用することで簡単に作れます。

でも、ちょっと問題があって、

やっててわかったこと（自分の周りも含め）は、XSLTのデータモデルへの理解不足と、コンテキストアイテム（1.0ではカレントノード）への理解不足ですね。

実際、XSLTを書く際の肝は↓をどれだけ理解できてるか、かと思います。

• コンテキストアイテム
• データモデル
• 組み込みテンプレート

この3つを理解できてれば、できない事なんて無いんじゃないですかね？？

組み込みテンプレートは慣れとしか言えないですが。

他の言語でよく言われる”おまじない”が隠匿してあるだけっていう。

わかっちゃえば、modeとかpriorityとかちょっと凝ってきても無問題だし。

初心者向けに情報をまとめたら見る人いるのかな？

いるならコメントください。書く気出ます。

で、2.0ですが、プロセッサがSaxonしかないのでSaxon無双な状態なんですが、

プロセッサが変更になるとプロセッサごとの微妙な違いで、出力されるデータに差異が生じることがあるので要注意です。

W3Cで策定されたXSLT2.0では処理内容については明確に定義されていないのが起因しています。

なのでSaxonではないプロセッサを使用していて、2.0へ移行するのは要注意ですね。

Saxonは3.0 Daftの一部が実装されているので、それを試してみても面白いかもです。

（Saxonの独自機能も面白そうですが、この先でどうなるかわからんのでアレですが。）

さて、コーディングにもどりますﾉｼ