カテゴリー別アーカイブ: コラム

2024年1月からの電子取引データ保存をどのように進めたら良いかを考える(1)保存しなければならないのは誰?

2022年1月より施行電子帳簿保存法の第7条で、所得税(源泉徴収に係る所得税を除く。)及び法人税に係る保存義務者は電子取引を行った場合、その取引に関する電磁的記録(デジタルデータ)を保存することが義務付けられています。2021年12月まではデジタルデータを書面に出力して、書面で保存しても良かったのです。但し、その準備が間に合わない向きが多いため2023年12月までは宥恕措置として、引き続き書面で保存することができるようになっています。しかし、2024年1月からは宥恕措置が廃止されデジタルデータ保存が必須になります。

この経過・事情の詳細については、これまでのブログを参照してください。
1.DX時代に逆行する電子帳簿保存法は、そろそろ、いさぎよく廃止するべきではないでしょうか?
2.電子帳簿保存法・電子取引データ保存で目にあまる迷走を続ける財務省
3.電子取引データの保存、宥恕措置終了後の2024年(令和6年)1月1日からはどうなる?
4.2024年1月からの電子取引データ保存方法がどうなるか? 財務省令(施行規則)を読んでみる

個人的には電子帳簿保存法は本質的なところで設計を間違えている日本希代の愚法(という言葉があれば)と断言して差し支えないと考えています。そうは言っても日本国の法律になってしまっている以上、善良なる国民としてはこれを守らざるを得ません。ということで、これからデジタルデータ保存の検討を始める保存義務者であるという想定のもとに、どのように準備を進めると良いかを考えてみます。

誰が対象か

最初に、「保存義務者」とは誰か? を検討します。

電子帳簿保存法の第2条4項には保存義務者が次のように定義されています。
保存義務者 国税に関する法律の規定により国税関係帳簿書類の保存をしなければならないこととされている者をいう。

ところが、第7条では、「所得税(源泉徴収に係る所得税を除く。)及び法人税に係る保存義務者は、電子取引を行った場合には、財務省令で定めるところにより、当該電子取引の取引情報に係る電磁的記録を保存しなければならない。」となっています。

つまり、電子取引のデジタルデータ保存では、所得税(源泉徴収に係る所得税を除く。)及び法人税に係る保存義務者に限定されているわけです。ご承知のとおり、国税にはこれ以外に様々な種類があり、特に大きなものでは消費税があります。消費税に係る証憑は必ずしもデジタル保存する必要がないことになります。なぜ消費税が除外されているのは謎です。

法人税の課税対象は、普通法人、一般社団法人等又は人格のない社団等などの法人で電子取引データの保存義務者となります。個人事業主は、所得税の課税対象者なので、電子取引データのやはり保存義務者です。

では例えば、本職会社員で、副業をしている人、個人の不動産を貸したり、フリマで販売したり、あるいは株式投資やFXなどの投資活動を行っている人はどうなるでしょうか? 

これについては、国税庁から出ている電子帳簿保存法一問一答【電子取引関係】 (PDFファイル/773KB)
【令和6年1月1日以後の取扱いに関するもの】
に次のようなQ&Aがあります。

質問(問68)
私は、勤務先から支払われている給与のほか、副業として行っている講演・原稿執筆から得ている雑所得を有しています。これらの雑所得を生ずる活動については、相手方等との一切のやりとりを電子メール・ウェブサイト上で行っていますが、法第7条の規定に基づき、その取引情報に係る電子データを保存しなければなりませんか。

回答
所得税法上、ある年の雑所得を生ずべき業務に係る収入金額について、前々年の金額が300万円を超える場合には、その業務に関してやりとりした請求書・領収書等(以下「現金預金取引等関係書類」といいます。)を保存する必要があります。
副業として行っている講演・原稿執筆等は、ここでいう雑所得を生ずべき業務に該当することから、その業務に関する現金預金取引等関係書類の保存義務があるため、それを電子データで授受した場合には、法第7条の規定に基づいて当該電子データを保存する必要があります。

