f

2015-12-29

XML宣言の正しい書き方:<?xml version="1.0" encoding="UTF-8"?>

XML文書を作成するとき、ファイルの1行目に以下のようなXML宣言(XMLDecl)を記述することが推奨されている。

<?xml version="1.0" encoding="UTF-8"?>

しかし、ここで以下の5の疑問が生じる。

  1. そもそもこのXML宣言は必要なのか?
  2. versionの値は何を使うべきか?
  3. encodingの値は何を使うべきか?
  4. standalone属性は省略して問題ないのか?
  5. XML宣言の終端である?>の直前に空白を入れるべきか?

これらの疑問を解消し、最も推奨される正しいXML宣言を書き方に関する根拠を得るためにXML 1.0(第五版)の勧告文書を調べた。

結論からいうと、XML文書には冒頭に書いたものと同じ以下の内容をファイルの1行目に書くべきだ。

<?xml version="1.0" encoding="UTF-8"?>

XML宣言は書くべきだし、versionとencodingの値もこの通りにし、standalone属性は省略すべきだ。

以下では勧告文書を調べて得られた結論と根拠を示す。

XML宣言(XMLDecl)の定義

XML 1.0(第五版)の勧告文書により、XML文書とは以下の3条件を満たす(整形式である)文書である。

  1. document生成規則にマッチ。
  2. 全ての整形式性制約を満たす。
  3. 文書中で参照される解析対象実体が整形式である。

参照元:2.1 整形式のXML文書 Well-Formed XML Documents

ここで、2.と3.に登場した[整形式性制約]と[解析対象実体]はXML宣言と関係ないので説明は省略し、document生成規則について説明する。

document生成規則とは、以下のバッカス・ナウア記法(EBNF:Extended Backus-Naur Form)で定義される。なお、EBNF自体も6 仕様書の記法 Notationで定義されている。

document ::= ( prolog element Misc* )

これが意味することは以下である。

  • 要素の前にプロローグ(prolog)が存在。
  • 一つ以上の要素(element)を含む。
  • ルート要素が一つだけ存在すること。

elementとMiscの説明はXML宣言と関係ないので省略する。

プロローグ(prolog)とは、ドキュメントの開始タグつまりルート要素の前に存在する情報を指す。プロローグには、文字エンコーディングなどドキュメント全体に適用される情報が含まれる。XML宣言はプロローグに含まれる。

プロローグは以下で定義される(2.8 プロローグと文書型宣言 Prolog and Document Type Declaration)。

prolog ::= XMLDecl? Misc* ( doctypedecl Misc* )?
XMLDecl ::= '<?xml' VersionInfo EncodingDecl? SDDecl? S? '?>'

XML宣言とは上記のプロローグの定義で登場するXMLDeclのことである。XML宣言という言葉については以下の定義がある。

[Definition: XML文書は、使われるXMLのバージョンを指定するXML宣言から始まる事が望ましい(SHOULD)。 ]

[Definition: XML documents SHOULD begin with an XML declaration which specifies the version of XML being used.]

参照元: 2.8 プロローグと文書型宣言 Prolog and Document Type Declaration - Extensible Markup Language (XML) 1.0 (第五版)

ここでの定義から、「XML宣言とは、XML文書に使われるXMLのバージョンを指定する宣言のこと」と解釈できる。

prologの定義でXMLDecl?とあるように、XMLDeclは0回以上存在すればよいので必須ではない。しかし、上記でXML宣言の記述が推奨されているため、書くべきである。

XML宣言(XMLDecl)は上記定義より以下の部品から構成されている。

'<?xml'VersionInfoEncodingDecl?SDDecl?S?'?>'

なお、ここでEncodingDeclSDDeclSは末尾に?が付いているので必須ではない。したがって、最小限のXML宣言は以下のようになる。

<?xml version="1.0"?>

以下ではこれらのXML宣言の各部品について説明していく。

'<?xml''?>'S?

まず、説明が簡単な'<?xml''?>'だ。これらはそのまま文字列として記述する。

次に、S?だ。

