Markdown でビジネス文書を作成する

まとめ

  • Pandoc’s Markdown という一方言には::: という汎用Divに対応する記法がある。
  • {markdown, latex} → html は pandoc のみでできる。別途 css を用意するといい。
  • {html, latex} → markdown は pandoc のみでできる。
  • {html, markdown} → latex はフィルタが必要。別途 sty を用意するといい。

ビジネス文書

しばらく前に「公文書を Markdown で」という話題があった。図入りの面倒くさいものや白書のような普通の書籍ほどの長大なものや法律の条文のような特殊なものは別として、圧倒的に多いであろう1枚ペラ程度の通達の類の文書には、 Markdown はとても向いていると思う。簡単なものほど Word のような高機能文書作成ソフトを使わずに Markdown で済ませたい。

この様式[1]は、役所が作成する公文書[2]から会社、さらには小学校や PTA、町内会までよく浸透している。

しかし Markdown では、この類の文書の様式に欠かせない右寄せ(右揃え)ができないのが最大のネックだ。意味見た目の分離という観点から言えば右寄せ(右揃え)は見た目なのだが、ここではもうそう呼ぶ ことにする。

Markdown

機能を絞り込んで簡潔であることが Markdown の特長なのだから、あれもこれも盛り込んでいけば最初から HTML を使えばいいとなって元も子もない。とは言え不満はなんとかしたい。Markdown で書きながらも最終的には HTML にすることを想定して直接 HTMLタグ (<div style="text-align:right">)を書いてしまうという手段もあるのだが、せっかくの Markdown なのだし他の形式への変換も考えるとなるべくそういうことはやりたくない。

ここは Markdown 記法に HTML の汎用タグ <div><span> を表せるものがあれば万能なのになあ……と思っていたら、Pandoc’s Markdown という一方言にはこれが存在していることに今さらながら気がついた。

Pandoc の Markdown 拡張

Pandoc’s Markdown という一方言には::: という汎用の Div に対応する記法がある。ここでは触れないが、汎用の Span に対応する []{} 記法もある。

この記法は Pandoc で考案されたようだ[3]。他の方言ではあまりサポートされていないようだ。HackMD (CodiMD, HedgeDoc) では ::: はやや違った意味にされ、記法も違い限定された語だけしか使えないようだ。

汎用タグを使いすぎれば意味見た目の分離が台なしになることは解っているのだが、最終手段として便利であることは間違いない。

たとえばファイル名 input.md に、Pandoc’s Markdown で書く。

::: {.myaddress}
○△□町会\
会長 ▼▲ ■◆
:::

Markdown から HTML へ

pandoc の標準機能で、特に何もしなくてもいい。コマンドラインで

pandoc --from markdown input.md -to html -o output.html

これにより作成される output.html は次のようになる。

<div class="myaddress">
<p>○△□町会<br />
会長 ▼▲ ■◆</p>
</div>

つまり、Markdown で書いた {.myaddress} がクラス名になる。このクラス名に対応する CSS は別途用意しておく。たとえばファイル名 myaddress.css に

.myaddress {
        text-align: right;
        text-indent: 0pt;
}

と書いておき、コマンドラインで

pandoc --from markdown input.md --to html --output output.html --css myaddress.css --standalone

として利用する。スタイルシートへのリンクがドキュメントヘッダに含まれるため、–standalone オプションも同時に付ける必要がある。

Markdown から LaTeX へ

出力形式を LaTeX とすると、::: は除去されてしまう。つまりコマンドラインで

pandoc --from markdown input.md --to latex --output output.tex

とすると、作成されるファイル output.tex は次のようになる。

○△□町会\\
会長 ▼▲ ■◆

pandoc の作者によるフィルタの例 latexdivs.py を使う[4]と、出力を

\begin{myaddress}

○△□町会\\
会長 ▼▲ ■◆

\end{myaddress}

のようにできる。これを実際に LaTeX で処理するには、 myaddress 環境を別途定義しておく必要がある。たとえば myaddress.sty に

% myaddress
\newenvironment{myaddress}
{\begin{flushright}}
  {\end{flushright}}

と書いておき、コマンドラインで --include-in-header で読み込ませる。

pandoc --from markdown input.md --to latex --output output.tex --include-in-header myaddress.sty --standalone

