Tag Archives: CSS

[CSS組版]ページ番号のリセット

今回紹介するのは「表紙を同一のHTMLから生成するとき、
表紙のページ番号はカウントしたくない」という要望の実現についてです。誤りがあれば、ご指摘いただければ幸いです。

組版にはAntenna House CSS Formatter V7.3MR1を利用しています。スクリーンショット画像の、ページ番号以外の本文内容について画像によって差異がありますが、記事を作りながら都度組版をしていたためで、本題には支障ありません。

CSSページ組版でページ番号を参照するには、content: counter(page)と指定します。

リセット未指定でのページ番号カウントを見てみましょう。

@page {
    size: JIS-B5 portrait;
    margin: 2cm;
    @bottom-center {
        content: counter(page);
        font-size: 24pt;
        font-variant: oldstyle-nums;
    }
}

@pageルールで全体のページレイアウトを設定しています。@bottom-centerでページ番号を表示するように指定していますね。

1枚目のページに「1」、2枚目のページに「2」が振られています。

pageカウンタをリセット

1枚目を表紙ページとして、2枚目のページに「1」が振られるようにしてみましょう。

ところでCSSのカウンタはページ組版に限らない汎用的な仕組みです。pageはページ組版のとき、定義済みのカウンタ名として存在している状態です。
つまり、カウンタリセットの仕組みを使うことで、ページ番号についてもリセットが可能です。

... {
      counter-reset: page 1;
     }

できることが分かったところで、次の問題、すなわち「どのセレクタ(要素・ルール)にリセットを記述するか」に移ります。

今回は「表紙ページ」と「それ以外のページ」という分け方ができます。「表紙用のページレイアウト」、
「本文用のページレイアウト」が用意できると嬉しいわけです。@pageルールでは、そういう処理が書けます。

@page {...}
@page mainmatter {
  counter-reset: page 1;     
}
#cover {
    break-after: always;  
}
div#mainmatter {
    page: mainmatter;
}
<div id="cover">
    <h1>[CSS組版]ページ番号のリセット</h1>
    <p>今回紹介するのは...</p>
</div>
<div id="mainmatter">
    <p>CSSページ組版でページ番号を参照するには、...</p>
</div>

上手くいった……と油断するのはまだ早いです。このままでは、@page mainmatterの対象ページが切り換わる度にpageは1にリセットされるのです。

リセット対象のページを追加で条件付けすることで解決できます。@page mainmatterに:firstを追加することで、「mainamtterページレイアウトが使用される最初のページでpageを1にリセットする」という処理になります。

 @page mainmatter:first {
    counter-reset: page 1;     
}

期待する出力になりました。

表紙のページレイアウトからページ番号を削除する

ついでに、表紙ページからはページ番号表示を外しておきます。

@page cover {
    @bottom-center {
        /*bottom-centerのコンテンツを上書き*/
        content:"";
    }
}
#cover {
    /*coverページレイアウトを適用*/
    page: cover;
    break-after:always;
}

参考

XSL-FO 試行錯誤 SVG 2.0 inline-sizeのTips

2023年01月19日に『Antenna House Formatter V7.3』がリリースされました!
関連して、2023年01月31日(火)16:00-17:00 にZoomウェビナーとして『Antenna House Formatter V7.3 リリース!  新機能と利用シーン紹介』を開催します。


https://us06web.zoom.us/webinar/register/4716717860524/WN_ElB-ZrzFQzShzKGqWZMHqg

新機能紹介ということで、XSL-FOやCSSページ組版の基礎知識があることを前提としています。しかし、特に知識の無い方でも「自動組版でこんな細かいレイアウト調整が効くのか」と楽しめることを目指していますので、お時間が合いましたら是非参加登録いただければ幸いです。

ウェビナースライドはFormatter V7.3で組版しています。スライドはCSSで組んでいるのですが、話題がSVGについてなので、暫くぶりとなる「XSL-FO 試行錯誤」シリーズを題に含めました。
(前回のXSL-FO試行錯誤のカレンダー作成の続きについてはまた時間があるときにさせていただければ……)

さて、本記事ではウェビナーで割愛する部分について、先行して補足します。
ということで、見た目が地味なのであまり深く掘り下げない予定のinline-sizeによるテキストの折り返しについてです。

発表スライドの見出し部分にはSVG 2.0を使っています。

テキストを配置するとき、SVG 1.xでは折り返しを扱えませんでした。
よって、複数行のテキストを配置するときは次の手順(これ以外にもなくはないですが)です。