前々年の収入金額が300万円を超えるという閾値が設定されていますが、電子取引データの保存義務があるようです。このように、電子取引データ保存義務が課せられるのは法人だけでありません。個人事業主(開業届を出している)や事業主ではない個人も対象になるようです。

他人事では済まされない人も多いのではないでしょうか。

前回:2024年1月からの電子取引データ保存方法がどうなるか? 財務省令(施行規則)を読んでみる
次回:2024年1月からの電子取引データ保存をどのように進めたら良いかを考える(2)保存しなければならない書類は?

関連記事




アウトライナー
PDFを解析して しおり・目次を自動生成


瞬簡PDF 変換 2024
PDFをOffice文書へ高精度変換

2024年1月からの電子取引データ保存方法がどうなるか? 財務省令(施行規則)を読んでみる

電子帳簿保存法の第7条で、電子取引を行なったとき、電子取引データをデジタルで保存しなければならないことになっています。その保存方法については財務省令で定めることになっており、2024年1月以降の保存方法は、2024年1月1日より施行される財務省令によります。

この財務省令(「電子計算機を使用して作成する国税関係帳簿書類の保存方法等の特例に関する法律施行規則」)(以下、施行規則)を読んで、電子取引データ保存方法について整理してみます。

電子取引データ保存については施行規則の第4条に規定されています。第4条には1~3の3項があります。

2項は用語の意義を規定しているものなので省略すると、第4条の主な内容は1項と3項になります。このうち、1項が電子取引データの保存要件に関する規定で、いわば本筋と言えます。これに対して、3項は本筋の要件を満たせないときのこと(猶予措置)を規定しているという枠組みのようです。

それぞれについてできるだけ簡単にまとめてみます。なお、以下の説明は分かりやすくするためかなり大雑把にまとめていることに注意してください。

1項 保存の要件について

原則として、次の(1)~(6)が保存の要件とされています。
※例えば、「電子帳簿保存法第7条 詳細」にも具体的な解説がありますのでご参照ください。
(1) 保存場所:取引情報の授受が書面で行われたとした場合に保存するべき場所
(2) 保存期間:取引情報の授受が書面で行われたとした場合に保存するべき期間
(3) 保存のための措置:次のa~dのいずれかを行う。
a. 電子取引データにタイムスタンプを打ってから取引データを授受する
b. 取引データを授受してから速やかにタイムスタンプを打つか、業務処理規程で定めた期間を経過した後速やかにタイムスタンプを打つ
c. 訂正削除できないか、訂正削除の事実・内容を確認できるシステムを使用して授受及び保存を行う
d. 電子取引データの訂正・削除を防止する事務処理規程を定めて運用する
(4) コンピュータシステムと説明書を備え付けて、画面と書面に整然と速やかに出力できるようにする
(5) 検索要件:次の検索要件を満たすことができるようにすること
a. 取引年月日その他の日付、取引金額、取引先を検索条件として設定できること
b. 日付または金額の範囲指定で検索できること
c. 二つ以上の任意の項目を組み合わせて検索できること
(6) (システム開発を他者に委託しているとき)システムの概要を記載した書類を備える

検索要件については例外があります。
例外1:税務調査の際に電子取引データの提示・提出要求に応じるようにしているなら、(5) 検索要件のb. c は不要。
例外2:さらに基準期間の売上高が5,000万円以下、または電子取引データを日付けと取引先毎に出力した書面を提示・提出に応じて、かつデジタルデータの提示に応じることができるなら、(5) 検索要件は不要。

保存要件の緩和措置
2023年12月までの施行規則では、タイムスタンプを打つときの電子取引データを保存する者や直接監督する者の情報を確認できる必要がありましたが、2024年1月からは不要になります。また、例外2の基準期間売上高は2023年までは1000万円以下ですが、2024年1月から5000万円となります。例外2の「または」以降は2024年1月から新設されます。

3項 保存の要件を満たせないとき(猶予措置)

3項(猶予措置)の全文を引用すると次のようになります。