これにより作成される出力ファイルの内容は

\documentclass (略)
  (略)
% myaddress
\newenvironment{myaddress}
{\begin{flushright}}
  {\end{flushright}}
  (略)
\begin{document}

\begin{myaddress}

○△□町会\\
会長 ▼▲ ■◆

\end{myaddress}

\end{document}

のようになる。

形式の相互変換

以上、markdown → {html, latex} の例を示した。

自分のよく使う markdown, html, latex の相互変換についてまとめると、

  • {markdown, latex} → html は pandoc のみでできる。別途 css を用意するといい。
  • {html, latex} → markdown は pandoc のみでできる。
  • {html, markdown} → latex はフィルタが必要。別途 sty を用意するといい。

となる。

具体的な例

変換された html で利用する CSS ファイル
business.css
latex 出力のための pandoc フィルタ
business_md.py
latex 出力が利用する sty ファイル
business.sty
入力ファイル (markdown)
business-sample.md
pandoc --from markdown --to html --css business.css --standalone --output business-sample.html business-sample.md での出力ファイル (html)
business-sample.html
pandoc --from markdown --to latex --filter=./business_md.py --include-in-header business.sty --standalone --output business-sample.tex business-sample.md[5]での出力ファイル (latex)
business-sample.tex
pandoc --from markdown --to pdf --filter=./business_md.py --include-in-header=./business.sty --output business-sample.pdf business-sample.md[6]での出力ファイル (pdf)
business-sample.pdf
  1. 英文レターの形式を調べると、アメリカ式「フル・ブロック・スタイル」とイギリス式「フル・インデント・スタイル」が見つかる。日本のいわゆるビジネス文書はこのイギリス式「フル・インデント・ス タイル」にとてもよく似ている。特に電磁的文書ならアメリカ式がとても楽だし合理的だと思うのだが、なんと言っても理屈ではない習慣だからそう簡単に廃れることはないだろう。
  2. 検索すると多くの自治体の規程が見つかる。たとえば墨田区佐伯市など。
  3. Syntax for divs
  4. サンプルのフィルタ latexdivs.py をそのまま使うには、入力ファイルのクラス名を書くところに .latex を加えておく必要がある。つまり input.md は ::: {.latex .myaddress} のように書く。
  5. PDF に変換させるには、オプションはこれだけでは実は足りず、ここの例では --pdf-engine=lualatex -V documentclass=bxjsarticle -V classoption=pandoc -V classoption=jafont=auto -V indent=1zw -V pagestyle=empty を加えている。
  6. 前註に同じ。

CSS で見出し(h1, h2, …)に連番を付ける

検索すると似たようなタイトルでたくさんの記事が見つかります。今さら……な話題ですが、それらを参考に試行錯誤して、次のような CSS になりました。

よく見かける例だと、それぞれの見出しでひとつ下の階層のカウンターだけをリセットしているのが多いのですが、それだと h2 の次に(h3 がなくて) h4 が来るような場合にうまくいきません。そういう文書が悪いとも言えますが。

Chrome と Firefox で異なる結果になったりして、結局こうなりました。counter-set を紹介している記事はほとんど見かけません。見つけたのはこの質問と回答くらいで、回答者が仕様を説明してくれているのはとても参考になりました。仕様の EXAMPLE 22 は Firefox では正しく再現されません。

【2022年4月18日追記】現時点での Safari や iOS 上のブラウザー(Webkit)では counter-set が実装されていないため、下記ではうまくいかないようです。【追記終わり】

padding で字下げをしています。番号の書式は「公用文作成の考え方」を参考にしました。\a0 (non-breaking space)をいくつか入れているのは、連番をカタカナとしたので、見出しそのものの内容がカタカナで始まっている場合にある程度あいだが開いていないと混乱するからです。

body {
    counter-reset: chapter section subsection subsubsection paragraph subparagraph;
}

h1 {
    counter-set: section subsection subsubsection paragraph subparagraph;
}
h2 {
    counter-set: subsection subsubsection paragraph subparagraph;
    padding-left:1em;
}
h3 {
    counter-set: subsubsection paragraph subparagraph;
    padding-left:2em;
}
h4 {
    counter-set: paragraph subparagraph;
    padding-left:4em;
}
h5 {
    counter-set: subparagraph;
}