Sはホワイトスペースのことであり、一つ以上のスペース文字(#x20)、キャリッジリターン(#xD)、ラインフィード(#xA)、タブ(#x9)から構成される。2.3 一般的な構文構成子 Common Syntactic Constructsで以下の内容で定義される。

S ::= ( #x20 | #x9 | #xD | #xA )+

XML宣言ではS?と表記されているため、'?>'の直前に配置されるホワイトスペースはあってもなくてもよい。

VersionInfo

VersionInfoはXMLDeclのすぐ下で定義されている。

VersionInfo ::= S 'version' Eq ( "'" VersionNum "'" | '"' VersionNum '"' )
Eq ::= S? '=' S?
VersionNum ::= '1.' [0-9]+

この定義により、version="1.0"version = '1.012'のような書き方が許可されている。

VersionNum生成規則は'1.x'の形であればあらゆるバージョン番号にマッチするが、XML 1.0文書が'1.0'以外のバージョン番号を指定する事は望ましくない(should not)。

Even though the VersionNum production matches any version number of the form '1.x', XML 1.0 documents should not specify a version number other than '1.0'.

参照元:2.8 プロローグと文書型宣言 Prolog and Document Type Declaration - Extensible Markup Language (XML) 1.0 (第五版)

また、現在XMLはXML 1.0とXML 1.1の2種類が存在する。しかし、以下の4点の理由からXMLのバージョンには"1.0"を選択するべきだ。

  1. XML 1.1固有の機能が必要とされる場面が極めて少ない
  2. XML 1.1の勧告でプログラムはXML 1.0を生成することが望ましいと記述されている
  3. XML 1.1はXML 1.0へ基本的に後方互換性がある
  4. XML 1.1の機能の一部はXML 1.0第五版にバックポートされている

参照元:My Future Sight for Past: XMLのバージョンに1.1ではなく1.0を使うべき4の理由

EncodingDecl?

EncodingDeclはエンコーディング宣言(EncodingDecl)である。エンコーディング宣言の役割は以下で示されている。

XMLのエンコーディング宣言は、それぞれの実体の内部ラベルとして機能し、どの文字エンコーディングが使われているかを示す。

The XML encoding declaration functions as an internal label on each entity, indicating which character encoding is in use.

参照元:F 文字エンコーディングの自動検知(非規範的) Autodetection of Character Encodings (Non-Normative)

このことから、「エンコーディング宣言とは、XML文書で使われている文字エンコーディングを知らせる宣言のこと」と解釈できる。EncodingDeclの定義は以下で示される。

EncodingDecl ::= S 'encoding' Eq ( '"' EncName '"' | "'" EncName "'" )
EncName ::= [A-Za-z] ( [A-Za-z0-9._] | '-' )"

文書実体では、エンコーディング宣言はXML宣言の一部である。EncNameは、使われているエンコーディングの名前である。

In the document entity, the encoding declaration is part of the XML declaration. The EncName is the name of the encoding used.

参照元:4.3.3 実体で使われる文字エンコーディング Character Encoding in Entities

XML文書は以下で示されるようにUTF-8かBOMあり(後述)のUTF-16を既定の文字エンコーディングとしている。これら以外の文字エンコーディングである場合、エンコーディング宣言は必須である。

外部の文字エンコーディング情報(MIMEヘッダなど)が無いのであれば、UTF-8とUTF-16以外のエンコー ディン グで記録された解析対象実体は、エンコーディング宣言を含むテキスト宣言(4.3.1 テキスト宣言 The Text Declaration参照)から始まらなければならない(must)。

In the absence of external character encoding information (such as MIME headers), parsed entities which are stored in an encoding other than UTF-8 or UTF-16 must begin with a text declaration (see 4.3.1 The Text Declaration) containing an encoding declaration:

参照元:4.3.3 実体で使われる文字エンコーディング Character Encoding in Entities

UTF-8とUTF-16はバイトオーダーマーク(BOM:Byte Orger Mark)をつけることができる。以下で示されるように、XML文書ではUTF-8のBOMはあってもなくてもよいが、UTF-16のBOMは必須である。

UTF-16でエンコードされた実体は、[ISO/IEC 10646:2000]の付録Hや、Unicode [Unicode]のセクション16.8で説明されているバイトオーダーマーク(Byte Order Mark、BOM。ZERO WIDTH NO-BREAK SPACE文字(#xFEFF)の事)から始まらなければならない(must)。UTF-8でエンコードされた実体は、バイトオーダーマークから始まっても良い(may)。

Entities encoded in UTF-16 must and entities encoded in UTF-8 may begin with the Byte Order Mark described by Annex H of [ISO/IEC 10646:2000], section 16.8 of [Unicode] (the ZERO WIDTH NO-BREAK SPACE character, #xFEFF).

参照元:4.3.3 実体で使われる文字エンコーディング Character Encoding in Entities

文字エンコーディングにUTF-8とBOMありUTF-16を使えば、エンコーディング宣言を省略できるが、以下で示されるように将来のことを考えて指定したほうがよい。

また、現在はエンコーディング方法を決める為にエンコーディング宣言を使う事が必要とされない場合もあるが、将来的にはそれらの場合でもエンコーディング宣言が必要になるような新しい文字エンコーディングが作られる事もあり得る。

Also, it is possible that new character encodings will be invented that will make it necessary to use the encoding declaration to determine the encoding, in cases where this is not required at present.

参照元: F.1 外部エンコーディング情報を使わない検知 Detection Without External Encoding Information - Extensible Markup Language (XML) 1.0 (第五版)

また、XML文書の文字エンコーディングには"UTF-8"を使うのがいい。理由は以下2点だ。

  • UTF-8だとBOMがあってもなくてもよいため。UTF- 16は必ずBOMが必要なのでユーザー側での設定が紛らわしい。
  • 以下で文書の交換においてUTF-8が推奨されている。

エンコーディング宣言では、値"UTF-8"、"UTF-16"、"ISO-10646-UCS-2"、及 び"ISO- 10646-UCS-4"は、UnicodeとISO/IEC 10646の様々なエンコーディングやトランスフォーメーションに対して使われる事が望ましい(should)。

In an encoding declaration, the values "UTF-8", "UTF-16", "ISO-10646-UCS-2", and "ISO-10646-UCS-4" should be used for the various encodings and transformations of Unicode / ISO/IEC 10646.

参照元:4.3.3 実体で使われる文字エンコーディング Character Encoding in Entities

XMLパーサーが文字エンコーディングの判定を楽にできるようにUTF-8で書いたXML文書であっても encoding="UTF-8"は書いておこう。

SDDecl?

SDDeclはスタンドアローン文書宣言(SDDecl)である。

スタンドアローン宣言という言葉には以下の定義がある。

スタンドアローン文書宣言はXML宣言の構成要素として現れる事があり、文書実体の外や、パラメータ実体の中に、文書の内容に影響するような宣言があるかどうかを知らせる。

The standalone document declaration, which may appear as a component of the XML declaration, signals whether or not there are such declarations which appear external to the document entity or in parameter entities.

参照元: 2.9 スタンドアローン文書宣言 Standalone Document Declaration - Extensible Markup Language (XML) 1.0 (第五版)

このことから、「スタンドアローン宣言とは、XML文書が単一ファイルとして独立しているかどうかを知らせる宣言のこと」 と解釈できる。上記定義で は「文書の内容に影響するような」とあるように、文書の内容に影響がなければ、たとえ外部に宣言があっても無視すると解釈できる。

スタンドアローン宣言(SDDecl)は以下で定義される。

SDDecl ::= S 'standalone' Eq ( ( "'" ( 'yes' | 'no' ) "'" ) | ( '"' ( 'yes' | 'no' ) '"' ) )

例:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

スタンドアローン宣言の属性値はyesnoがあり、以下の意味となる。

  • yes:外部マークアップ宣言が存在しないことを示す。
  • no:外部マークアップ宣言が存在するか、存在するかもしれないことを示す(既定値)。

スタンドアローン宣言の属性については以下の説明がある。

外部マークアップ宣言が一切無ければ、スタンドアローン文書宣言は何ら意味を持たない。外部マークアップ宣言はあるもののスタンドアローン文書宣言が無い時は、値"no"が指定されたものと見なされる。

If there are no external markup declarations, the standalone document declaration has no meaning. If there are external markup declarations but there is no standalone document declaration, the value "no" is assumed.

参照元: 2.9 スタンドアローン文書宣言 Standalone Document Declaration - Extensible Markup Language (XML) 1.0 (第五版)

また、スタンドアローン宣言について解説された記事において以下の解説がある。

standalone="yes"の文書が外部のファイルを参照することはありえないので、yesとnoを区別する必要がない。

つまり、事前に外部への参照の必要性が判明していれば、それによって処理を最適化できる可能性があるということだ。

参照元:XMLを学ぼう(9):Standaloneと究極の外部非依存文書 - @IT

XML 1.0において、スタンドアローン宣言(SDDecl)はXML宣言(XMLDecl)でしか使われず、外部マークアップ宣言が存在すれば自動 的に必要な設定であるstandalone="no"が設定されるので、明示的に書く必要がない。したがって、パフォーマンスを最適化する必要があるときだけ、必要に応じて明示的にyes|noを設定すればよい。

Q&A

前節までで、XML宣言の各部品の説明と、書くべき内容について説明してきた。ここでは、冒頭で掲げた5の疑問にQ&A形式で回答していく。また、その際に重複になるが根拠となる勧告文書の該当箇所も掲載した。

Q1. XML宣言を書くべきか?

A1. XML宣言は書くべき。勧告文書でXML宣言の記述が推奨されており、XML文書のバージョンと文字エンコーディングを明確にできる。また、XML宣言によりXMLパーサーに必要な情報が渡され正常な動作を期待しやすい。

根拠1-1:

[Definition: XML文書は、使われるXMLのバージョンを指定するXML宣言から始まる事が望ましい(SHOULD)。 ]

[Definition: XML documents SHOULD begin with an XML declaration which specifies the version of XML being used.]

参照元: 2.8 プロローグと文書型宣言 Prolog and Document Type Declaration - Extensible Markup Language (XML) 1.0 (第五版)

Q2. XML宣言のversionには何を使うべきか?

A2. 1.0を使い、version="1.0"とすべき。

根拠2-1:XML 1.0文書で書くならば1.0とすべき。

VersionNum生成規則は'1.x'の形であればあらゆるバージョン番号にマッチするが、XML 1.0文書が'1.0'以外のバージョン番号を指定する事は望ましくない(should not)。

Even though the VersionNum production matches any version number of the form '1.x', XML 1.0 documents should not specify a version number other than '1.0'.

参照元:2.8 プロローグと文書型宣言 Prolog and Document Type Declaration - Extensible Markup Language (XML) 1.0 (第五版)

根拠2-2:XML 1.1(第二版)ではXMLの生成プログラムはXML 1.0を生成することを推奨している。

XMLを生成するプログラムは、 XML 1.1特有の機能が必要とされない限り、 XML 1.0を生成する事が望ましい(SHOULD)。

Programs which generate XML SHOULD generate XML 1.0, unless one of the specific features of XML 1.1 is required.

参照元: 5.1 妥当性を検証するプロセッサとしないプロセッサ Validating and Non-Validating Processors - Extensible Markup Language (XML) 1.1 (第二版)

Q3. XML文書の文字エンコーディングとXML宣言のencodingの値は何を選べばよいか?

A3. XML文書の文字エンコーディングはUTF-8にすべき。また、XML宣言のencoding属性は省略せずにencoding="UTF-8"と記述すべき。

根拠3-1:XML文書の文字エンコーディングをUTF-8にすべき理由1。

エンコーディング宣言では、値"UTF-8"、"UTF-16"、"ISO-10646-UCS-2"、及 び"ISO-10646-UCS- 4"は、UnicodeとISO/IEC 10646の様々なエンコーディングやトランスフォーメーションに対して使われる事が望ましい(should)。

In an encoding declaration, the values "UTF-8", "UTF-16", "ISO-10646-UCS-2", and "ISO-10646-UCS-4" should be used for the various encodings and transformations of Unicode / ISO/IEC 10646.

参照元:4.3.3 実体で使われる文字エンコーディング Character Encoding in Entities - Extensible Markup Language (XML) 1.0 (第五版)

根拠3-2:XML文書の文字エンコーディングをUTF-8にすべき理由2。

XML文書をUTF-16でエンコーディングするときは、必ずバイトオーダーマーク(BOM:Byte Order Mark)が必要である。しかし、UTF-8には、BOMがあってもなくてもよい。つまり、UTF-8の方が受けが広くユーザーに優しい。

UTF-16でエンコードされた実体は、[ISO/IEC 10646:2000]の付録Hや、Unicode [Unicode]のセクション16.8で説明されているバイトオーダーマーク(Byte Order Mark、BOM。ZERO WIDTH NO-BREAK SPACE文字(#xFEFF)の事)から始まらなければならない(must)。UTF-8でエンコードされた実体は、バイトオーダーマークから始まっても良い(may)。

Entities encoded in UTF-16 must and entities encoded in UTF-8 may begin with the Byte Order Mark described by Annex H of [ISO/IEC 10646:2000], section 16.8 of [Unicode] (the ZERO WIDTH NO-BREAK SPACE character, #xFEFF).

参照元:4.3.3 実体で使われる文字エンコーディング Character Encoding in Entities - Extensible Markup Language (XML) 1.0 (第五版)

根拠3-3:XML宣言のencoding属性を省略すべきでない理由。

また、現在はエンコーディング方法を決める為にエンコーディング宣言を使う事が必要とされない場合もあるが、将来的にはそれらの場合でもエンコーディング宣言が必要になるような新しい文字エンコーディングが作られる事もあり得る。

Also, it is possible that new character encodings will be invented that will make it necessary to use the encoding declaration to determine the encoding, in cases where this is not required at present.

参照元: F.1 外部エンコーディング情報を使わない検知 Detection Without External Encoding Information - Extensible Markup Language (XML) 1.0 (第五版)

Q4. XML宣言のstandalone属性は書くべきか?

A4. パフォーマンスが重要な用途でない限り、XML宣言のstandalone属性は書くべきでない。

根拠4-1:

外部マークアップ宣言が一切無ければ、スタンドアローン文書宣言は何ら意味を持たない。外部マークアップ宣言はあるもののスタンドアローン文書宣言が無い時は、値"no"が指定されたものと見なされる。

If there are no external markup declarations, the standalone document declaration has no meaning. If there are external markup declarations but there is no standalone document declaration, the value "no" is assumed.

参照元: 2.9 スタンドアローン文書宣言 Standalone Document Declaration - Extensible Markup Language (XML) 1.0 (第五版)

Q5. XML宣言の終端である?>の直前に空白を入れるべきか?

A5. XML宣言の終端である?>の直前には空白を入れない方がいい。この位置での空白は完全に任意であり、あってもなくてもかまわない。勧告文書ではこのような属性や値に使われない空白をどうすべきかについて明記されていない。

しかし、勧告文書で掲載されている例では以下の2例を除き、省略可能なホワイトスペースは基本的に省略されていた。

  1. 勧告文書で掲載されているXML宣言の例では、終端に空白が存在する例は全7個中1個しかなかった。
  2. XML宣言の終端と同様にあってもなくてもよい空白をもつEqの例(記号=の前後の空白)では、前後の空白が存在する例が全27個中1個しかなかった。

このことから、勧告文書としては、基本的に省略可能なホワイトスペースは省略すべきという方針が伺える。したがって、この方針にのっとりXML宣言の終端の空白は入れないほうがいいだろう。

根拠5-1:XML 1.0(第五版)の勧告文書でXML宣言の例として終端にホワイトスペースがある唯一の例。

<?xml version="1.0" encoding="UTF-8" ?>
                    <!DOCTYPE greeting [ <!ELEMENT greeting (#PCDATA)>
                    ]>
                    <greeting>Hello, world!</greeting>

参照元: Extensible Markup Language (XML) 1.0 (Fifth Edition)

根拠5-2:XML 1.0(第五版)の勧告文書でEqが使われている例全27個中ホワイトスペースがある唯一の例。

a= "&#xd;&#xd;A&#xa;&#xa;B&#xd;&#xa;"
参照元:Extensible Markup Language (XML) 1.0 (Fifth Edition)

結論

結論として、最も推奨されるべき正しいXML宣言は、冒頭に示したとおり以下の内容をファイルの1行目に記述することだ。

<?xml version="1.0" encoding="UTF-8"?>

そしてXML文書の文字エンコーディングをUTF-8する。これにより、どんなXML文書でも通用するXML宣言を記述できる。

2015-12-26

XMLのバージョンに1.1ではなく1.0を使うべき4の理由

現在XMLにはXML 1.0とXML 1.1の二つのバージョンがある。どちらを使うべきか調査すると、XML 1.0を使うべきだとわかった。

XML 1.1ではなくXML 1.0を使うべき理由は以下の4点だ。

  1. XML 1.1固有の機能が必要とされる場面が極めて少ない
  2. XML 1.1の勧告でプログラムはXML 1.0を生成することが望ましいと記述されている
  3. XML 1.1はXML 1.0へ基本的に後方互換性がある
  4. XML 1.1の機能の一部はXML 1.0第五版にバックポートされている

XML 1.1固有の機能が必要とされる場面が極めて少ない

まず、XML 1.0と1.1の違いを調べた。このバージョン間の違いはXML 1.1(第二版)の1.3 XML 1.1での変更点とその原理的説明 Rationale and list of changes for XML 1.1に書かれている。

XML 1.1での変更点は主に要素名や属性値で使える文字の拡大である。Unicodeでまだ割り当てられていない文字も含めほとんど全ての文字を使えるようになった。XML 1.0は1998年に勧告が発表された。この当時にXML 1.0が頼っていた文字集合の定義はUnicode 2.0である。Unicode 2.0に登場しない文字でも要素の値としては使えるが、属性名などには使えなかった。

上記のXML 1.1の新機能を踏まえて、以下の記事でXML 1.1の必要性について意見が書かれている。

@IT:特集:XML 1.1を分析する Page3

ここで書かれている通り、XML 1.1固有の機能が必要であったり有用である場面は限定的であり、利用頻度が極めて少ない。

XML 1.0の時点で要素名に日本語を使うことはできており、日本人であれば名前文字の拡大は特に影響がない。万が一問題があるならば、英語で表記すれば事足りてしまう。

XML 1.1の勧告でプログラムはXML 1.0を生成することが望ましいと記述されている

先ほど参照した@IT:特集:XML 1.1を分析する Page3で以下のようにXML 1.1の勧告でXML 1.0の文書を生成することが望ましいと書いてある。

XMLを生成するプログラムは、 XML 1.1特有の機能が必要とされない限り、 XML 1.0を生成する事が望ましい(SHOULD)。

Programs which generate XML SHOULD generate XML 1.0, unless one of the specific features of XML 1.1 is required.

引用: 5.1 妥当性を検証するプロセッサとしないプロセッサ Validating and Non-Validating Processors

このように、XML 1.1としてもXML 1.0の利用を推奨しているように解釈できる。

XML 1.1はXML 1.0へ基本的に後方互換性がある

XML 1.1の勧告文書で以下の記述がある。

もしある文書が整形式のXML 1.0文書、あるいは妥当なXML 1.0文書であり、なおかつ文書が[#x7F-#x9F]の範囲の制御文字を(文字エスケープを使う場合は別として)一切含まない場合、その文書は、単にバージョン番号を変える事で、それぞれ整形式のXML 1.1文書、あるいは妥当なXML 1.1文書になる事もできる。

If a document is well-formed or valid XML 1.0, and provided it does not contain any control characters in the range [#x7F-#x9F] other than as character escapes, it may be made well-formed or valid XML 1.1 respectively simply by changing the version number.

引用:2.8 プロローグと文書型宣言 Prolog and Document Type Declaration

このことから、基本的にXML 1.1はXML 1.0と後方互換性があり、XML 1.0の文書宣言において以下のようにversion="1.0"version="1.1"に変更すればよい。

<?xml version="1.0" encoding="UTF-8" ?>
<?xml version="1.1" encoding="UTF-8" ?>

XML 1.1の機能の一部はXML 1.0第五版にバックポートされている

XML 1.0はXML 1.1の勧告が発表された後にも更新されており、2008-11-26にXML 1.0第五版の勧告が発表されている。更新内容はXML 1.0第五版で以下のように書かれている。

この第五版は、XMLの新しいバージョンではない。読者の簡便の為、2006年8月16日に公開されたXML 1.0 (第四版)で報告され、集積された正誤情報(http://www.w3.org/XML/xml-V10-4e-errata)をまとめ、修正を反映したものである。特に、正誤情報[E09]に基づく修正は、要素や属性の名前における制限を緩和するものであり、これによって、これまでXML 1.1を使う事でしか得られなかった恩恵が、XML 1.0においても大多数のエンドユーザにもたらされる事となる。この結果、この仕様の以前の版に拠ると整形式でないとされてきた多くの文書でも、今では整形式となり得る。また、今回新しく許されるようになった(以前の版では許されていなかった)名前文字をID属性などに使っていた為に妥当でないとされてきた文書も、妥当となり得る。

参照:この文書の位置付け Status of this Document

このように、XML 1.0第五版のこの勧告ではXML 1.1の機能を一部取り込んでいる。XML 1.0第四版と第五版の違いの詳細は XML 1.0 Fourth Edition Specification Errataに書かれている。この内、XML 1.1の機能を取り込んでいるのは利用可能文字集合の拡大である(参照:はE09 - XML 1.0 Fourth Edition Specification Errata)。

Names and Tokensで定義される文字集合の範囲が第五版で大幅に拡張された。以下に第四版と第五版のNames and Tokensの定義部分を記載する。

XML 1.0 第四版( Name and Tokens - Extensible Markup Language (XML) 1.0 (Fourth Edition)

Names and Tokens

[4]    NameChar    ::=    Letter | Digit | '.' | '-' | '_' | ':' | CombiningChar | Extender
[5]    Name    ::=    (Letter | '_' | ':') (NameChar)*
[6]    Names    ::=    Name (#x20 Name)*
[7]    Nmtoken    ::=    (NameChar)+
[8]    Nmtokens    ::=    Nmtoken (#x20 Nmtoken)*

XML 1.0 第五版(Name and Tokens - Extensible Markup Language (XML) 1.0 (第五版)

Names and Tokens

[4]    NameStartChar    ::=    ":" | [A-Z] | "_" | [a-z] | [#xC0-#xD6] | [#xD8-#xF6] | [#xF8-#x2FF] | [#x370-#x37D] | [#x37F-#x1FFF] | [#x200C-#x200D] | [#x2070-#x218F] | [#x2C00-#x2FEF] | [#x3001-#xD7FF] | [#xF900-#xFDCF] | [#xFDF0-#xFFFD] | [#x10000-#xEFFFF]
[4a]    NameChar    ::=    NameStartChar | "-" | "." | [0-9] | #xB7 | [#x0300-#x036F] | [#x203F-#x2040]
[5]    Name    ::=    NameStartChar ( NameChar )*
[6]    Names    ::=    Name ( #x20 Name )*
[7]    Nmtoken    ::=    ( NameChar )+
[8]    Nmtokens    ::=    Nmtoken ( #x20 Nmtoken )*

このようにXML 1.0第五版から、XML 1.0はXML 1.1で利用可能文字も扱えるようになっており、XML 1.1の利点がより小さくなっている。

まとめ

以上で示したとおり、XML 1.1の機能が必要な場面はほとんどなく、XML1.0第五版によりXML 1.0で十分な場面がほとんどである。そのため、XMLを書いたり、データとして出力する場合はXML 1.0を使うべきであり、どうしても必要な場面に限ってだけXML 1.1を使うべきだ。

2015-12-12

Install JabRef 3.0 from .jar file on Ubuntu 14.04

先日リリースされたJabRef 3.0のUbuntu 14.04でのインストール手順を記す。

JabRef 3.0での変更点

JavaベースのBibTeX文献管理ソフトであるJabRef version 3.0が2015-11-29にリリースされた(JabRef reference manager)。2.0が2006-01-30であることから、9年ぶりのメジャーバージョンアップとなる。

2系最後である2.11.1からの変更点を見たところ以下の変更点に大きな印象を持った(jabref/CHANGELOG.md at v3.0 · JabRef/jabref)。

  • Java7→Java8への以降。
  • Windows版の64bit対応。
  • LibreOffice5のサポート。
  • Springer、DOAJ、Open Access Jounalsへの検索エンジンに追加。
  • UIの刷新。
  • 検索バーの位置がトップに移動。
  • BibTeXキーの生成パターン設定の変更。
  • プラグイン機能の廃止。
  • タスクトレイへの常駐機能の廃止。
  • 今までファイルを開くなどで分けていたPDFとPSを単に「ファイル」という括りで統一。

外観が変わったのが大きい。2系ではアイコンなど古臭い印象があった。3になってフラットデザインを取り入れて現代的な見た目になった。参考までに以下に2.11と3.0の画面を示す。

個人的には[Rating]フィールドが5文字分の幅をとるようになってちょっと残念。2.11の1文字幅で数字で表すほうが省スペースでよかっ た。検索バーは位置的には3.0で一番上に来たのは良かったと思う。しかし、書誌情報のところはできるだけ広いスペースを確保したいので、表示/非表示を 切り替えれたらよかった。

Ubuntu 14.04でのJabRef 3.0のインストール手順

Ubuntu 14.04が標準でAPTでインストールできるJabRefは2.10beta2となっている。バージョンが古いので自分でJabRefをインストールしたほうがよい。

JabRefは3.0になってJava8を使うようになった。そのため、まず最初にJava8以降をインストールする。なお、現在Java9も公開されているようなので今後の更新も踏まえてこちらを使ってみる。

Ubuntu 14.04の標準ではJava7がAPTで提供されている。最新版がほしければ非公式のwebupd8teamのリポジトリを使う。

sudo add-apt-repository ppa:webupd8team/java
sudo apt update
sudo apt install -y oracle-java9-installer

参考: Install Oracle Java 8 In Ubuntu Or Linux Mint Via PPA Repository [JDK8] ~ Web Upd8: Ubuntu / Linux blog

2017-02-02追記開始

Java9だとJabRef(3.4あたりから)の挙動がおかしい。例えば,[Options]→[Preferences]が開けなかったりする。やはりJava8を使ったほうがいい。JabRef 3.8.2だとJava8を使えばちゃんと動いた。

sudo apt install -y oracle-java8-installer

2017-02-02追記終了

続いてJabRef 3.0をインストールする。以下のSourceForgeでJabRef 3.0のjarファイルをダウンロードして使用する。なお、Windows版はSourceForgeで配布されているインストーラーでJava8のインストールも自動で簡単に行える。

配布元:JabRef - Browse Files at SourceForge.net

mkdir -p ~/.local/opt/JabRef
cd ~/.local/opt/JabRef
wget -nc http://sourceforge.net/projects/jabref/files/v3.0/JabRef-3.0.jar
## ランチャーに登録するために一旦JabRef 3.0を起動する。
java -jar JabRef-3.0.jar

Ubuntuでは、debファイルを使わずに外部からインストールしたとき、標準ではDASHで検索したりランチャーに登録するできない。自分でDesktopファイルを用意する必要がある。しかし、今回は上記の最後で起動するとランチャーにアイコンが表示されており、ここで以下の操作でランチャーに登録できた。

[ランチャーを右クリック]→[Lock to Launcher]

上記操作で以下の場所にDesktopファイルが自動的に生成されたようだ。このおかげでDASHからも検索できる。

~/.local/share/applications/net-sf-jabref-jabrefmain.desktop

このファイルの内容は、例えば以下のようになっている。

[Desktop Entry]
Encoding=UTF-8
Version=1.0
Type=Application
Name=JabRef - /home/senooken/Copy/ref/bibfile/mybib.bib
Icon=net-sf-jabref-jabrefmain
Path=/home/senooken/.local/opt/JabRef
Exec=java -jar JabRef-3.0.jar
StartupNotify=false
StartupWMClass=net-sf-jabref-JabRefMain
OnlyShowIn=Unity;
X-UnityGenerated=true

Nameキーはランチャーを右クリックしたときやマウスホバーしたときのツールチップとして表示されるので、例えば以下のように修正する。

NAME=JabRef

JabRef本体へのPATHは通していないので、ターミナルからjabrefと入力しても起動されないので注意する。

これでUbuntu 14.04へのJabRef 3.0のインストールは完了した。メジャーバージョンアップしたばかりなので、まだバグや不具合に出くわす可能性が高いので注意して使おう。

デスクトップにショートカットを作成

2016-07-10追記

現時点での最新のJabRefのバージョンは3.4だが,画面の表示が乱れている。安定しているのは3.3なので,これを使うことを勧める。

Javaがインストールされていれば,ダウンロードした[JabRef-3.3.jar]ファイルなどで[右クリック]→[Open With Oracle Java9 Runtime]でもJabRefを起動できる。しかし,この場合はMozcなどのIMEがきかなくなり,日本語入力できない。日本語入力するには,前述の通りコマンドラインから起動してからランチャーに登録する必要がある。

java -jar JabRef-3.3.jar

JabRef-3.3を使って,ランチャーの存在しないLinux Mintなどのために,デスクトップにショートカットを貼る方法を記す。

Linux Mintのようにランチャーが存在しない場合,デスクトップにショートカットアイコンを配置しておけば,すぐにJabRefを起動できて便利だ。

この場合,desktopファイルを自作する。基本的には既に示したサンプルで,PathExecで指定するバージョンを変えるだけでよいだろう。また,JabRefのアイコンは,JabRef-3.3.jarファイルを解凍して確認できる,JabRef-3.3/images/icons/abRef-icon-mac.svgを使うとよい。SVGファイルであれば,拡大してもぼやけないので一番汎用性が高い。同じディレクトリに存在するJabRef-icon.svgは余白があるので使いにくい。

例えば,バージョン3.3を使うなら,以下のコマンドでdesktopファイルを作成できる。

mkdir -p ~/.local/opt/JabRef
cd ~/.local/opt/JabRef
VER=3.3
wget -nc http://sourceforge.net/projects/jabref/files/v$VER/JabRef-$VER.jar
unzip -o JabRef-$VER.jar -d JabRef-$VER
cp JabRef-$VER/images/icons/JabRef-icon-mac.svg ~/.local/share/icons/net-sf-jabref-jabrefmain.svg
cat <<- EOF > ~/.local/share/applications/net-sf-jabref-jabrefmain.desktop
[Desktop Entry]
Encoding=UTF-8
Version=1.0
Type=Application
Name=JabRef
Icon=net-sf-jabref-jabrefmain
Path=$HOME/.local/opt/JabRef
Exec=java -jar JabRef-$VER.jar
StartupNotify=false
StartupWMClass=net-sf-jabref-JabRefMain
OnlyShowIn=Unity;
X-UnityGenerated=true
EOF

そして,最後に以下のコマンドで,desktopファイルに実行権限を付与してから~/Desktopにdesktopファイルのシンボリックリンクを貼ればよい。なお,Ubuntuユーザーなどで,ランチャーの他にデスクトップにもショートカットを登録したければ,ここだけやればよい。

chmod +x ~/.local/share/applications/net-sf-jabref-jabrefmain.desktop
ln -sf ~/.local/share/applications/net-sf-jabref-jabrefmain.desktop ~/Desktop/

実行権限を付与していない場合,デスクトップに作成されるファイル名はnet-sf-jabref-jabrefmain.desktopとなり,ダブルクリックで実行しようとすると以下のエラーメッセージが出て起動できない。

Untrusted application launcher
The application launcher "net-sf-jabref-jabrefmain.desktop" has not been marked as trusted. If you do not know the source of this file, launching it may be unsafe.

ランチャーに登録したJabRefのバージョン更新時に注意が必要だ。ランチャーのJabRefを解除して,新しいバージョンのJabRefを起動してランチャーに登録しても,バージョンが変わらない。これは最初に作成したdesktopファイルが残っているからだ。そのため,ランチャーのJabRefを更新する場合,以下のどちらかの方法で行う。

  1. ~/.local/share/applications/net-sf-jabref-jabrefmain.desktopを直接編集。
  2. ~/.local/share/applications/net-sf-jabref-jabrefmain.desktopを削除してランチャーを再登録。

1.のdesktopファイルを直接編集する場合は,desktopファイルのExec欄のバージョン番号を変更すればよいだろう。

Exec=java -jar JabRef-3.3.jar

2.のdesktopファイルを削除するには,例えば以下のコマンドを実行すればよい。

rm ~/.local/share/applications/net-sf-jabref-jabrefmain.desktop

これでデスクトップにJabRefのショートカットを作れるので,ランチャーの存在いないデスクトップ環境でも素早くJabRefを起動できるだろう。

2015-12-08

TeXにはまらないための基本

#texadvent2015 これは「TeX & LaTeX Advent Calendar 2015 - Adventar」の8日目の記事だ。

7日目:515hikaruさん:TeX & LaTeX Advent Calendar 2015 7 日目 - 515 ひかるのブログ 日常編

9日目:p_typoさん:Typesetting and Related Topics - 今さら人に聞けないLaTeX入門書の選び方

「はまる(填まる、嵌まる)」という言葉には以下の意味がある。

  1. 穴の部分にぴったりとはいる。うまくはいっておさまる。「栓が―・る」「ボタンが―・る」「型に―・る」
  2. うまくあてはまる。「条件に―・る」「役に―・る」
  3. くぼんだ場所などに落ち込む。「堀に―・る」
  4. 計略にのせられる。だまされる。「敵の術に―・る」
  5. かかわりあって抜け出せなくなる。また特に、女性の色香におぼれる。「悪の道に―・る」

[補説]5は、近年、「すっかり旅行にはまっている」のように、のめり込んでいるようすを、肯定的にとらえた意味でも用いる。

はまる【填まる/嵌まる】の意味 - 国語辞書 - goo辞書 http://dictionary.goo.ne.jp/jn/179287/meaning/m0u/%E3%81%AF%E3%81%BE%E3%82%8B/

TeXを使っていると上記の5の意味で「はまる」ことがある。つまり以下の2現象に出くわすことがある。

  • やりたいことがうまくできず、問題から抜け出せなくなる。
  • 夢中になって、のめりこむ。

この記事ではTeXにはまらないための基本として、僕が考える以下の項目について説明する。

  1. TeXを使わない
  2. 頑張ればできそうなことはやらない
  3. 編集に適したエディタ・ツールを使う
  4. ディストリビューションには世界標準であるTeX Liveを使う
  5. 組版にはuplatex+dvipdfmxを使う
  6. TeXでスライドを作らない

TeXを使わない

TeXではまらないための最も根本的な解決方法は、TeXを使わないことだろう。

既に僕はTeXの問題点について以下の記事・スライドで指摘してきた。

  • My Future Sight for Past: 初心者にとってのLaTeXの問題点とLyXの紹介 http://myfuturesightforpast.blogspot.jp/2013/12/latexlyx.html
  • TeXはオワコンなのか?(TeXユーザーの集い2014) http://www.slideshare.net/iesli/20141108-senooken-tex

TeXには大きく以下のような問題があるだろう。

  • 難しすぎる。
  • 将来性のなさ。
  • TeX以外で役にたたない。

もちろん現状TeXを使わざるえない場面も存在するだろう。例えば以下のような場面が想定できる。

  • 過去のTeXで文書の保守・引き継ぎ。
  • 数式、参考文献や相互参照などTeXを使わないと実現が困難。
  • バッチ処理など自動文書生成の必要。
  • 出版レベルの高品質な組版。

主に組版関係の人や、教員、研究者など限られた人で需要があるのだろう。次世代の組版であるCSS組版が完成すればTeXを置換できるかもしれないが、それはまだもう少し先の話だ。今のところTeXを置換できるようなものはない。しかし、本当にTeXを使う必要があるのだろうか。

何かを調べて文章を記述するときは、ネット(HTML)の文章を参照するだろう。しかし、TeXだとテキスト以外は画像を使うか、HTMLをTeXに変換するしかWebページを取り込めない。MS WordやLibreOffice WriterであればWebのスタイルもそのまま文書に取り込める。仕事などで一般的に使われているMS Wordのdocx形式で文書を用意することは現実的な判断だ。

そもそもTeX自体使っている人はそんなに多くない。複数人で文書を共有する場合、TeXを使える場面というのはほとんどないだろう。まず、TeXのインストールから始めないといけない。そしてTeXを使うためだけに難しい構文・環境・コマンドの使い方覚えなければいけない。そんな面倒なことするくらいなら、HTMLやMarkdownやAsciiDoc、Sphinxなどの軽量マークアップを使うほうが保守もしやすいし、流用がきくだろう。

頑張ればできそうなことはやらない

先日、次のツイートを見かけた。

ワトソンさんはTwitterを使っています: "TeX/LaTeX でコレ組めますかね? (画像や picture 環境の類を使うのはナシで) https://t.co/u6E1dQwEnz" https://twitter.com/Watson_DNA/status/670787026606620672

大きなマトリックスの外側からさらに行や列の説明を入れるというものだ。TeXを使っているとこのような複雑なことを実現したいことがあるだろう。しかし、TeXにはまらないためにはこうした「頑張ればできそうなことはやめる」べきだ。少々手間がかかり泥臭い方法を取ることになっても、TeX単体で頑張ってやろうとするのはやめたほうがいい。

例えば、今回のケースでは以下のような手順で画像として処理することで手短にほしい見た目が手に入る。

  1. 骨格の数式だけTeXで作り、それを画像として出力。
  2. 画像編集ソフトで行と列の注釈を付与。
  3. 画像として取り込む。

このツイートに対して、複数のarray環境を使ったり、tikzpictureを使うことでTeXだけで実現する回答が寄せられていた。もちろんこういった方法がぱっと思いついてすぐに解決できるなら問題ない。しかし、できるあてもないのに頑張ってやろうとするのはやめるべきだ。無駄に時間を浪費することになる。頑張ってできたとしても、後で見なおしたときや他の人が見たときに理解できず、修正・保守が困難になる。

うまくできてしまうとその達成感から、本来ならTeXでそこまでやる必要のないことまで無理やりTeXでやり遂げたくなり、さらにはまり込んでしまう。TeXを極めたいのならば問題はない。思う存分はまりこんでやりこむのもいいだろう。しかし、多くの人にとってはTeXをあくまで組版のための単なる道具に過ぎない。本来の目的である組版物を得ることから外れる。検索してすぐにできそうならともかく、検索してもすぐにはわからず頑張らないとできなさそうなことは素直に諦めよう。暇なときなどに趣味として調べよう。

同じような考えで、マイナーなパッケージやTikZの多用、PythonTeXやRとの連携を行うSweaveとknitrなどの利用はできるだけ避けよう。これらを用いれば高度な組版が可能である。しかし、学習コストは無視できず、情報は少なく扱える人も少ない。複数人での文書の再利用が困難になる。また、自分一人の個人文書であっても、数年後に自分がそれらを扱えるか、記憶しているという保証はない。したがって、本当に必要な部分に限ってこれらの機能を使おう。

編集に適したエディタ・ツールを使う

TeXで文書を書くならば、その大部分である執筆作業を快適に行えるエディタを使うことが非常に重要だ。

TeXを使うという時点で相互参照、図版、表組み、数式、参考文献、索引など組版に重要で、かつTeX特有のコマンド・環境を扱うことになる(これらを活用しないならばTeXを使う必然性もないだろう)。これらを単なるテキストエディタで済ませるのは効率が悪すぎる。短い文書であれば問題ないだろうが、しっかりとした長く残すような文書であれば自然と文量も多くなるので無視できなくなってくる。TeXを書く度に打ち間違いや構文エラーなどではまることは避けよう。

また、組版結果であるPDFのビュアーや、文献処理ツールBibTeXで使う.bibファイルの文献管理ソフト、画像編集ソフト、表計算ソフトといった周辺ツールも自分にあったものを用意しておくべきだ。

エディタ

TeXのエディタとしては大きく以下の2種類があるだろう。

  • 汎用のテキストエディタ
  • TeX専用のエディタ

TeXのエディタとしては、汎用のテキストエディタよりはTeXに特化した専用のエディタの利用をおすすめしたい。

汎用のテキストエディタ

汎用のテキストエディタにはVim、Emacs、Atom、秀丸などがある。これらを使うのならば、マクロやプラグインを導入して自分でカスタマイ ズしていく必要がある。これによって得られるのは、シンタックスハイライト(構文強調)や入力補完が主だろう。しかし、これには以下の欠点がある。

欠点:

  • latexやbibtex、mendex、extractbbコマンドの実行などはMakefileやlatexmkの設定が追加で必要であり完結しない。
  • エディタ自体とLaTeXへの習熟が必要で学習コストが高い。

特に学習コストが大きい。LaTeXは難しいので、難しいことはソフトに任せてもっとユーザーは楽できるべきだ。

TeX専用エディタ

TeX専用エディタとしては、将来性や情報の多さなどから以下の項目を満たしているのが望ましい。

  • クロスプラットフォーム(Windows、Linux、Mac)
  • 自由ソフト
  • 活発な開発

これらで絞り込むと残ってくるものは自然と限られる。以下のソフトがよく使われているようだ。

  • TeXmaker
  • TeXworks
  • TeXStudio
  • LyX

参考:人気のあるTeXのエディタまとめ - SengNingの日記 http://d.hatena.ne.jp/SengNing/20130606/1370503515

この中ではLyX( LyX | LyX – 文書プロセッサ http://www.lyx.org/WebJa.Home)を勧める。LyXは他のエディタと決定的に異なる部分がある。それは以下だ。

TeXコードやTeXコマンドを一切みなくても執筆できる

LyX以外のエディタであれば、結局のところユーザーのTeXへの知識を前提としている。図を入れたかったらあのコマンド、表を入れたかったらあのコマンドといったように。LyXではTeXコマンドそのものをはっきりと覚えていなくてもメニューから選ぶことでやりたいことを実現できる。TeXの知識があればなおよいが、そこまで詳しくなくてもストレスなく使えるようになっている。

また、数式エディタが優れている。入力補完やMathML出力など扱いやすくて優れている。

操作性から最初は戸惑うかもしれないが、使う価値がある。LyXの操作イメージ・利点については「TeX & LaTeX Advent Calendar 2013」の以下の記事に記している。

My Future Sight for Past: 初心者にとってのLaTeXの問題点とLyXの紹介 http://myfuturesightforpast.blogspot.jp/2013/12/latexlyx.html

また、LyXと似たようなソフトにScientic WorkPlaceというWindows専用の不自由ソフトがあるようだ。参考までにリンクを掲載しておく。

Scientific WorkPlace | TeX, LaTeX文書作成ソフト Scientific WorkPlace/Word | ライトストーン http://www.lightstone.co.jp/latex/product_swp.html

PDFビューアー

PDFビューアーに重要な機能は以下3点だ。

  • 軽量さ。
  • 自動更新の対応。
  • synctexへの対応。

自動更新とはpdfファイルが更新されたらそれを自動検知して表示内容を更新してくれる機能のことだ。これがなければ、いちいち自分でビューアーを開き直す必要があり効率が悪すぎる。synctexは出力したPDFから.texソースへジャンプするための仕組みだ。これができると、TeXソースでどこに記述されているか発見が難しいものも、PDFからたどることができTeXソースの修正が楽になる。

自動更新やsynctexに対応しているPDFビューアーは少ないので必然的に数が絞られる。OSごとに以下のソフトがお勧めだ。

  • Windows:SumatraPDF
  • Linux:Evince、Xpdf

Windowsであれば軽量さからSumatraPDF一択となるだろう。LinuxやMacでの使用経験はあまりないので、他にもっとよいものがあるかもしれない。

文献管理ソフト

特に大学院生や研究者などで論文を(これから)書く人は文献管理ソフトを活用することが非常に重要である。Excelなどの表計算ソフトで管理する方法もあるが、専用のソフトを使うことを勧める。文献の書誌情報の配布形式はrisやbibであることが多く、初めからこれらの形式に対応しているソフトを使ったほうが楽だ。

文献管理は普通の人には馴染みがないが、論文を書かない人であっても電子書籍やマニュアルなどの文書管理ソフトとして便利だと思う。文献管理ソフトといっているが、その気になれば音楽や動画も管理できる。例えば、ある漫画・アニメについて電子書籍やDVD、BGMといったように複数のメディアに分かれているときでも同じインターフェースで管理できる。

文献管理ソフトに必要な機能は以下のような内容だろう。

  • 論文や書籍の書誌情報(タイトル、著者名、出版日付、URL、ページ数、雑誌名など)の記録。
  • 書誌情報(bib、risなど)のインポート・エクスポート。
  • 文献リストの生成。
  • 検索・グループ管理。
  • ローカルに保存したPDFなどへのリンクやURLなど文献本体へのアクセス。
  • 文献に対する感想やメモ、レビューなどの記録。

参考までに以下に文献管理ソフトJabRef 3.0の画面を掲載する。概ねどの文献管理ソフトも似たような画面構成になっている。

  • 右下の部分に登録した文献の書誌情報がずらっと並ぶ。
  • 右下の部分では書誌情報に加えた内容からPDFやURLのリンクが付き、対応するマークから対応する文献にアクセス可能。
  • 左サイドバーに書誌情報につけたキーワードによるタグや格納ディレクトリツリー、検索ボックスが配置。

必要な文献を収集してその書誌情報を管理し、論文執筆時に引用し、参考文献リストへの記載することになる。TeXにはBibTeXという引用と参考文献リストの作成を行ってくれるツールが存在している。MS WordやLibreOffice Writerにはこのような文献処理ソフトは存在しないため、BibTeXの存在はTeXを使う理由の大きな一つだろう。このBibTeXはテキスト形式の.bibファイルを利用する。

BibTeXや文献管理という分野自体があまりメジャーではなく情報はそんなに多くない。文献管理ソフトは以下のWikiPediaのページにまとめられている。

Comparison of reference management software - Wikipedia, the free encyclopedia https://en.wikipedia.org/wiki/Comparison_of_reference_management_software

大きく以下の3種類に分類される。

  • オープンソース(例:JabRef、Zotero、BibDesk)
  • 商用(例:EndNote、Papers)
  • Webベース(例:RefWorks、Mendeley、ReadCube)

Endnoteという不自由な商用ソフトのが研究の分野ではデファクトスタンダードだと、学生時代に指導教員からきいた記憶がある。文献管理ソフトの利用者の感想やレビューを見つけるのはなかなか難しい。その中でも以下の2ソフトは、クロスプラットフォームで無料で使え、利用者や情報が比較的多くておすすめだ。

  • JabRef( JabRef reference manager http://jabref.sourceforge.net/)
  • Mendeley( Free reference manager and PDF organizer | Mendeley https://www.mendeley.com/)

TeXとの連携を考えるならJabRefのほうがいいだろう。なぜならば、Mendeleyには以下の欠点があるからだ。

  • データ形式が.bibでないため引用するときに.bibにエクスポートする必要がある。

しかし、複数人で文献情報を共有する上ではMendeleyの方が優れている。Mendeleyサイトでアカウントを作ることで、書誌情報を不特定多数のユーザーでシェアできるサービスを提供しており、またMendeleyのアプリはQtで作られておりスマホでも使える。

.bibとMendeleyの変換コンバーターは見あたらない。文献はどんどんため込んでいくことになるので、後で乗り換えるのはやっかいだ。どちらが合うか見極めて使うのがいいだろう。個人的には、Mendeleyのほうが利用者が多く、一般的に使いやすそうなのでこちらがよいと思う。僕はJabRefから使い始めた都合、Mendeleyへの乗り換えは頭の片隅に入れているが、なかなか行動に移せない。

ディストリビューションには世界標準であるTeX Liveを使う

TeXは多数のマクロやフォントパッケージなどを適切に配置・設定することで使えるようになる。手動で行うのは煩雑で現実的でない。このために、これらの調整を行ったものを配布物(ディストリビューション)と呼んでいる。

比較的有名なTeXのディストリビューションとしては以下の3種類が存在する。

  • TeX Live
  • MiKTeX
  • W32TeX

日本ではW32TeXをベースにしたインストーラーが存在しており、比較的よく使われているようだ。

TeXインストーラ 3 http://www.math.sci.hokudai.ac.jp/~abenori/soft/abtexinst.html

TeXインストーラ3の使い方として、以下の記事のようなわかりやすいインストール手順も存在している。

簡単LaTeXインストールWindows編(2015年7月版) http://did2memo.net/2014/03/06/easy-latex-install-windows-8-2014-03/

しかし、以下の理由からTeX Liveを使うべきだ。

  • 世界標準。
  • 既定でインストールされるパッケージの多さ。
  • パッケージ管理・新規パッケージのインストールの簡略化。

世界的にみてTeX Liveが最も利用者の多いTeXディストリビューションだろう。利用者が多ければ、何か問題があったときに助けとなる情報にたどりやすい。質問サイトであるStack ExchangeでもTeX Liveの利用者が多い印象だ。

TeX - LaTeX Stack Exchange http://tex.stackexchange.com/

既定でインストールされるパッケージが多ければ、新しいパッケージやフォントを使うときに自分でインストールする必要がなくなる。初回のインストール時間やファイルサイズなど、デメリットもあるがあとで手動でインストールする手間を考えると問題ないだろう。また、TeX Liveは毎年その年ごとにリリースされている。TeXのパッケージは日々更新されており、バージョンによって追加機能など挙動が変わることもある。年ごとに更新のタイミングがあることで問題の切り分けも簡単になる。更新はディレクトリを切り替えるだけであるため、古いバージョンを使い続けることも可能であり保守性も高い。

また、TeX Liveにはtlmgrというパッケージマネージャーが付随している。これを使うことで、CTANに登録されている新規パッケージのインストールが自動で行える。

ただ、TeX LiveはあくまでTeX関係のコマンド・パッケージフォント類しかインストールできない。エディタやPDFビューアーなどは自前で用意する必要がある。

自分のPCにTeXをインストールするのが面倒であったり、できないことや、手軽にTeXを使いたいこともあるだろう。その場合は以下のオンラインでTeXを使えるサービスの利用を検討してみてもよい。

  • Cloud LaTeX | Build your own LaTeX environment, in seconds https://cloudlatex.io/ja
  • Overleaf: Real-time Collaborative Writing and Publishing Tools with Integrated PDF Preview https://www.overleaf.com/

2010年ごろからWriteLaTeXというサイトがあり、ここがオンラインでのTeX利用サービスを提供していた。2013-4年頃にOverleafという名前に変わった。Overleafは海外で生まれたサービスであり日本語への対応がいまいちな部分があり、使いづらかった。2014年にはCloud LaTeXという日本で生まれた同種のサービスがある。日本で生まれただけに日本語対応もできており、歴史は浅いが有用だ。

組版にはuplatex+dvipdfmxを使う

.texファイルから組版結果であるpdfを得るにあたって、TeXにはいくつかの処理系がある。

例えば以下の記事で説明されている。

LaTeX - TeX処理系御伽話 - Qiita http://qiita.com/yyu/items/6404656f822ce14db935

日本語組版ができるものは概ね以下の4通りとなる。

  • platex+dvipdfmx
  • uplatex+dvipdfmx
  • xelatex
  • lualatex

個人的には2番目のuplatex+dvipdfmxを勧める。理由は以下の2点だ。

  • platexで使えないUnicodeが使える。これにより半角カタカナやはしご高(髙)、ウムラウト(ö)などをTeXコマンドを使わずにTeXソースコードに記述するだけで表示できる。
  • 日本ではplatexが長く使われてきており、それを基本的にユニコード拡張しただけのuplatexは安定している。

xelatexやlualatexは.texソースから直接pdfを出力でき、機能的に優れている部分もある。しかし、platexに比べたらこれらはマイナーで普及しているとはいいがたい。人柱になりたくなければuplatexを使うのがよいだろう。

lualatexは次代のTeXとして将来が約束されている。MarkdownからPandocで日本語の入ったBeamerのスライドを作るときに使われていたり一部で使われているようだ。

日本語Markdownからスライド資料を作る http://rcmdnk.github.io/blog/2015/04/23/computer-markdown/

しかし、利用者が減少し将来性のないTeXにLuaTeXなんかできて誰が得をするのだろうか。実行速度が遅いとか、日本語の縦書はまだうまくできないとか悪い噂はきく。TeXの中でLuaが使えるので、LuaでTeXマクロが組めるようになるのがよいらしい。TeXの中でPythonTeXのように外部の拡張機能ではなく、ネイティブにまともなプログラミング言語を使えるのには便利な面はあるのだろう。しかし、ただでさえややこしいTeXがこれ以上ややこしくなって誰が嬉しいのだろう。

LuaTeXにより利用者数が増えるのか?誰がLuaTeXの登場を望んでいる?TeXが難しくてとっつきにくいことに変わりはない。問題の解決にはなっていない。

TeXでスライドを作らない

TeXにはスライドを作成するためのパッケージがいくつかあり、Beamerがよく使われている。

例えば、最近だと以下のスライドがBeamerで作られている。

keiichiro shikano λ♪さんはTwitterを使っています: "プレゼン資料をアップしました! "ドキュメントシステムはこれを使え2015年版 by @golden_lucky https://t.co/9JVHL4e4QE @SlideShareさんから #sphinxjp" https://twitter.com/golden_lucky/status/669105646369792000

ありがたいことに以下でソースも公開しているのでbeamerを使っていることがはっきりとわかる。

keiichiro shikano λ♪さんはTwitterを使っています: "「ドキュメントシステムはこれを使え2015年版」プレゼン資料のソース https://t.co/tGMGFLp3iW #sphinxjp" https://twitter.com/golden_lucky/status/669106399981404161

TeXでスライドを作ると以下のような利点があるだろう。

  • 数式をきれいに表示
  • 既存の文書を流用
  • マウスを使わずにキーボードだけでスライドを作れる

上記の利点からスライド作成の効率が上がるように思われる。しかし、TeXでスライドを作るのはやめたほうがいい。以下の欠点がある。

  • スライドは見た目が重要なので、マークアップしても無駄になる。
  • 画像やテキストの配置など込み入ったことをしようとするとTikZを使う必要があり、難易度が高い。

TeXでのスライド作成については以下で欠点が言及されている。

gfnさんはTwitterを使っています: "今回Beamerを初めていじった感想は「スライドのマークアップはほぼ確実に考えるだけ無駄」でした." https://twitter.com/bd_gfngfn/status/530389444939898880

gfnさんはTwitterを使っています: "15回くらい言ってるけど,よっぽど意味マークアップするのでもない限り,スライドづくりにbeamerを使う恩恵はほとんどないに等しい" https://twitter.com/bd_gfngfn/status/611256797014286336

☃ZR-TeXnobabbler☃さんはTwitterを使っています: "まあ、スライドは“見た目が命”(そして多くの場合構造が希薄)だから、マークアップ言語と相性が悪いのは当然なのだが。" https://twitter.com/zr_tex8r/status/530362224120836096

☃ZR-TeXnobabbler☃さんはTwitterを使っています: "結局やりたいことは「スライドの好きな位置にモノを置きたい」であって、スライドの場合は、ページ上絶対座標で配置する(https://t.co/HsArH92Sy6)という手段が最も自然で使いやすいのじゃないかな。 #TeX" https://twitter.com/zr_tex8r/status/306358970010959872

セノペンさんはTwitterを使っています: "TeXでのスライド作成は超上級者向け。優れたスライドを作るにはBeamerの設定やTikZなどを暗記が必須。画像やテキストボックスの配置調整で悶絶するぞ。一般人はだまってLibreOffice Impress。中身に専念できる。ナビバーとかは羨ましいけどね…。" https://twitter.com/senopen/status/530714713378668544

唯一TeXでスライドを作成するとしたら、箇条書きをひたすら列挙するようなシンプルなスライドだろう。ただ、このようなスライドだと視覚に訴えるものが少なく、スライド品質の低下を招くだろう。やはり基本的にTeXでスライドを作るのはやめ、素直にLibreOffice ImpressやMS Powerpointなどのプレゼンテーションツールを使うのが無難だろう。数式を多用するような場合は、付属の数式エディタを使うか、画像として用意するのがよいだろう。

まとめ

TeXにはまらないための基本について自分の考えを記した。TeXにはまらないための根本的な解決策としては、最初に述べた「TeXを使わない」ことだ。本当に自分にTeXが必要なのか考えて、どのように付き合っていくか考えて使うのがよいだろう。

TeXは難しすぎて、僕は他の人に勧めることができない。早くCSS組版が普及して誰でも簡単に組版ができるようになって、「TeXグッバイ」したい。