昨年のクリスマスプレゼント「スナップサーキット Snap Circuits Snaptricity」

昨年のクリスマスプレゼントを振り返るシリーズ。スウちゃん (仮名・当時8歳) が受け取ったのは「スナップサーキット Snap Circuits Snaptricity」でした。

日本での情報が多く、たぶん簡単に購入できそうなのは SC-100 か SC-300 です。それらのマニュアルを PDF で見ることができるので、よく見てみました。するとトランジスタや、さらにはブラックボックス化している IC までが部品にあることがわかりました。そもそも電気回路の初歩の初歩も知らない子にはレベルが高すぎるし、ブラックボックスが含まれるのはいただけません。作例の数が 100 や 300 となってはいますが、そういうものを除くとぐっと少なくなってしまいます。

Webページを見てみると、基本モデルセットだけでも実はたくさんあることがわかりました。そのうち Snaptricity (SCBE75) は次のようです。

  • 部品は豆電球、スイッチ、モーター、メーターなどで、入門用にはぴったり。トランジスタ・抵抗・コンデンサなどはないが SC-100 にはない電磁石がある。
  • 日本では入手しにくそうだが、アメリカの Amazon.com で購入すれば、送料を入れてもけっこう安い。
  • マニュアルが充実。SCBE75 のマニュアルは作例ごとに Educational Corner という解説がついていて、これがちょっとした教科書並みにいい。
  • いざとなれば (つまりスウちゃんがぐっとのめり込んできたら) 追加パーツを購入すればいいさ。あるいは Project Labs EP130 というのもいい[1]

抵抗くらいは欲しい気がしますが、このキットでオームの法則の実験例では豆電球やモーターを抵抗として使っています。確かにそれでいいですね。

マニュアルは英語ですがとても丁寧な感じです。でも英語だとスウちゃんはきっと見向きもしないので、父が翻訳版を作ることにしました。図がメインなのでそれはオリジナルを見てもらって、文章のところだけ。作例も75ほどなのでなんとかなるでしょう。PDF のマニュアルが Web ページから見ることができるので、実物が届く前からすこしづつ訳し始めました。

スウちゃんは、まずマニュアルの作例を見ながら組んでみました。プロペラが飛び上がるのが単純に面白いらしく、ゲラゲラ笑いながら何度もやっていました。そのうちマニュアルを離れ、とにかく電池の両端をつなぐ路ができればいいということに気づき、その間に電球やらスイッチやらを入れながら適当に組んでやってみていました。横から口を出してあまり勉強ぽく言ってもつまらなくなるので放っていますが、ときどき思い出したように遊んでいます。

作りはしっかりしていて、スナップもなかなか勝手のいいものです。何度も書きますが、マニュアルの充実ぶりはたいへんすばらしいものです。惜しむらくは日本語でないこと。訳をプリントして渡してみたものの、やはりはじめから自分で読めるものがあるともっと入り込みやすかったでしょう。日本で「電脳サーキット」という名前で売られているものには日本語解説書が付くようです (残念ながら Snaptricity の日本版はないようです)。

もうひとつ残念だったのは、3つの電球の抵抗値 (明るさ) がかなり違うことです。もうちょっと揃っていないと、簡単な「直列つなぎと並列つなぎ」の違いも実感しにくいと思いました。

いまのスウちゃんには特に磁力のところは、マニュアルどおりに組んでやってはみたものの、あまりピンときていない模様です。数年前のプレゼント Zome toolと同じく、もう何年か経ってからでも遊び直してほしいものです。

  1. すごく昔、学研マイキット(検索してみたら「システム7」というセット)というそっくりなもので父は遊んでいました。

消しゴムを使うな

小学校3年生のスウちゃん (仮名) は夏休みに入りました。

1学期のあいだ、テストがいくつもありました。宿題のプリントもそれはそれはたくさんありました。どれも採点されて返されます。スウちゃんはどうしてもうっかりミスが多く、なかなか100点が取れません。そういうたくさんのプリントやテストを持ち帰って見せてくれるのですが……。

間違えたところも解答が消しゴムで消されて書き直され、丸が付けられています。先生がそのようにしているのです。「ぜんぶ丸になるまで」という指導のようです。担任の先生は毎年変わっているのですが、これまでのどの先生もこのやり方でした。流行りというか、そういう指導の指導でもあるのでしょうか。

プリントを持ち帰ったスウちゃんに「ここ、はじめはどういうふうに間違ったの?」と聞いても「わからない。忘れた」というのがほとんどで、何をどのように間違えたかがわからないのです。この「間違った答を消しゴムで消して丸になるまで」の効果がさっぱりわかりません。

授業中にとるノートも、消しゴムを使ってきれいに仕上げることが徹底して指導されているようです。まあ、まだ小学校低学年ですから「ノートの書き方」そのものを教えなければならないこともわかるのですが。