h1::before {
    counter-increment: chapter;
    content: counter(chapter, upper-roman) "\a0\a0\a0\a0";
}
h2::before {
    counter-increment: section;
    content: counter(section, decimal) "\a0\a0\a0\a0";
}
h3::before {
    counter-increment: subsection;
    content: "(" counter(subsection, decimal) ")\a0\a0\a0";
}
h4::before {
    counter-increment: subsubsection;
    content: counter(subsubsection, katakana) "\a0\a0\a0\a0";
}
h5::before {
    counter-increment: paragraph;
    content: "(" counter(paragraph, katakana) ")\a0\a0\a0";
}
h6::before {
    counter-increment: subparagraph;
    content: counter(subparagraph, upper-alpha) "\a0\a0\a0\a0";
}

きっかけは Markdown でした。最近、Firefox なら拡張機能 Markdown Viewer Webext 、Chrome なら拡張機能 Markdown Preview Plus などを使って、手元で Markdown で書いたものをブラウザーで眺めることがしばしばあります。その際に、この文書は見出しに連番がほしいよなあなどと思ったのです。

ここに挙げた2つの拡張機能は CSS を追加できるので、そこにこれを書いてもいいですが、そうすると Markdown なら全て連番付き見出しになってしまいます。拡張機能 Stylus で、好きなときに入れたり切ったりすることにしました。もちろん Markdown のプレビューだけではなく、あらゆるサイトを見る際に適用できます。

Expert Mouse を買った(14年ぶり2回め)

この前の記事「HHKBを買った」から9か月も何も書いていなかったのか。しかもその時とほとんど同じような内容とは……。

Expert Mouse トラックボール(EM7) を長いこと使っています。正確に記録を残していませんでしたが、今では高校生になっている、友人の子がその当時はよちよち歩きで、膝に乗せてこのボールを触らせてあやしたことを覚えているので、購入したのは14,5年前のことです。

今でも問題なく使えているのですが、この前の HHKB と同じく、ふと壊れる前に新しくしてみようという気になりました。これまた HHKB と同じく、すっかり体に馴染んでいるので別のものに変えようという気にはなりません。現在もデザインもまったく変更なく同じものが販売されています。ありがたいことです。

新品と比べてみてみれば、古いものは何らか劣化していることに気づくかなと思ったのですが、案外そのままでした。スイッチの感触もほとんど変わりありません。見た目は確かに指の触れるところの塗装が剥げているのと、スクロールリングのギザギザがすっかり摩耗してツルツルになっているくらいでした。

ときどき掃除してきれいに使っているつもりでしたが、支持球が汚れているのか操作球が摩耗しているのか、新品のほうがはるかに滑らかにボールが動きます。この製品のスクロールリングの出来はあまり評判がよくなくて、前のは一度分解してどこか磨いたりしたような記憶がありますが、今回の新品は最初からスムーズで心地よく回ります。

自分の使い方では、本体は20年はもちそうです。HHKB 同様、この先これを買い換えることはもうないかもしれません。

EM7 とペットボトルカバーによるパーム(リスト)レスト
付属のパームレストはとうの昔にひび割れてだめになったので、試行錯誤の末、今は100円ショップで買ってきたペットボトルカバー350mL用にタオルを詰め込んで使っています。詰物をおはじきか何かと工夫しようと考えていますがまだ実現できていません。かなり高めにして、パームと言うよりは手首の上のほうを置いています。

ボタン割り当て

EM7 と右手ボタンの割り当ては自由に設定できるため、各自が自分の好みにすればいいのですが、参考までに私の例を晒しておきます。

右利きで、キーボードの右側に置いて右手で使用しています。

  • 左下ボタンを左クリック相当(親指)
  • 右下ボタンを右クリック相当(小指)
  • 右上ボタンを中クリック相当(薬指)
  • スクロールリングは時計で言うと3時の位置を薬指で、時計回りで下スクロール、半時計回りで上スクロール

ボールはだいたい人差し指と中指の2本の指先で操作しています。

HHKBを買った (22年ぶり2回め)

初代 HHKB の裏面ラベル

