投稿者「mod_poppo」のアーカイブ

Bamboo Slate を買った

コメントを残す

現代の情報化社会に生きる我々にとって、電子的にノートを取りたい、あるいは、手軽にノートを電子化したい、というのは自然な欲求である。

最近だと iPad Pro + Apple Pencil を使っている人をちらほら見かけるが、 iPad Pro は高い。iPad Pro 12.9インチモデル + Apple Pencil を買うと、最低でも10万円は超える。9.7インチモデルはもう少し安いが、A4の半分程度のサイズなので狭そう。

そんな中、筆者のアンテナに留まったのが、最近出た、ワコムの Bamboo Slate という製品である。バインダーみたいな板 (Slate) の上に紙を置いて、専用のボールペンで書くと、紙のノートに加えて電子的なノートも取れる。

Bamboo Slate は、一年くらい前から発売されている Bamboo Spark というやつの姉妹品らしい。Slate には Spark と比べて

  • でかい。Spark はA5サイズなのに対し、 Slate はA5サイズとA4サイズの2種類がある。なお、 Spark のような2つ折り形態でA4サイズの製品としては、 Slate と同時に発表された Bamboo Folio がある。
  • 軽い。Spark は一番軽いやつでも 535g なのに対し、Slate はA5モデルが 264g で、A4モデルが472g である。
  • 薄い。2つ折りとかいいから、とにかく薄いのをくれ。

というメリットがある。以前量販店で見かけた Spark では筆者の食指は動かなかったので、これらの点は大切なのだろう。 続きを読む →

LaTeX 文書から処理系を推定する（主に日本語）

1件のフィードバック

前回の記事では、 LaTeX 文書にマジックコメントとして処理系やメインファイルを記述するやり方について書いた。今回は、マジックコメントがない場合に処理系を推定する方法について考える。

LaTeX 文書の処理系（エンジン）には色々あるが、このブログの読者が使うのは次の6種類のうちのどれかだろう（最近はデフォルトで e-TeX 拡張が使えるみたいなのでその辺の細かい区別は必要ない）

  • pdfLaTeX
  • XeLaTeX
  • LuaLaTeX
  • LaTeX + dviware (e.g. dvipdfmx)
  • pLaTeX + dviware (e.g. dvipdfmx)
  • upLaTeX + dviware (e.g. dvipdfmx)

（この他に、最近は pTeX-ng なる代物もあるらしいが、筆者はよく知らないのでこの記事では無視する）

日本語の場合は、文書が特定の処理系専用になることが多く、ドキュメントクラス等を調べることによって判別できる（できてしまう）ことが多い。逆に、欧文の文書を pdfLaTeX, XeLaTeX, LuaLaTeX のどれで処理すべきか判別するのは難しいと思われる（まあ、「どれでも処理できる」のであればデフォルトの処理系で処理するというので問題ないのだが）。

ドキュメントクラスから処理系を判定する

日本語の文書向けのドキュメントクラスは、特定の処理系専用に作られているか、もしくはクラスオプションで処理系を指定するようになっていることが多い。

pLaTeX 用：

  • jarticle, jbook, jreport
  • tarticle, tbook, treport
  • jsarticle, jsbook (without ‘uplatex’ option)

upLaTeX 用：

  • ujarticle, ujbook, ujreport
  • utarticle, utbook, utreport
  • jsarticle, jsbook (with ‘uplatex’ option)

LuaTeX 用 (LuaTeX-ja) :

  • ltjarticle, ltjbook, ltjreport
  • ltjsarticle, ltjsbook
  • ltjtarticle, ltjtbook, ltjtreport

BXjscls:

  • bxjsarticle, bxjsbook, bxjsreport, bxjsslide
  • クラスオプションとして処理系を指定： latex,platex,uplatex,lualatex,xelatex,autodetect-engine のいずれか
  • DVI 出力の場合、クラスオプションとして dviware を指定： dvips,dviout,xdvi,dvipdfmx のいずれか
  • autodetect-engine が使用されていた場合は、文書から処理系を判定することはできない。

もちろん、これらのドキュメントクラス自体の改訂によってこの辺りの仕様が変わる可能性があり、今後もずっとこの判定方法に頼れるとは限らない。（実際、この記事を書いている間に jsclasses に autodetect-engine が実装されてしまった）

使うパッケージによって処理系を判定する

日本語文書であっても、例えば Beamer を使う場合は、ドキュメントクラスからエンジンの推定はできない。しかし、そのような場合でも、使うパッケージによってエンジンを判定できる場合がある。

  • minijs, okumacro, jsverb, okuverb, pxjahyper, etc: (u)pTeX 専用
  • luatexja, luatexja-ruby, luatexja-otf, luatexja-preset: LuaTeX 専用
  • xltxtra, xeCJK, zxjatype: XeTeX 専用
    • xltxtra パッケージは fontspec パッケージに取って代わられたようなので、見かけることは少ないかもしれない。
  • fontspec, unicode-math: XeTeX または LuaTeX
  • 以前このブログで言及した filemod パッケージは pdfTeX または LuaTeX を必要とするものだった。（しかし、広く使われているとは思えないので、判定には利用できないだろう）

