XPathについて」を終えました。ご視聴いただいた方、ありがとうございます。お時間の合わなかった方、動画が公開されたので、ぜひご覧ください。発表直前に気付いたのですが、Zoomの「画面の共有」ボタンの横に、いつの間にやら「注釈」というボタンが増えていたので早速使ってみました。いかがでしたでしょうか。PowerPointスライドと違い(おそらくほとんどの)PDFビューアにはレーザポインタ機能がないので、助かりますね。(他機能として、テキストも表示できます。スライド表示中に「これ補足した方がいいかな」といった思いつきでテキストを追加したりはPDF注釈でも実現できますが、操作の切り換えの手間があるため、Zoomにあるに越したことはない、くらいの感想です。)CSS組版スライド担当したここ数回のウェビナーではPowerPointでスライドを作成していました。FormatterでHTML+CSS組版によるPDFスライドに移行しました。以前XSL-FOでスライドを組版したことを紹介しました。スライド発表程度の長さであれば単一HTMLでもあまりテキスト分量はかさみません。今回、HTMLが650行弱、CSSは240行程度でした。実作業としてはSCSSで記述して変換していたので......240行程度でした。セレクタ部分は簡潔になりますが、改行・インデントとしてはあまり変わらないんですね。Formatterの既定のCSSを読み込んだ上でなので、0から組むのであればもう少し嵩むでしょう。Codeで行いました。printなども最初からある程度対応しています。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ページではテキストで表示する、という目的にも使えます。}}前提として、「スライド上隠蔽されても前後の話は分かるようにする」というライティングが必要です。パラグラフライティングの基本や、DITAにおけるshortdescのように、「これは最低限最初に伝える」という文章から書いていくよいでしょう。ページ向け媒体ではフロートはページの上端、下端を前提に書けます。これはpositionについても同様です。XSLT超入門3の補足さて、発表の補足です。何度か述べましたが、XPathの特長は、簡単には「ある文書で、目的の箇所を簡便な記法で指定できる」「取り出した値の加工が行える」ことにあります。「hoge/fuga/...」と書きつらねるだけでなく、軸や述部といった機能・概念を使うことで、他の言語、というかDOMインターフェイスでは難しいこともスマートに行える、ということをXSLT超入門3ではフューチャーしたのですが、いかがでしたでしょうか。「ここが分からないのでここをじっくりやってほしい」などの要望を、メール・SNS・動画へのコメントなどでいただけると幸いです。発表について、事前の予定から大きく削った箇所としては2箇所です。1.0のコードを3.1でリライトするという内容です。2.0でいかに整理されたか、3.0(3.1)で何が拡充されたか、の詳細を削りました。このあたりについてはW3CのXDMのページに図示があるので内部処理モデルに興味のある方はご参照ください。3.1でのリライトについては、題材として丁度良いバランスのものを見つけるのはかなり難しかったため、構成から削除しました。3.1で明らかに改善されるように書き直す」ということの難しさは、「そもそも1.0で書けなかった処理を拡充したものがほとんど」「1.0では(XSLT上では)独自functionの定義もできないので、XSLTも多分に含むことになる」といった点にあると感じます。1.0のコードでの超絶技巧についてはfunctXライブラリが有名でしょうか。超絶技巧はおいておいて、もう少し簡単なものはあります。...</xsl:template>行っているのはDITAの@class処理で、スペース区切りで続く文字列の部分一致判定です。contains()では含まれてさえいれば真を返してしまうので、topic/ph前後にスペースは必須です。ないと「mytopic/ph」なども一致してしまいます。contains-token()は、なんだったら名指しで「HTMLやDITAのclass処理に使えるよ」と書かれているのでさもありなん。コア関数についてはかなり駆け足で紹介しました。コード例をバーッと載せていましたが、コードをしっかり読んでもらうことは意図していません。これは構成上割と悩みどころで、関数名と処理内容を淡々と流すのであれば、ウェビナーよりもWebサイトや本などを参照するように誘導しても良いと考えています。......といった進め方をしたと思います。1.0では、関数型言語らしい「関数を組み合わせて使う」ことはなかなか難しいため、その有用性のアピールを分かりやすく行うのは難しくなっています。第2版』制作報告」を発表しました。販売、公開よりも発表が先になってしまったため、内容が気になっていた方もいらっしゃるのではないでしょうか。こちらが表紙画像です。XML関連出版物の紹介』ページに掲載しています。Amazonの販売ページへのリンクは次の通りです。https://www.amazon.co.jp/gp/product/4900552836また、本書のPDF版は弊社オンラインショップからご購入いただけます。印刷版とレイアウトの微調整を行いました。Servers資料室のページからご覧いただけます。Formats入門』の初版は2007年に出版社から刊行されました。今年は2021年、つまり14年程前の書籍の改訂版ということになります。内容的な修正は必要とはいえ、以前の版の原稿をベースに新たな版を制作するというとき、XML原稿はほとんど変更が必要ありません。以前の版の構造に不満がある場合はその限りではありませんが。一方で大規模な修正の余地があるのがXSLTでした。ウェビナー(と書籍の後書き)では、XSLTについてはかなり省いて説明することになったため、本記事ともう一度どこかで補足することにしたいと思います。2007年というのは、XSL的にもそこそこ大きな節目でした。2.0のW3C勧告です。1.1の勧告は2006年でしたが、実利用として熟れていないという点では二者とも同様です。1.0とは別言語に近い体験をもたらします。msxmlのXSLTが1.0であることや各ウェブブラウザほか処理系の多くが1.0までしか対応していないことも手伝って、使える状況が限られるのは悩ましいところです。今回は自社事例でしたので、初版で1.0だったXSLTを3.0に書き換えました(完全に3.0向けに最適化したとはとても言えませんが)。1.1での大きなポイントにbookmarkのとindex関係の語彙が入ったことが挙げられます。Formatterの拡張仕様、索引についてはbasic-linkとXSLTによる力技による解決が図られていました。Formatterの拡張仕様では実際のフローコンテンツ登場箇所と同一の箇所に記述するため、処理においてXML中の章構造に当たったときに同時に処理すれば良いことになります。よってXSLT記述としてはbookmark-tree用に処理を追加するよりも単純に書けます。1.0で書く場合は複数回ドキュメントを走査することが難しいということも手伝っていたのかもしれません。1.1のindexを導入することで、XSLTで行わなければならなかった処理が簡略化されます。索引語に当たったときの処理で、「既に同じ索引語が登場しているか」「同じ索引語が同ページに登場したときにページ数表示を合一する」といった判別がXSLのプロパティで変更可能になるため、分岐処理などが大幅に簡略化できました。アドホックな書き換えを行っていたり、徹底できていなかったりするため、引き継ぎをするにはリファクタリングが必至ですが、大体このようなことを行いました。テンプレート中に直接書き込まれたattributeをattribute-setへまとめる共通処理をまとめる。apply-templatesを含まないような分岐は名前付きテンプレートへ追いだし、パラメータを渡すようにするXPathによる値の取得はできるだけテンプレートの先頭でまとめ、利用箇所ではselect="$value"のように呼び出すだけにする先に書いた通り徹底はできておらず、私自身も、テンプレート中で直接attributeを指定しているような箇所をかなり生み出してしまいました。いえ、ギリギリの時期に「ヘッダーの位置をもう少し下げて」といった指示に1行の変更だけで対応できるようにはできたので、無駄ではなかったと思います。1.0時点でも時間さえあれば行える変更で、3.0への変更には関係ありません。値のみを取得、操作したい箇所をfunction化したり、処理をreplace()関数に書き換えたりといった作業は2.0から行えます。3.0としては関数の括弧が入れ子ではなくarrowを使えたり、文字列結合に「||」を使えるといった枝葉の変更点を使用しています。カレンダーを自動生成したい(構想編)師走まで間もなくとなり、日中の気温もかなり下がってきました。来年のカレンダーを用意する時期ですね。「XSL-FOでオリジナルのカレンダーを作りたい」なんてこともあるのではないでしょうか。12月分であるのでDTPソフトウェアやXSL-FOの直書きで頑張っても何とかなるかもしれませんが、来年もある程度使い回せるようにしたり、2021年のように直前の変更があるかもしれないことを考えると自動化したいところです。実現したいカレンダーは次のようなものを想定します。手書きであるため半端なところまでしか日付がありません。実現したいカレンダーのラフ今回は構想編ということで、方針や使っていくFO、XSLTのアタリを付けていきましょう。ページレイアウトカレンダーを作るにあたって、先ず決めなければいけないことは「どの程度グラフィカルにするか」、具体的にはページレイアウトをどこまで制限するか、ということです。個別箇所の自由度を上げるとその分だけ自動化できる箇所は少なくなります。いっても、「高々12月分」と書いたように12パターン程度であれば12通りのページレイアウトを用意しても良いでしょう。今回はページレイアウトを1つに定めることにします。ページレイアウトは1つ毎月1ページで構成(スケジュール帳を組むのであれば「1月分の中にページ分割はあるか」も考慮しなければなりません。Formatterであれば見開き要素が使えるため比較的簡単に対応できます。その場合は、見開きの左右に分割される位置と格子の位置を上手く配置する工夫が必要になりますね。)ページサイズはA3縦(縦420mm、横297mm)にしましょう。月ごとにページを分けるのであれば、各ページに共通して登場するのは年でしょうか。来年であれば「2022年」ですね。これはstatic-contentに置くことにします。年度(4月始まり)で設定したい場合、途中で年の表示は変わりますね。このことに備えて、マーカーで取り出した値を使うことにします。後述するように画像を上半分にページ幅一杯に表示する際、画像の上にstatic-contentを被せて表示することが可能です。Formatterではregion表示の優先順位も自由が利きます。マス目表示を実現するFOここは奇をてらわずtableを使っていきます。カレンダーでは、曜日をカラムのタイトルとして、1週目、2週目、...をrowのまとまりとして、それぞれの日付がセルとして表されます。常にマス全体を長方形にすることとして、rowの数は5週分にします。例示した画像のように日付の始まりと曜日の始まりが一致するなら並べるだけなので楽ですが、そうではないためXSLTで自動化することになります。当月の他、その先月または来月の数日間の情報が必要になることも、お手元のカレンダーから想像が付くのではないでしょうか。元となるカレンダー用のXMLがある場合は、そこにテンプレートを適用するだけで済むでしょう。2.0からは日付のための関数や型を利用できます。ある日付の曜日を取りたいときはたとえばformat-date('[w1]')とすればxs:integer型ではありますが曜日が取得できます。このことと日付用のduration、そしてmodを組み合わせればカレンダーのマス目が実現できそうです。休日・祝日(今回は対応しない)休日、祝日の背景色を変更することについて考えます。日曜を示すカラムが先に決まるため「毎週日曜の背景色を変更する」であればカラムに対して設定したりすれば良いでしょう。XSLTの標準ライブラリは日本の祝日対応まではしてくれていません。確実なソースとなると、内閣府のページにあるCSVでしょうか。2.0以降でCSVをパース可能なようにプログラムを書くこともできますが(<xsl:analyze-string>などを使います)、とりあえず今回は対応しないことにします。そのほか二十四節気なども同様に、「どこかから日付と紐付いた外部ソースを得る」「XSLTで取り込んで展開する」といった手順になるでしょう。話をFOメインに戻します。ページレイアウトは1つだけにすることを決めました。Formatterではページマスターに背景画像を設定することも可能ですが、1つのページレイアウトを使い回すのであれば、フローコンテンツとして指定していく形になるでしょう(実はマーカーに画像を指定することも可能ですが、テンプレートの記述量は大して変わりません)。画像のクリッピングや位置調整については背景画像の方がプロパティ指定の余地が広いため、ブロックコンテナーの背景画像として配置することにします。画像をページギリギリまで表示したい場合、フローコンテンツを塗り足し領域まで表示させる必要があります。拡張仕様使いこなしガイド』に載せていたりします。次回はカレンダーを実現するための関数、テンプレートについて考えていく予定です。「makeが良い、悪い」という話が一部で盛り上がっているのを見ました。結局ツールなので、「用途に向いていなくても慣れなどを取る」か「学習が必要でも別のものを使う価値が見合う」かといった、状況に合わせた選択が必要になるでしょう。個人的にはファイルの絶対パスをハードコードするのは可能な限り避けてほしいですが。ビルドツールにも様々な得手不得手があるものですが、XMLに特化したものもあります。そんな導入で、XProcの話題です。LanguageはXML文書やその他の処理を記述するための言語です*1。output.”とあります。ステップ処理として記述ができる、ファイル操作についてもある程度はできるなど他にもありますが、XSLTとは目的も書き味も結構違います。2010年に1.0がW3C仕様として勧告された後、勧告としてはそれが最新の状態がまだ続いています。3.0の最終ドラフトが上がっており*2、期待が持てるようになってきました。Draftは8月31日に更に更新されていますが。ちなみに2.0は諸般の事情で見送られています。Siegel)*3が刊行されています。teamのメンバーです。3.0についてはドラフト版仕様とこの本を読むのが確実でしょう。3.1に対応したことだと思いますが、今回はXProcの雰囲気だけ紹介します。XProc」にある例です。<p:declare-step>がルート要素です。inputやoutputを省略できる<p:pipeline>も使用できますが、2行程度では大して労力は変わらないですね。XMLSchemaのネームスペースが宣言されているのは、XSLT同様asで型を明示できるからです。書かれた処理を簡単に書けば、「入力をxsl/basic-conversion.xslのXSLTで処理し、出力へ渡す」ということになります。わからないプロパティportの存在がありますね。それぞれの指定で想像が付くかと思いますが、inputによる入力を処理対象(source)というportにつなぎ、with-inputによる入力は(XSLT)スタイルシートというportにつなぎ、このスタイルシートによってsourceを処理します。resultというportにつながった出力へ結果を渡す、という流れです。書くと同語反復をしているように感じられるかと思いますが、それぞれのportにきたものをステップ処理していく流れが直観に近い記述で書けるということです。他のportとしては、スキーマの検証のスキーマを渡すためのschemaなどがあります。<p:xslt>や<p:validate-with-xml-schema>はデフォルトのstepです。portは決まったstepと結びついていて、portに渡したものは結びついたstepが記述されていれば、そのstepで処理されます。デフォルトのstepとport、そして独自のstepと結びついた独自のportを記述していくことがXProcの基本となります。3.1)JSONをXMLに変換せずに利用する先週はXMLの形にしたJSONを、XMLにしないまま扱う方法について紹介します。CSLはでてきません。3.1*1で名前にJSONが入る関数は4つです。map(*))$optionsについては説明しません。JSONをテキストとして引数にとるのがfn:parse-json()とfn:json-to-xml()、fn:json-doc()は外部JSONファイルを読み込むときなどに指定します。fn:unparsed-text()で取得したテキストをfn:parse-json()へ適用するのと大体同じことを行います。今回取り上げるのはfn:parse-json()とfn:json-doc()についてです。mapとarray関係する名前空間は次に挙げるものです。3.1のmap構造とarray構造は一般的なプログラミング言語におけるそれとほぼ同じもので、JSONオブジェクトをそのままの形で格納できます。先週登場したJSONを見てみましょう。]}このJSONを外部ファイルとして取り込むには次のように記述します。select="parse-json($json-text)"/>XMLに変換した先週と、mapやarrayを活用する今回はこの後がまったく異なります。次の記述で、先頭のtitleを一息で取得します。キーitemsの値はarray型です。このままmap:get()を行おうとしてもできませんから、arrayの先頭を取り出すarray:head()を使用しています。ところで上の記述はパイプ演算子を使えば次のように書けます。/>mapのarrayでは、map:find()を利用することで指定したキーの値を配列で得ることもできます。3.0*2のページを確認してください。typeの値が何種類かに決まっていて、その種類を元にif文の判定をしたいのであれば、次のように書けます。</xsl:if>もちろんXMLの構造に変換しても同じことはできますが、より一般的なプログラミング言語に近い形で扱えています。mapやarrayとして扱うために、JSONテキストとして記述してパースしたり、select="map{"key":value}"のような書き方をする以外に、<xsl:map>や<map-entry>を使うことができます。mapの操作はエントリの追加やキー指定での削除などの他、map:merge()によるmapの統合、map:for-each()によるmap要素単位での関数適用などが可能です。arrayの方はarray:fold-left()とarray:fold-right()の畳み込み関数や、array:for-each()でarrayの要素ごとに関数適用などなど、XML形式を扱うよりもすっきりした構文で記述が可能な関数が用意されています。注意しなければならないこととして、mapであるかarrayであるかを間違えるとうまく値を取り出せません。$itemはnodeでもないので、直接xml-to-json()は使えません。3.1のJSONの扱いですが、誤りなどありましたらご指摘ください。前回引用データとスタイルの分離の必要性については述べていたので、CSL自体の歴史を見てみました。Kornblith氏がコントリビュートしていました。Zelleによって開発が主導されています。リンクが張られている2010年9月の外部記事はすでに読めなくなっていて、Blogは1.0のニュースリリース*2からです。Wikipediaの記事*3にはその前身はBiblioXという取り組みであると記載されているのですが、2020年8月31日現在BiblioXのページは消失しており、辿ることが少し難しいようです。BiblioXの発表は2004年ですので、合わせれば15年以上の歩みとなります。脱線しますが、URLが失効しあるものの歴史を辿るのが難しいというのは堪えます。Archiveなどのプロジェクトにしても、無限、無制限というわけにはいきません。それでも、参照した情報元が分かるよう引用情報を記述することの大事さを噛みしめています。引用データのJSONをXSLTでXML化するさて、CSLの引用データを確認してみましょう。...」という文字列が見えます。......無事ダウンロードされました。「export-data.json」が。]}引用データそのものは文書レイアウトのような複雑な構造を持ちませんし、XML形式である必要はないですからね。いえXSLTでこのデータを扱うにはどこかの段階でXMLに変換する必要があります。幸いなことに2020年のXSLTはJSONだって簡単に扱えます。今回はJSONがXSLT3.0で扱えることを示します。3.1)ではmap、arrayという頼もしい機能が用意されていますが、今回は構造に登場するだけです。次のテンプレートでは、外部ファイルであるexport-data.jsonを読み込んでXMLとして表示します。unparsed-text()でテキストファイルとしてJSONを読み込み、読み込んだJSONをjson-to-xml()でXMLにします。select="json-to-xml(unparsed-text($input))"/></xsl:template>結果のXMLを次に示します。</array></map>XML形式で出力せずに扱う方が便利なこともありますが、とりあえず今回のところは得られた引用データのXMLから一部を抜き取ってFOにしてみます。!='title']"></xsl:template>これをexport-data.xmlに適用します。省略していますが、export-data.xmlのtitleとdate-partsから年の値を取り出し、加工して出力できました。font-family="sans-serif">『スタイルシート開発の基礎』</fo:inline><fo:inline>2016年</fo:inline>CSLからXSLT、XSL-FOへの完全な変換まで到達予定でしたが、XPath3.1やXSLT3.0の機能を調べだしたら今回の記事に間に合わなくなったため、少し時間を空けて再挑戦したいところです。WordWebページをWordで作る!CommonMark文書をXSL-FO経由でPDFへ変換する前回、cmark[1]でCommonMark[2]のASTをXML形式で得られることを確認しました。記事中で登場するコードの動作についての保証はできかねます*1。今回の記事で使用した環境は次になります。MR3文書はその目的に適した構造を持ち、組版では多くの場合その構造に沿ってマークアップを行うでしょう[3]。Markdownはそれらを放棄しているために、文書として組版するためには不足するものを補う必要があります*2。基本的には、「レポート」であるならレポートの見た目になるよう、Markdown文書とレポートの対応関係を用意する必要があるということです。level="1">のテキストをレポートのタイトルとする」として、「レポートタイトルはフォントサイズは本文の2倍、中央寄せ、前後のアキは......」とスタイルを用意していきます。書籍を組むのであれば目次や索引などが補う対象となります。記法の数が比較的少ないCommonMarkとはいえ、すべての対応関係について記述するのは労力が大きいため、一部のみとします。PDF」[4]の記事ではリンク記法を応用して脚注記法を用意していますが、処理が複雑化しますのでこういった応用もしません。はじめに[XSL](https://www.w3.org/TR/xsl/)は2部に分けられます。一方はスタイルシート言語としてのXML語彙(XSL-FO)、他方はXML変換のための言語XSLTです。基本版面`<fo:simple-page-master>`とその子要素に基本版面のサイズとそれぞれの区画を記述していきます。`<fo:region-body>`startからendは*行進行方向*、beforeからafterは*ブロック進行方向*です。...```region-bodyの`region-name`の既定値は「xsl-region-body」ですが、**変更**できます。見出しや本文の`<fo:flow>`を記述していきます。版面で指定したページマスタや区画を指定します。紙面に文字を表示するための記述に入れます。LaTeXなどではクラスファイルとしてまとめられている箇所を自力で書いているようなものですので、慣れるまでは煩雑に見えるかもしれません。XMLへの変換このCommonMark文書をPDFに変換します。cmarkによるCommonMark文書のXML変換はコマンドライン操作になります。標準出力に出力されるため、出力結果をファイルに書き込んでいます。変換結果のXMLで文字化けがしていたら、コマンドラインの文字コード設定などが関係しているかもしれません。FormatterでPDFへと変換します。先に結果を見てみましょう。源ノ明朝、源ノ角ゴシックを使用したPDFが出力されています。Formatterではソフトウェア側の設定をあまり弄らずともOpenTypeフォントを使用できます。match="/">に<fo:root>を置きます。</fo:flow></xsl:template>基本版面についてはMarkdown側で干渉するところは特にないので名前付きテンプレートとして省略しました*3。coverPageテンプレートで本文とは別に表紙を作っています。著者情報を「レベル1見出しの直後の段落を著者名にする」といった形でMarkdown側で記述するようにもできるでしょうが、やはり「Markdownでは記述しない箇所を決める」という割り切りがある程度の単純さを保つために必要に思えます。ブロックの例を見てみましょう。</fo:block></xsl:template>コードブロックです。CommonMarkのASTにはinfoとして最初の行の```xml、「xml」が格納されていますが、1からシンタックスハイライトを行うのはつらいので、背景色やボーダー、等幅フォントを指定しています。match="md:code_block">の箇所はかなりシンプルにできていますね。</fo:list-block></fo:block-container></xsl:template>箇条書き(リスト)です。それぞれの項目が短い場合、1段だと余白がかなり空いてしまいます。Formatterではブロックコンテナでも段組みを別に指定できるので、2段組にしてみました。今回使用してはいないものの、数字付き箇条書きでも動作します。CommonMarkのASTでは箇条書きは同じlist構造でtypeプロパティの値が違う形なので、HTMLのようにulとolが分けられているより対応が楽だと感じました。/>のようにすれば階層が割と簡単に分かりそうです。ところでこの組版結果は想定とズレていて、ASTの<item>の内部で一度<paragraph>が使われているため、ラベルと項目の間に、通常の段落を想定した段落開始のインデントが入ってしまっています。インライン記法の変換例を見てみましょう。</fo:inline></xsl:template>和文の簡易マークアップで悩ましいemとstrong。Fromatterでは圏点の拡張がありますから、emでは圏点を使用してみました。XMLとFOで簡単な本を作ってみよう』[5]を片手に、適宜読み替えながら書き進めてみました。Markdownからの変換はLaTeXやHTML経由でのものが多く、それぞれに長所や特徴がありますが、XSL-FOで1つ1つ記法とFOを確かめながらというのも、組版全般やXSLTの学習がしっかり進んだように感じ、良いものです。体感としては、一般的なプログラミング言語で同程度の内容を書くよりも3倍くらいの行数になっている感じがします。*1XSLTとXSL-FOの記法について学習中の人間が執筆しました。誤りが含まれる箇所があるかもしれません。「不足する」他のものとしては、表示言語などもそうです。多くのXMLアプリケーションでは「xml:lang」や「id」といった情報は<xsl:copy-of>を利用して入力から出力へそのまま渡せますが、CommonMarkのASTにその情報は含まれません。<html_block>の情報としてマークアップを処理する、言語ごとにファイルを分けるなど、手軽な処理とはいかないでしょう。match="/">は個人的な感覚としては一般的なプログラミング言語におけるmain関数に近いので、切り出せる処理を適時追い出し、子の箇所で必要な値(で子からの取得が面倒なもの)については<xsl:with-param>で渡しています。<xsl:attribute>は調整する可能性がないものは<xsl:template>内でハードコード、そうでなければxsl:use-attribute-setsで別に切り出しています。2ページもない文書を処理するにしては冗長かもしれません。2024アンテナハウスPDFソフトの統合製品!「技術書典7」に出展いたします。―理論と実践―』を作成いたしました。当日販売いたしますので、ぜひお手にとってご覧ください。本書籍の内容については、先日、弊社ブログでご紹介しております。ご関心ございましたらご覧ください。7◆技術書典ご来場予定の方に一般参加者は13時まで有償の整理券が必要です。整理券は1,000円で、3種類あります。12時~弊サークルの場所は、展示ホールD(2F):き45Dです。アンテナハウスCAS電子出版(き45D)入場が13時過ぎると無償(ただし、待機列解消後)になります。Markdown本はたくさん印刷しましたので、まず売り切れはないと思いますので、遅くてもたぶん大丈夫なはずです。組版しようという動きもあるにはありますが、まだまだ少数派でしょう。両方を1日で学んでしまおうという、ちょっと贅沢なセミナーを開催しています。今まで25回以上開催し、ご参加者の延べ人数は100名様を超えてます。入力していただく、ちょっとしたスパルタな内容です。今月は12日と13日に二日連続で開催しました。二日連続というのは今までになかったかもしれません。皆さんに満足していただき、うれしい限りです。Formatter:Windows版と非Windows版との違い(組版機能に違いはありません)こんにちは。Formatterサポート担当です。Formatterのサポートで比較的よくあるご質問を紹介いたします。FormatterはWindows版、Linux版、Solaris版、Macintosh版など種々のOSに対応したバージョンがございます。Windows版とLinux版とでどちらがいいのか?違いがあるのか?といったご質問を受けることがあります。Formatterの「組版機能」に関してはWindows版と非Windows版とで違いはありません。Windows版以外では実行のためにいくつか設定等を行っていただく必要があります。FormatterのGUIはWindows版のみの機能です。・非Windows版では直接プリンタへ出力することはできません。プリンタへ直接印刷指定できるのはWindows版のみの機能です。Formatterはフォントファイルを含みません。非Windows版では欧文基本14フォントのみインストールされますが、これはメトリクス情報ファイルのみ含まれます。フォントのアウトライン情報ファイルは含まれません。これらのフォントをPDFやPSに埋め込もうとする場合は、ご自身でフォントをご用意ください。それ以外のフォントのインストールはお客様の環境にて行ってください。非Windows版ではフォント構築ファイルにてお客様の環境に合わせて設定していただく必要があります。FormatterはXSLTプロセッサは含みません。Windows版は通常MSXMLがインストールされていますので(特に指定がない限り)それを自動的に使用しますが非Windows版ではお客様がXSLTプロセッサを選択、インストールしていただいたのち、オプション設定ファイルや環境変数にて使用するXSLTプロセッサを指定していただく必要があります。・非Windows版では環境変数を設定する必要があります。Windows版ではインストール時に初期設定されますが非Windows版では設定されません。必要な環境変数はオンラインマニュアルの「環境変数」でご確認ください。【PDFテックの知恵袋】PDFの墨消しとはどんなことでしょうか。墨消し範囲に跨るデータはどうなりますか?【PDFテックの知恵袋】PDFのページに書かれているテキストを取得(抽出)できますか?【PDFテックの知恵袋】PDFのページに書かれているテキストを削除できますか。【PDFテックの知恵袋】PDFのしおりとは何でしょうか。AntennaHouse,Inc.。