法第七条に規定する保存義務者が、電子取引を行った場合において、災害その他やむを得ない事情により、同条に規定する財務省令で定めるところに従って当該電子取引の取引情報に係る電磁的記録の保存をすることができなかったことを証明したとき、又は納税地等の所轄税務署長が当該財務省令で定めるところに従って当該電磁的記録の保存をすることができなかったことについて相当の理由があると認め、かつ、当該保存義務者が国税に関する法律の規定による当該電磁的記録及び当該電磁的記録を出力することにより作成した書面(整然とした形式及び明瞭な状態で出力されたものに限る。)の提示若しくは提出の要求に応じることができるようにしているときは、第一項の規定にかかわらず、当該電磁的記録の保存をすることができる。ただし、当該事情が生じなかったとした場合又は当該理由がなかったとした場合において、当該財務省令で定めるところに従って当該電磁的記録の保存をすることができなかったと認められるときは、この限りでない。

猶予措置の引用文中アンダーラインを施した箇所は2024年1月1日からの施行規則で追加されたものです。本筋で電子取引データの保存要件について規程しているにも関わらず、猶予措置では規程に関わらずに保存できるということなので、矛盾しているように見えます。猶予措置の前提として税務署長が相応の理由があると認めることも、恣意的な印象があります。このあたりはもう少し調べてみたいところです。

なお、第3項でも電子取引データの提示・提出が必要とされているので、電子取引データの保存が不要になるということはありません。

Webを検索すると2024年1月から「電磁的記録の電子保存義務化の経過措置として整備されていた「宥恕措置」が、恒久的なものとして制度化された」といった解説も見られます。しかし、この理解は誤りと思われます。つまり、宥恕措置では書面による保存を認めていたのに対し、2024年1月からの猶予措置では「電磁的記録及び当該電磁的記録を出力することにより作成した書面」の提示となっているので、デジタルデータと書面の両方を提示する必要があります。つまり書面の保存のみでは認められなくなります。

最後の「ただし」以降は何を意味しているのか理解しにくい文で不気味です。いまのところ、これに関する解釈を見つけることができていません。

前回:電子取引データの保存、宥恕措置終了後の2024年(令和6年)1月1日からはどうなる?
次回:2024年1月からの電子取引データ保存をどのように進めたら良いかを考える(1)

関連記事




瞬簡PDF 変換 2024
PDFをOffice文書へ高精度変換


瞬簡PDF 編集 2024
かんたん操作でPDFを自由自在に編集

電子取引データの保存、宥恕措置終了後の2024年(令和6年)1月1日からはどうなる?

前回は、「電子帳簿保存法・電子取引データ保存で目にあまる迷走を続ける財務省」として、法律で2022年1月から電子取引データをすべてデジタル保存することが法律で義務付けられたのにも関わらず、実際には2022年1月から2023年12月まで宥恕措置として書面保存ができるようになったことを説明しました。

この宥恕措置は2023年12月で終了します。では、2024年1月からはどうなるでしょうか?

これについては、2022年(令和4年)12月23日に閣議決定された2023年度(令和5年)税制改正大綱に次のような方針が出されています。

令和5年度税制改正の大綱(pp.82-83)

(3)電子取引(取引情報の授受を電磁的方式により行う取引をいう。以下同じ。)の取引情報に係る電磁的記録の保存制度について、次の見直しを行う。
① 電子取引の取引情報に係る電磁的記録の保存要件について、次の措置を講ずる。
イ 保存義務者が国税庁等の当該職員の質問検査権に基づく電磁的記録のダウンロードの求めに応じることができるようにしている場合には検索要件の全てを不要とする措置について、対象者を次のとおりとする。
(イ)その判定期間における売上高が 5,000 万円以下(現行:1,000 万円以下)である保存義務者
(ロ)その電磁的記録の出力書面(整然とした形式及び明瞭な状態で出力され、取引年月日その他の日付及び取引先ごとに整理されたものに限る。)の提示又は提出の求めに応じることができるようにしている保存義務者
ロ 電磁的記録の保存を行う者等に関する情報の確認要件を廃止する。
② 電子取引の取引情報に係る電磁的記録を保存要件に従って保存をすることができなかったことについて相当の理由がある保存義務者に対する猶予措置として、申告所得税及び法人税に係る保存義務者が行う電子取引につき、納税地等の所轄税務署長が当該電子取引の取引情報に係る電磁的記録を保存要件に従って保存をすることができなかったことについて相当の理由があると認め、かつ、当該保存義務者が質問検査権に基づく当該電磁的記録のダウンロードの求め及び当該電磁的記録の出力書面(整然とした形式及び明瞭な状態で出力されたものに限る。)の提示又は提出の求めに応じることができるようにしている場合には、その保存要件にかかわらず、その電磁的記録の保存をすることができることとする。
③ 電子取引の取引情報に係る電磁的記録の保存への円滑な移行のための宥恕措置は、適用期限の到来をもって廃止する。
(注)上記の改正は、令和6年1月1日以後に行う電子取引の取引情報に係る電磁的記録について適用する。
(4)その他所要の措置を講ずる。