右揃えで3行でテキストを描画するとします。座標は適当です。

  1. 改行位置でテキストを分割し、別のtspanに分ける
  2. それぞれのtspanにx,yの座標を指定する。2行目であれば1行目から1文字分以上離れた位置にyを設定する
<!-- SVG 1.x -->
<text x="0" y="0">
<tspan text-anchor="end" x="250" y="0">Formatter V7.3</tspan>
<tpsan text-anchor="end"  x="250" y="10">リリース!</tspan>
<tspan text-anchor="end"  x="250" y="20">新機能と利用シーン</tspan>
<text>

text-anchor=”end”によって、xの位置がテキストの終端になっています。

x,yはSVG内の座標系なので、font-size:18ptのように絶対単位で指定されていると対応する高さを調整するのはちょっと手間ですね。
他にも拡大縮小の際などにこれを忘れずに変更しなければなりません。

メリット、といえるかは分かりませんが、あらかじめ分割しているので、意図しない行分割が発生するということはないでしょう。

SVG 2.0のテキスト折り返し機能を使えば、折り返しを自動化可能です。Formatter V7.3ではinline-sizeによる折り返しをサポートしています。
Scalable Vector Graphics (SVG) 2 11.4.1. The ‘inline-size’ property



<text x="0" y="0" inline-size="1000">Formatter V7.3リリース! 新機能と利用シーン</text>

inline-sizeにはテキストの行長を指定します。

  • 両端揃えができない
  • 日本語は行頭・行末禁則以外では基本的に改行可能と判断される

また、見出しのような箇所で使う場合、次のことを意識しておくとよいでしょう。

今まで手動でやっていた行分割を自動処理にする都合上、特に、本文でない箇所での行分割規則は意識しておかなければなりません。
言語処理が日本語になっていれば(xml:lang=”ja”が適用されるような箇所であれば)
意図してそうしない限り「ー」は先頭に来ませんが、「リ」はそうではないので、

Formatter V7.3 リ
リース!

となるかもしれません。

特定単語の行分割を防ぐため、その箇所のマークアップをtspanにして、分割禁止のプロパティを付けることにします。
「tspanを使うなら結局SVG 1.xとあまり変わらない?」と思われるかもしれませんが、座標の明示がなくなるので処理はかなり単純化します。
「この単語で行分割されるのは困るが、ここ以外であれば別に構わない」というケースが多いとみているのですが、どうでしょうか。

<!-- <heading>Formatter V7.3<keep>リリース!</keep><keep>新機能</keep>と<keep>利用シーン</keep></heading> -->
...
<xsl:template match="heading">
  <svg:svg viewBox="0 0 1920 1080" >
  ...
    <svg:style>
      svg|tspan.keep {
        word-break: keep-all;
      }
    </svg:style>

    <svg:text x="1800" y="100" text-anchor="end"><xsl:apply-templates mode="#current"/></svg:text>
  </svg:svg>
</xsl:template>
...

<xsl:template match="keep">
  <svg:tspan class="keep"><xsl:apply-templates mode="#current"/></svg:tspan>
</xsl:template>

上記は実際に使用したコードではないため、参考程度にお考えください。
inline-sizeが対応するalign調整はtext-anchorによるものになるため、両端揃えの自動配置はできません。

その他、SVGのテキストを使う場合の注意点として、FOのブロックやHTMLのテキストと異なり、
「viewBoxは伸長しないため、想定よりテキストが長くなると表示が見切れる」という点があります。
つまり、「ページ単位で表示領域を確保できる」など、特に高さ・テキスト長があらかじめ想定できる
範囲で使うようにするとよいでしょう。

そして、Formatter V7.3で対応したSVGフィルタ・マスク機能と組み合わせることで文字列に効果を付加できます!

SVGテキストとマスク

画像に対し、テキストをマスクとして被せたものになります。このSVGではtext-anchor=”middle”です。
実のところ、SVGマスク以外の方法もあります、ただ、SVGマスクやフィルタは汎用的ですし、追加の独自仕様無しでXSL-FOでも使えるというメリットがあります。

【動画公開】XSLT超入門3, CSS組版スライドと補足

ちょっと一息アンテナハウスウェビナー「XSLT超入門 3 XPathについて」を終えました。ご視聴いただいた方、ありがとうございます。お時間の合わなかった方、動画が公開されたので、ぜひご覧ください。


Zoomの注釈機能