一つ前の型 HHKB Professional2 Type-S (PD-KB400WS) が Amazon のタイムセールで 20% OFF になっていたので、思わず購入してしまいました。現時点の最新型 Hybrid ではなく、USB 有線のみのものです。

これまで使っていたのは初代の Happy Hacking Keyboard (PD-KB01) で、裏を見ると1997年7月のものでした。

アメリカ西部のカウボーイたちは、馬が死ぬと馬はそこに残していくが、どんなに砂漠を歩こうとも、鞍は自分で担いで往く。馬は消耗品であり、鞍は自分の体に馴染んだインタフェースだからだ。

いまやパソコンは消耗品であり、キーボードは大切な、生涯使えるインタフェースであることを忘れてはいけない。

の言葉のごとく、本体は何度も替わりましたがこのキーボードを22年も使い続けてきました。

まだ壊れてしまった訳ではありません。左シフトの反応が少しおかしい (キーをいったん外して紙片を入れて押し込みの深さを調整すれば大丈夫) のと、数年前に掃除した際にスペースバーの裏のバネを1本紛失してしまったのが不都合と言えるくらいです。

1990年代、私は Sun のワークステーション (SPARCclassic) を独占してデスクトップで使えるという環境にあったのですが、純正のキーボードは確か Type5 で、かなり大きくて邪魔なものでした。「CTC 省スペースキーボード」を入手して使ってみたのですが、これはノート PC のキーボードを持ってきたようなもので、キーストロークが非常に浅く、打鍵感がどうにも不快でしかたありませんでした。

そこに Happy Hacking Keyboard が登場してきたので購入したのです。ケーブルは Sun 用と PS/2 用 があって、はじめはもちろん Sun SPARCclassic で使っていたのですが、そのうち PC がどんどん高性能・低価格になり、Debian をインストールした PC がメインになり、PS/2 で接続して使うようになっていきました (SPARCclassic は画面なしキーボードなしで、リモートログインして使うサーバーとしてしばらく存在していましたが、6,7 年で退役しました)。

新旧 HHKB

それから本当に何台も本体は入れ替わっても、キーボードはずっと生き残り続けました。しかし接続口が Sun または PS/2 では、そろそろ「馬」に合わなくなってきたようです。

新旧の二つを並べてみると、この色の違い! 新品どうしならおそらくほぼ同じ色のはずです。煙草は吸わないのですがここまで黄ばんでいたとは。毎日目にしていると案外気がつかないまま、ここまで変色していました。

新旧 HHKB を横から見る

さっそく新しいのを使ってみていますが、やはりちょっと違和感があります。写真にうまく撮れませんでしたが、本体の厚さ(高さ)がほんの数 mm ですが高くなり、それに本体断面のカーブがゆるくなっています。それから、各キーの縁が微妙に指に痛い。前のは使い込みすぎて縁が丸くなっていたのでしょうか。もちろんこれらは慣れの問題で、すぐに気にならなくなるでしょう。

今回購入したものがこの後また20年ほどもつとしたら、次のキーボードを買うことはもうないかもしれません。

「6÷2(1+2)」問題は100年前にも議論されていた

明示されない乗算と除算記号の演算順序について、記事『「6÷2(1+2)」問題について教育委員会に問い合わせてみた』『6÷2(1+2)問題あらため2a÷2a=1問題 — はてなブックマークのコメントに反応してみる』を書いたのは2015年3月でした。そのときですら既に周回遅れで、検索してみるとその2,3年前にも話題になっていたようです。そして年に数回ほど、突然ばっとこの記事へのアクセスが増えることがあります。どこかで話題になり、検索してたどり着くのでしょう。

私はこの問題に特に興味を持っているわけでもなく、その後を追っているわけでもないのですが、今年(2019年)に入ってまた急にアクセスが上昇したので、思い出したように自分でも検索してみたところ、興味深い例を見つけました。

Lennes, N. J. “Discussions: Relating to the Order of Operations in Algebra.” The American Mathematical Monthly 24.2 (1917): 93-95. Web. https://www.jstor.org/stable/2972726

