SS blog

C/C++/javaについての話題

季節に関する暦と感覚のズレはなぜ起こる

毎年1月か2月になると、テレビの天気予報で「暦の上では今日から春です」と報じられます。まだこんなに寒いのに春だというのはおかしいと感じる人も多いでしょう。この暦と感覚とズレはなぜ起こるのでしょうか。

二十四節気

二十四節気は「にじゅうしせっき」と読みますが、大昔からある暦の節目の日で、1年を24分割した日を示しています。
「暦の上では」というのは、この二十四節気が示す季節をのことを言っており、例えば春の始まりを意味する「立春」の日になると、「暦の上では今日から春です」という事になります。二十四節気にはちゃんと「立春」、「立夏」、「立秋」、「立冬」の4つが含まれています。

季節が何故ずれる

暦の季節が感覚とずれる理由について、ネットを検索すると「昔と気象が変わった」とか「二十四節気を考案した中国の気候は日本とずれている」などという、説明が見受けられますが、それはおそらく誤りでしょう。
暦の上の四季はそれぞれ春分夏至秋分夏至を季節の中心と考えて一年を4等分にして決めています。その結果立春立夏立秋立冬も決まります。
春分夏至秋分夏至黄道上の太陽の位置で決まるもので気温は無関係です。
夏至になり太陽が最も高くまで登っても、気温が最も高い日がくるのはそれから2か月ほど後のことで、これは別に日本だけの現象でもないし、現代の異常気象の影響でもない、普通の事です。

この太陽の位置と気温のズレが季節に関する暦と感覚のズレになっているのです。

敢えて今と昔の違いを挙げるとすれば、今は例えば気温が最も低い日を冬の中心とかが得ますが、昔は気温が最も低い日が過ぎれば日々気温が高くなっていくのですから、そこからが春の始まりと考えたのでしょう。だから正月を「新春」と呼ぶのではないでしょうか。日本書紀でも旧暦元日の事を「新春朔」と呼んでいることからもそれがうかがえます。

フォントファミリー、フォントフェイスの違い

フォントファミリー、フォントフェイス

よく似た言葉と言えますが違いを説明します。

Excel等でフォントを使うとき、例えば「MS Pゴシック」と指定したりしますが、この「MS Pゴシック」はフォントファミリーの名前です。

さらにフォントの形状を太字とか斜体を指定したりしますが、これにより選択されるのがフォントフェイスです。

太字とか斜体は元になる標準形のフォントを加工して表示しているわけではなく、それぞれ専用のフォントデータを作ってインストールされています。

フォントファミリーはフォントフェイスをグループ化したものという事になります。通常「太字」と「斜体」の有無を選択できるようにするわけですから、フォントファミリーは4種類のフォントフェイスがあることになります。

例えばフォントファミリー「MS Pゴシック」は以下のフォントフェイスが属します。

  • 「MS Pゴシック」
  • 「MS Pゴシック 太字」
  • 「MS Pゴシック 斜体」
  • 「MS Pゴシック 太字 斜体」

但しフォントファミリーが必ず上記4種類があるわけではありません。2種類だったり、1種類だったりします。逆に8種類も16種類もあるかもしれません。

しかし、Excel等には必ず「太字」ボタンと「斜体」ボタンがあるので4種類なければ誤動作になるのではと思うでしょうか?

そうならないのは、こういったユーザーによるフォント指定によって、システムは「なるべくそれに近いフォント」を選択するだけだからです。「MS Pゴシック」を指定してもMS Pゴシックが使われるとは限りません。インストールされてなければ別のフォントフェースをシステムは選択しますし、表示するのがタイ語の文字だったりするとMS Pゴシックでは描画できないので、システムはタイ語を持っていて、しかも太字、斜体等のユーザー指定になるべく沿ったフォントフェイスを選んでくれます。

 

OpenTypeフォントとOpenType系フォント

OpenTypeフォントについては、XXXXで少し説明しました。
「OpenType系」は正しい言葉か分かりませんが、OpenTypeをベースにしたフォントの形式の事です。
OpenTypeフォントはパッキングとか圧縮については、それ程考慮されていません。実際問題として現在のPCのディスク容量を考えれば、過剰にパッキングや圧縮を追求する必要も無いと言えますが、フォントをネットワークを通して提供するような場合はそうも言ってはいられません。
それで、OpenTypeフォントをさらにパッキングや圧縮した形としたのが、ここでいうOpenType系フォントの事です。「ネットワークフォント」等と呼ばれる事もあります。

  • WOFF
  • WOFF2
  • EOT