発表直前に気付いたのですが、Zoomの「画面の共有」ボタンの横に、いつの間にやら「注釈」というボタンが増えていたので早速使ってみました。いかがでしたでしょうか。

PowerPointスライドと違い(おそらくほとんどの)PDFビューアにはレーザポインタ機能がないので、助かりますね。(他機能として、テキストも表示できます。スライド表示中に「これ補足した方がいいかな」といった思いつきでテキストを追加したりはPDF注釈でも実現できますが、操作の切り換えの手間があるため、Zoomにあるに越したことはない、くらいの感想です。)

CSS組版スライド

担当したここ数回のウェビナーではPowerPointでスライドを作成していました。今回も途中まではそうだったのですが、内容の大幅な修正を行うついでにAH FormatterでHTML+CSS組版によるPDFスライドに移行しました。

以前XSL-FOでスライドを組版したことを紹介しました。スライド発表程度の長さであれば単一HTMLでもあまりテキスト分量はかさみません。今回、HTMLが650行弱、CSSは240行程度でした。実作業としてはSCSSで記述して変換していたので……240行程度でした。まあ、セレクタ部分は簡潔になりますが、改行・インデントとしてはあまり変わらないんですね。CSSについてはAH CSS Formatterの既定のCSSを読み込んだ上でなので、0から組むのであればもう少し嵩むでしょう。

VS CodeでSCSSを編集 with AH CSS Extension

SCSSの編集はVS Codeで行いました。VS CodeでのCSSの補完・サジェストについては、@media printなども最初からある程度対応しています。
加えて先日、AH CSS Formatterの豊富な拡張仕様を入力補助してくれるAH CSS Formatter Extensionが公開されたので早速使っています。SCSSファイル編集でも有効なようです。

https://github.com/AntennaHouse/ahformatter-vscode-css-ja

「HTMLソースでスライドを作成する」というと、気になるのは「発表スライドとWebページを同時作成できるか?」という点ではないでしょうか。結論としては「内容次第」ということに落ち着いてしまうのですが、「ある程度まで同一ソースで作成する」ことを目標とすると、方針として押さえるべき点は次のことでしょう。

  • HTMLソースはWebページ向けが主、スライドは従
    • スライド組版時はdisplay:noneにする情報を決めておく
    • スライド向けCSSを先行する場合、とくに注意するのはfloat配置とheightの100%

もちろん、広告を目的とするWebページなどで一度に入る情報量を絞ることなどはよくあります。ここではある程度技術的内容のプレゼンとそのWebページ化を前提としています。

スマホ向けとPC・タブレット向けのページを同じソースで作成する場合にスマホ向けをメインにレイアウトすることを「モバイル・ファースト」といったりしますが、Webページとプレゼンテーションの関係はもう一捻りあります。
モバイルとそれ以外で異なるのは、主に画面サイズです(より正しくは前提とする通信環境によるリソースの出し分けなどもあります)。
一方、Webページとプレゼンにおいて、Webページはそれのみですが、プレゼンは(通常)「スライド+発表者+発表」で構成されます。この違いは「読者側が受動的か能動的か」「発表者による注意対象・情報量のコントロール」といった差異を生みます。

HTMLソースの話に戻ると、ある変換を行うとき、情報量は落とす方が楽で、足すのはかなり困難です。
つまり「より情報量を必要とする方を主とし、そうでないものを従とする」ということになります。
プレゼンは発表という追加情報を前提とするため、スライドにWebページと同じ情報量を与えると情報量が過多になりがちです。

CSSでは手軽に表示を隠蔽する方法としてdisplay:noneがあります。これは、プレゼンでは口頭で与える情報を、Webページではテキストで表示する、という目的にも使えます。

@media print {
.web-page-only {
  display:none;
  }
}

前提として、「スライド上隠蔽されても前後の話は分かるようにする」というライティングが必要です。なので、パラグラフライティングの基本や、DITAにおけるshortdescのように、「これは最低限最初に伝える」という文章から書いていくよいでしょう。

ページ向け媒体ではフロートはページの上端、下端を前提に書けます。これはpositionについても同様です。

XSLT超入門3の補足

さて、発表の補足です。

何度か述べましたが、XPathの特長は、簡単には「ある文書で、目的の箇所を簡便な記法で指定できる」「取り出した値の加工が行える」ことにあります。ただ「hoge/fuga/…」と書きつらねるだけでなく、軸や述部といった機能・概念を使うことで、他の言語、というかDOMインターフェイスでは難しいこともスマートに行える、ということをXSLT超入門3ではフューチャーしたのですが、いかがでしたでしょうか。
「ここが分からないのでここをじっくりやってほしい」などの要望を、メール・SNS・動画へのコメントなどでいただけると幸いです。