この方針に基づいて、財務省令が改正されて2023年(令和5年)3月31日に、新しい財務省令が公布されています。

電子計算機を使用して作成する国税関係帳簿書類の保存方法等の特例に関する法律施行規則の一部を改正する省令
新旧対照表(PDF)
新財務省令(Web)

このように手続きは粛々と進められています。新財務省令は2024年(令和6年)1月1日より施行になるので、来年からの電子取引データ保存は新財務省令に沿って行うことになります。

新財務省令に沿う電子取引データ保存の要件については、別途整理する予定ですが、このように短期間で、分かりにくい方針転換が行われるため、納税者である民間企業の立場から見るとシステム投資の計画を立てにくい状態となっています。

前回:電子帳簿保存法・電子取引データ保存で目にあまる迷走を続ける財務省
次回:2024年1月からの電子取引データ保存方法がどうなるか? 財務省令(施行規則)を読んでみる

関連記事




HTML on Word
WebページをWordで作る!


瞬簡PDF 統合版 2024
アンテナハウスPDFソフトの統合製品!

電子帳簿保存法・電子取引データ保存で目にあまる迷走を続ける財務省

先日は、「DX時代に逆行する電子帳簿保存法は、そろそろ、いさぎよく廃止するべきではないでしょうか?」と主張しました。この記事をお読みになっても、なぜ廃止するべきと主張するのか理解できないかもしれません。

そこで、今回は電子取引データ保存を例として、財務省の迷走をご紹介します。

例えば、アマゾンや楽天などのECサイトで、会社で使う物品を購入したとします。そうすると請求書または領収書をPDF形式で入手して、それによって経理処理をすることになるでしょう。

このPDF形式の証憑は電子帳簿保存法で保存義務が課せられます。該当する条文は、当初は第10条でしたが、2021年3月に電子帳簿保存法が改定されてからは第7条となります。

第10条は次のようになっていました。

第十条 所得税(源泉徴収に係る所得税を除く。)及び法人税に係る保存義務者は、電子取引を行った場合には、財務省令で定めるところにより、当該電子取引の取引情報に係る電磁的記録を保存しなければならない。ただし、財務省令で定めるところにより、当該電磁的記録を出力することにより作成した書面又は電子計算機出力マイクロフィルムを保存する場合は、この限りでない。

つまり、PDFを出力した書面を保存すればよく、デジタルデータは保存する必要はなかったのです。ところが、2021年3月改正の第7条では次のようになりました。

第七条 所得税(源泉徴収に係る所得税を除く。)及び法人税に係る保存義務者は、電子取引を行った場合には、財務省令で定めるところにより、当該電子取引の取引情報に係る電磁的記録を保存しなければならない。

そして、財務省令で保存のための要件が定められ、2022年1月より施行するとされていました。つまり、2022年1月からは書面にプリントして保存するのではなく、財務省令の要件を満たした上で、デジタルデータのまま保存しなければならないことになったわけです。

こうした状況を予想して、アンテナハウスは、2021年春から財務省令で定める要件を満たす電子取引データ保存専用の製品開発に急いで取り組みました。これは『電子取引Save』という製品名で2021年秋から発売するとともに、2022年1月から『電子取引Save』を用いて、自社でも電子取引データ保存を運用することとしました。

