段落の最初の行頭の字下げ

WordPress.org の日本語フォーラムでの「日本語字下げをいつまで無視し続けるのか」という投稿に答えるなかで改めて調べてみて、いくつかを知ることになったのでここに記しておく。

多くの言語で使われることが想定される WordPress に、日本語の一つのスタイルである「全角アキ」を実装するよう求めるのは現実的ではない。利用者(サイト運営者)が style.css なりカスタマイズの「追加CSS」で対応するしかないだろうと思う。もっとも英語使用者にも似たような要望を持つ人はいるようで、たとえば英語のフォーラムにも Indent first line of most paragraphs, not all のトピックがあるし、そこからたどってみると #37462 の要望も出されている。

まず、英語をはじめとする多くの欧文で、段落整形は

  • 段落間は大きくあけず、段落の最初の行頭を字下げする
  • 字下げせず、段落間の行間をあける

のどちらかである。それぞれ「インデントスタイル」「ブロックスタイル」のように呼ばれるようだ。どうやら前者は伝統的なスタイルで、後者はウェブページなど電子テキストに多く見られる。

日本語の横書きもこれに準じる。ただし欧文の場合に字下げ幅が3–5文字であるのに対し、日本語の場合は全角アキである。

スタイルシート

私自身も、まとまった文章では伝統的な「インデントスタイル」が望ましいと考えているので、このサイトではスタイルシートで次のように設定している。

.entry-content p {
  margin-bottom:.25em;
  text-indent:1em
}

つまり、段落ブロックの下のアキは少しだけにして、最初の行頭の字下げ幅は 1em にしている。

見出し直後の段落

「インデントスタイル」の場合でも、最初の段落(見出し直後の段落)のみは字下げしない、という流儀もある。たとえば CSS のプロパティ text-indent の解説にもこのことが書かれている。まさにそこにあるように書くことで実現できる。

このサイトではこの流儀は採用していない。

日本語組版処理の要件

日本語については「日本語組版処理の要件」が重要な参考資料となる。「段落整形」の章でこの件について書かれている。

そこに、これまでどうしようか迷って自分でも揺らいでいた部分についての言及があった。

改行にして始めかぎ括弧[「] (LEFT CORNER BRACKET)及び終わりかぎ括弧[」] (RIGHT CORNER BRACKET)でくくった会話などを“といった……”などと受けて続く場合は,文節が連続していると考え,段落の先頭行の字下げは行わないで天付きとする(Figure 151).横組の別行にした数式を受けて,改行で“となるので……”などと受ける場合も,同様に段落の先頭行の字下げは行わない.ただし,小説などでは,すべて段落の先頭行の字下げは行うという処理方法も行われている(Figure 152).

「日本語組版処理の要件」3.5.1 段落先頭行の字下げ

要は、カギカッコの会話文や独立行の数式を挟んで文が続いているとき、それらの会話文や数式の後の段落は字下げしない。ここまで明確に書いてある説明をこれまで見ていなかった。

この記事でいうと、上のほうにある箇条書きに続く「のどちらかである。」のところは字下げしない、ということになる。これまでどうしたものかと思いっていたことの答がはっきりと示されていて、すっきりした。

内容に依存するため、さすがに一律に設定はできない。ここだけは字下げしないという場合にその CSS を適用する。WordPress のブロックエディターなら、右のほうのメニューの「ブロック」→「高度な設定」→「追加CSSクラス」で、前もって style.css か「追加CSS」に用意しておいた .noindent {text-indent: 0em} を指定するようにする。

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」マークをクリックして「新着情報」でも見ることができます。

Mastodon / GNU social はブログである

GNU social のインストール

Mastodon ブームに乗って GNU social をインストールしてみました。

このところ Mastodon が大流行のようで、その流れに乗って mastodon.cloud にアカウントを作ってみて、そこで情報を仕入れていくつかの記事を読んでどんなものかが少しづつわかってきました。割と早い時期に目にしてたいへん参考になったのは「gnusocial や mastodon の哲学」です。

