日別アーカイブ: 2023年9月11日

[XSL-FO試行錯誤]索引のページ番号表示で一部を太字にする

索引語に続くページ番号表示。「3,6,11-15,100,…」のように並んでいても、「どこがその語を説明している箇所なのか」は分かりません。そのようなときに、索引表現ではとくに重要・説明的である箇所のページ番号についてスタイルを変えて表現することがあります。これを実現するFOについて考えてみましょう。


「ある箇所について特別な処理をしたい」というとき、必要なのは次の情報です。

  • 「ある箇所」と他を区別するルール
  • 特別な処理を実現するFO

今回の場合、「通常の索引と、重要な1箇所の索引が区別できること」については元のXMLとXSLT処理の書き方によって
大きく異なると思われますので、それらを最終的に落とし込むFOについて検討します。

索引用FOの機能

索引用のFOの基本は、@index-keyによって指定されるキーと、そのキーを表示するための<fo:index-citation-reference>です。

索引 XSL-FOの基礎 第2版

これらのFOでは、該当するキーを含むページ番号について、FOプロセッサが列挙し表示を調整するという処理を行います。
つまり、FOプロセッサというユーザの手を離れた段階で処理されるので、「索引用のFOで一部のページ番号だけを太字にしたい」という要求を実現するには、このFOでは上手くいかなさそうだということを意味します。


索引用FOでは「2ページだけを太字にする」処理は難しい

索引にリンクを付けたい場合はfo:index-citation-list/@page-number-treatment="link"で表示されたページ番号にリンクが付与されます。

汎用のページ番号参照

あるページの参照だけであれば、fo:page-number-citaionに該当箇所のidを指定すれば実現できます。これを利用することにします。
制限として、数ページにわたるページ番号参照には対応できません。

汎用的なリンク用のFOであるfo:basic-linkでは、internal-destinationにidを指定することで内部リンクを付与できます。

よって、id情報があれば、該当の番号のページへジャンプするリンクが付与されたページ番号参照が実現できます。

最終的な方針とFO

重要な箇所の索引をspとします。通常の索引のときは、fo:wrapper/@index-keyを挿入する通常の索引用の属性を、spの索引のときはfo:wrapper/@idを本文に挿入します。このとき、spの前後でindex-keyの値は変えておきます。

本文のFOを通常の索引とspとで切り換える
<fo:block><fo:wrapper index-key="あんてなはうす1"/>アンテナハウスは、Data Usability Companyです。</fo:block>
<!-- spの索引語 -->
<fo:block ...><fo:wrapper id="antenna"/>アンテナハウスは、日本のソフトウェア企業で、XML自動組版ソフトウェアAntenna House Formatterや、PDFに関連した製品を開発・販売しています。</fo:block>
<fo:block ...><fo:wrapper index-key="あんてなはうす2"/></fo:block>
<fo:block ...><fo:wrapper index-key="あんてなはうす2"/></fo:block>

索引ページのFO
<fo:block ... space-after="2rem" font-size="72pt">索引</fo:block>
  <fo:block background-color="black" color="white">あ</fo:block>
  <fo:block text-align-last="justify" text-align="justify">アンテナハウス<fo:leader leader-pattern="dots" leader-alignment="center"/><!--
--><fo:index-page-citation-list merge-sequential-page-numbers="merge"
	merge-pages-across-index-key-references="merge" 
	merge-ranges-across-index-key-references="merge">
	<fo:index-page-citation-list-separator>,</fo:index-page-citation-list-separator>
	<fo:index-page-citation-range-separator>-</fo:index-page-citation-range-separator>
	<fo:index-key-reference ref-index-key="あんてなはうす1" page-number-treatment="link" />
</fo:index-page-citation-list><!--spの索引--><fo:inline>,<fo:inline font-weight="bolder"><fo:basic-link
 internal-destination="antenna"><fo:page-number-citation ref-id="antenna"/></fo:basic-link></fo:inline>,</fo:inline><fo:index-page-citation-list
  merge-sequential-page-numbers="merge"
  merge-pages-across-index-key-references="merge" 
  merge-ranges-across-index-key-references="merge">
	<fo:index-page-citation-list-separator>,
	<fo:index-page-citation-range-separator>-
	<fo:index-key-reference ref-index-key="あんてなはうす2"  page-number-treatment="link"/>
