TeX でゆきだるまを“もっともっと”たくさん
これは TeX ＆ LaTeX Advent Calendar 2015 の13日目の記事です。昨日は MNukazawa さんでした。明日は kuroky_plus さんです。
TeX ＆ LaTeX Advent Calendar 2015 もちょうど折り返し地点です。今年のテーマは「今さら人に聞けない、TeXのキホン」というわけで、今日は「“TeX でゆきだるま”のキホン」です。
次のような文を書きたいとします：
たとえば、upLaTeX を使うと次のようになるでしょう（pLaTeX の場合は☃の代わりに otf パッケージを使って \ajSnowman とするとよいでしょう）：
% upLaTeX 文書 \documentclass[dvipdfmx,uplatex]{jsarticle} \begin{document} 私の名前は「黒☃大輔」です。 \end{document}
簡単ですね…と思いきや、ここで気になることがあります。
たとえば「IPA明朝」埋め込みで PDF 化すると次のようになります：
しかし、「小塚明朝」や「ヒラギノ明朝」の場合はそれぞれ以下のようになります：
これを「IPA明朝」の場合と比較すると、小塚明朝は帽子がなくなってマフラーを付けていますし、ヒラギノ明朝は雪がなくなってしまいます。これはいわば「大輔」が「太輔」や「犬輔」や「人輔」になってしまったようなもので、一大事です。JIS90 から JIS2004 に変わったときに「フォントのバージョンによって“しんにょう”の点のかずが違う！」と辻さんや渡邊さんは困惑したでしょう。それと同じかさらに深刻な問題に、黒☃さんは常に直面しているわけです*1。
ゆきだるまのキホン：フォントによって違うゆきだるまたち（復習）
このような問題が起きるのは、フォントによってゆきだるまの字形が全く異なることが原因です。しかも、歴史的経緯によって事態はより複雑になっています：
- 初期の Unicode には「ゆきだるま」は "U+2603 SNOWMAN" 一点だった。
- Unicode 5.2 で日本の ARIB 外字が追加されたことにより "U+26C4 SNOWMAN WITHOUT SNOW" と "U+26C7 BLACK SNOWMAN" が登場。
この時点で、従来のコードポイント "U+2603 SNOWMAN" は突然暗黙に「雪あり白ゆきだるま」になってしまいました*2。結果的に、それ以前にデザインされたフォントの中には、U+2603 に「雪なしゆきだるま」のグリフを割り当てたものが一定数存在します。
これほどの「字形の多様性」があるのは Unicode の膨大な文字のなかでも☃が群を抜いており、これだけで一記事書けるほど興味深いものです。このあたりの事情について良く知らないという読者の方は、以下の記事（調査レポートと参考文献含む）をご一読ください：
しかし、情報を伝えるにあたって「フォントによってマフラーの有無が異なる」というのは不都合でしょう。また逆に、ゆきだるまが Unicode にたった3人しかいないのは不満だという意見もあるでしょう。（ちなみに私は「ゆきだるまが足りない」派で、Unicode に「追加ゆきだるま面 (Additional Snowman Plane)」くらいあってもよいと思っています☃）
この両者の不満を解消すべく、画期的なパッケージを開発しました。
*1:えっ、☃なんて人名に使えない？ それは心の中でのツッコミにとどめてこの記事を楽しんでください☃⛄⛇
*2:最初に Unicode 1.0 が策定されたときの "U+2603 SNOWMAN" の例示グリフは、モリサワのリュウミン（IPA明朝とほぼ同じ）でした。そのグリフデザインを踏襲したのでしょう。
MOPAC で分子のアニメーションを作成して JSmol で観察する
“回答を得やすい質問” と “良い報告” のコツ — ソフトウェア開発を例に
私は最近「日本語 TeX 開発コミュニティ」などのメーリングリストに参加していますので、ここでは LaTeX を例に説明しますが、これはいかなる技術系コミュニティにも当てはまることだと思います。私なりの「技術系コミュニティへの貢献・レポートのコツ」として、ここにまとめることにします。あくまで “理想論” といってしまえばそれまでですが、一部は参考になるかもしれません。
タイトルに「“回答を得やすい質問” と “良い報告” のコツ」と書きました。この2つのポイントはほぼ同じです。みなさんも、学校の授業で質問する場合にまず「自分がどこまでわかっているかを理解し、それを人に伝える」ところから始めると良い回答が得られたという経験があると思います。それと同じことで、ソフトウェアを使っていて疑問に思ったこと・期待どおりにならなかったことを他人に質問する場合にも同じような心がけが必要です。良い質問をするコツは良い報告をするコツと多くを共有していますので、ここでは私の経験をもとに “私が考える良い報告とは” を考えていきます。
LaTeX などのソフトウェアを使っていると、ときどき「これは意図した動作なのだろうか？」「ここがもしこうだったらよいのに」「こういう場合にも対応してほしい」のように思うコトがあります。そのような場合に、「これはそういうものだからしょうがない」として泣き寝入りするのも一つの手ですが、これを上流（＝開発者）に報告したいと思うことがあります。
報告するメリットはいうまでもありません：
- 新しい機能が追加される
- 嬉しくない挙動が改善される
このようなことは、良いレポートがあって初めて成立します。「良いソフトウェアを使わせていただいているのだから、できる範囲で自分も開発に貢献する」、それが特にオープンソースのソフトウェアを利用する上でのマナーといっても過言ではないと私は考えています。
では、良いレポートとは何でしょうか？ それは、「開発者に具体的に再現してもらえるように、状況を詳しく説明する」ことから始まります。まずはレポートする前になにを考えるべきか5つの観点からみていき、それに続いて実際にレポートするにあたっての注意点を述べてみます。これはあくまで私の経験にすぎませんが、だいたいの場合成功していると思います。
続きを読む
LaTeX で PDF の一部だけ表示したい(3)
TeX Live 2015 時点での「PDF の BoundingBox」まとめ
第1回・第2回の更新から実に3か月が空いてしまいました… ほかの作業*1に追われておりました。この長いブランク（というより、第1回・第2回の記事を公開した直後の一週間以内）に、この PDF の BoundingBox 問題に大きな進展がありました。このことについて説明する前に、改めて TeX Live 2015 時点での BoundingBox の扱いについてまとめると以下のようになります：
- pdfLaTeX：デフォルトは CropBox である。pagebox オプションを使えば好きな Box を選択できる。これらを bb= で上書きすることはできないが、これは間違いを起こさないという点で安全で、最も理想的な状態。
- LuaLaTeX：デフォルトは CropBox である。現時点では pagebox オプションを使えず、bb= で上書きすることもできないので「常に CropBox である」。pagebox オプションさえ使えるようになれば理想的（つまり pdftex.def の改修が必要）。
- XeLaTeX：デフォルトは CropBox である。現時点では pagebox オプションを使えないが、bb= で上書きすることは可能。pagebox オプションさえ使えるようになれば理想的*2。
- dvipdfmx：「CropBox → ArtBox → TrimBox → BleedBox → MediaBox の順で明示されている最初のもの」を使う。pagebox オプションは使えないが、bb= で上書きすることは可能。これは改善の余地が相当あるといってよい。
- いずれにおいても、viewport= オプション単独指定の場合は「自動取得された正しい BoundingBox 値と、そこからの相対座標」によって期待どおりの出力が得られる。
のようになります。見てのとおり、dvipdfmx はかなり深刻です。bb= で上書きできることは諸刃の剣で、良く知っているユーザなら自分で好きな ﾅﾝﾄｶBox を指定するインタフェースになりうるのですが、そうでない場合はマチガッタ使い方の温床になります。実際、bb= をまるで viewport= かのように使った失敗例は数多く、それに ZR さんが警鐘を鳴らしてきたわけです。
続きを読む