サイズが問題なら単にフォントファイルをZIP圧縮すれば済みそうなものですが、何故形式を作る必要があるのでしょう。それはフォントと使われ方の特質上、圧縮ファイルを解凍するまでどういうフォントなのかが分からないという事では困るからです。
日本語文字列を描画しようと、ダウンロード、さらに解凍してフォントの特性を見ると日本語文字は持っていない、では別のフォントを探す、という事を繰り返してロスが大きくなってしまうので。

 

OpenTypeとTrueTypeの違い

Windowsのフォント一覧画面を見るとフォントの種類として「OpenType」、「TrueType」、それと「ラスター」の何れかが表示されます。
「ラスター」とは要するにビットマップのフォントということで分かりますが、「OpenType」、「TrueType」はアウトラインフォントという事になりますが、両者の違いはご存じでしょうか。
フォントを使う側の立場では認識できる違いは無いので、違いを気にする必要は無いでしょう。しかし名前が違う以上、何某かの差異があるわけですので、その差異を知りたい人は先を読み進めてください。

歴史

「歴史」とは題しましたが、ここで言いたいのはTrueTypeが先、OpenTypeはその発展形という事です。

マイクロソフト社がWindows3.1をリリースした時、TrueTypeが実装されました。アウトラインフォントがWindowsで使えるようになったのはこの時からです。
当時はアウトラインフォントの技術としてはAdobe社のPostScriptという仕様で、DTPあるいは印刷用途ではスタンダードな地位にあったと言えるでしょう。

両者を較べると、PostScriptはフォントのデータをギリギリまでパッキングし、また多用・多彩なアウトラインの描画命令を持ち、パッキングと呼べる程の事はしていない、命令はBスプラインのみという、「冗長」とも言えるのがTrueTypeでしたが、逆にこの冗長がTrueTypeの柔軟性・発展性に繋がりっていきます。

TrueTypeは固有のタグ名が付けられた「テーブル」と呼ばれるデータブロックを追加していくだけで仕様を拡張していく事ができるので拡張性が非常に高く、また多用・多彩な描画命令は、フォント製作者にしてみれば面倒くさいものなのでしょう。
少なくてもWindows用のフォントとしてはTrueTypeが標準的となっていきます。

OpenTypeは、TrueTypeがPostScriptを吸収合併したものと言えます。より正確には、PostScriptのアウトラインデータをテーブルとして持つことができるようになり、PostScriptの遺産を取り込むことが容易にできるようになりました。

TrueTypeとOpenType

TrueTypeとOpenType、それぞれが何を指しているのか捉えどころがないのはこのような経緯からです。

Windowsのフォント一覧で「TrueType」、「OpenType」と表示されるのはフォントファイルのヘッダーの先頭にあるシグネチャーの違いに過ぎないと言ってよいでしょう。中身を表しているわけではありません。
TrueTypeフォントは内部のアウトラインを格納したテーブルは必ずTrueType形式のアウトラインとなっていますが、OpenTypeフォントはTrueType形式、またはPostScript形式、あるいはSVG形式の何れかですが、TrueType形式である事が多いので、結局のところTrueTypeはOpenTypeと大体同じと言えてしまいます。
ちなみにアウトラインデータのテーブルのタグ名は、下記の通りです。

  • TrueType形式: glyf
  • PostScript形式: CFF
  • 新PostScript形式: CFF2
  • SVG形式:SVG

新PostScript形式は、PostScript形式のアウトラインデータを可変フォントの拡張を加えたものです。TrueType形式の可変フォントの拡張は別のタグ名のテーブルで拡張しています。それぞれに「らしい」拡張の方法をしています。

さて、気が付いた事と思いますが「TrueType」という言葉はフォントファイルの形式を指している場合と、フォントファイル内のアウトラインデータを指している場合があり、いささか紛らわしいのです。
どちらを指しているのか文脈から判断する事が必要です。

アウトラインデータ TrueType形式とPostScript形式

アウトラインデータ TrueType形式とPostScript形式の違いを説明します。