早速自分でもインスタンスを立ててみようかと思いましたが、環境が整っていれば簡単そうなものの、その環境を準備するのが面倒くさい。そこで Mastodon と交流可能な GNU social を見てみることにしました。参考になったのは「GNU socialのインストール」です。

GNU social のインストールは、インストール版 WordPress を使ってことのある人にとっては簡単です。その説明を読めば分かるように、基本的に要件は PHP, MariaDB(MySQL), Web サーバー(Apache など)で、WordPress のそれと同じです。

まず https://git.gnu.io/gnu/gnu-socialから GNU social を入手し、Web サーバーでアクセスできるところに展開します。既に WordPress を動かしているサーバーなら、https://expample.net/social などのようにサブディレクトリでもいいでしょう。

それから、データベースにアカウントを用意しておきます。

そしてブラウザからアクセスします。あとは欄を埋めるだけです。サイト名、データベースのID、パスワード、管理者の名前、パスワードなどです。これで設定ファイル config.php が作られます。

これで終わり。このへんの手順も WordPress の「5分でインストール」にそっくりです。

一人だとちょっとさびしい

GNU social や Mastodon のタイムラインは

  1. 自分の発言
  2. 自分がフォローしている人たちの発言
  3. ローカル = 同一インスタンスのユーザーの(A)の和
  4. ネットワーク = 同一インスタンスのユーザーの(B)の和(だと思う)

があります。おひとり様インスタンスだと、(C)や(D)の意味がないので、ちょっとさびしいです。

要はブログである

おひとり様インスタンスを立ち上げてみて、WordPress そっくりのインストール過程からも感じたのは、「これは要はブログである」ということです。実際「マイクロブログシステム」と言われています。Twitter もそう言われていましたが、同一サーバー(名前空間)にすべてのユーザーがいるためにそれを意識することがなくなっていました。

自分の発言はブログで言うところの「記事」に相当し、その記事にコメントがついたりトラックバックしているようなものと考えることができます。記事を極端に短くして、コメント/トラックバックを短期間に大量に投げ合っているイメージです。「フォロー」というのは RSS で情報をやり取りして自分のブログに相手方の記事を混ぜ込むようなものです。ブログの記事を寄せ集める Planet (そういえば最近とんと聞かなくなった言葉です) に似ています。

このように考えるとストンと腹に落ちました。Mastodon や GNU social は自分の書く記事と大量のコメントをデータベースに蓄え、それを整形して表示するものと言えます(もちろん他のインスタンスに情報を送る機能を持っていて、それが肝なのですが)。デフォルトの GNU social の見かけに対して、はじめから添付されている qvitter を使うようにすると、同じ中身を Twitter そっくりにして表示します。WordPress で言うところの「テーマ」と同様に、GNU social も外見を変更できます(INSTALL の Themes の節を参照)。

それにしても、ブログをぎゅっと圧縮すると、あたかも IRC やネットニュース(NNTP) のような様態になるとは面白いことです。

やっぱりブログである

「ブログの集合体」と考えると、たとえば「そろそろマストドンについて語っておくか」に見られるような批判は、当たらないとは言わないまでもピント外れと言うべきでしょうか。

たとえば WordPress を自分のサイトに導入してブログを始める。それ自体はとやかく言われることではないでしょう。そうやってブログを運用する大抵のサイトは、アカウント作成を開放して不特定多数の人がそこに書き込む権限を渡すようなことはしません。一人か、もしくは特定少数のライターに権限を与えて運用されています。それと対比すれば mastodon.cloud や mstdn.jp はかなり特殊な状態です。逆に、ユーザー側からしても同じです。他所のブログサイトにアカウントを作れるからと言って、得体がしれないのに個人情報を渡すのだとすれば、それはユーザー側にも落ち度があります。何も Mastodon や GNU social の問題ではありません。

サーバーの設置は自由なソフトウェア実装が存在するだけではだめで、十分な性能を持ったコンピューターと十分なネットワーク帯域が必要になる。GNU SocialはPHPで実装されているし、マストドンはRuby on Railsで実装されている。実行には普通にWebサーバーを運営するのと同じだけの煩わしさがある。

