2020年2月20日に XML/HTML 自動組版ソフトのベストセラー『AH Formatter』をバージョンアップした『AH Formatter V7.0』を公開しました。
『AH Formatter V7.0』では、欧文組版における行分割処理の改良、BIDI処理の改良、GUI の改良、
ドロップキャップ・PDF 2.0 出力・PDF/X-4p 出力・Adobe Fonts・WebP への対応など
盛りだくさんです。
詳しくは「ニュースリリース」に記載しておりますので、是非ご覧ください。
2020年2月7日、先週の金曜日に開催されたXMLパブリッシング交流会『ウェブ出版と日本語組版の未来』に参加してきました。アンテナハウスもブースを出展していた、page2020のイベントの1つという位置付けでした。
会場は池袋サンシャインシティの文化会館7F会議室。最近の技術書典の会場として2F、3Fには来たことがあったので、まあ結構ギリギリの到着でも大丈夫かと高を括っていたのですが、素直にエスカレータを登っていたらスポーツジムに着いてしまい、慌ててエレベータを探しました。
そんなこんなで本当にギリギリの時間に会場に到着すると、席は前方から後方まで割と満遍無く埋まっていました。こくちーずでの申込数上限は80人で、終了後に確認したら登録者数は57人となっていましたね。
以下、スライドや発表に解釈を加えて記述している箇所がありますが、発表者の方の意図に沿えているか分からない箇所もございます。ご了承、ご指摘ください。
Keynote for iCloud上の資料となるので、環境によってはご覧になれないかもしれません。FireFoxやSafariなら見られる筈です。
JLReq Task Force Chairmanの木田氏による、「W3C 日本語組版の処理要件」とその周辺の話となります。
原型としてはJIS X 4051:2004の「日本語文書の組版方法」となり、これを国際的な文書にまとめ直したもの、というのがJLReqの概要となります。
しかし、JLReqはJIS X 4051の単純な移植に留まらない、ということを発表を聴いて改めて意識させられました。
まず、非日本語話者にも要件を伝えるということから、JIS X 4051よりも詳細にその背景や用語の解説や図示が行われているということ。「ルビとはなにか」という説明が、ルビ文化が無い人のために必要になるといった例が挙げられました。
また、世界に向けて日本語組版における要件を発信したJLReqは、様々な言語における要件をまとめていく活動の先駆けとなりました。総称すると「xLReq」とでも言うべきこの活動は、世界が協力し多言語組版を実現していく上での重要なファクターとも言えそうです。
業界的な意味でも、W3Cの専門家と言語の専門家を繋ぐ架け橋としてxLReqがあるということでした。
JLReqTFとしても活動は続けられています。これは公開された活動で、GitHub上にインターフェースがあります。英語での意見投稿はハードルが高いと感じている方も、日本語で投稿した内容をJLReqのチームが拾い上げ、翻訳を行ってくれるとのことなので、積極的な参加を呼びかけておられました。
まず、JLReqの2版に向けた内容のアップデート。これは1版にドラスティックに変更が走るといった類のことではなく、
といった内容だそうです。
次に、JLReqの機能を滿たすようなCSSが定義されているか、あればその動作の検証の諸々と、そのドキュメント化までを行っているそうです。事前にキーワードとして挙げられていた「gap analysis」ですね。スライドの表にその例示があります。要件があっても実際にそれを実現できる仕組みがないとどうしようもないので、こういった調査を行ってくださっていることに頭の下がる思いです。GitHubで課題、意見の吸上げを行っているので、その整理自体も重要な仕事ということでした。
結びとして、「未来に向けて」という題で幾つかのお話をされました。
紙面とデジタルテキストとの違いということを軸に話されていたものの、多くは組版そのものが持っていた問題のうち、今まで人が都度なんとかしており、また完成したものが紙面など固定されたものであったために表に出ていなかったもの、という印象でした。
人間が監督するものと完全に自動で組版するものとの課題の例として、縦書きで左ルビの行と右ルビの行が隣り合うときの行間制御の例など（大抵は人間が位置をずらすことで対処）、画面サイズで文字の配置が変わる場合などに確かに考えねばならないものです。
また、世界で使われるということは、これまでの和文と欧文の高々2つの関係の独自の世界から、「多言語のうちの1つとしての日本語」ということを意識した要求にしていく必要がある、ということも「xLReq」、そしてインターネットとWebブラウザが登場してより顕在化した事柄ではないでしょうか。
そして、そもそも紙面上での組版の時代でも、媒体の事情に合わせて組版要件が変化していったということも、言われてみればその通りであるのに、見落としがちであった視点であったと思います。パラグラフマーク「¶」が、飾りではなく紙の値段が現在よりも高かったときに段落区切りを余白以外の手法で表していた、という例示がありました。
冊子の持っていた優位性の消失というのも興味深い話でした。ページを捲ることでのランダムアクセス（巻物はシーケンシャルですね）、これはデジタルテキストであればリンク機能で事足ります。新技術が登場するときに旧来の技術・表現を模倣するという視点での「デジタルテキストでの組版とその処理要件」は、どこに自分の立ち位置を合わせるかを考える上で重要なものだと感じました。
そして、参加者からの質問タイム。
「禁則処理や和欧文間のアキがJIS X 4051から引き継いでいるが、この要件を変更する議論はあるのか？」というもの。例えば「四分アキが適当な箇所と適当で無い箇所」といった具合ですね。「Tシャツ」という日本語としての単語の「T」と「シ」のアキが四分だと広すぎる、というような例が挙げられていました。
返答として、議論は行われているということでした。
関連して、和語の単語区切りのアイデアといったものも示されました。Webブラウザ表示では、日本語でも行末が不揃いであることもかなり受け入れられてきているので、今後そういった表現に関しての要件が必要になってくることも納得ですね。
「もっと皆さんに試してみてほしい」という言葉も印象的でした。
最後にされた「JLReqは今後『Rule』になるのか」という質問に対して「要件であり、複数あって良いものである」という姿勢が示されていました。その前にされたアキの変更議論なども含めての回答になっており、大変充実した内容でした。
W3Cの作業草案（Working Draft）から勧告（Recommendation）に至る流れの解説の後、それに則って進められている本題のCSS規格の話へ移ります。
勧告候補まで行っても、状況によっては差し戻しされ議論に戻ることもあるというのは随時チェックする程でない身としてはショックがありました。
最新の仕様を追うならDraftを見ることになりますが、何せ草案なので揺れて怖いという話。
「CSS3」という呼称がCSS2.1までのバージョニングの話とは違うということは
不勉強であまり意識したことがありませんでした。CSS2.1に入っていた仕様をレベル3とし、各モジュールに分けて進行状況をレベルで表すということです。
各Webブラウザでの仕様の実装状況のチェック方法など、初学者に嬉しい内容のスライドとなっていました。
JLReqの発表でもあった、要件と対応するCSSのモジュールに関しても、そのモジュールを勧告まで持っていくには別のレイヤでの議論がある、ということでした。「行どり」のためのモジュールは2つほどあったけれどどちらもポシャってしまった話からも、その難しさが察せられます。
より高度なルビ機能の実装に向けたWebブラウザの動向という例も挙げられていました。FireFoxのみ両側ルビに対応を始めたものの、他ブラウザは行っていないといったズレがあるということでした。
定まっていない仕様が定まると、どのような場合に嬉しいのかということで、
text-spacingが規格化されれば、ぶら下げインデントでの約物の表示挙動が統一されたりする、といった例が挙げられていました。
自動縦中横のアイデアなど、どう実装するのか難しそうな話題もあるようです。
また、ルビと圏点を同時に使った場合の挙動といった、議論が定まっていないものもあります。ところで、Antenna House Formatterではルビと圏点の同時使用に対応しており、挙動としてはルビ文字の上に、親文字に対応する圏点を表示します。ルビ文字に合わせた圏点は行えません。
発表スライドもVivlioStyle製です。
紙とWebでの出版コンテンツの違いについてから始まりました。
どちらかというとページメディアとスクロールメディアの違いについてと言えなくもない内容でしたが、「CSSの表現力によってコンテンツの表現力が変わる」という主張は恐らくVivlioStyleの開発陣の情熱の起点となるものではないかと感じました。
電子書籍の形態として普及が進むEPUB3の話題も当然深く拘わってきます。EPUB3.0の仕様に縦書き機能が入ったことでも話題になりましたね。これも、W3CにおけるCSS標準化の進みによるもの、JLReqが貢献した1例といえます。
そして提示された「EPUBはウェブ出版といえるか」という疑問に対し、村上さんとしては現状そうではない、という立場のようです。
「Web Publications」というそのものズバリなW3C Working Groupの存在と、それが現状停滞してしまっていること。この試みをそのまま形にする筈であったEPUB4.0も現状ではどうなるか分からない、とのこと。
また、メタデータの付与をJSON-LD形式で行うPublication Manifestについての言及もありました。こちらは勧告候補。
通常のWebページにSchema.orgに沿ったJSON-LDを付与することも聞くようになってきましたし、Webを志向する上ではそういった流れなのかもしれませんね。
各Webブラウザが機能を実装するにはとても時間がかかります。CSS Paged Media関連など、通常のWebページを表示するためのWebブラウザとしては後回しになりがちなCSS仕様もあります。一方で「標準化」のためには、いち早くその仕様を実装し、検証し、フィードバックを行うことも必要です。
CSSでの機能標準化をより強く進め、同じソースからCSSによって複数のレイアウトを実現し、印刷、EPUB、Web出版を1つのラインに載せたいという情熱を感じました。
「ここから本題です」と村上氏が発言し、会場に笑いが。確かにまだVivlioStyleの話が全然出ていませんでした。
商用のCSS組版ソフトウェアについても言及。弊社の「Antenna House CSS Formatter」の名前も上がりました。
VivlioStyleはオープンソースのJavaScriptプログラムで、EPUB Adaptive Layoutの機能やPaged Mediaなどの、Webブラウザが対応できていない機能をJavaScriptによって補完するものになります。大きなトピックとして、2019年からJavaScriptからTypeScriptに移行しました。
個人的にはVivlioStyle Flavored Markdownの話が聞きたかったのですが、デモもそこそこに時間終了となってしまいました。デモでは、同じHTMLソースからCSSの設定変更のみでレイアウトを大きく変更する例などを駆け足で紹介していました。
https://www.slideshare.net/ogwata_1959/cssvivliostyle-227189333
VivlioStyleの沿革から。スライド外の情報としては、もともとInDesignのレイアウトをWebで実現したかったのがEPUB Adaptive Layoutの思想だったということで、驚きました。
開発の活発さをコミットログから見ると、会社時代と法人化以後を比較してもあまり衰えていない様子が表示されました。開発に参加してくれているメンバーなどにアンケートを取ったところ、「VivlioStyleの開発に加わると最新仕様の実装ができる」というところに魅力を感じている方が多いとコアメンバーが驚いたとか。ちなみに、コアメンバーがそのあたりに無自覚的だったことに会場から驚きの声が上がっていました。
開発者会議を現在月1度ほどの頻度で行っており、濃密な場となっているそうです。
そして、これからも開発を継続していくために、現在法人としてのVivlioStyleに欠けている、開発者支援のための費用など用意していくために、VivlioStyleを利用したサービスを構想中ということで、「VivlioStyle Pub」の構想が紹介されました。
VivlioStyleを利用したオンラインエディタ「Viola」を元に、「ブラウザで原稿執筆可能」「PDF/X-1a出力可能」「（独自仕様の）Markdown原稿をサポート」を目玉にサービスを行っていくというもののようです。VivlioStyle Pubとしては技術同人誌出版などを当面のターゲットとし、印刷所との連携などまで持っていくつもりとか。
VivlioStyle開発メンバーでもあるspring-raining氏のCSS組版・パブリッシング交流会でのViolaの発表が去年の6月ごろだったことを考えると、こういったプロジェクトでの歯車が噛み合う瞬間の速度というものの凄まじさを感じずにはいられません。同じく去年のCSS組版・パブリッシング交流会で課題として挙げられていたPDFの規格問題もGhostScriptでのアウトラインフォント埋め込みを実装したメンバーがVivlioStyle開発メンバーに参加したということです。
CSSの未だ定まっていない仕様も、それを実際に実装し、フィードバックしていくシステムを調えていくこともまた重要で、どんな立場からでもその立場なりにできることがあるということを強く印象づけるXMLパブリッシング交流会となりました。
10月14から17日にロンドンで開催された S1000D User Forum は、航空宇宙および防衛分野の技術文書を作成する多くのアンテナハウスのパートナーおよび顧客と会うことができました。アンテナハウスは卓上展示とベンダーとしてのプレゼンテーションを行いました。フォーラムには世界中から300人以上の航空宇宙および防衛分野の専門家が集まりましたが、その出席者の多くに弊社の Antenna House XSL Formatter を使用していただいています。また同じく弊社の製品である Regressions Testing System と、OSDC (Office Server Document Converter) の PDF を SVG に変換する機能に大きな関心が寄せられました。航空宇宙および防衛分野で使用される技術文書においては、依然としてページ出力が非常に重要とされていますが、現在の目標はその文書をタブレット上に表示することです。SVG になぜ関心があるのかというと、そのページを表示する速度にあります。
プレゼンテーションでは Antenna House XSL Formatter を使用してS1000D サンプル文書をフォーマットし、PDF と SVG 出力を作成しました。次に Regressions Testing System のデモンストレーションでは２つのディレクトリにある8つのペアになっている文書（合計で2,000ページ）の内容の比較を行いました。 デモンストレーションでは各ペアの文書の全ての相違点を２分以内に発見することができました。
10月にAntenna Houseは、Xplor Webinarとロンドンで開催された S1000D User Forum / ILS specification day に参加しました。
今回はXplor Webinarのご紹介をしたいと思います。
10月16日に開催された Xplor International が主催する教育ウェビナーで、弊社のシニアアーキテクトであるトニー・グラハムはAccessibility Mattersを発表しました。多くのアンテナハウスの顧客とパートナーがこのウェビナーに参加し、Xplorのメンバーもこの話題に興味を持っていました。このウェビナーはデジタルの世界においてアクセシビリティがいかに、またなぜ重要であるかを学ぶ絶好の機会でした。
プレゼンテーションの中で、トニーはHTML、Web Content Accessibility Guidelines（WCAG）、およびPDF / UA（Universal Accessibility）標準のアクセシビリティ機能を調査しました。アクセス可能なHTMLやPDFを作成するために必要な情報は、通常ソースXMLに含まれているか、ソースXMLから推測できるため、ユーザーの行動よりもファイル形式に重点を置いて調査しています。ただしXMLそのものをユーザーが目にすることはほとんどありません。このウェビナーでは、神経障害や失読症などの学習障害のある人がアクセスしやすいように、コンテンツのスタイリングが持ついくつかの側面についても調査しました。
プレゼンテーションはこちらのYouTubeからご覧いただくことができます。
（https://www.youtube.com/watch?v=X00icPURCvw&feature=youtu.be）
来週 9月22日（日）に開催される「技術書典」（主催：TechBooster / 達人出版会）に向けて、最近、組版界隈で話題の Markdown（と CSS）を用いて、実際に技術同人誌『簡単！Markdown+CSSによる冊子本作り ―理論と実践―』を作成いたしました。当日販売いたしますので、ぜひお手にとってご覧ください。
本書籍の内容については、先日、弊社ブログでご紹介しております。ご関心ございましたらご覧ください。
→ Markdown＋CSS組版で冊子本（PDF）を作ってみる
◆ 技術書典概要
・開催日時：2019年9月22日（日） 11:00～17:00
・開催場所：池袋サンシャインシティ2/3F 展示ホールC/D（文化会館ビル2/3F）
・サークル名とブース番号：アンテナハウスCAS電子出版（き45D）
・販売書籍
・技術書典7
◆技術書典ご来場予定の方に
一般参加者は13時まで有償の整理券が必要です。ご注意ください。
整理券のご案内
整理券は1,000円で、3種類あります。
(1) Cホール（3階）から入場 11時～
(2) Dホール（2階）から入場 11時～
(3) Dホール（2階）から入場 12時～
弊サークルの場所は、展示ホールD（2F）：き45Dです。
アンテナハウスCAS電子出版（き45D）
入場が13時過ぎると無償（ただし、待機列解消後）になります。Markdown本はたくさん印刷しましたので、まず売り切れはないと思いますので、遅くてもたぶん大丈夫なはずです。
[AH Formatter] より良い欧文組版を目指して
[AH Formatter] より良い欧文組版を目指して その2
上記の記事の続きです。
欧文組版で考慮すべき事柄には以下もあります。
読み手に違和感が発生しないように工夫して組版する必要があります。
適切なプロパティの値を設定したり、元文書を直すことで対処できます。
・ハイフネーションできない単語を含む行の前後で字間が空き過ぎる
ハイフネーションができない単語が行末にある場合、その行前後で空白が空きすぎる場合、表現を変えるか、固定幅の空白文字を挿入する等の対処が考えられます。
・widow や orphan を回避したことによるページ量の増加
『AH Formatter』では widowsプロパティで最低何行から次ページに送るかを設定をすることができますが、プロパティの値によってはページ数が増える可能性があります。もし、それが許容できる範囲ではない場合、widowsプロパティの値を変える、行の高さを再設定するなどで対応することが出来ます。
組版で審美的な問題が発生したとき、いちいち手で修正するのは面倒です。
『AH Formatter』では自動組版をもっと便利に利用できるよう、有用なプロパティを開発しています。
また、目視で組版結果を判定せずプログラムによって自動で判定し、上記のような審美的な問題を自動検出できれば文書作成のコストはぐっと下がるだろうと思います。対応策などもサジェストしてくれるものだとなお良いでしょう。
『AH Formatter』の評価版は以下のページよりお申し込みいただけます。是非、お試しください。
→ AH Formatter 評価版のお申し込み
『AH Formatter』についてお問い合わせがございましたら sis@antenna.co.jp 宛てにご連絡ください。
XML を自動組版するには XSLT の開発と XSL-FO の知識が不可欠です。HTML と CSS で組版しようという動きもあるにはありますが、まだまだ少数派でしょう。
弊社では XSLT と FO の両方を１日で学んでしまおうという、ちょっと贅沢なセミナーを開催しています。今まで 25 回以上開催し、ご参加者の延べ人数は 100 名様を超えてます。「XSLT や FO は名前を聞いたことはあるけれど…」という方々からご好評をいただいているセミナーで、6～7時間かけて XSL-FO の基礎を学びながら XSLT をひたすら入力していただく、ちょっとしたスパルタな内容です。
セミナーで使うテキストの一部
先日、久しぶりに XSLSchool 開催のご依頼をいただき、静岡にあるお客様のオフィスに出向き開催させていただきました。
来月も他のお客様から開催の打診をいただいています。
詳しくは「XSLSchoolのご案内」をご参照ください
JATS-Con 2019 は 5月20～21日、今年はイギリスのケンブリッジ郊外のウェルカムゲノムキャンパスで開催されました。 JATS は Journal Authoring Tag Suite の略です。
過去にこの会議はアメリカのメリーランド州ベテスダ（Bethesda）の国立医学図書館で行われおり、来年はまたベテスダで開催される予定です。
国立医学図書館は 2005年よりアンテナハウス XSL Formatter を使用して、JATS を使用した構造化文書を作成しています。
会議の議事録は https://www.ncbi.nlm.nih.gov/books/NBK540820/ から見ることができます。
今年の Markup UK は、6月7～9日にイギリスのロンドンで開催されました。
マークアップ UK 2019 の議事録は https://markupuk.org/webhelp/index_frames.htmlから見ることができます。
アンテナハウスのシニアアーキテクトであるトニーグラハムは、アクセシビリティを取り巻く重要性と問題点を論じた論文「Accessibility Matters」を発表しました。
また、Peter Flynn のプレゼンテーション、「Software we have lost」を拝聴した人たちは、きっと懐かしさを感じたことでしょう。
こんにちは。
AH Formatterサポート担当です。
今回は XSL-FO の line-height プロパティのお話です。
line-heightプロパティは、行高さを指定するものですが、
その値は次のような種類があります。
normal：
line-height-“normal” のように指定します。既定値です。ユーザエージェント（AH Formatter）が適切な値に設定します。
AH Formatterではline-height=”1.2″ を初期設定としています。この値はオプション設定によって変更することも可能です。
<length>：
line-height=”20pt” のように数値＋単位を指定します。
<number>：
フォントサイズに対する倍数を指定します。line-height=”1.5″ のように指定します。
<percentage>：
フォントサイズに対するパーセンテージを指定します。line-height=”150%” のように指定します。
ここで、１つ疑問に思われた方がいるかもしれません。
line-height=”1.5″ と line-height=”150%” って結局同じじゃないの？ と。
実際に組版してみると、このようになります。
例１：
<fo:block line-height=”1.5″>line-height=”1.5″</fo:block>
<fo:block line-height=”150%”>line-height=”150%”</fo:block>
そうです、”この場合”の行高さは同じです。
例えばフォントサイズが 30pt の場合、どちらもフォントサイズ 30pt × 1.5 で行高さは 45pt になります。
では、<number> と <percentage> で何が違うのか。
XSL-FO の仕様説明をみてみましょう。
<number>
The computed value of the property is this number multiplied by the element’s font size. Negative values are illegal.
However, the number, not the computed value, is inherited.
<percentage>
The computed value of the property is this percentage multiplied by the element’s computed font size. Negative values are illegal.
どちらの説明も前半の意味は同じですが、<number> にはこの一文が追加されています。
However, the number, not the computed value, is inherited.
日本語訳：しかしながら、計算された値ではなく、数値が継承される。
line-height プロパティの値は継承されます。親block で指定された値が子（子孫）block にも適用されます。
親block に line-height=”1.5″ または 150% が指定されていて、
子（子孫）の block でフォントサイズが変更されたとき、この “the number, not the computed value, is inherited.” が関係してくるのです。
例えば、次のような場合です。
例２：
<fo:block font-size=”30pt” line-height=”1.5″>
<fo:block font-size=”20pt”>line-height=”1.5″</fo:block>
<fo:block >line-height=”1.5″</fo:block>
</fo:block>
例３：
<fo:block font-size=”30pt” line-height=”150%”>
<fo:block font-size=”20pt”>line-height=”150%”</fo:block>
<fo:block >line-height=”150%”</fo:block>
</fo:block>
どちらも親block で line-height を指定しています。
１つめの子block で、フォントサイズを変更しています。
<number>の場合は、指定された数値が継承されます。
line-height=”1.5″ の場合、”1.5″ の値が継承されて
フォントサイズが変更になると、その block のフォントサイズ×1.5 の行高さになります。
例２では１つめの子block は、20pt×1.5 で35pt、2つめの子block が 30pt×1.5 で 45pt の行高さになります。
<percentage>の場合は、それが指定されたときのフォントサイズから計算された値が継承されます。
例３では、親block の font-size=”30pt” line-height=”150%” から行高さは 45pt と計算されます。
（line-height の指定がない）子block には、その “45pt” の値が継承されます。
1つめの子block も 2つめの子block も同じ 45pt の行高さとなります。
両者の違いに注意してお使いください。
『AH Formatter』の評価版は以下のページよりお申し込みいただけます。是非、お試しください。
→ AH Formatter 評価版のお申し込み
XSL-FO の基本仕様と『AH Formatter』の拡張機能をお試しいただけるよう「サンプル FO 集」もご用意しています。
『AH Formatter』についてお問い合わせがございましたら sis@antenna.co.jp 宛てにご連絡ください。
AH Formatter の導入事例紹介ページに有限会社フェリックス・スタイル様の事例「AH Formatter を用いた Markdown-PDF 変換事例紹介」を掲載しております。
事例紹介ページにある PDF文書では、Markdown形式の原稿を『AH Formatter』の CSS組版により、表紙や目次、ノンブルなどを備えた PDF文書へと変換するフローが詳解されております。
また、この事例紹介の PDF文書も Markdown原稿から作成されており、その作成に用いたソースファイル一式も GitHub にて公開しておりますので、実際に Markdown原稿から CSS組版を利用した PDF へのビルドをご体験いただけます。是非ご覧ください。
なお、主に海外の方に向けて、ソースファイルは英語版もご用意しております。
→ https://github.com/2SC1815J/md2pdf/tree/en (English Version)
『AH Formatter』の評価版は以下のページよりお申し込みいただけます。是非、お試しください。
→ AH Formatter 評価版のお申し込み
XSL-FO の基本仕様と『AH Formatter』の拡張機能をお試しいただけるよう「サンプル FO 集」もご用意しています。
『AH Formatter』についてお問い合わせがございましたら sis@antenna.co.jp 宛てにご連絡ください。