『電子取引Save』のWebページ
『電子取引Save』発売のお知らせ

ところが、2021年秋の税制改正大綱策定で雲行きが怪しくなりはじめました。そして最終的には2021年12月27日に財務省令が改定され、2022年1月から2024年12月31日まで次のような宥恕措置が施行されることとなりました。

電子取引データの出力書面等による保存措置の廃止(令和3年度税制改正)に関する宥恕措置について(財務省のWebページへのリンク)

一言でいえば、間に合わない事業者が多いので引き続き書面による保存を可能にするということです。

こうして、折角、新製品を開発してリリースしたにも関わらず、肝心かなめの財務省が腰砕け、真面目に取り組んだ国民は梯子を外されたということになりました。でも間に合わないというのは言い訳に過ぎないのです。実際に弊社は2022年1月より『電子取引Save』を使って電子取引データを保存しているわけですから。

こうして財務省の方針が一転してから約2年、2023年12月で宥恕措置の期限が切れることになります。さて次回は2022年から2023年の経過で迷走の第2幕、2024年1月からの保存がどうなるかをみたいと考えています。

参考資料)
見積書、注文書、請求書、領収書をPDFとして作成し、Webダウンロード配信や電子メールによる送受信をしたときの保存義務について(更新日: 2021/11/3)

前回:DX時代に逆行する電子帳簿保存法は、そろそろ、いさぎよく廃止するべきではないでしょうか?
次回:電子取引データの保存、宥恕措置終了後の2024年(令和6年)1月1日からはどうなる?

関連記事




アウトライナー
PDFを解析して しおり・目次を自動生成


瞬簡PDF 書けまっせ 2024
PDFに文字が書ける! 入力欄を自動認識

DX時代に逆行する電子帳簿保存法は、そろそろ、いさぎよく廃止するべきではないでしょうか? 

法人税法などの国税関連法では、企業は決算に影響を与える証憑書類を、決算申告時点から7年(必要に応じて10年)保存することが義務付けられています。これは、会社を経営する人や、税理士なら皆知っていることなので、いまさら話題にもなりません。

取引の証憑が書面(紙)である場合は、会社から取引相手に発行した請求書や、取引相手から送られてきて支払いに使った請求書や領収書などは決算処理を行った後、整理して段ボールなどに入れて倉庫保存しておくのが普通です。一旦、倉庫にいれてしまえば、後日、取り出してみることはほとんどありません。何年かに一回、『税務署から調査にいくので用意しておいてください。』といった連絡があると、倉庫から送ってもらい、税務調査に備えるくらいです。

ところが、これらの証憑書類をPDFなどのデジタルデータにしたとたんに、「電子帳簿保存法」という法律の対象となってきます。そのため保存のための要件がいきなり厳しくなってしまうのですね。

電子帳簿保存法は1998年(平成10年)に初めて制定された法律で「電子計算機を使用して作成する国税関係帳簿書類の保存方法等の特例に関する法律」というタイトルが付いています。

電子帳簿保存法では、①始めからコンピュータを使ってデジタルで作成した証憑のデータの保存、②書面(紙)で作成された証憑をスキャナなどでデジタル化したデータを書面に代えてデジタルで保存する、③インターネットなどでデジタルでやり取りした取引データをデジタルで保存するための要件を定めています。

詳しい内容は省きますが、電子帳簿保存法があるために、弊社のような中小企業では書面で作成してやり取りした証憑よりも、デジタルデータとしてやりとりしたデータを(要件を満たすように)保存する方が、保存に手間とコストがかかってしまうことになっています。

これは取引先が多岐にわたるため、書面とデータが混在してしまっていることもかなり大きな原因です。

最近では、電子帳簿保存法を最初に制定するときに、コンピュータを使って作成した国税関係帳簿書類の保存を「特例」として扱ってしまったことが根本的に誤っていたのではないかと考えています。つまり、書面とデジタルデータを、記載された内容が同じであれば同等のものとして扱うとしないで、書面とデジタルという内容を表現する媒体によって保存時の扱いが別になる・区別したということが問題ではないかということです。