もっと色々あるだろうが、網羅的に列挙しても仕方がないので、このぐらいにしておく。

ドキュメントクラスと同じく、パッケージについても、仕様の変化や代替パッケージの登場によって、ここに書いた情報が古くなっていく可能性がある。

雑感

このような heuristics はやはり筋が悪い気がしてきたし、確実な動作を望むなら、前回書いたような方法でユーザーが明示的に指定するべきだろう。

それでもこの記事に書いたような方法で処理系の推定を行いたいのであれば、なるべく最新の動向を追いかけるようにしたい。

TeX 文書の Magic Comment

この記事では、 TeX 文書におけるマジックコメントの種類と構文についてまとめてみた。

マジックコメントとは

プログラムのソースコードというのは、プログラミング言語の処理系（実行環境）向けに書かれているものである。しかし、テキストエディターなどの周辺ツールは、そのソースコードについて、処理系が必要とする以上の情報が欲しいことがある。そういう場合に、追加の情報をソースコードのコメントとして記述してやって、周辺ツールに与えてやるということがよく行われる。このようなコメントは、俗に、マジックコメントと呼ばれる。

「追加の情報」の中で典型的なものが、文字コードである。Emacs で編集されるソースコードに -*- coding: utf-8 -*- と書かれたコメントがあるのを見たことがある方も多いだろう。

（ちなみに、 Python や Ruby などの一部のスクリプト言語処理系は、マジックコメントによってファイルの文字コードを判定する場合がある。つまり、コメントとして書かれたものが処理系にとってい意味を持つ。） 続きを読む →

Xcode/Cocoaで始めるモダンOpenGL

モダンなOpenGLを勉強したいと思い立ったので、「OpenGL 4.0 シェーディング言語 実例で覚えるGLSLプログラミング」（原著は OpenGL 4 Shading Language Cookbook）という本で少しずつ勉強している。

OpenGL自体はグラフィックスに関するAPIなので、アプリケーションやウインドウの初期化、画像の読み込み等は各プラットフォームで使えるGUIツールキットの力を借りることになる。この本のサンプルコードではQt（キュート）を使っているが、GitHubにあるサンプルコードではGLFWを使っている。

筆者としては、Cocoaで書いているMac向けのアプリケーションでOpenGLを使いたいという目標があるため、サンプルコードもCocoaアプリケーションに組み込む形で試すことにした。 続きを読む →

macOS向けのwxMaximaを自分でビルドする

コメントを残す

wxMaxima とは、数式処理システム Maxima をGUIで使えるようにしたソフト（フロントエンド）である。Windows, macOS, Linux の各プラットフォームに対応する。Maxima のGUIフロントエンドの中では最もポピュラーかと思われる。

しかし、macOS 向けにリリースされているバイナリのバージョンは 15.04.0 （記事執筆時点）と、少々古い。そこで、最新版 (16.04.2) を自分でビルドしてみよう。

この記事は、ターミナルの操作に慣れていてソフトウエアのビルドもできる人向けとなる。wxMaxima や wxWidgets 特有の事情については記事の中でなるべく説明しているので知らなくても問題ない。

続きを読む →

TypeScript における let/const と control flow based type analysis

前にこのブログの記事に書いたように、TypeScript 1.4以降(ターゲットがES5の場合は1.5以降)では let/const による変数宣言ができるようになった。let は書き換え可能な変数で、const は書き換え不可能な変数だ。let 宣言と const 宣言の登場によって、var 宣言は用済みになったと言っていいだろう。

let も const もスコープに関する規則は同じなので、書き換えない変数に対して let と const のどちらを使っても違いはないはず。そう思って、個人的に書いているコードでは文字数を重視して常に let の方を使っていた。

しかし、 TypeScript 2.0 で導入された control flow based type analysis により、「書き換えない変数に対して let と const のどちらを使っても違いはない」とは言ってられなくなった。 続きを読む →

Haskell (GHC) の型レベル自然数とリフレクションを試してみる

コメントを残す

【2020年4月20日追記】GHCの型レベル自然数については、より網羅的な記事を書いた。型レベル自然数についてより詳しく知りたい方は、こちらの記事も参照いただきたい：GHCの型レベル自然数を理解する【追記終わり】

最近のGHCでは、自然数をパラメーターとするデータ型を定義できる。固定長リストの長さを型に持たせるとか、行列の大きさを型に持たせるとか、そういうことができる。あるいは、自然数 m に対して Z/mZ を表す型を作ることもできる。m を素数とすればこれは有限体となる。

実際に、型レベル自然数を使って Z/mZ に相当する型を作ってみよう。（名前は FiniteField とした） 続きを読む →

駅名に「地下鉄」をつけると地下鉄の駅になる

※なりません

評価のポイント

当てはまる数が多いほどポイントが高い。

  • 本物の地下鉄が近くにないこと。
  • 同じ地名を冠する地上駅が近くにあること。
  • 当該地下駅と「同じ地名を冠する地上駅」とは、それほど一体的ではないこと。
  • 地上の鉄道路線と地下の鉄道路線がある程度並走していること。

続きを読む →