しかし子どもは、短絡的にしか理解していません。

先日、スウちゃんは宿題の漢字練習をやっていました。ひとつの漢字を1行びっしり書き、漢字ドリル2ページ分、つまり20個ほどの漢字を練習するというものです。そのやり方自体がいいかどうかはここではとやかく言わないことにします。

スウちゃんは最後近くまでいったところで、そのびっしり書いたほとんど丸2ページ分を消しゴムで消し始めました。私がびっくりして「どうしたの?」と聞くと、3文字めか4文字めの漢字を飛ばしていたことに気がついたのでやり直すというのです。「いや、もういいよ。飛ばしていた字を最後に1行やればいいよ」と私が言っても、「そんなんじゃだめなんだよ。先生がちゃんとぜんぶ消して書き直しなさいって言うもん」と、泣きそうになりながら頑なに消しゴムをかけ続けます。時間はものすごく無駄だし消しゴムのかすもひどいことになるし、漢字練習の意味も何もありません。それでも先生の言うことは絶対のようです。本当に先生がここまでのことを要求しているかどうかは不明ですが、普段のノートやプリントの指導からして、子どもがこのように理解していても不思議はありません。

***

スウちゃんのことを離れて、自分のことを書きます。

もう何十年も前、私が子どもだったころ、父にノートの使い方を教わったことを思い出しました。父は高校の教師でしたから、多くの経験からそれを確立していたのだと思います。

美しさにこだわらない
本でもないし人に見せるものでもない。自分のためのもの。
詰め込みすぎない
とはいえギュウギュウに書いても、自分ですら読み返せない。訂正 (後述のように消しゴムはなるべく使わない) したりコメントを追記したりできる余裕を持たせる。
2本のラインを引く
ノートのページを番号欄、本体、備考欄に3分割して使う。これをうまく説明する参考にできるものはないかと検索してみたら、「東大合格生が小学生だったときのノート」というものを見つけました。「約束5」がまさに父が教えてくれたことそのものです。
消しゴムはなるべく使わない
途中式、間違いにも意味がある。備考欄を活用すれば消しゴムはあまり使わずに済むはず。
定規はなるべく使わない
定規を使わずに直線をきれいに描く練習はあらかじめしておく。分数や筆算のときはもちろん、数直線やグラフのときにも不要。

先ほどの「東大合格生が小学生だったときのノート」の紹介PDFを見てみると、ここに挙げたほかの項目も実にそっくりという気がします。先駆けること数十年、わが父ながら感服します。

私が父に教わったのは小学校の高学年のころだったと記憶しています。自分でも非常に効果的だと実感したので、その後の中学・高校もしっかり踏襲していました。東大にこそ進まなかったけれどそれなりの成果にもつながったのだろうと、いま振り返ってみても思います。

***

スウちゃんはいま夏休みの宿題 (ドリル) に取り組んでいます。採点は親がやることになっています。やっぱりうっかりミスが多いスウちゃんに「間違ったところは消さないで、その脇にもう一度考え直してから答を書いてごらん」と言って採点したものを渡しても、もう染み込んでしまった習慣で、見直しもそこそこにまず最初に消しゴムで消してしまうのでした。先生の威厳と信頼を損ねないように気をつけながら、なんとかこの悪癖を止めさせたいものです。

dvipdfmx の map の置き場所

TeXLive 2016 から 2017 での変化なのか、Debian 固有の問題なのかわからないが、メモ。

LaTeX から PDF を作るのに dvipdfmx を使っている。いまどきは、はじめから pdfLaTeX とか LuaLaTeX を使うのだろうが、もう10年ほどもこの方法で、スクリプトにしてやっているからそのままだ。

つい最近、Debian Testing (Buster) でパッケージを更新したら TeXLive が 2016 から 2017 になったようで、dvipdfmx でフォントを埋め込む際に参照する map ファイルが見つけられず PDF を作れなくなってしまった。map ファイルは /etc/texmf/dvipdfmx/ 以下にある。

調べてみると、/usr/share/texlive/texmf-dist/web2c/texmf.cnf で、以前も今も

TEXMFSYSCONFIG = /etc/texmf

は変わらないが、

TEXMF = {$TEXMFCONFIG,$TEXMFVAR,$TEXMFHOME,$TEXMFSYSCONFIG,!!$TEXMFSYSVAR,!!$TEXMFLOCAL,!!$TEXMFDEBIAN,!!$TEXMFDIST}

TEXMF = {$TEXMFAUXTREES$TEXMFCONFIG,$TEXMFVAR,$TEXMFHOME,!!$TEXMFLOCAL,!!$TEXMFSYSCONFIG,!!$TEXMFSYSVAR,!!$TEXMFDEBIAN,!!$TEXMFDIST}

になり、