振り返ってみると、1998年といえば、コンピュータがビジネスインフラとして欠かせなくなっていて、コンピュータで証憑の為のデータを作成するのが当たり前となり、インターネットもPDFも使われ始めていた時期です。そういう時に、コンピュータのデジタルデータを特例扱いする法律として制定された、というあたり、電子帳簿保存法は、未来が見えていない、どうしようもなく行き詰っているという印象を禁じえません。

次回:電子帳簿保存法・電子取引データ保存で目にあまる迷走を続ける財務省

関連記事




HTML on Word
WebページをWordで作る!


瞬簡PDF 編集 2024
かんたん操作でPDFを自由自在に編集

目次 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ではナビゲーションにはノンブルよりもリンクを使うのは便利である。ノンブルはページ数の増減に弱いが、リンクはページ数の増減があっても問題が生じないという自由さがある。




瞬簡PDF 作成 2024
ドラッグ&ドロップでPDF作成


瞬簡PDF 変換 2024
PDFをOffice文書へ高精度変換

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

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

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

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

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

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

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

2023年2月28日

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



瞬簡PDF 統合版 2024
アンテナハウスPDFソフトの統合製品!


瞬簡PDF 変換 2024
PDFをOffice文書へ高精度変換

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

ピート“マーヴェリック”ミッチェルといえば、トム・クルーズ演じる海軍パイロット。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 書けまっせ 2024
PDFに文字が書ける! 入力欄を自動認識


瞬簡PDF 変換 2024
PDFをOffice文書へ高精度変換

XSL-FO 試行錯誤 カレンダーを自動生成したい(その月のマスの最初の日を取得する)

XSL-FO 試行錯誤 カレンダーを自動生成したい(構想編)の続きとなります。

大抵のカレンダーにおいて、ある月の表における最初の日付は「1日」ではありません。日曜始まりのカレンダーなら、「その月の1日が含まれる週の日曜日の日付」を取得する必要があります。このとき同様に「その月の最終日が含まれる週の土曜日」も考える必要がありますが、今回は割愛します。

XSLT 2.0からは日付関連の関数が使えるので、これを使っていくことにします。

<xsl:transform 
 xmlns:xs="http://www.w3.org/2001/XMLSchema"
 xmlns:fn="http://www.w3.org/2005/xpath-functions"
 xmlns:fo="http://www.w3.org/1999/XSL/Format"
 xmlns:axf="http://www.antennahouse.com/names/XSL/Extensions"
 xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="3.0"
 xmlns:cal="urn:calendar"
 exclude-result-prefixes="xs fn">...</xsl:transform>

ルートはこんな感じです。foやaxfは今回登場しません。XSLT 2.0からは型の時点でエラーを検知したりといったことが可能なので、XMLSchemaの名前空間はかかせません。xpath-functionsの名前空間は宣言しなくとも使えますが、自作関数との区別用に明示しています。独自に実装する名前空間はcalというprefixを付けることにします(functionのnameには名前空間の明示が必要になります)。

 <xsl:function name="cal:getWeekDay" as="xs:integer">
   <xsl:param name="day" as="xs:date"/>
     <xsl:sequence select="$day => fn:format-date('[F]') => cal:weekDayInteger()"/>
 </xsl:function>

 <xsl:function name="cal:weekDayInteger" as="xs:integer">
   <xsl:param name="wd" as="xs:string"/>
   <xsl:choose>
     <xsl:when test="$wd eq 'sunday'">
       <xsl:sequence select="0"/> 
     </xsl:when>
     <xsl:when test="$wd eq 'monday'">
       <xsl:sequence select="1"/> 
     </xsl:when>
     ...
     <xsl:otherwise>     
       <xsl:message terminate="yes" select="'Invalid input'"/>
   </xsl:otherwise> 
 </xsl:choose>
 </xsl:function>

曜日を0-6のxs:integerで取得することにします。日付の曜日自体はfn:format-date(‘[F]’)で取得できますが、これをxs:integerに置き換えます。これは次回以降、moduloを使って日付の表を埋めていくためです。