</fo:index-page-citation-list>
</fo:block>

fo:index-page-citation-listは複数のfo:index-page-referenceを持てますが、今回は特別扱いするfo:inlineを挟みたいため、一旦終了して特別処理の箇所の後に別のfo:index-page-citation-listを開始しています。

これをFormatterで組版し、冒頭に上げた画像の索引が作成できました。

補足

実作業で厄介なのはXSLTでの処理時に@index-keyを持たないspを、索引リスト作成時にどのようにして取得するかでしょうか。また、spである索引が登場する場合としない場合、sp前後に同じ語の索引が登場しない場合の「,」表示の分岐など、索引FOが吸収していた面倒な分岐も自前で用意する必要があるでしょう。

索引ウェビナーの宣伝

索引について、もう少し全般的な紹介をするウェビナーを2023年9月19,26日(火)16時に行います。今回の記事は応用実装よりでニッチ度が高いものでしたが、まだまだ話題がありますので、どうぞご検討ください。


2024年1月からの電子取引データ保存方策検討:検索要件対応で選択肢を細分すると・・・

電子帳簿保存法第7条で義務付けられている電子取引データ保存の方策を続けて検討します。2024年1月から施行される財務省令(施行規則)で適法とされる保存方策を検索要件対応まで考慮して分けると次の図の1~4の4レベルになります。

背景を黄色で塗りつぶしたセルは2024年より変更(対象者拡大)になったもの。背景をうす緑色で塗りつぶしたセルは2024年より新規追加されたものです。

保存要件対応策については、本ブログで何回か検討してきました。これまでは、検索要件対応についてのレベルを分けずに、次の二つの対応策を検討しました。
A 規則第4条第一項の保存要件に対応して保存する。
B 電子取引データの保存要件に対応せず保存だけする。

参考)
電子取引データ保存の2つの方策を比較する(9月5日)
2024年1月からの電子取引データ保存義務化への対応方法(9月4日)

保存方策Aは検索要件への対応レベルを加味すると、図表の1~3に細分できることになります。

検索要件については前回のブログで説明しています。
電子取引データ保存要件の中で、複雑なパズル並みに理解し難いのが検索要件だ

イは、①取引年月日その他の日付、②取引金額、③取引先の3項目を検索の条件として適用できるように設定するという要件です。

検索項目の設定方法としては、ワークフローシステムから電子取引データを登録するときに、自動的に検索項目を設定するシステムを構築できれば工数がかかりません。しかし、そうではなく、電子取引データを人手で登録し、そのときに検索項目を設定することになると結構工数がかかり負担が大きくなります。

検索要件のロ、ハは検索を手作業で行うときは負担になるかもしれませんが、データ保存にデータベースシステムを使っている場合は負担にならないでしょう。つまり図表の「2 検索要件イのみ対応」のメリットは大きくありません。

こうしてみると図表の「3 検索要件に対応せず保存する」という方策は検索項目を設定する必要がなくなるので、手作業で登録する際のデータ保存コストが小さくなりメリットがあります。

検索要件に対応しなくても良いケースは、2024年1月からの施行規則で適用範囲が拡大されました。具体的にはつぎのようになっています。

(1) 基準期間の売上高が5000万円以下の事業者は、税務調査でのダウンロードの求めに応じる場合、検索項目の登録が不要です。(2023年12月までは同期間の売上高が1000万円以下)。
(2) 電子取引データを出力した書面を日付などで整理をしたうえで提示・提出する求めに応じ、かつ、電子取引データのダウンロードの求めに応じる場合は検索機能の確保の要件は不要になります。(2024年1月より新設)

(2)は売上高が多くても適用されます。書面に出力したものを整理しておく必要があるので電子取引データの件数が多いとコストが大きくなりますが、件数が少ないときは採用を検討する価値があります。

前回:電子取引データ保存要件の中で、複雑なパズル並みに理解し難いのが検索要件だ
次回:日本に残っている「紙と電子の間」のベルリンの壁を壊せ

関連記事