Generated by MetaSvg (C)Seiichi.S 2024- 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 rmoveto 2 3 4 5 6 hvcurveto rlineto 9 10 vvcurveto 12 13 14 15 16 vhcurveto rlineto 19 20 hhcurveto 22 23 24 25 26 hvcurveto rlineto 29 30 vvcurveto 32 33 34 35 36 vhcurveto rlineto 39 40 hhcurveto PostScript 形式のアウトライン TrueTyoe 形式のアウトライン

上図に示した通り、PostScript形式の方がTrueType形式よりも複雑であることが分か課と思います。TrueType形式は「×」で示した「OFF点」と「□」で示した「ON点」の二種類だけでアウトラインが作られます。「ON」とか「OFF」とかはアウトライン線上にあるか無いかを示しているのですが、OFFの場合はBスプラインの制御点として曲線を作る点を示します。つまりTrueType形式は移動、Bスプライン、直線の3命令だけでアウトラインを作成する仕様となています。

一方、PostScript形式は様々な命令を持っています。

  • 移動
    rmoveto / vmoveto / hmoveto
  • 直線
    rlineto / vlineto / hlineto
  • 直線+曲線
    rcurveline / rlinecurve
  • 曲線
    rrcurveto / vvcurveto / hhcurveto / hvcurveto / vhcurveto / hflex / flex / hflex1 / flex1

これ以外にも算術演算、論理演算、サブルーチン、ヒント命令を持ち、さらにスタックを持ち、逆ハンガリアン記法により、さながら「プログラミング」によりアウトラインを作成します。

CreateFont の引数は何故に沢山?

CreateFont はWindowsアプリケーションのプログラムが文字を描画するためにフォントを選択するときに使用するAPIです。

その引数は下記の通りで、うんざりするほどの数です。

指定したいのはフォント名、太字、斜体、サイズくらいなのになにゆえにこれほど沢山なのでしょう。

この点、よく理解するとフォントの仕組みをよりよく理解できると思うので今回のテーマとします。

HFONT CreateFont(
  [in] int     cHeight,
  [in] int     cWidth,
  [in] int     cEscapement,
  [in] int     cOrientation,
  [in] int     cWeight,
  [in] DWORD   bItalic,
  [in] DWORD   bUnderline,
  [in] DWORD   bStrikeOut,
  [in] DWORD   iCharSet,
  [in] DWORD   iOutPrecision,
  [in] DWORD   iClipPrecision,
  [in] DWORD   iQuality,
  [in] DWORD   iPitchAndFamily,
  [in] LPCWSTR pszFaceName
);

CreateFont はこれら引数で指定したフォントを取得する、と思ってしまうと実際にAPIを使用した時に結果に戸惑ってしまうことがあるでしょう。

より正しい理解は、これら引数はフォントを選ぶ「ヒント」に過ぎないという事です。

Windowsはフォントマッパーという機能を持っており、与えられたヒントに最も適合するフォントを選ぶように善処します。

なのでCreateFont が正常終了したからと言って、指定したフォントが使われているとは限りません。フォントがシステムにインストールされていてもいなくてもCreateFont は正常終了します。

もしインストールされていなければ他の引数で最適な別のフォントを使用します。

またインストールされていても別のフォントを使う事があります。例えば「Times New Roman」はインストールされてはいますが、持っているのは英数字だけですので、日本語の文字列の描画には使えない訳ですから、この場合フォントマッパーが最善のフォントを探し出して使用してくれます。

そういえばCreateFont  APIの解説には「論理フォント」という言葉が使われていました。「Times New Roman」とか「MS Gothic」とかは物理フォントですが、CreateFont が作成する論理フォントは、インストールされた物理フォントの中から最善のものが使われるという点で論理フォントという事です。

フォントの情報

引数はフォント選択のヒントだと書きましたが、例えばFF_SWISSとしてした場合、プロポーショナルフォントでセリフ無しのフォントを求めることになります。

フォントマッパーは個々のフォントにセリフがあるかをどうやって判断しているのでしょうか。言わずもがなフォント自体がそういう属性データを保持しています。

とは言えWidndowsのフォント一覧を見てみると、そういう属性は見当たりません。それはWindowの一覧では表示していないだけです。

Windowsのフォント一覧の表示

専用のビューワーでフォントの名部のデータを照会したのが下記の画像です。

フォントファイル内の「OS/2」というテーブルにそれはあります。

MS Gothic フォントの内部データ

「panose」と「Unicode Range」という名のデータがフォント選択に深くかかわっています。