「=>」はXSLT 3.0から使える記法で、処理の見た目がすっきりします。cal:weekDayIntegerについてはXSLT 3.0的にはmap{‘sunday’:0, …}のように曜日のstringと対応付ける整数をまとめて、それを展開する形がより望ましいかもしれません。2.0でも外部XMLや、xsl:chooseではなくXPathのifなどにまとめると記述量は減ります。xsl:otherwiseではmessage@terminate=”yes”で処理を強制終了していますが、ライブラリなどとして整備するなら分岐処理前にxsl:assertやxsl:tryなどで対応しておきたいところです。

  <xsl:function name="cal:getFirstDayOfTable" as="xs:date">
   <xsl:param name="firstDay" as="xs:date"/>
   <xsl:param name="weekStart" as="xs:integer"/>
     <xsl:variable name="weekDayOfFD" select="cal:getWeekDay($firstDay)"/>
     <xsl:choose>
       <xsl:when test="$weekDayOfFD eq $weekStart">
         <xsl:sequence select="$firstDay"/>
       </xsl:when>
       <xsl:otherwise>
         <xsl:variable name="dur" select="'P' || string(abs($weekDayOfFD - $weekStart)) || 'D'" as="xs:string"/>
         <xsl:sequence
           select="(xs:dateTime($firstDay) - xs:dayTimeDuration($dur)) =>xs:date()"/>
       </xsl:otherwise>
    </xsl:choose>
 </xsl:function>

その月の最初の日(xs:date)と、左端に来る曜日(xs:integer)を引数にして、初週の左端にくる曜日を取得します。

最初の日の曜日をvariableで持つことで、後で使用しやすくしています。この日が始まりの曜日と一緒なら後の計算はいらないので分岐させます。整数同士の比較です。

一緒でない場合、最初の日から曜日のギャップ分遡った日付を取得する必要があります。

最初の日をdateTimeにキャストし、そこにdayTimeDurationでギャップ分の日をマイナスし、それをxs:dateに戻します。

結果を確認してみましょう。2022年1月のカレンダーの表(日曜始まり)ならば、入力「2022-01-01」に対し「2021-12-26」が期待する結果となります。

<xsl:param name="dateArg" as="xs:date" />
 <xsl:template name="xsl:initial-template">
   <xsl:variable name="weekStart" select="0" as="xs:integer"/>
   <xsl:message>
     <xsl:sequence select="xs:date($dateArg) =>
       cal:getFirstDayOfTable($weekStart)"/>
   </xsl:message>
 </xsl:template>

XSLT 3.0では、ダミーのソースXMLファイルを用意しなくとも上のように「xsl:initial-template」という特殊な名前のテンプレートを使うなどして直接XSLTプログラムを走らせられます。グローバルのパラメータdateArgに入力した月始めのxs:dateを処理した結果を表示してくれます。

果たして私の環境では「2021-12-26」が出力されました。

考慮するケースが足りないかもしれません。無保証であることにくれぐれもご留意ください。

他、関数などに落としこめる事項としては年度の切り換えがあります。これは次回取り組みたいと思います。XSL-FOまでいきませんでした……。

関連記事

XSL-FO 試行錯誤 カレンダーを自動生成したい(構想編)

関連資料

XSL Transformations (XSLT) Version 3.0
W3C Recommendation 8 June 2017





瞬簡PDF 変換 2024
PDFをOffice文書へ高精度変換


瞬簡PDF 統合版 2024
アンテナハウスPDFソフトの統合製品!

書籍のHTML版の構造を考える(OOXML入門第2版)

12/07に「『Office Open XML Formats入門 第2版』制作報告」のウェビナーを行いました。ウェビナーで言及したように、『Office Open XML Formats入門 第2版』はHTML版も制作中です。

編集用XMLであるSimpleDoc(の改造版)はほぼHTMLの文法なので基本的にはそのままです。
とはいえ、そのままで出せるかというとそうでもなく、「表示媒体の違い」へ意識を向ける必要があります。本記事ではその辺りについて「こんなことを考えながら作っています」という話です。

