作成者別アーカイブ: AHEntry

[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;
}

参考


目次 vs しおり vs アウトラインの微妙な関係

ここでは、「目次」と「しおり」と「アウトライン」という長文文書のパブリッシングに重要な機能について考えてみます。

目次」とは、冊子本などの最初の方にある、あのページです。「目次」といえば、だれでもイメージが湧くのではないかという位ポピュラーな存在。冊子本で目次のないものは少ないのではないでしょうか。

しおり」という言葉で思い浮かべるものは人によって違うかもしれません。ここでは、PDFファイルのしおりのことを示します。しおりとはどんなものかを知らない人は、次の解説文を読んでみてください。

PDF資料室: PDFのしおりってなに? どうやって作るの?

アウトライン」いう言葉では、人によって思い浮かべる内容は、「しおり」よりもさらに多様かもしれません。ここでは、Microsoft Wordのアウトライン機能を指し示します。アウトラインとは何か、は次のWebページをご参照いただくと良いでしょう。

Antenna House Office Servers資料室: Microsoft Wordのアウトラインと見出しスタイルを活用する方法(概要)

「目次」と「しおり」と「アウトライン」はかなり似通った存在ですが、しかし、微妙に違う点もあります。

そこでざっくりとした比較表を作ってみました。3者が微妙に異なるのは、たぶん、素性が異なるためではないかと思うのですがどうでしょう。特に、アウトラインは、アウトライン編集機能から由来することで、編集操作を伴っています。

PDFのしおりはなんとなく、後から取ってつけたような印象もあります。