panoseは10バイトのデータで、各バイトがフォントの特徴を示す10個の情報となっています。セリフの有無などもpanoseを照会すれば直ぐに分かるというわけです。

Unicode Rangeは、フォントファイルに納められた文字の範囲を示しています。文字列を描画するときに、このフォントが使えるのかを直ぐに調べることができます。

それと肝心のフォント名ですが、これは「name」というテーブルに格納されています。

nameテーブル

フォントファミリー名が英語、日本語それぞれの「1」に格納されていますが、Excel等でフォントを選択したときに「MS Gothic」としても「MS ゴシック」としても同じフォントが選択されるのはこれによります。

西暦の「A.D.」は何の略か(ちょっとだけ深く考える)

西暦の「A.D.」は、ラテン語「Anno Domini」の略で「主の年に~」という意味です。

これまあネットを検索すれば普通に見つかる説明だと思いますが、最後の「に~」が付くのが気にならないでしょうか。「に~」無しにすることはできないのか…などと思わないでしょうか。

ここでは、このラテン語「Anno Domini」について説明したいと思います。

「に~」無しにできないか

「に~」無しにできないかと言えば、全く問題なくできます。ラテン語では「Annus Domini」と書けばよいのです。

「A.D.」は「Annus Domini」の略で「主の年」という意味です、と言っても全然間違っていません。

 

では、何故「に~」が付いた方を挙げるのでしょう。

正直分かりません。別に文法的な理由があるわけではなく、時間を表す表現は何故か副詞的な表現を代表させる慣習なのです。

あるいは単にラテン語を知らない人が無思慮にそうすることを広めてしまっただけかもしれません。

ラテン語の「格」

AnnoとAnnusの違いは同じ単語の格の違い、前者は奪格、後者は主格です。

格とはラテン語の単語の語尾変化の一つで、日本語の「てにをは」に相当します。英語では単数・複数で語尾変化しますが、ラテン語ではそれに加えて性と格によっても語尾が変化します。

一つの単語は通常6つの格を持ち一般的には主格を代表させます。例えば「太陽」ラテン語で何と言う?と聞かれれば複数ある格変化形の中から主格を代表として選び、「sol」です、と答えます。敢えて奪格で「sole」です、と答える人はいないでしょう。

ですので、Anno  Dominiで間違っているとは言いませんが、上に述べた理屈は頭の片隅にいれておくと良いでしょう。

書き忘れていましたが、Dominiの方は、「主 Dominusの属格」の変化形です。

余談ですが、小文字でa.d.と書いた場合はAnno Dominiではなく、日付の表現で使う「ante diem」の略と解されます。

したがって「西暦」の方は大文字で「A.D.」と書くことに気を付けた方が用でしょう。

 

グレゴリウス暦制定物語


グレゴリウス暦は「グレゴリオ暦」とも呼ばれますが、グレゴリウスはラテン語名ですので同じものと思ってください。

日本でグレゴリウス暦と言えば、

  • 西暦年が4の倍数なら閏年
  • ただし西暦年が100の倍数なら閏年としない
  • ただし西暦年が400の倍数なら閏年とする

という置閏法で知られているかと思います。学校ではそのように教えています。

グレゴリウス暦以前の暦は古代ローマユリウス・カエサルが定めた「ユリウス暦」で、閏年は4年に一回ですから、グレゴリウス暦は他2項を追加した分だけ精度が上がっているという事。

日本でのこの置閏法の説明は、グレゴリウス暦の内容というより、明治に公布された太陽暦導入に関する太政官布告と勅令の内容を説明しているもので、グレゴリウス13世の改暦の布告の説明とは言い難いでしょう。

今回はこのグレゴリウス13世の改暦の布告にどのようなことが書かれているか抜粋しながら説明したいと思います。原文はラテン語です。

布告は1582年2月24日に聖ローマ教会(S.R.E.=Sacra Romana Ecclesia)の名で発布されました。ちなみにこの日付はユリウス暦です。

改暦の趣旨

布告冒頭で改暦の趣旨が説明されています。

それは、1545年に開催されたトレント公会議ローマ教皇に裁定を一任された問題があるというのです。それが当時の暦、すなわちユリウス暦の日付が、観測される太陽や月の位置とずれているという問題です。

それで困ってしまうのはキリスト教最大の祝いの日である復活祭の開催日です。