です。内容をかいつまんでみると、

  • 理論的には、演算順序は左から右なので、9a2÷3a = 3a3 であって 3a ではない。
  • しかし実際には、9a2÷3a = 3a のような例ばかりが見られる。
  • 当時の Chrystal の代数の教科書では、これを避けるため、乗算記号のない積を除算記号の直後に置かないよう注意深く書かれていた。
  • それに続くいろいろな人による教科書ではその注意が足りず、10bc\div 12a = \frac{(10bc)}{(12a)} などと書かれた。
  • 9a2÷3a は 3a を意味して 3a3 ではない、というのは「数学の慣用表現」である(英単語 drink の過去形が drank であって drinked でないように)。
  • これは論理的ではなく、歴史的な事柄である。

というものです。

以前の私の記事には、なんとか 9a2÷3a が 3a であることの理論的(?)根拠を示そうと、多くのコメントが付きました。私にはさっぱり響きませんでしたが。それが100年も前に「理論ではない、“慣用表現”だ」と喝破されていたのでした。古い文献に 9a2÷3a が 3a のような例があることをもって、それみろと言わんばかりにこれを主張する人がありましたが、むしろ逆で、古い文献にあるからこそ「歴史的遺物」とも言えるわけです。

以前の記事へのコメントに答えて私も「Smith の第33条で、(a÷b÷cは)「a÷bcと書くこともあるよ」と、ほんのおまけのように付け加えていることは、ただこの慣習に触れているにすぎないのではなかろうか、と思わされました。」(2015年3月18日のコメント)と書いています。今あらたにその思いを強くしています。

繰り返しますが、私はこの問題に特段の興味があるわけでもなく緻密に議論を追っているわけでもありません。その私は今、

  • ずっと昔は、乗算と除算の優先順位が同等でない考え方もあった。“If an arithmetical or algebraical term contains ÷ and ×, there is at present no agreement as to which sign shall be used first.” (Cajori ”A History of Mathematical Notations” 1928–29)
  • 「慣習的に」9a2÷3a が 3a であるような表記もしばしば行われた。
  • 既に100年前に、それは慣習的・歴史的なものであり、理論的ではないと指摘されていた。
  • 理論的でない表記は廃れるかと思われたが、いつしか「慣習的」であることが抜け落ちた。
  • 今日でも中学生にはこれが「慣習的・歴史的」とは告げずに教えられている。

のような流れではなかろうかと推測しています。

この Lennes (1917) の存在を教えてくれたのは、今回検索していて見つけた動画でした。

私の記事よりは後の2016年に公開され、現在(2019年)までに1千万回以上も視聴され、7万件以上のコメントが付いています。もちろんすべてのコメントを見ることはできていませんが、ざっとみたところ「1派」も「9派」もたくさんいます。このことからはっきりわかるのは、この問題は「あいまい」であるということです。

以前の記事へのコメントでも書きましたが、この問題についての私の考えは次のとおりです。それは上述の100年前の指摘を知った今も変わりません。

ab÷ab を ab÷(ab) と書きさえすれば誰もあいまいだとは思いません。中学校でもこの表記で教えて何か困ることがあるでしょうか。括弧を付けても単項式の除算の意味を教えるのに何の不都合もありません。現状のあえて括弧を付けない ab÷ab でしか表せない何かがありますか。ab÷ab と書かなければならない必然性がどこにもありません。(2016年3月7日のコメント)
「すべき」ことは、むしろ括弧を使うことです。別の解釈をさせたければ ab÷(ab) と、括弧をつかう「べき」です。単項式わる単項式の理解度を計測するのに、括弧を使っても何の不都合もありません。(2018年9月4日のコメント)

【この記事にコメントする際の注意】

この話題に関する以前の記事『「6÷2(1+2)」問題について教育委員会に問い合わせてみた』『6÷2(1+2)問題あらため2a÷2a=1問題 — はてなブックマークのコメントに反応してみる』には非常に多くのコメントが付けられ、後から読む人が苦労するほどになってしまいました。そのため、それらの記事へのコメントの受付を停止します。

この記事へのコメントは、それらの記事に既に付けられているコメントと同内容と私が判断するものは、原則として不掲載とし、削除することをあらかじめ宣言しておきます。自由に意見を述べることを封殺する意図はありません。後にここを目にする人たちに対しての配慮です。ご理解ください。

WordPress の新テーマ Twenty Nineteen での日本語フォント

2018年12月に WordPress 5.0 がリリースされ、それに含まれるデフォルトテーマは Twenty Nineteen という新しいものになりました。