形式

まず、HTMLとしてはHTML5、もといLiving Standardに合わせています。他社コンテンツを制作するような場合に比べれば更新の自由が利きますし、セマンティックな語彙が多い方が嬉しいですね。変換自体にはXSLT 3.0を利用しています。

スタイル設定

SCSSで大本を記述した後、CSSに変換したものをlinkの読み込み対象にしています。あるページ特有のスタイルというものは無かったため「_color.scss」「_header.scss」、「_footer.scss」これらを読み込む「common.scss」のようになっています。

ページ分割とナビゲーション

まずページ分割単位の決定。「最終的に1ページのHTMLファイルに収める」というのはそれなりの文量のある書籍では現実的ではありません(動的に内容を取得するのであればそういった方法もあるでしょう)。今回は「章単位でフォルダーを分け、節単位でファイルを分ける」ということにしました。
余談として、DITAではDITA-OT標準のHTML出力を行うとトピックごとにページが分けられます。書籍の形態を重視する場合はこのトピック単位というのは個人的にはやや扱いづらいものであったりします。

ナビゲーションの追加について。特に静的なページとして用意する場合、次の箇所へ遷移する方法の確保は重要です。HTML版用に新たに考えるべき項目としては「常に目次をページ内に配置する」「前後の箇所へのリンクを配置する」「検索用のページを用意する」といったことが挙げられます。

「常に目次をページ内に配置する」については「目次へのリンクを各ページに配置する」で濁してあります。ページごとに記述量が増えて若干デバッグがしづらくなるためです。全ページに目次を配置した場合も、ファイルサイズとしては誤差でしょう。「iframeタグで目次ページを表示させる」ことも可能ですが、今回はリンクを選択しました。

コンテンツの配置レイアウト

body/headerに章題と章トップページ・目次ページ・前後ページへのリンク、body/footerに前後ページへのリンク、body/main内にそのページのコンテンツを配置しました。
書籍と構成は変わるものの「常に(画面上という意味でなく)表示されて欲しい情報」とコンテンツとして欲しい情報といった整理を行うことに変わりはありません。

書籍版と見せ方を変えるもの

Webブラウザーでは紙の本ではできない操作が可能です。今回、次のような変更をしています。

  • コードブロックにoverflow:scrollを設定。
  • h3のsection内容をdetailsタグでアコーディオン表示設定。
  • 画像にwidth:100%を指定。

記事内容の主題といっても良い箇所だと思うんですが、3行で終わってしまいました。

相互参照、リンク

これは「できるならやった方が良い」という話です。HTML版用に新たに用意するにはコストが高く、やるのであればHTML版に関係なく取り組む価値があります。
書籍内の単語や索引、図参照などをハイパーリンクとして設定することについて、元原稿であまり積極的に設定していなかったためにほぼ見送りました。PDF用にリンク用の機構をしっかり準備、活用していれば流用できただけに惜しいです。

メタデータ

「メタデータ、head内をどこまで用意するか」といった話があります。「この場所(弊社Webサイト)にこのコンテンツがあることを知っている」方に対して公開する向きが強いため、ひとまず先送りにできるだろうということがあげられます。
JSON-LDによるメタ情報の追加やサーチエンジン巡回用のRobots.txt、といったものですね。

最低限の項目としてtitle、言語、エンコーディング、viewportの初期値といったものは設定しました。これらは文字化けやモバイル端末での表示性確保として最低限設定すべき箇所でしょう。

OGPについてはある程度用意した方がSNS上でのリンク表示が見栄えするのである程度は確保したいので悩ましいところです。

作業が完了していないこともあり今回はこの辺りで。HTML版(、そして販売準備中のプリントオンデマンド版も)の完成まで少しだけお待ちください。

参考資料




瞬簡PDF 編集 2024
かんたん操作でPDFを自由自在に編集


アウトライナー
PDFを解析して しおり・目次を自動生成
Pages: Prev 1 2 3 4 5 6 7 8 9 10 ... 110 111 112 Next