比較項目 目次 しおり アウトライン
主な対象 冊子本。冊子本のPDF版(デジタル冊子本) PDF Word文書
英語 TOC (Table of Contents) Book Mark(ISO 32000では、document outlineとなっている) Outline Level
場所 冊子の本文の手前(前付け)に配置する しおりのWindow アウトラインWindow内
役割 本の内容構成を章・節レベルで把握できる PDFファイルのナビゲーション Word文書の編集機能の一部。ツリー編集操作が付随する。
指し示す先 本の内部(分冊のとき、例えば上巻に下巻の目次が配置されることもある。 指し示す先はPDFファイルの内部、別のPDFファイルの内部、Webページなど自由度が高い Word文書の内部
行き方 冊子本ではノンブルで行先を示す。デジタル冊子本ではリンクがあると便利。双方向リンクがあると特に便利。 リンク アウトラインは編集用途なので行き方は二の次。
本文との関係 取り外しはできない PDF編集ツールがあれば、脱着可能、本文から参照しない。PDFリーダー依存。 脱着できない。本文に設定する。表示を別ウィンドウ

冊子本のナビゲーションはページ番号(ノンブル)を使用する。一方、デジタル冊子本や、PDFではナビゲーションにはノンブルよりもリンクを使うのは便利である。ノンブルはページ数の増減に弱いが、リンクはページ数の増減があっても問題が生じないという自由さがある。


第39期決算終了。決算公告を更新しました。

お陰様で、弊社は2022年12月末をもちまして、第39期を無事終了しました。

この2月27日に定時株主総会を開催し、第39期決算報告等が承認されました。そこで、Webページの会社案内中の貸借対照表を更新しましたので、お知らせいたします。

会社概要の「決算公告」の項

現在は第40期に入っております。40年と言いますと長いようですが、会社設立以来、あっという間に過ぎ去ったという印象があります。

コンピュータのソフトウェア業界は、この40年間でまったく変わってしまいましたが、この間、なんとか会社を継続することができましたのは、一重にお客様に支えていただいたお陰です。

ここに深く深く御礼申し上げます。

2023年2月28日

アンテナハウス株式会社
代表取締役 小林 徳滋

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でも使えるというメリットがあります。


Wordの見出しスタイルがPDFのしおりに出力されるかどうか

本日(9月27日)のちょっと一息アンテナハウスウエビナーは「ゼロから学ぼう! Microsoft Wordのスタイル機能・シリーズ -主に見出しスタイルの使いこなし術について解説-」というタイトルでお話しました。

Wordで編集中の文書に見出しスタイルを設定すると、ナビゲーションウィンドウに見出しが階層化(ツリー)表示されるようになります。ウェビナーではこれがPDFのしおりと似たような機能です、と紹介しました。

そうしましたら、終了後の質疑応答で「Wordの見出しによるナビゲーションは、Word文書をPDFにしたとき、PDFのしおりとして設定されるのでしょうか?」という質問をいただきました。

記憶に確信がもてなかったため、質疑応答ではWordからPDFに出力する方法はいろいろあるので調べてみますと回答いたしました。ウェビナー終了後に調べてみましたので、以下に、簡単に整理します。

1.Wordのナビゲーションウィンドウの表示
次の図はWordで編集中の文書に段落のアウトラインレベルと見出しスタイルを設定した例です。この例では「はじめに」と「参考資料」はアウトラインレベルを設定しています。また、章番号のついた段落は見出し1、節番号のついた段落は見出し2、項番号のついた段落は見出し3のスタイルが設定されています。

Wordのナビゲーションウィンドウ

2.Antenna House PDF Driver V8でWordからPDFを作成する
(1) Wordの印刷メニューからPDFを出力すると、でき上ったPDFにはしおりは設定されません。

(2) Antenna House PDF Driver V8は、Wordのアドインとしてリボンに組み込むことができます。アドインを使ってPDFを作成するときは、オプションでしおりを作成するかどうかを指定できます。

PDF Driver V8のアドインーオプション設定ダイアログ

ここで「しおりを出力する」にチェックを入れると、出力されたPDFでは、見出しスタイルを設定した段落がしおりとして作成されます。(アウトラインレベルを設定した段落はしおりになりません)。

PDF Driver V8で作成したPDFのしおり

3.Wordの「名前をつけて保存」でPDFを作成する
(1) Wordの「名前をつけて保存」でPDFを作成するとき、オプション設定をデフォルトのままとしてPDFを作成するとしおりは作成されません。

(2) Wordの「名前をつけて保存」にはオプション設定を変更するダイアログを表示して、しおりを作成する方法を指定できます。オプションの「次を使用してブックマークを作成」で「見出し」にチェックしてみます。

Wordの名前を付けて保存のオプション設定

できあがったPDFを見ると、一応、しおりが設定されています。しかし、しおりは不完全です。

Wordの名前を付けて保存で、PDFにしおりを作成する

問題点は①しおり項目が2重になっている箇所がある。②見出しの中でしおりに出力されていない箇所がある。

こうしてみると、Wordの名前を付けて保存のしおり作成は不完全なできのようです。なお、Micorosft Wordにもいろいろなバージョンがありますので、あくまでも手元のWordで調べた限りではありますが。

〇チェックに使ったツールなどのバージョンは次のとおりです。
① Microsoft Word 2019 バージョン2208(ビルド15601)
② Antenna House PDF Driver V8.0MR1 (8.0.1) 『瞬簡PDF編集9』同梱のもの

2022年11月15日追記
アンテナハウスでは、PDF Driverを使わないで、Wordファイルを直接PDFに変換する「Office Server Document Converter(OSDC)」という製品も提供しています。

OSDCのWebページ:
https://www.antenna.co.jp/sbc/

OSDCでは、WordファイルをPDFに変換するさい、しおりを出力することができます。例えば、コマンドラインでは次のように指定します。

C:\>sbccmd -d 変換元.docx -o 変換先.pdf -p @PDF -docpdfbookmarklevel n
(n: Wordの見出しのレベル)


【動画公開】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からあります。


『トップガン マーヴェリック』ピート・ミッチェルは大佐? 大尉?

ピート“マーヴェリック”ミッチェルといえば、トム・クルーズ演じる海軍パイロット。1986年に大人気となった『トップガン』の主人公です。36年ぶりの第2作目が5月27日から公開されて大人気です。公開直後は混んでいたので敬遠、2週目に見に行ったのですが、気になったことが幾つかあり、チェックするために3週目に改めて見に行きました。

そのひとつは階級です。最初に見に行ったとき、英語ではCaptainと呼ばれていたのはよく覚えていたのですが、日本語字幕では大佐になっていたと思い込んでいました。ところが、『週刊文春』6月23日号の町山智浩・言霊USAに『トップガン マーヴェリック』の話題がとりあげられていて、そこに、マーヴェリックは「36年後の今も大尉のまま出世していなかった」という文があり、ちょっとびっくり。

大佐だと思っていたけど「え! 大尉だったのだろうか?」と気になってしまいました。それを確かめるためにふたたび見に行ったのですが、オープニングの直後には、ピート・ミッチェル大佐という階級付の紹介があり、さらに、映画の中では何度も何度もCaptain(字幕では大佐)とでてきました。

町山智浩さんはカリフォルニアのバークレー在住とのことなので、現地で字幕なし英語版を観たのでしょう。で、Captainを大尉と理解したのだろうと思います。しかし、米国海軍のCaptainは、日本語では大佐と訳すのが普通のようです。

なお、トップガンの第一作では、マーヴェリックを階級で呼ぶ箇所は遥かに少ないですが、その中で、恋人になる前のチャーリーがピートに対して(字幕で)大尉と呼びかけており、原語ではLieutenantと呼んでいたようです。

なので、英語で見ても、LieutenantからCaptainに昇格しているわけで、「36年後の今も大尉のまま出世していなかった」という解釈は誤りでしょう。アメリアが、まだ大佐なの? とからかうシーンでは、ピートは「飾りの多い大佐だよ」(勲章をいろいろもらった)と言い訳しており、マーヴェリック本人も階級を気にしてないわけではないようです。

ちなみに第1作では、大尉と呼びかけられるケースはまれで、上官・教官・仲間はマーヴェリックと呼び、友人・恋人同士ではピートです。これに対して、第2作は、上官も同僚もミッチェル大佐と呼び、生徒は大佐と呼んでいます。友人・恋人同士ではもちろんピートです。マーヴェリックと呼ばれるケースは少ない。最後にフェニックスが「マーヴェリックは5機よ」と言うので、パイロット仲間ではマーヴェリックなのだろう。このように呼ばれ方から見ても、第1作と第2作で地位が相当変わっていることが分かります。

ところで字幕と言えば、感心したのはアイスマンが画面にタイプした「It’s time to let it go.」「It’s time to let go.」を「過去は水に流せ」と訳しているところ。なかなかこういう訳はできないな、と感心した次第です。

ただ、実をいうと「it」があったかどうか確信をもてません。文法的には必要なような気がしますがどうなんでしょう。もう一度見に行こうかなぁ。確認したところitはありませんでした。

神は細部に宿り、プログラムは1文字でエラーになるので、常に隅々までチェックを怠らないようにしないとね。


PDFの表形式データをExcelに変換する機能を比較してみる

PDFファイルの中に表形式のデータがあったとき、このデータを加工したり、集計したり、計算したり、あるいは別のアプリケーションに取り込みたいと思うことがあります。少しくらいのデータなら、手入力するという方法でもなんとかなるけれど、量が多いとき、繰り返しが多いときなどは手作業ではなく、なんとか自動的にできないかと思うことでしょう。

いまは、PDFファイルの表からExcel形式に変換するツールは市場にいくつかあります。来週(5月31日)のちょっと一息・アンテナハウスウェビナーでは、PDFファイルの表をExcel形式に変換するツールとして、Adobe のAcrobatと、弊社のPDFtoCellsの次の2つを選んで、変換精度についてがちの比較を行ってみます。

夕陽の対決! PDF-Excel変換ソフト PDFtoCells VS Acrobat
     -真に使えるExcel変換ソフトはどちらか、徹底検証します

2022年5月31日16時から (無料)

詳しい紹介とお申し込みは次のZoomページにてどうぞ。

Zoom でのお申し込みはこちら


速習XSLT超入門1(明日に迫るXSLT超入門2ウェビナー )

ゴールデンウィークも明け、XSLT超入門2のウェビナーが明日に迫りました。

セミナーのようなイベントでは、ナンバリングによって「初回参加してないからどうしよう」と尻込みされてしまう方がいるかもしれません。ということで、第1回をおさらいする記事を用意しました。
「これだけ見ておけば大丈夫」というよりは、書籍におけるあらすじと目次のようなものと考えてください。

導入として「XSLTを活用する自動組版の流れとして、XSLTがどの部分の役割を果たすか」を紹介しています。元の文書にあるコンテンツから目次を生成したりできます。
このウェビナー内では大きく触れていませんが(PDF自動生成超入門の内容なので)、「生成時まで内容が決定できないこと」をオブジェクトとしてレイアウトできるのがXSL-FOとなります。弊社製品Antenna House XSL Formatterによる拡張要素・プロパティも、この視点で眺めてみるとスタイルシート設計に役立つのではないでしょうか。

書籍の完成状態を例にして、抽象的な「構造」について紹介し、それをXMLで表現することについて触れています。

XMLを変換するにあたって、「どの部分を変換するか」という指定が必要になります。XSLTでは、そのためにXPathを使うよ、ということを紹介しています。XPathはXSLTから独立するほど多様な機能がありますが、「XML上の特定位置を指定する」ことは基本といって良いでしょう。そのために「ノード」という形でXML文書を解釈し、ノード間の関係としてXML上の位置を指定できるようにしています。関係の方向性として「軸」があり、不足する指定を補う「述部」がある、という紹介をしています。

より実際的な説明として、弊社の過去記事を紹介しておきます。
XSLTを学ぶ (1) XMLのツリーモデルとXPath/XSLTのツリーモデルではルートの意味が違う

明日のウェビナーが「基本文法編」ということで、では「XSLTの基本」は何を紹介しているんだ、疑問があるでしょう。ここでは初学者にとって概念的にあまり馴染みがないであろう、XSLTを構築する基本であるxsl:template@matchとxsl:apply-templatesについてを図を用いて紹介しています。文法は比較的資料があるため、図示に注力した形です。後半のデモでトラブルがあった関係でウェビナーと動画で違いが生じてしまっていますが、このmatchとapplyの関係はコインソータに似ている、ということを覚えておくと良いでしょう。

ウェビナーではトラブルのあったデモについては動画を撮り直しています。
デモを通し、xsl:template@matchとxsl:apply-templatesでXML文書を処理していく様子を紹介しています。

全体を通して、「学習開始で環境構築に悩むよりプレイグラウンドなどを利用するのも良い」「業務利用としてXMLエディタは十分ペイする」「変換元のXML文書としてCommonMark文書が難易度として丁度良いのではないか」といった話をしており、「初学者が取り組みやすい形を提示する」をサブテーマとしていました。

明日のウェビナーではこの第1回からの流れを受けて、基本的なコードリーディングによる学習ができる段階まで持っていけるようにすることを目標にしています。ご参加をお待ちしています。


DITA-OTでソースコードを書くならcoderefが便利

DITAでソースコードを書くときはcodeblock要素を使います。

(HTML5では引用ブロックやcodeblock(pre/code)もfigureの子孫として記述する方法がよく見られます。個人的な感覚として、英語だとキャプションに「figure 1」のようにしてソースコードが記載されていても違和感はないのですが、日本語で「図1」となっているところにソースコードが記載されていると違和感があります。)

さて、codeblockの中をどう書くかについて、方針はおおむね次の2つです。

  • 直接書く。XMLの<や>は
    • &lt;のようにして書く
    • xml-mentionドメインのタグを使って書く
  • coderefを使う

今回は記事タイトルにもあるように、coderefを使う方法が便利という話です。

DITA-OTではcodeblockでの処理について、仕様から拡張しています。記事タイトルが「DITAでcodeblockを書くときは~」ではないのはDITAの仕様ではないからです。なお、記事を作成する際に試行した環境はDITA-OT 3.7.1となります。

Extended codeblock processing DITA-OT

拡張内容は幾つかあるのですが、先に述べた通り、今回紹介するのはcoderefについてです。

codeblockにはテキストをそのまま記述することもできますが、XMLタグ、というか<などがきっちり処理されてしまうため、XMLやHTMLをソースコードとして例示するのは結構大変です。そこでcoderefです。

coderefは外部ソースコードを(主にテキストとして)参照し、結果を展開してほしい場合に使うタグです。@hrefで参照する先を指定します。XMLを参照する場合、@format=”xml”を付けましょう。

coderefの第一の利点は<をエスケープしなくて済む点です。これについてはDITA仕様のうちです。

coderefを使ったコードブロック
<codeblock xml:space="preserve"><coderef href="hoge.xml" /></codeblock>

ただ、実際のXMLファイルというのは結構行数が嵩みます。「coderefで参照する用にコード片を別ファイルに保存して……」というのはメインテナンス性からするとあまり歓迎できません。そこでDITA-OTの機能によって行数を制限します。

coderefの拡張記法は#から続くフラグメントによるものです。これに対応していない、DITA-OT以外のDITA処理系で使われても、ファイルの全行が出力されるだけで済みます。……結構大変なので、keyrefで切り出して切り換え可能にしておくのが良いかもしれませんね。

行数の記法はドキュメントにある通り、#line-range(<start>,<stop>)またはRFC 5147の記法で#line=<start><end>のようにして開始行、終了行を指定します。

このままで十分便利ですが、「元のソースコードを弄ったらトピックファイルで指定している行位置も変更しなくてはいけないのだろうか」と疑問を持たれたことでしょう。それはあまりメインテナンス性が良くありませんね。ということで、任意文字列を行位置の識別子にする方法が提供されています。
#token=<start-text>,<end-text>を指定すると、ソースコード中のstart-textがある行の次行からend-textがある行の前行までが範囲として取り出されます。想定としてはコメントアウトした行にstart-text、end-textを書いておく形のようなので、あまりトリッキーなことはしない方が良いでしょう。ほかにも幾つかの機能がDITA-OTのページで紹介されていますが、プラグインや処理系依存の機能もあるようなので都度確かめて使うと良いでしょう。

coderefのstart,end用文字列を追加したXML
<!-- example1start -->
<fo:block><fo:inline>Title</fo:inline></fo:block>
!-- example1end -->

ほか、coderefというcodeblockの中で更に別のタグを使うことのメリットは、@hrefで参照した箇所と、直接書く箇所をcodeblockの中で行える点です。

coderefを使ったコードブロック

<codeblock xml:space="preserve"><coderef href="hoge.xml#line-range(1,5)" />
... <!-- 直接書いた部分 -->
<coderef href="hoge.xml#line-range(10,15)" /></codeblock>

1-5行目、「…」を書いて10-15行目、なんて表示も可能になります。

そんなcoderef、DITA 2.0で若干の変更が入ることが現在のドラフトで言及されています。といってもエンドユーザがトピックを記述する上ではそう変化はなく、主に仕様上の立ち位置がより整理されるということのようです。


Pages: Prev 1 2 3 4 5 6 7 8 9 10 ... 210 211 212 Next