これだけサーバーの実行が面倒だと、結局、既存のサーバーを利用するものが大半だろう。その結果、どこかの学生が1個人が運営している怪しげなサーバーに人が集中する。これはとても問題だ。

自分でやってみて実感しましたが、「これだけサーバーの実行が面倒だ」とは思いません。何度も引き合いに出しますが、インストール版 WordPress がこれだけ広がっているなら、それとほぼ同じ手間で設置できるものですから、同じくらい広まる可能性はあります。そもそも知らなかったという人たちが多いのだと思います。私自身、GNU social という言葉はどこかで小耳に挟んでいたものの、それが何かということを知ろうとはしていませんでした。それが今回の Mastodon 大流行でちょっと触ってみる気になったのです。これから雨後の筍のごとく、あちこちでおひとり様インスタンスが立ち上がるでしょう。

ブログシステムの WordPress も近年になってホスティング会社が簡単にセットアップできる仕組みを提供しています。それと同様になればかなり広まるでしょう。さっそくさくらのクラウドのスタートアップスクリプト Mastodon が現れています。

脱中央集権化

ところで、はじめに紹介した記事「gnusocial や mastodon の哲学」でも強調されている理念に「脱中央集権化 decentralization」があります。それは、今回の大流行に関係しているでしょうか。

もし多くの人がその理念を好ましく思っているなら、いま日本で大流行の LINE などより XMPP のようなオープンなメッセージングシステムが受け入れられていてもいいように思います。ところが登場時期については全く逆で、XMPP のほうがずっと前から存在するのに後から出てきた LINE があっという間に広まりました。

理念よりも、何かもっと表面的なこと—たとえば見た目のいいアプリとか—がきっかけのようにも思えます。XMPPサーバーを公開して数年経つのに登録者はあんまり増えていないからなあ。

font-family 指定を見る側が選べるようにしてみる

ある料理店があった。料理は「コックおすすめのワイン」とセットだった。

ある日コックは考えた。「人はみな自分好みのワインがあるに違いない。俺の好みを押し付けるのはやめてみるか」。それ以降、この料理店は「ワイン持ち込み自由」になった。「これでお客さんはもっと料理を楽しんでくれるだろう」。

ところが大半の客は持ち込みなどしない。料理の前に出される水と一緒に食べるだけなのだ。コックは愕然とした。「俺の料理を、まるで流し込むように水で食べるなんて」。

また以前のやり方に戻すことにした。必ず「おすすめワイン」で食べてもらう。多くの客は喜んだ……かどうかわからない。どうでもよかったのだ。もし聞かれれば「そう言えば水よりはこのワインのほうが、料理がおいしく感じられるね」と答える。だが、あっちの店に行ったときに茶が出されるのなら茶、ビールならビールにするだけだ。自分で選べるなどと考えたこともなかった。だからどこでどう手に入れるかどころか、ワインの自分の好みすら知らなかったのだ。

コックは悩んだ。多くの客が水で食べるよりましな状態にはなった。しかしごく少数とは言え、各々こだわりのワインを持ち込んで料理を楽しんでくれていた客はどうなるのか。いちばんよくわかってくれている彼らの思いを踏みにじるのか……。

フォントを指定しないこと

以前、「フォントの指定をやめる」と題して記事を書きました。そのときには

「本文は明朝系」という信念の人 (私だ) はブラウザのデフォルトを serif に設定しているだろうし、Windows でも自分の好みの表示になるようにがっちり設定している人には、そのフォントで読めるようにしてあげればいいではないか。

という訳で、このページの本文の font-family の指定はやめることにした。

と考えていたのです。

数年ぶりに WordPress のテーマを変えてみて、それが元々は欧文向きとは言え、文章を読ませるのに適したデザインでセリフ系のフォントを指定してあったこと、そのフォントを入れ替えてみようとしたことから、いろいろと考えながら調べているうちに、「Windows でも自分の好みの表示になるようにがっちり設定」することがほとんど不可能らしいことに気がつきました。