さて、発表について、事前の予定から大きく削った箇所としては2箇所です。データモデルと、XPath 1.0のコードを3.1でリライトするという内容です。

データモデルについては、XPath 2.0でいかに整理されたか、3.0(3.1)で何が拡充されたか、の詳細を削りました。このあたりについてはW3CのXDMのページに図示があるので内部処理モデルに興味のある方はご参照ください。

XPath 3.1でのリライトについては、題材として丁度良いバランスのものを見つけるのはかなり難しかったため、構成から削除しました。「XPath 1.0でまともに処理できるように記述した上で、XPath 3.1で明らかに改善されるように書き直す」ということの難しさは、「そもそも1.0で書けなかった処理を拡充したものがほとんど」「1.0では(XSLT上では)独自functionの定義もできないので、XSLTも多分に含むことになる」といった点にあると感じます。XSLT 1.0のコードでの超絶技巧についてはfunctXライブラリが有名でしょうか。

超絶技巧はおいておいて、もう少し簡単なものはあります。

XPath 1.0(XSLT 1.0)
<xsl:template match="*[contains(@class, ' topic/ph ')]"> 
  ...
</xsl:template>
XPath 3.0(3.1) (XSLT 3.0)
<xsl:template match="*[contains-token(@class, 'topic/ph')]"> 
  ...
</xsl:template>

行っているのはDITAの@class処理で、スペース区切りで続く文字列の部分一致判定です。contains()では含まれてさえいれば真を返してしまうので、topic/ph前後にスペースは必須です。ないと「mytopic/ph」なども一致してしまいます。
contains-token()は、なんだったら名指しで「HTMLやDITAのclass処理に使えるよ」と書かれているのでさもありなん。

コア関数についてはかなり駆け足で紹介しました。コード例をバーッと載せていましたが、コードをしっかり読んでもらうことは意図していません。
これは構成上割と悩みどころで、関数名と処理内容を淡々と流すのであれば、ウェビナーよりもWebサイトや本などを参照するように誘導しても良いと考えています。あるいは数時間~数日のワークショップであれば、サンプル、基本、応用、基本、……といった進め方をしたと思います。

とくにXPath 1.0では、関数型言語らしい「関数を組み合わせて使う」ことはなかなか難しいため、その有用性のアピールを分かりやすく行うのは難しくなっています。

発表中、contains()が(2.0)となっていましたがこれは記述ミスで、XPath 1.0からあります。

SCSSで(S)CSS組版の見通しを良くする

Antenna House CSS FormatterはHTMLあるいはXMLとCSSからPDFを生成できます。

ところで、CSSを直接書くのは結構大変です。
スタイル設定を書いていると、数百行程度はすぐに超えてしまうかもしれません。
そうして膨れ上がったスタイル設定はメインテナンス性の観点からもあまり望ましくはありませんね。
そこで他の記述形式からCSSを生成する方法が普及してきました。
CSSを生成する言語あるいは処理系を指してメタCSSという呼称が用いられることもあります。メタCSSとしてはLESSやSCSSがあります。

本記事ではSCSSを記法として採用し、処理系としてsassを使用しました。SASSとSCSSの違いなどについては割愛します。SCSSは記法として素のCSS記法も可能なため、既に記述されているCSSからの移行が比較的容易いというメリットもあります。

今回はサンプルとして、弊社で公開している『CSSページ組版入門』のサンプルファイルを利用しました。
Antenna House CSS FormatterのバージョンはV7.2改訂1版を想定しています。

処理の流れとしては次のようになります。

1. SCSSファイルの記述
2. SCSSをCSSにコンパイル
3. HTML、XML+CSSをAH CSS Formatterで組版

sassの導入

sassは現在Dart言語で開発されていますが、インストールはDart環境よりもWeb系でより普及しているnpmやyarn経由の方が簡単かもしれません。

$ yarn add sass 

今回SCSSに変更していくbooklet-page-ja.cssをリネームし、booklet-page-ja.scssとします。SCSSに変更後、sassによって改めてbooklet-page-ja.cssを生成します。

$ yarn run sass booklet-page-ja.scss booklet-page-ja.css

ネスト記法

booklet-page-ja.css(変換前)