WordPress 5.0 のリリース告知 に、Twenty Nineteen の特長として次の点が挙げられています[1]

Simple, type-driven layout

Featuring ample whitespace, and modern sans-serif headlines paired with classic serif body text, Twenty Nineteen is built to be beautiful on the go. It uses system fonts to increase loading speed. No more long waits on slow networks!

WordPress 5.0 “Bebo”

この部分が日本語では

シンプルなタイポグラフィ主導のレイアウト

たっぷりとった余白と、モダンなゴシック体の見出し、クラシックな明朝の本文テキストの組み合わせが特色の Twenty Nineteen は、出先でも美しくあるために造られました。システムフォントを使用して、読み込みスピードを向上させました。もう、遅いネットワークで長時間待つ必要はありません !

WordPress 5.0 “ベボ”

と、「ゴシック体」「明朝」と訳されています。

バージョン 1.0 での日本語への対応

確かに、元々の Twenty Nineteen では sans-serif と serif を使い分けるようにスタイルシートで設定されています。しかし WordPress 5.0 の最初のリリース時点 (Twenty Nineteen バージョン 1.0) では、日本語 (など非ラテン文字言語) の場合の議論が十分に間に合わず、非常に乱暴な対処がなされました。スタイルシート style.css を見ると、

/* Japanese */
html[lang="ja"] .site * {
  font-family: -apple-system, BlinkMacSystemFont, "Hiragino Sans", Meiryo, "Helvetica Neue", sans-serif !important;
}

と、すべてのタグに同一の sans-serif 系の font-family が指定されています (しかも !important 付きで)。これはもう本文テキストと見出しが同じどころか、<pre><code> も monospace ですらなく何もかもが一緒くたという指定です。はっきり言って「看板に偽りあり」です。

バージョン 1.3 での改善点

さすがに全称セレクターと !important だと思わぬところにも影響が及ぶということもあり、最初のリリースには間に合いませんでしたが、WordPress 5.1 とともに配布される Twenty Nineteen (バージョンはおそらく 1.3) では、根本的な対応がなされることになりました。

Twenty Nineteen のスタイルシートは Sass で開発されています。@each@mixin を使うことで既存部分の変更は最小限で書き足す部分もほんのわずかで済み、さらに @extend (と placeholder) を使って、生成される style.css のサイズ増加をできるだけ抑えるという変更案が出されました。

これにより Twenty Nineteen バージョン 1.3 では、元々あった font-family の一つ一つに対して、非ラテン文字言語ごとのバリエーションが設定されました。1.0 とは対極の、実に丁寧な対処です。

改善されなかった点

スタイルシート内にたくさんある font-family に埋め込む値は、sass/variables-site/_fonts.scss に記述されているのですが、元々、ラテン文字言語に対して

$font__body: "NonBreakingSpaceOverride", "Hoefler Text", "Baskerville Old Face", Garamond, "Times New Roman", serif;
$font__heading: -apple-system, BlinkMacSystemFont, "Segoe UI", "Roboto", "Oxygen", "Ubuntu", "Cantarell", "Fira Sans", "Droid Sans"
$font__code: Menlo, monaco, Consolas, Lucida Console, monospace;
$font__pre: "Courier 10 Pitch", Courier, monospace;

のように、4つに分けて設定されています。非ラテン文字言語に対しては、下2つ ($font__code, $font__pre) のそれぞれは手を付けずそのままとなったのはいいとして、上2つ ($font__body, $font__heading) は区別せずに合わせて同じフォントとされてしまいました。

私は、本文用と見出し用のそれぞれ別のフォントが設定できてしかるべきと考えています (各言語ごとに合意を形成する段階で、本文用と見出し用のフォントを同一にするという結果に達すればそれはそれでいいことです)。しかしこの時点では、既にリリースしたものからの大幅な変更は避けたい、非ラテン文字言語での serif 系と sans-serif 系の使い分けの合意はない、まとめられるものはまとめようということで、別々の実装は退けられました。

もうひとつの問題は、style.css のサイズがかなり大きくなってしまうことです。ラテン文字言語しか使わない人たちにとっては無用の記述が大量に追加されたことになります。今回の追加部分は別ファイルにして、不要な人たちは読み込まずにすむようにできればよりいいでしょう。