私は長いこと、デスクトップに Debian を使っています (Windows はどうしてもそれでしか動かないソフトを使う必要があるときだけなので、その際の見かけなど細かいことはまったく気にしないことにしています)。現在の Debian なら fontconfig で、たとえば

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
    <match target="pattern">
        <test qual="any" name="family">
            <string>serif</string>
        </test>
        <edit name="family" mode="prepend" binding="strong">
            <string>IPAexMincho</string>
            <string>DejaVu Serif</string>
        </edit>
    </match>
</fontconfig>

のように設定することで、総称名 serif だけが指定されたときに使われるフォントを設定できます (もっと正しい書き方があるかもしれませんが)。

これでも随分と簡単になったものです。以前は defoma とかいうのがあって、その hints という設定ファイルを書くのがものすごく面倒でした。TrueType のフォントファイルを所定のフォルダに置くだけですぐに使える Windows などがとても羨ましく思えたものでした (Mac はよく知らない)。

それが周回遅れでトップに立ってしまったようなものです。Windows では「serif という総称名で表示される実際のフォントを設定する方法」が (少なくとも簡単には) ないのです (Mac はよく知らない)。web ブラウザーで設定できるかと思ったら Windows10 標準の Edge では、それすらもできないようです。

それでも Firefox では about:preferences#content の「フォントと配色」の詳細設定で、また Chrome では chrome://settings/fonts の詳細設定で、だいぶ設定できそうです。Safari はよくわかりませんが、ユーザー定義のスタイルシートを書けばできるらしいです。そういえば Firefox でも、userContent.css というユーザー定義のスタイルシートでもできそうですし、Chrome でも拡張機能でユーザー定義スタイルシートを使えそうです。

しかし、そこまでしてデフォルトのフォント設定をしている閲覧者はどれほどいるのでしょう。結局、「フォントの指定をやめる」というのは、そのようにデフォルトの設定も行っていない“意識の低い”閲覧者に対して何も与えないものでした。

フォントを指定すること

では、サイト制作者側できっちりフォントを指定してやればいいのでしょうか? ちょっと検索すれば「font-family 指定のおすすめ」のような記事がたくさん見つかります。たとえば

body {
font-family: -apple-system, BlinkMacSystemFont, "Helvetica Neue", "Yu Gothic", YuGothic, "ヒラギノ角ゴ ProN W3", "Hiragino Kaku Gothic ProN", Arial, "メイリオ", Meiryo, sans-serif;
}

みたいにするのがいいのでしょうか?

今度は“意識の高い”閲覧者を切り捨てていることになってしまいます。「sans-serif ゴシック系より serif 明朝系」とか、ヒラギノと游のどちらがいいかはほんとうに好みによりそうだし、さらにはもっといい (自分好みの) フォントを自分でインストールしてそれをデフォルトに設定している閲覧者に対して、その意図を無にしてしまうことになると思うのです。

閲覧者が選べるスイッチ

ブラウザーでもっと手軽にフォントを切り替えるボタンがついていればいいのでしょうが、現実にそういうものはありません。ズームは割と簡単にアクセスできるメニューやキーボードショートカットが用意されているのに。そういえば、そういうものがあるのにコンテンツの側で「文字の拡大・縮小」を用意しているサイトもときどき見かけますね。……というところで、そうかフォント切替スイッチをコンテンツ側で用意するという方法もあるのか、と思いつきました。

まずは「明朝体/ゴシック体の切替」の二択のボタンです。Javascript の element.classList.toggle を使えば簡単です。

CSS のほうで

body {
        font-family: Georgia,Times,"Times New Roman","YuMincho","Yu Mincho","Hiragino Mincho ProN",serif;
}
.sans {
        font-family: -apple-system,BlinkMacSystemFont,sans-serif;
}

のように、<body> に class=”sans” のない場合とある場合の font-family 指定を書いておき、HTML のほうには