...
/* 目次 */
.TOC > ul {
  font-size: 15.5q;
  font-family: source-serif-pro, source-han-serif, serif;
}
.TOC li.TocLevel1 {
  font-size: 15.5q;
}
.TOC li.TocLevel2 {
  font-size: 14q;
}
.TOC li.TocLevel3 {
  font-size: 12.5q;
}

CSSでは基本的にセレクタは個別に書いていく必要がありますが、SCSSではセレクタの親子関係を入れ子で記述できます。また、「>」や同じ要素で別のクラス指定のものも入れ子にし、Parent Selector 「&」を使うことで目的の出力が得られます。
@pageはトップレベルのセレクタのため、「& :left」のような利用方法はエラーとなります。

booklet-page-ja.scss

...
/* 目次 */
.TOC {
   
 & > ul {
  font-size: 15.5q;
  font-family: source-serif-pro, source-han-serif, serif;
 }
 li {
  &.TocLevel1 {
    font-size: 15.5q;
  }
  &.TocLevel2 {
    font-size: 14q;
  }
  &.TocLevel3 {
    font-size: 12.5q;
  }
}
...

フォーマットした上での行数は増えることもありますが、同じ要素やクラスを親とするスタイル指定がすっきりまとまりました。

SCSSでの「&」は「&-top」のようにも使えるのですが、CSSのNesting Module(Draft)では処理が変わってしまうため、使用を控えています。

@mixin

SCSSでは@mixin <name> (<arg>) { ...}で指定した内容を@include <name>(<arg>)で取り出して使用できます。

フッタのページ番号とヘッダのテキストでfont-familyとfont-sizeが揃っていたため、@mixinを使用してみましょう。

booklet-page-ja.css

 ... {
  @top-left {    /* 柱(ページヘッダ)*/
    font-size: 11.5q;
    font-family: source-serif-pro, source-han-serif, serif;
  }
  @top-right { content: none }

  @bottom-left { /* ノンブル(ページ番号)*/
    font-size: 11.5q;
    font-family: source-serif-pro, source-han-serif, serif;
    content: element(Title);
  }
...
}
booklet-page-ja.scss

@mixin running-font {
      font-size: 11.5pt;
      font-family: source-serif-pro, source-han-serif, serif;
}
...
... {
    @top-left {    /* 柱(ページヘッダ)*/
      @include running-font();
    }
    @top-right { content: none }
  
    @bottom-left { /* ノンブル(ページ番号)*/
      @include running-font();
      content: element(Title);
    }
}

今回は使用していませんが、SCSSではCSSに変換時に置換される変数が使用できます。CSSにも変数機能がありますが、組版に使う処理系がCSSの変数に対応していないときなどはこちらが有用です。

AH CSS Formatter V7.2はCSS変数に対応しています。
AH Formatter V7.2 | CSS仕様の実装状況

@mixinなどと併用するときは粒度の管理が大切です。

ファイルをまとめる

素のCSSでは分割したファイルは都度HTMLのlink要素で読み込んでいたかもしれません。CSSの@import機能もありました。
「分割して細かくしていくうちに数十ファイルのCSSでどこに何が書かれているか分からなくなり、そのまますべて読み込むことにした」という話も耳にします。Webサイト読み込みにおけるパフォーマンス以外に、メインテナンス性にもかかわる話です。

SCSSでは複数の入力SCSSファイルから、1つまたは複数のCSSファイルを出力することもできます。
「SCSSファイルと同数のCSSファイルをチェックすることになり作業が倍に」といった事態にしないため、
出力するCSSファイルはまとめることにします。

複数の入力ファイルから出力を得る場合、sassへ指定する引数の書き方が少し変わります。
次のSCSSファイルのあるディレクトリをscss、出力するCSSファイルを含むディレクトリをcssとします。

$ yarn run sass scss:css 

scssディレクトリ内部のSCSSファイルがCSSへと変換されます。scss/a.scss、scss/b.scssファイルが存在する場合はcss/a.css、css/b.cssファイルが生成されます。

さてこのとき、ファイル名の先頭を「_」とすることで、そのファイルは出力するCSSファイルから除かれます。この除外されてしまうファイルの意義はどこにあるかというと、出力対象の別ファイルから内部的に読み込ませるためにあります。

出力するCSSファイルから除外するファイルを_color.scssとします。

booklet-page-ja.scss

@use "_color"
...

@useで読み込まれた_color.scssの内容は変換出力されたbooklet-page-ja.cssに反映されます。このとき名前空間などの概念が登場しますが、詳細はSCSS(SASS)のWebサイトなどをご覧ください。

ざっくりとした紹介となりましたが、メタCSSによってCSS組版の設定記述の見通しを良くする方法について説明しました。WebサイトでのSCSS-CSS利用との差異はほとんどありませんが、Webサイトよりも細かに異なるレイアウト指定を行うであろうCSSページ組版で、メタCSSによって得られる恩恵はより大きくなるのではないでしょうか。

参考資料


海外ウェビナー動画「CSSとXSL-FO:印刷出版に私はどちらを使うべきでしょうか?」(日本語字幕付き)

Xplor International(https://xplor.org/)主催のウェビナーにて、弊社副代表のMichael Millerが発表を行いました。

タイトルは「CSSとXSL-FO:印刷出版に私はどちらを使うべきでしょうか?」(原題:CSS or XSL-FO: Which should I use for producing print publications)です。
「CSSとXSL-FO、どちらを使うべきでしょうか?」という質問をよくいただきます。こののウェビナーではCSSとXSL-FO、それぞれの特徴や歴史的な背景を昨今の出版を取り巻く環境も含めてご紹介しています。技術的な内容は少なめで、どなたでも理解しやすい内容となっています。

ウェビナーの様子はYouTubeでご覧いただくことができますので、ぜひご視聴ください。

なおYouTubeの字幕機能を使えば、日本語字幕付きでご視聴いただくこともできます。
字幕の設定方法は、

  1.  動画右下の設定アイコン(歯車マーク)をクリック
  2. 「字幕」をクリック
  3. 「日本語」にチェックを入れる

以上の設定で日本語字幕付きでご視聴いただけます。



XSL-FO/CSSスタイルシートにより、XMLとHTMLをサーバー上で高速にPDFに変換!



アンテナハウス ウェビナー スケジュール一覧 2020

AH FormatterでXSL-FO 2.0 仕様DraftのWebページをPDF化してみる

業務を行っていると、W3Cで公開されている仕様を確認しにいくこと、例えばXSL-FO 2.0のDraft[1]を確認しにいくことがあったりなかったりします。
Webページの利点の1つはスクロール操作によって文書の目的の位置へいけることですが(もちろんそうでない作りのWebページもあります)、手元の電子ペーパー端末でページをめくるように読みたい場合もあります。
「WebページのURLを打ち込むだけでそこそこ読めるPDFを出力してほしい」、そんなときにもCSS組版が可能なお手持ちのAntenna House (CSS) Formatterが利用できます。

AH Formatterでファイルを読み込む際、通常はファイルパスを指定するかと思います(GUIではドラッグ&ドロップも可能です)。しかし、ここにWebページのURLを指定することもできます。マニュアルにも記載してありますね。「組版種別」によって、AH FormatterのデフォルトCSSを使用する設定、元のHTMLのCSSを利用するなど違いがあるので、マニュアルを確認してください[2]。

Windowsの場合、AH Formatterをインストールしたフォルダにhtml.cssがあります。これがHTMLファイルを読み込んだときにAH Formatterのデフォルトとして適用されるCSSです。
今回は「HTML」を指定しました。

全体的な文字サイズやページサイズなどを「組版オプション」で設定してみます。


XSLT2.0の仕様[3]を、ページサイズをJISB5、本文14ptとしてみたところ、673ページ程度になりました。

JIS B5サイズのPDFでXSLT2.0 仕様出力

記事冒頭で「例えば~」とXSL-FO2.0の話題を振っておきながらFOではなくXSLT2.0で例を出しているのは、XSL-FO2.0のドラフトだと1200ページ超え(JISB5、本文14pt程度)となり、GUIでプレビューを表示しながら操作をするには手元のマシンだと厳しいためです[4]。CUIで組版する分には問題ありません。

JIS B5サイズのPDFでXSL 2.0 Draftを出力

今回PDF出力してみたWebページの場合ですと、ソースコードや巨大な画像ではページサイズに収まるように表示できていません。元がリフロー型のWebページなので、デフォルトのCSSでは少し無理があったようです。とはいえ、手軽にそこそこ見やすいPDFを得ることができました。

Antenna House Formatterの評価版は、こちらのページからお申込みいただけます。
AH Formatter 評価版のお申し込み

CSSでのページメディアの印刷に興味がある方へ、アンテナハウスでは『CSSページ組版入門』という書籍を発行しています。

  1. [1] Extensible Stylesheet Language (XSL) Version 2.0
    W3C Working Draft 17 January 2012
  2. [2] ドラッグ&ドロップ組版 – Antenna House Formatter V7 マニュアル グラフィカルユーザインターフェイス
  3. [3] XSL Transformations (XSLT) Version 2.0
  4. [4] ページ数上限自体は変更可能です。 制限事項 – Antenna House Formatter V7 マニュアル グラフィカルユーザインターフェイス

関連記事

  1. AH Formatter の CSS組版例「MathML 3.0 2nd Edition」

Antenna House Formatter V7XSL-FO/CSSスタイルシートにより、XMLとHTMLをサーバー上で高速にPDFに変換!

アンテナハウスの公開資料

ここ暫く外出が減り、外に出ていた時間を読書や学習にあてるという方も少なくないのではないでしょうか。
出版社による期間限定の書籍の無料公開も様々にあります。
以前から公開されている企業の技術資料をこの機会に読んでみるのも、新たな発見があるかもしれません。

何気なくWebページで技術資料を検索していたら弊社の記事だった、
なんてことを先週の休日にも体験しました。日本語情報自体が少なめなものでしたから、見つけて吃驚しました。日々技術や規格はアップデートされるものですから、資料の更新日時などには注意が必要ですが、そこさえ押さえてあれば色々と興味深い資料が見つかります。

アンテナハウスでは書籍や漫画のような形態の資料も公開しています。
トップページや製品ページからもアクセスできますが、折角なのでここでも一部紹介します。

「マンガでわかる!! アンテナハウス システム製品利用例シリーズ」
https://www.antenna.co.jp/system/PDFCase000.html
仕事の合間にもさらっと読める、漫画形式の製品利用例の紹介です。同じようなお悩みが見つかるかもしれません。
「XSL-FO の基礎 第2版 – XML を組版するためのレイアウト仕様」
https://www.antenna.co.jp/AHF/ahf_publication/index.html#fo-basis
「XML組版に興味はあるけど、JISやW3Cのページをいきなり読むのは辛いなぁ」という方におすすめです。
「CSSページ組版入門 第4版」
https://www.antenna.co.jp/AHF/ahf_publication/index.html#CSSPrint
こちらはCSS組版での書籍作成の入門書になります。AH CSS Formatter用の拡張を使う箇所もありますが、CSS組版での基本を把握できるようになっています。
「MathML 数式組版入門」
https://www.antenna.co.jp/AHF/ahf_publication/index.html#MathML
数式マークアップ用の言語MathMLの入門書です。こちらも、「興味はあるけれど、いきなりリファレンスを読むのは辛い」という方におすすめです。

その他にも http://www.cas-ub.com/project/index.html で公開している書籍などがあります。「印刷された形で欲しい」という方にもPrint On Demand 本として購入いただけますので、ぜひどうぞ。

Antenna House Formatter V7.0 リリースのお知らせ

2020年2月20日に XML/HTML 自動組版ソフトのベストセラー『AH Formatter』をバージョンアップした『AH Formatter V7.0』を公開しました。

AH Formatter のロゴ

『AH Formatter V7.0』では、欧文組版における行分割処理の改良、BIDI処理の改良、GUI の改良、
ドロップキャップ・PDF 2.0 出力・PDF/X-4p 出力・Adobe Fonts・WebP への対応など
盛りだくさんです。

詳しくは「ニュースリリース」に記載しておりますので、是非ご覧ください。
 
 

2/7のXMLパブリッシング交流会に参加してきました

2020年2月7日、先週の金曜日に開催されたXMLパブリッシング交流会『ウェブ出版と日本語組版の未来』に参加してきました。アンテナハウスもブースを出展していた、page2020のイベントの1つという位置付けでした。

会場到着

会場は池袋サンシャインシティの文化会館7F会議室。最近の技術書典の会場として2F、3Fには来たことがあったので、まあ結構ギリギリの到着でも大丈夫かと高を括っていたのですが、素直にエスカレータを登っていたらスポーツジムに着いてしまい、慌ててエレベータを探しました。

そんなこんなで本当にギリギリの時間に会場に到着すると、席は前方から後方まで割と満遍無く埋まっていました。こくちーずでの申込数上限は80人で、終了後に確認したら登録者数は57人となっていましたね。

以下、スライドや発表に解釈を加えて記述している箇所がありますが、発表者の方の意図に沿えているか分からない箇所もございます。ご了承、ご指摘ください。

木田泰夫氏『JLReqタスクフォース』

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』になるのか」という質問に対して「要件であり、複数あって良いものである」という姿勢が示されていました。その前にされたアキの変更議論なども含めての回答になっており、大変充実した内容でした。

田嶋淳氏『日本語組版に関連する CSS 規格の策定状況について』

https://speakerdeck.com/juntajima/ri-ben-yu-zu-ban-niguan-lian-surucssgui-ge-falsece-ding-zhuang-kuang-nituite

W3Cの作業草案(Working Draft)から勧告(Recommendation)に至る流れの解説の後、それに則って進められている本題のCSS規格の話へ移ります。

勧告候補まで行っても、状況によっては差し戻しされ議論に戻ることもあるというのは随時チェックする程でない身としてはショックがありました。

最新の仕様を追うならDraftを見ることになりますが、何せ草案なので揺れて怖いという話。

「CSS3」という呼称がCSS2.1までのバージョニングの話とは違うということは

不勉強であまり意識したことがありませんでした。CSS2.1に入っていた仕様をレベル3とし、各モジュールに分けて進行状況をレベルで表すということです。

各Webブラウザでの仕様の実装状況のチェック方法など、初学者に嬉しい内容のスライドとなっていました。

JLReqの発表でもあった、要件と対応するCSSのモジュールに関しても、そのモジュールを勧告まで持っていくには別のレイヤでの議論がある、ということでした。「行どり」のためのモジュールは2つほどあったけれどどちらもポシャってしまった話からも、その難しさが察せられます。

より高度なルビ機能の実装に向けたWebブラウザの動向という例も挙げられていました。FireFoxのみ両側ルビに対応を始めたものの、他ブラウザは行っていないといったズレがあるということでした。

定まっていない仕様が定まると、どのような場合に嬉しいのかということで、

text-spacingが規格化されれば、ぶら下げインデントでの約物の表示挙動が統一されたりする、といった例が挙げられていました。

自動縦中横のアイデアなど、どう実装するのか難しそうな話題もあるようです。

また、ルビと圏点を同時に使った場合の挙動といった、議論が定まっていないものもあります。ところで、Antenna House Formatterではルビと圏点の同時使用に対応しており、挙動としてはルビ文字の上に、親文字に対応する圏点を表示します。ルビ文字に合わせた圏点は行えません。

村上真雄氏『ウェブ出版と日本語組版の未来とCSS組版Vivliostyle』

https://vivliostyle.github.io/vivliostyle.js/viewer/vivliostyle-viewer.html#b=/vivliostyle_doc/ja/events/page2020xpub/&spread=false&renderAllPages=true

発表スライドも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の設定変更のみでレイアウトを大きく変更する例などを駆け足で紹介していました。

小形克宏氏『CSS組版とVivliostyleの未来』

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パブリッシング交流会となりました。



Antenna House Formatter

DITA/XML Service Antenna House

IT化が進むロンドン、変わったものと変わらないもの

海外展示会情報第2回目は、展示会の内容から少し離れてロンドンの情報をお伝えしようと思います。筆者自体、約10年ぶりのロンドンでしたが、色々な変化した点を感じられました。

まずヒースロー空港で驚いたのはかなり自動化が進んでいることです。日本の空港を出発する際もパスポートのスキャンなど一部は自動化されていましたが、スタンプを押すところは職員の方がやっていました。しかしヒースロー空港に着くと、入国審査はすべて自動化ゲートで、税関も申告するものが無ければ素通りです。(ただし自動化ゲートを利用できるのは日本や韓国、オーストラリアなど一部の国のパスポートのみです)

また預け荷物が出てくるのも早く、入国審査が5分ほどで終わったにも関わらず、受け取り場所に行ったら、すでに荷物が流れていました。このスピードはおそらく羽田や成田空港よりも早いのではと思います。

パスポートにスタンプが押されないのはちょっと寂しい気もしますが、スピーディーで英会話の必要もありません。

レストランも自動化が進んでおり、キャッシュレスなのは当然ながら、注文をスマートフォンアプリで行うお店もありました。アプリ上で「店舗を選択」、「テーブル番号を入力」、「料理を注文」、「カードで決済」すれば後は料理が来るのを待つだけ、ほとんどウェイターと接することはありません。英語を話すのは料理が運ばれて来た時の「Thank you」くらいです。

ITテクノロジーによって、どんどん海外へ行くハードルは下がってきているようです。

ただ、レンガの壁と赤い屋根の家並みや、2階建てバス、まあまあの味のイギリス料理など、変わっていない点もたくさんありました(笑)