WordPress のデフォルトテーマは、そのまま使われるだけでなく、「標準」としてしばしば参照されます。非ラテン文字言語フォントの扱いの例としてきちんとした形に残してほしかったのですが、リリース時期の制約などもあってそれが叶いませんでした。次の機会には何とかしてほしいものです。GitHub でのやりとり (それに、それが回送された Trac でのやりとり) はそのうち埋もれて忘れられそうなので、こうしてここにメモしておくことにしました。

  1. WordPress 5.0 をお使いなら、管理画面の左上隅の「W」マークをクリックして「新着情報」でも見ることができます。

2001–2010年ころの日本語システムフォント

これまでにも何度か書いているように、私自身は個人的には「日本語のある程度の長さのまとまった文章には、ゴシック体より明朝体のほうが向いている」と考えています。Web ページにおいても、です。

一方で、「Web ページはゴシック体」という意見が数多く見られます。おそらく、単純に「明朝派」か「ゴシック派」かで言えば、「ゴシック派」のほうがかなり多数のような印象があります。

システムフォントの歴史

いろいろ思い出すために、2000年頃以降のシステムフォント—大きなシェアを占めていた Windows と Mac にデフォルトで装備されているフォント—について、ざっと調べてみました。

Windows

2001XPMS明朝ゴシック 2.30 MS明朝 2.31
2006Vistaメイリオ 5.00 MS明朝ゴシック 5.00 MS明朝 5.00 (JIS X 0213:2004)
20138.1游ゴシック 游明朝

Mac

MacOS 9.2.2までOsaka 平成明朝 リュウミンライト-KL
2001OS X 10.0ヒラギノ角ゴ Pro W4・ヒラギノ明朝 Pro W3
200710.5ヒラギノ角ゴ ProN W4・ヒラギノ明朝 ProN W3
201310.9游ゴシック体 游明朝体 M

フリーフォント

私自身はこの時代より前から今日に至るまでずっと Linux (Debian) を常用していて、それにはデフォルトとか標準という考えがなく好みのフォントを使います。もう記憶が確かでない部分もあるのですが、主流だったと思えるものを拾い出してみました。

1998-1999渡邊フォント
2000-2003Kochi
2003-2004Sazanami
2007IPAゴシック・IPA明朝 (単体配布)
2010IPAexゴシック・IPAex明朝
2010Takaoフォント
2014源ノ角ゴシック / Noto Sans CJK JP
2017源ノ明朝 / Noto Serif CJK JP

参考:ブラウザーの歴史

1992mozaic
1994Netscape Navigator
1996NN3, IE3
1997NN4
2001IE6
2003Safari (10.3から。それ以前(10.2)の標準ブラウザはIEforMac)
2004Firefox 0.8
2006IE7
2008Chrome

漠然とですが、

  • 2001–2010年ころ、Web ページにとって明朝体は、技術的に「使い物にならな」かった
  • そのため、その頃とそれ以降、日本語の Web ページは圧倒的にゴシック体を主体としたものが多い
  • その環境で育った人たちは、もう「Web ページはゴシック体」が当たり前であり、技術的な問題が既に解決されても、むしろ明朝体だと違和感がある

のようなことではなかろうかと考えています[1]

2001年のMacOS Xにヒラギノというのは本当に画期的だったとは思うのですが、何しろシェアが違いすぎ、それにあぐらをかいた Windows のために「暗黒の10年」だったと言っても過言ではありません。ブラウザーの IE6 天下と軌を一にしています。

話はややずれますが、ハードウェアとしてのディスプレイが CRT から LCD になっていったのものこの頃でした。私が切り換えたのはだいぶ遅めの2005年ころでしたが、CRT ではいい具合にボケていた文字の輪郭が LCD だとくっきりしすぎて、文字として美しくなくなったのを覚えています。それからアンチエイリアスとかヒンティングなどを意識することになりました。

  1. 翻って考えると、私の「日本語のある程度の長さのまとまった文章には、ゴシック体より明朝体のほうが向いている」という考えも、WWW 以前の、印刷物に接する時間が長かった(印刷物は言うまでもなく、本文は明朝系であることが圧倒的に多い)影響が強いのかもしれません。