<button id='toggle-font-button' title='明朝体/ゴシック体の切替' onclick='(function(){document.getElementsByTagName("body")[0].classList.toggle("sans");})()'>フォント切替</button>

をどこかに追加すれば済みます。

WordPress での実践

【2018年10月10日追記】Google Web FontsNoto Serif JP, Noto Sans JP が利用可能になったので、それを追加 (優先) しました。

「ヒラギノ明朝優先」「游明朝優先」……と選択肢を増やすときは、CSS で用意する class を増やして、HTMLでは element.classList.toggle の代わりに element.classList.removeelement.classList.add を使います。

style.css で

body {
        font-family: Georgia,Times,"Times New Roman","Noto Serif JP","YuMincho","Yu Mincho","游明朝","Hiragino Mincho ProN","ヒラギノ明朝 ProN",serif;
}
.serif {
        font-family: Georgia,Times,"Times New Roman",serif;
}
.noto-serif {
        font-family: Georgia,Times,"Times New Roman","Noto Serif JP","Hiragino Mincho ProN","ヒラギノ明朝 ProN","Yu Mincho",YuMincho,"游明朝",serif;
}
.hiramin {
        font-family: Georgia,Times,"Times New Roman","Hiragino Mincho ProN","ヒラギノ明朝 ProN","Noto Serif JP","Yu Mincho",YuMincho,"游明朝",serif;
}
.yumin {
        font-family: Georgia,Times,"Times New Roman","Yu Mincho",YuMincho,"游明朝","Noto Serif JP","Hiragino Mincho ProN","ヒラギノ明朝 ProN",serif;
}
.sans, .sans-serif {
        font-family: -apple-system,BlinkMacSystemFont,sans-serif;
}
.noto-sans {
        font-family: -apple-system,BlinkMacSystemFont,"Noto Sans JP","Hiragino Kaku Gothic ProN","ヒラギノ角ゴ ProN","Yu Gothic",YuGothic,Meiryo,sans-serif;
}
.hirago {
        font-family: -apple-system,BlinkMacSystemFont,"Hiragino Kaku Gothic ProN","ヒラギノ角ゴ ProN","Noto Sans JP","Yu Gothic",YuGothic,Meiryo,sans-serif;
}
.yugo {
        font-family: -apple-system,BlinkMacSystemFont,"Yu Gothic",YuGothic,"Noto Sans JP","Hiragino Kaku Gothic ProN","ヒラギノ角ゴ ProN",Meiryo,sans-serif;
}

のように用意しておき、functions.php で

add_action( 'get_footer', 'fontSwitcher' );
function fontSwitcher () {
?>
<script type="text/javascript">
  var body = document.getElementsByTagName("body");
  function resetFontClass () {
        body[0].classList.remove("serif", "noto-serif", "hiramin", "yumin", "sans", "noto-sans", "hirago", "yugo");
  }
  function addFontClass ($class) {
        resetFontClass();
        body[0].classList.add($class);
  }
</script>
<div id="fontswitcher">
  «
  <form id="fontswitcherform">
        <input type="radio" name="fontswitcher" onClick="addFontClass('serif')"><span class="serif">serif</span><br/>
        <input type="radio" name="fontswitcher" onClick="addFontClass('noto-serif')"><span class="noto-serif"> Noto Serif</span><br/>
        <input type="radio" name="fontswitcher" onClick="addFontClass('hiramin')"><span class="hiramin"> ヒラギノ明朝</span><br/>
        <input type="radio" name="fontswitcher" onClick="addFontClass('yumin')"><span class="yumin"> 游明朝</span><br/>
        <input type="radio" name="fontswitcher" onClick="addFontClass('sans')"><span class="sans"> sans-serif</span><br/>
        <input type="radio" name="fontswitcher" onClick="addFontClass('noto-sans')"><span class="noto-sans"> Noto Sans</span><br/>
        <input type="radio" name="fontswitcher" onClick="addFontClass('hirago')"><span class="hirago"> ヒラギノ角ゴ</span><br/>
        <input type="radio" name="fontswitcher" onClick="addFontClass('yugo')"><span class="yugo"> 游ゴシック</span><br/>
  </form>
</div>
<?php
}