復活祭はイエスの復活を祝う日で、聖書は、イエスが処刑されされたのはユダヤ教の祝日である過越祭の前日で、処刑の日から3日目の日曜日に復活したと伝えています。

過越祭はユダヤの教義にのっとって春分の後の満月の日に行うのですが、春分は天体観測を行う事で知り得る日ですが、ユダヤの暦は太陽太陰暦ですのでそれはさしたる問題ではありませんでした。

しかし太陽暦であるユリウス暦を使用するキリスト教世界ではどうにも使い勝手が悪いのです。それで4世紀のニカイアの公会議では春分の日ユリウス暦の日付で3月21日とすることに決めてしまいましたが、それはいささか配慮不足でした。

数年数十年のスパンではそれで大きな問題はならないのですが、数百年も経てばユリウス暦の精度不足の問題が表面化するようになります。3月21日が天体観測上の春分と数日単位のズレが生じ始めるのです。

上に書いた復活祭の日を決めるルールを読み返していただきたいのですが、春分が数日ずれると次の満月の日の選定が1か月ズレる可能性があるのです。そうなると何が起こるでしょう。

ユダヤ教徒が過越祭を行って、その1か月も後にキリスト教徒が復活祭をやるなんてことになってしまいます。聖書には過越祭の数日後にイエスが復活すると書いてあるではないですか。それを指摘されても間違っているのはキリスト教の方なのですから教会のメンツは丸つぶれです。

それを何とかせよ、というのが「トレント公会議ローマ教皇に裁定を一任された問題」です。

問題整理

一見、原因も解決も至極単純に思えます。問題整理もなにも、もはや3月21日が春分の日でないのが原因の全てなのだから、ちゃんと天体観測して日にちを改めればそれで済むはずではないか、そう思ったでしょう。しかし問題はもう少し複雑です。

キリスト教には聖人歴がありはそれこそ年がら年中何某かの祝祭をやっているのです。復活祭の日程を変えると、前後関係がある他の祝祭も一緒に動かさなければならなくなり、例えば9月1日が誕生日の人の祝いを来年から8月25日に行いますと言われても簡単に「相分かった」というわけには行けません。そういった事情で問題を認識しながらこの時まで解決ができずにいたのです。

もう一つの案が3月21日が春分の日になるように暦そのものをスライドする案です。この場合、日にちを後送りにスライドできるなら良いのですが、この時生じているズレは10日分、日にちを1前送りにスライドして補正すべきものですので、その10日が暦から消え、その中で行うはずの祝いが行き場をなくしかねない事になります。

いずれにしても何かを捨てなければ解決ができないのです。

教皇の選択

さて教皇グレゴリウス13世の選択はどうだったでしょう。

選択は上記案のうち後者でした。すなわち暦を10日分前倒しにスライドさせることにしました。

そのため1582年10月の暦はかなり変わったものになりました。

1582年10月の暦

布告

折角ですの布告の内容も見てみましょう。原文はラテン語ですが

Considerantes igitur nos, ad rectam paschalis festi celebrationem  〜 tria necessaria coniungenda et statuenda esse;

 したがって、(中略)復活祭を正しく祝うためには、以下の3つが要件を組み合わせ確立しなければなりません。

  • primum, certam verni aequinoctii sedem;
    ます、真春分の位置
  • deinde rectam positionem XIV lunae primi mensis, quae vel in ipsum aequinoctii diem incidit, vel ei proxime succedit;
    次に、真春分の当日または直後の月齢第14日
  • postremo primum quemque diem dominicum, qui eamdem XIV lunam sequitur;
    最後に、その第14日の後の最初の日曜日

既に説明した事ですが、復活祭を行うべき日の確認しようとしています。

Quo igitur vernum aequinoctium, quod a patribus concilii Nicaeni ad XII kalendas aprilis fuit constitutum, ad eamdem sedem restituatur, praecipimus
その上でニカイア公会議の教父たちによって4月カレンダエ12日前(3月21日)と定められた春分を、本来の位置に戻るよう定め、
et mandamus ut de mense octobris anni MDLXXXII decem dies inclusive a tertia nonarum usque ad pridie idus eximantur, 
1582年10月のノーナエ3日前(=5日)からイードゥス前日(=14日)までの 10日間を除外するよう定めます。