TEXMFDBS = {!!$TEXMFSYSVAR,!!$TEXMFLOCAL,!!$TEXMFDEBIAN,!!$TEXMFDIST}

TEXMFDBS = {!!$TEXMFLOCAL,!!$TEXMFSYSCONFIG,!!$TEXMFSYSVAR,!!$TEXMFDEBIAN,!!$TEXMFDIST}

に変更されていた。要するに $TEXMFSYSCONFIG に !! が付き、それが $TEXMFDBS に含められている。

対処としては texmf.cnf の設定を以前と同じようにすればいいのかもしれないが、/etc/texmf/ls-R を (mktexlsr で) 作成すれば、すんなり元のように PDF を作れるようになった。どちらのほうがいいのだろう。

“しきんだん”、あるいは海戦ゲーム

スウちゃん (仮名、3年生) は、最近とくに退屈していて、うっかりするとぼーっとテレビを見続けている。そんなにテレビを見るんじゃないと言うと「じゃ、あそぼう!」となるが、トランプなども飽きてしまった。

ふと、父である私がちょうどいまのスウちゃんの歳のころにやった、紙と鉛筆で遊ぶゲームを思い出し、やってみることにした。当時は意味もわからず「しきんだん」と呼んでいたが、これが“至近弾”と知るのはもう少し後のことだった。いま調べてみると Wikipedia にある「海戦ゲーム」にそっくりで、簡略化されたローカルルール版だったのだろう。

ゲームの概要

2人で対戦する。
それぞれ手持ちの紙のマス目に自分の軍艦3隻を置き、相手には秘密にする。交互に「砲撃」して、相手の艦をすべて言い当て (撃沈し) たほうが勝ちとなる。
マス目は 8×8。行・列番号をつける。
広くしても狭くしてもいいだろう。行・列番号は、スウちゃんの今後の算数の学習を考慮して、それに合わせた。
最初の軍艦の数は3隻。区別はしない。
広さに合わせて増減させてもいいだろう。
交互に「砲撃」する。ただし砲撃の代わりに「移動」してもよい。
  • 「砲撃」は、「(2,3) に砲撃」のように、座標を伝えることで行う。1回につき1発のみ (移動する場合は砲撃できない)。
  • 砲撃の「射程」は、自艦の周囲1マス分のみ。つまり自艦のまわり8マス (斜めも含む) のみ砲撃可能。
  • 「移動」は、「北へ1マス」のように、方位と距離を伝える。どの艦が移動するかは伝えなくてよい
  • 移動は、東西南北 (上下左右) の直進のみ。
  • 移動は1回につき1隻。移動する回は、砲撃できない。
砲撃の宣告を受けたら、「命中」「至近弾」「異常なし」を答える。
「命中」は、沈没を意味し、艦を消去する。
「至近弾」は、着弾点の周囲1マス分、まわり8マス (斜めも含む) のいずれかに艦がいることを意味する。
「異常なし」は、着弾点の周囲1マス分内に艦がいないことを意味する。

ゲームの途中で気づいて取り決めたが、「自艦のいるマスを砲撃すると、自艦も沈没する」とした。

練習

はじめからルール全部を教えるのは大変だと思ったので、次のようなステップを数回ずつ繰り返しながら徐々に習得してもらった。

  • 5×5マス。艦は1隻。射程の制限なし。移動もなし。これで座標の読み方、砲撃の宣告方法を練習した。
  • 5×5マスに1隻で、射程あり。これで射程の制限と「至近弾」の応答を練習した。
  • 8×8マスに広げ、艦は3隻。移動もありにして、ぜんぶのルールを導入した。

これで無理なくルールを覚えることができた。

ゲームの楽しみ

トランプなどに飽き飽きしていたスウちゃんはすぐにノッてきて、何度も繰り返しやりたがった。頭を使うのが楽しいらしい。数回のうちにメモのとり方も工夫して上手になった。だんだん自分の砲撃による探索と、相手の砲撃の着弾から相手の艦の位置を絞り込めるようになった。そして「自分の行動が、相手に自分の情報を与えてしまうこと」を学んだ。

さらに繰り返すうちに、自艦の配置を適度な間隔にして相手を幻惑させること、狙われている艦ではなく別の艦を移動させて (このルールではどの艦か宣告しなくてもいい) 情報を撹乱すること、など高等戦略まで身につけたのだった。

試しに、調べてみて出てきた「海戦ゲーム」もやってみた。ルールが複雑になっているが、楽しさはあまり変わらない。むしろ、どの艦が移動するかがあからさまになるので、この点はローカルルール版のほうが面白みがある。

そのうちメールやチャットを介して「通信チェス」みたいにやったりできるかな、もっと先にはコンピュータでこのゲームのプログラムを組みたくなったりしてくれないかな、などと父である私は思っているのであった。

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 の読み込みの順番が正しくなるように優先度を付けます。