としました。add_action( 'get_footer' )で最後のほうに付け加えました。スイッチのデザインは style.css で行います。

こういうものを作ってここに付けてみましたが、他で似たようなものを見かけたことはまったくありません。必要ないから流行らないのか、はたまた弊害があるのかもしれません。

***

コックが考え出した新しいやり方はこうだ。

何も言わない客には「おすすめワイン」をセット。だがちょっとだけ好みがある客にはテイストの違ういくつかの中から選んでもらおう。そして知識もあり手間も厭わぬこだわりの客には自分のワインで楽しんでもらおう。

さあ、この料理店は繁盛するだろうか……。

特定の文字だけ別のフォントを使う

まとめ

まとめを先に書いておきます。

特定の文字コードのみ(ここでは「除算記号」(U+F7))別のフォントを使いたい場合、まずそれについて定義します。

  @font-face {
    font-family: 'division sign';
    src: local('Georgia'),local('Times'),local('Times New Roman'),local('Serif');
    unicode-range: U+F7;
  }

その後に全体で使うフォントを定義します。ここでは Google Fonts から読み込む CSS で

...
/* latin */
@font-face {
  font-family: 'Lora';
  font-style: normal;
  font-weight: 400;
  src: local('Lora Regular'), local('Lora-Regular'), url(https://fonts.gstatic.com/s/lora/v10/4vqKRIwnQQGUQQh-PnvdMA.woff2) format('woff2');
  unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2212, U+2215;
}
...

などです。それらの後で、実際に使用するフォントを指定します。

body {
	font-family: "division sign",Lora,Georgia,Times, ... ;
}

この定義と指定の順番を入れ替えてはなりません。

web フォント Lora のうち「除算記号」だけ使わない

結論を先に書いた後でゆっくり経緯を書きます。

このブログでの欧文フォントに Google の web フォント Lora を使うことにしました。デザインがとても気に入っています。

ところでこの Lora で「除算記号」は、真ん中の水平線がなく、コロン「:」にそっくりのデザインになっています。除算記号としてこの形のものを使う地域がある、ということを聞いたことがあります。

Lora の除算記号÷
Georgia の除算記号÷

その違いがうまく表示されているでしょうか。

通常の文章なら除算記号などめったに出てくるものでもなく、たいした問題ではないでしょう。ところが、このブログ「半月記」での一番人気の記事は

なのです。ここで除算記号が、日本でおなじみの形ではなく、すべて「:」そっくりになっていたら、読者は訳がわからなくなってしまいかねません。これらの記事の中の主張のひとつが「除算記号などごく限られた領域でしか使われないのだ」なのですが、その内容を書くためには除算記号を使わなければならず、そのデザインにまでこだわらなければならないとは、なんと皮肉なことでしょう。

@font-faceunicode-range

全体的には Lora をたいへん気に入っているので使い続け、「除算記号」のみ別のフォントで表示するようにしてみます。

CSS の @font-face には unicode-range という記述子がありますので、これを使います。このリンク先の例にあるのとほぼ同じように

  @font-face {
    font-family: 'division sign';
    src: local('Georgia'),local('Times'),local('Times New Roman'),local('Serif');
    unicode-range: U+F7;
  }

のように書きます。文字コードU+F7(つまり「除算記号 division sign」)の場合のみ、Lora ではなく、Georgia, Times, “Times New Roman”, Serif のどれかを使うようになります。

定義の順序

さて、そもそも web フォント Lora を使うためには、CSS に定義 @font-face があるはずです。ここでは外部 CSS として Google Fonts より読み込んでいます。

これらの定義があれば

body {
	font-family: "division sign",Lora,Georgia,Times, ... ;
}

のように使用フォントを指定して、意図通りになるはずでした。しかし実は、それらの記述の順序が大事でした。まず局所的なフォント定義(‘division sign’)が最初、それから全体のフォント定義(Lora)、最後にフォント指定、の順番でなければなりません。

WordPress での実践

ここでは WordPress の子テーマを使っています。子テーマの style.css のはじめのほうに局所的なフォント定義(‘division sign’)を書いても、それより前に外部 CSS の読み込めば、正しい順番になりません。もし 子テーマの style.css より後に外部 CSS 読み込みをもってきても、やはり正しい順番にはなりません。

そこで局所的なフォント定義を分離して先に読み込むようにします。この部分はたいした量でもなく、あとで書き換えることもまずないので別ファイルにせず、functions.php に直接書いて読み込ませることにしました。そして優先度を上げ(10より小さく)ます。

add_action( 'wp_head', 'division_sign_font', 7 ); /* 8 だと遅すぎる */
function division_sign_font() {
?>
<style type='text/css'>
  @font-face {
    font-family: 'division sign';
    src: local('Georgia'),local('Times'),local('Times New Roman'),local('Serif');
    unicode-range: U+F7;
  }
</style>

あとは、前の記事に書いたように、外部 CSS の読み込みと子テーマの style.css の読み込みの順番が正しくなるように優先度を付けます。

親テーマ指定の web フォントを子テーマで変更する

まとめ

まとめを先に書いておきます。

<head> 内で

<link rel='stylesheet' id='libre-lora-css' href='https://fonts.googleapis.com/css...' ... />
...
(親テーマ指定のwebフォント用CSSの削除)
...
<link rel='stylesheet' id='libre-2-style-css' href='...' ... />

の順になってほしいため、子テーマの functions.php では

add_action( 'wp_enqueue_scripts', 'libre_kid_fonts', 9 ); /* style.css より先に読み込む必要がある */
function libre_kid_fonts() {
        wp_enqueue_style( 'libre-lora', libre_lora_url(), array(), null );
}
add_action( 'wp_enqueue_scripts', 'libre_dequeue_google_fonts', 11 ); /* 優先度を落とす */
function libre_dequeue_google_fonts() {
        wp_dequeue_style( 'libre-2-fonts' );    
}

のように、add_action('wp_enqueue_scripts') に優先度を付ける必要があります。

WordPress のテーマ Libre 2 と Google web フォント Lora

では、結論を先に書いた後でゆっくり経緯を書いてみます。

ふと WordPress のテーマを変えてみました。もう自分で作る気力もないので、公式ディレクトリで人気順に見ていって、シンプルな Libre が気に入りました。すぐ後に WordPress.com のほうで後継 Libre 2 を見つけ、「ダウンロードしてインストール型 WordPress で使用できます」とあったので早速そうすることにしました。

いくつか直したいところがあったので、子テーマで手を入れることにしました。変更点を備忘録的にここに書いておくと、

  • フォント関連の変更。欧文フォントを Libre Baskerville からLora に変更した。
  • 装飾に Dashicons を使うことにした。
  • 記事の最初のメタ情報にカテゴリー・タグを表示することにした。記事の最後には表示しない。
  • 本文の段落は1字下げ。段落間は小さくする。箇条書きの上下のマージンも小さく。
  • 本文内の見出し(<h3>など)は上下にマージン。ただしその見出しが本文先頭なら上マージンなし。

このテーマは、やや長めの文章を見せるのに適するようにセリフ(serif)の書体 Libre Baskerville が指定してありました。そこで日本語で書かれるこのブログでも、セリフ(明朝体)にすることを考えます。ただ、よくあるヒラギノ明朝体や游明朝体の中に混ぜてみると Libre Baskerville は落ち着かない感じがして、同じく Google web フォント の Lora に変更することにしました。

wp_dequeue_style() の実行順序

親テーマの Libre 2 は、その functions.php で

function libre_2_scripts() {
        ...
        wp_enqueue_style( 'libre-2-fonts', libre_2_fonts_url(), array(), null );
}
add_action( 'wp_enqueue_scripts', 'libre_2_scripts' );

と、webフォント Libre Baskerville 用の CSS を google から読み込むようになっています。子テーマでは、ここで enqueue しているものを dequeue すればいいのです。

が、子テーマの場合、そもそも functions.php の実行順は (1)子テーマの functions.php (2)親テーマの functions.php です。したがって、子テーマの functions.php に普通に dequeue を書いてもこれが先に実行され(つまりまだ enqueue されていないものを dequeue しようとする)、その後に親テーマで euqueue されることになります。

そこで、子テーマでは dequeue の実行の優先度を下げて(10より大きな数字にして)書いておかなければなりません。

wp_enqueue_style() の実行順序

子テーマでは、親テーマの libre_2_fonts_url() を真似して、別のwebフォントである Lora 用の CSS を指定する libre_lora_url() を書きます。

この CSS は Google Fonts から読み込まれますが、内容は

...
/* latin */
@font-face {
  font-family: 'Lora';
  font-style: normal;
  font-weight: 400;
  src: local('Lora Regular'), local('Lora-Regular'), url(https://fonts.gstatic.com/s/lora/v10/4vqKRIwnQQGUQQh-PnvdMA.woff2) format('woff2');
  unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2212, U+2215;
}
...

のような @font-face がいくつも並んでいるものです。子テーマの style.css では

body {
	font-family: Lora,Georgia,Times, ... ;
}

のように、この定義を利用して使用フォントを指定します。

ところでこの 定義 @font-face と指定 font-family の順序ですが、ブラウザー Chromium の場合 (Debian の Chromium で確認しました。おそらくどの OS でもブラウザー Chrome でも同じだろうと思います)、前もって @font-face がないと font-family での指定時にそれが存在しないものと扱われるようです。Firefox ではその順番は関係ないようでしたが。

そこで、子テーマの style.css より前にこの CSS が読み込まれるように、wp_enqueue_style() を呼ぶ add_action('wp_enqueue_scripts') の優先度を 9 にします。

WordPress 10周年 (自分の中で)

しばらく何も書かずに間が空いてしまいました。

ふと気がついたらこのブログの最初の記事「WordPressの導入」を書いたのがちょうど10年前でした。それまでの手書き(というのも変ですが、テキストエディタで HTML タグを陽に書きながら、という意味)でWebサイトを作るというのがだんだん億劫になり、何かいいソフトはないものかと探してみてたまたま見つけたのが WordPress でした。その WordPress が現在、ここまで広まっていようとは夢にも思いませんでした。

WordPress の最大の強みのひとつは、このソフトウェアを取り巻くコミュニティの存在です。「ソフトウェアはコピーされても、コミュニティはコピーできない」という言葉を何度も思い出します。この10年のうちの長い時間を日本語版作成チームの一員として過ごせたことをとても光栄に思います。そういう関わりをしなければきっと私は WordCamp にも参加しなかっただろうし、いろいろな人たちに出会うこともなかったでしょう。

WordPress のもうひとつの強みは、これは私の思いですが、GPL を採用していることです。WordPress は、GPL の元で公開されているソフトウェアの中で最も成功しているもののひとつでしょう。GPL であることが今日の WordPress の隆盛の大きな要因だろうと思います。また逆に、WordPress は GPL の理念を広めるのにとてつもなく貢献している存在です。WordPress に接して初めて GPL を知った人は大勢いるのではないでしょうか(もしこれを読んでいるあなたが WordPress を利用しているなら自分のサイトの管理画面の左上の W マークをクリックして「自由について」というページを見てみてください。ここからリンクを張れないのが残念ですが、つまり URL は (自分のサイト)/wp-admin/freedoms.php です。WordPress をインストールして利用していてもこのページはあまり読まれていないでしょう。翻訳に関わった者としてちょっと残念に思っています)。

10年。けっこう長い時間です。たとえば WordPress や GPL をまったく知らない子どもだった人がそれらをよく知って利用するまでになるくらい。さてもう10年経ったら、WordPress や GPL はどう発展しているでしょうね。