春分を決まった日にちではなく天体観測による真春分を採用することと、1582年10月の暦から5日〜14日を除外する、つまり10月4日の翌日が10月15日ことを定めています。

et dies, qui festum S.Francisci IV nonas celebrari solitum sequitur, dicatur idus octobris,
そして、ノーナエ4日前(=4日)の恒例聖フランシスコ祭は 10月イードゥス(=15日)に当て、
atque in eo celebretur festum Ss.Dionysii, Rustici et Eleutherii martyrum, cum commemoratione S. Marci Papae et confessoris, et Ss. Sergii, Bacchi, Marcelli et Apulei martyrum;
さらのその日に、殉教者大聖ディオニシウス、ルスティクス、エレウテリウスの祝祭が、聖マルクス教皇と告白者の祝祭、大聖セルギウス、バッカス、マルセルス、アプレイウスの殉教とともに行われる。
septimodecimo vero kalendas novembris, qui dies proxime sequitur, celebretur festum S. Callisti Papae et martyris;
しかし、その直後に続く11月カレンダエ17日前(=10月16日)には、聖カリストゥス教皇と殉教者の祝祭(10/14)が行われる。
deinde XVI kalendas novembris fiat officium et missa de dominica XVIII post Pentecostem, mutata littera dominicali G in C;
その後、11月カレンダエ16日前(=10月17日)に礼拝とペンテコステ(聖霊降臨日)後、主日文字G(水曜日)をC(日曜日)に変更して第18回日曜ミサを行います、
quintodecimo denique kalendas novembris dies festus agatur S. Lucae evangelistae, a quo reliqui deinceps agantur festi dies, prout sunt in kalendario descripti.
最後に、11月カレンダエ15日前(=10月18日)に聖ルカ伝道者の祝祭がおこわれ、以降は暦に記載された通りに残りの祝日が祝祭されます。

日付で出てくる「イードゥス」とか「カレンダエ」の意味は、以下の記事の解説を見てください。

seiichis.hatenablog.com暦から消えた10月5日〜10月14日に行うはずだった祝祭のやりくりを定めています。個別の説明は省きますが、復活祭の日付を10日動かそうとすると、これだけのインパクトがあったという事です。

さらにこんなことも書かれています。

Ne vero ex hac nostra decem dierum subtractione, alicui, quod ad annuas vel menstruas praestationes pertinet, praeiudicium fiat, partes iudicum erunt in controversis, quae super hoc exortae fuerint, dictae subtractionis rationem habere, addendo alios X dies in fine cuiuslibet praestationis.
この10日間の削除が、人々の年次・月次の支払いに不利益害を及ぼさないようにするために、担当判事は、これに関して生じた訴訟において上記削除に配慮し、各支払いを10日間延期するものとします。

まあそれはそうだという気はします。

それとこんなことになったそもそもの原因、ユリウス暦の改定をしなければなりません。布告は下記の通りです。

Deinde, ne in posterum a XII kalendas aprilis aequinoctium recedat,
 次に、将来春分の日が 4月カレンダエ12日前(3月21日)から後退しないように、
statuimus bissextum quarto quoque anno (uti mos est) continuari debere,praeterquam in centesimis annis;
100年ごとを除いて、4年ごとに (これまで通りに)閏年を継続することを定めます。
qui, quamvis bissextiles antea semper fuerint, qualem etiam esse volumus annum MDC,
これは以前は常にうるう年でしたが1600年もそのようにしたいと考えていますが、
post eum tamen qui deinceps consequentur centesimi non omnes bissextiles sint,
その後に続く100年毎はすべて閏年とせず、
sed in quadringentis quibusque annis primi quique tres centesimi sine bissexto transigantur,
ただし、400年内の100年毎の最初の3回は閏年とせず、
quartus vero quisque centesimus bissextilis sit, ita ut annus MDCC, MDCCC, MDCCCC bissextiles non sint.
400年目は閏年とし、1700年、1800年、1900年は閏年ではないようにします。
Anno vero MM, more consueto dies bissextus intercaletur, februario dies XXIX continente,
しかし、2000年は通常の方法で閏日が挿入され、2月に29日を挿入し、
idemque ordo intermittendi intercalandique bissextum diem in quadringentis quibusque annis perpetuo conservetur.
そして、同様の閏日の挿入の順序が、400年ごとに永久に継続されるものとします。

要するに本記事冒頭に書いた置閏法のルールはこういう表現で定められています。