TEIガイドラインP5: 14 図・表・式

14 図・表・式

Contents

文書の多くには，古いものであれ，現代のものであれ，テキスト以外にも，図，芸術作品，画像などが含まれている．画像データの中には，符号化テキストで表現することが可能なものもあるが，一般的には，画像データは，画像を表現する適切な形式で電子化され，外部実体として存在し，それを参照すること(典型例はURL)で，取り込まれることになる．

図に限らす，文書には，絵的に表現されたり，表形式で表現されたりする部分が含まれていることがよくある．このような部分では，時に，そこにあるテキストよりも，レイアウトや表示のされ方そのものの方が重要であることもある．例えば，情報の表現のされ方と，その情報そのものの関係は，明確に分けられない場合も多い．

また，文書には，数式が含まれることもある．本ガイドラインでは，数式そのものの表記法については規定していない．

この種のもの(図，表，数式など)には，他の規格団体や専門家集団も強い関心を持ってきた．そのようなこともあり，本ガイドラインでは規定していない，既に存在している記法を使い，それらの符号化や処理を考えた方が便利である．よって，本章では，表，式，図をまとめて考えることにする．

テキストの符号化の状況と同じく，図，式，表の符号化においても，整合性のない，複数の方法が提案されている．残念ながら，テキストデータをXMLで表現する様に，これらを効率よく，ひとつのフォーマットで符号化し，データを交換できる方法はまだ存在しない．これは，データ形式が運ぶ情報を，その表示のされからから独立して表現することが難しいからである．

本章で定義するモジュールは，特別な役割を持った「コンテナ」要素といえる．これらの要素は，図，式，表のような情報を，TEI準拠の文書中に簡単に埋め込ませることができる．表の符号化方法については，14.1 表を，数式の符号化方法については，14.2 式で解説する．図の符号化方法については，14.3 画像データ向けの要素で解説する．この他の節では，図情報を符号化する際の，一般的な問題について解説する．

このガイドラインを執筆している時点では，合意が得られている，図を表現するデータ形式はない．従って，図を表現するデータ形式は，多様となる．本ガイドラインでは，画像の表現方法については，(14.4 画像データについてで)少し解説する．また，よく使われるデータ形式のリストを(14.5 画像データ形式で)紹介し，そこで簡単な解説をする．本ガイドラインでは，広く支持され，同意が得られていると思われるいくつかの表現方法について，推奨することになる．

» 14.2 式
Home | 目次

14.1 表TEI: Tables¶

表は，本章で解説される要素が記録する「図」とされる．どのようなテキスト構造も，一連の行や列で表現することが出来る．例えば，用語集やそのようなリストなどは，表でなくとも，表のような形式で示すことができる．この場合，属性rendを使い，ある要素が，表の形式を示していることを示すことができる．表の形式が，本質的に重要なものではないと判断されるような場合には，表中の内容を記述したり，またはその処理命令を記録することになる．例えば，あるセルには名前を記録し，あるセルには日付を記録し，この2つは組み合わされる可能性もある．

しかし，表の形式自体を記録するためには，それ向けの要素が必要で，その場合には，複数の異なる表の表示方法(スキーマ)を選択することができる．表を表現する一般的なスキームでは，表は，セルを束ねた行を記録する要素から構成されている． ⁴⁴ 表にあるセルは，一般に，行に視点をおいた順番を使い構成されており，行の左から右へ，そして次の行へ，という順番に並んでいる．列の幅や，線の太さ，間の幅などについての詳細は，一般には，複数の属性で記録されることになる．但し，このような共通点よりも，表向けのスキーマ間の差異は大きい．この節では，はじめに，この種の表向けスキームを解説し，広く使われている他の表向けのスキームについては， 14.1.2 他のスキーマで簡単に紹介する．

» 14.1.2 他のスキーマ
Home | 目次

14.1.1 TEIにおける表TEI: TEIにおける表¶

本ガイドラインでは，低・中間程度の複雑な表を符号化する為の，特別な要素を，以下のように用意している．

table 表形式で示されるテキストを，行と列で示す．

rows	当該表中の行数を示す．
cols	当該表中の列数を示す．

row 表の1行を示す．
cell 表中のひとつのセルを示す．

要素tableは，挿入レベル要素(inner)クラスのメンバーである．従って，本章で定義されているモジュールが使えるのであれば，章の始めに示したように，この要素は，他の要素(例えば，段落) の中でも，それらの間でも使うことができる．

表を，一連の行と見なすか，または一連の列と見なすかは，自由である．現行あるシステムとの互換性を考慮し，本ガイドラインでは，表を，一連の行から成るとしている．表は，一連のセルと見なすことも可能である．表が，単純な行列の形式ではない場合，この見方はとても便利だろう．

属性rowsとcolsは，表の大きさを記録することが出来る．すなわち，行や列における数ではなく，表全体からみたセルや行の数を記録している．表やセルにおいて，行や列は，上から下，左から右の順番に並んでいるとする．本ガイドラインでは，表の大きさを指定することは求めていない．整形ソフトウェアなどの多くでは，2つのステップを踏んで，表全体を処理する必要がある．

セルが複数の行や列に渡る場合，符号化する人は，それが純粋に表示目的のものなのか(この場合は属性rendを使うのが適切である)，その部分は表の入れ子として扱う方が良いのか，それとも，上にある，(幅)数を示す属性を使うのかを，決める必要がある．

属性roleは，セルを分類するために使われる．または，当該行にあるセル全ての初期値を記録するために使われる．本ガイドラインでは，役割のうち，labelと dataのみを定義する．符号化する人は，必要であれば，これ以外の役割も定義することができる．

これら3つの属性は，属性クラス att.tableDecoration のメンバーであり，要素cellと要素rowも，そのメンバーである．この詳細は，1.3.1 属性クラスを参照のこと．

以下の例は，3.7 リストで解説されたラベル付きリストを，表として，元の表示方法を記録している．

参考文献

<table rend="boxed" rows="2" cols="2">
<head rend="it">Report of the conduct and progress
   of Ernest Pontifex. Upper Vth form — half
   term ending Midsummer 1851</head>
<row>
  <cell role="label">Classics</cell>
  <cell>Idle listless and unimproving</cell>
</row>
<row>
  <cell role="label">Mathematics</cell>
  <cell>ditto</cell>
</row>
<row>
  <cell role="label">Divinity</cell>
  <cell>ditto</cell>
</row>
<row>
  <cell role="label">Conduct in house</cell>
  <cell>Orderly</cell>
</row>
<row>
  <cell role="label">General conduct</cell>
  <cell>Not satisfactory, on
     account of his great unpunctuality and inattention to
     duties</cell>
</row>
</table>

ここでは「ditto(同上)」とあるセルに，特別な配慮をしていないことに注意して欲しい．「ditto」とは，これを含むセルと，これが参照するセルの内容とを関連づけている，またはその内容をコピーしていると解釈されるものである．これらの解釈については，16 リンク，分割，統合を参照のこと．

以下にある例では，先のスキームを使い，統計データの表を記録している．

<table rows="4" cols="4">
<head>Poor Man's Lodgings in Norfolk (Mayhew,1843)</head>
<row role="label">
  <cell/>
  <cell>Dossing Cribs or Lodging Houses</cell>
  <cell>Beds</cell>
  <cell>Needys or Nightly Lodgers</cell>
</row>
<row>
  <cell role="label">Bury St Edmund's</cell>
  <cell>5</cell>
  <cell>8</cell>
  <cell>128</cell>
</row>
<row>
  <cell role="label">Thetford</cell>
  <cell>3</cell>
  <cell>6</cell>
  <cell>36</cell>
</row>
<row>
  <cell role="label">Attleboro'</cell>
  <cell>3</cell>
  <cell>5</cell>
  <cell>20</cell>
</row>
<row>
  <cell role="label">Wymondham</cell>
  <cell>1</cell>
  <cell>11</cell>
  <cell>22</cell>
</row>
</table>

最初の行にある空のセルは，列のラベルが，正しく対応するために，使われていることに注意して欲しい．この例では，行と列にあるのラベルは，それが対応するデータとの関係は，明示されていないことになる．表にある内容の意味を記録することが重要な場合には， 18 素性構造で解説する素性構造の仕組みを使い，構造的な意味を表現する方がよい．または， 16 リンク，分割，統合で解説される，より一般的な目的で使われるリンクを使った機能を，表にある各セルで使うことができる．

表にあるセルの内容は，文字データである必要はない．セルには，3 コアモジュールで解説される，一連の句レベルの要素を取ることもできる．これにより，より有効な意味情報を，以下にある例のように記録することが出来る．例えば，あるセルには数値が含まれ，あるセルには，土地名が含まれていることを明示することができる．

<table>
<head>US State populations, 1990</head>
<row>
  <cell>
   <name>Wyoming</name>
  </cell>
  <cell>
   <num>453,588</num>
  </cell>
</row>
<row>
  <cell>
   <name>Alaska</name>
  </cell>
  <cell>
   <num>550,043</num>
  </cell>
</row>
<row>
  <cell>
   <name>Montana</name>
  </cell>
  <cell>
   <num>799,065</num>
  </cell>
</row>
<row>
  <cell>
   <name>Rhode Island</name>
  </cell>
  <cell>
   <num>1,003,464</num>
  </cell>
</row>
</table>

属性roleを使うと，同種の情報を，より簡潔に記録することが出来る．

<table>
<head>US State populations, 1990</head>
<row>
  <cell role="statename">Wyoming </cell>
  <cell role="pop">453,588 </cell>
</row>
<row>
  <cell role="statename">Alaska </cell>
  <cell role="pop">550,043 </cell>
</row>
<row>
  <cell role="statename">Montana </cell>
  <cell role="pop">799,065 </cell>
</row>
<row>
  <cell role="statename">Rhode Island</cell>
  <cell role="pop">1,003,464</cell>
</row>
</table>

要素cellの中で，意味を示す役割を担う要素を使うことで，当該セルを，行や列中でどのように表示するのかという情報以外に，セルの内容にある情報の性質や重要性を記録することができる．

« 14.1.1 TEIにおける表
Home | 目次

14.1.2 他のスキーマTEI: 他のスキーマ¶

編集ソフトの多くは，独自のスキーマや，公的なスキーマに対応している．編集ソフトには，高度なユーザーインタフェースと，嬉しい書式付け機能がある．但し，それらの多くは，XMLを使っているにもかかわらず，製品独自のものである．

アメリカ出版者協会(AAP)が開発し，ANSI Z 39.59として規格化されたlDTDは，簡単な表を符号化する簡易な方法を示している．このDTDは，ISO 9537にあるDTDと一緒に開発され，現在では，ISO 12083の一部となっている．先に紹介した，TEIにおける表向けのモジュールは，このISO 12083ととても似た機能を持っている．

より複雑な表に対応した，公開されているもっとも効率の良い DTDは，恐らく，アメリカ国防省のCALSプロジェクトで開発されたものである．このDTDは，垂直・水平両方向のセルの合成に加えて，各種のテキスト回転や，セル中でのテキスト位置の指定などをサポートし，また，これをサポートする多くのSGML向けのソフトウェアが存在している．

CALSプロジェクトの表モデルは，複雑すぎるので，ここで詳細を解説することはできない．この歴史的な背景については，http://www.hbingham.com/technical/tables/calstbhs.htm を参照のことまた，これを簡易化したものの，最新の情報については，http://www.oasis-open/specs/tablemodels.php を参照のこと．他のXMLアプリケーションと同様，CALSモデルのXML版も，TEI スキームの中に簡単に取り入れることができる．この詳細については，23.2 Personalization and Customizationを参照のこと．

XHTMLの表モデル(XHTML™ 1.0 The Extensible HyperText Markup Language (SecondEdition) (2000) は，HTMLの表モデル(Ragget et al. (eds.) (1999)がベースになっている．この2つのモデルは，行や列に，任意にデータを付与することが出来る．表の行や列は，付加的な構造情報示すために，まとめることができる．また，ユーザーが使うソフトウェアは，その構造を強調して表現することも可能である．また，表を少しずつ表示したり，グラフィカルでないソフトウェア上でも表示するようなことも可能である．表と関連するメタデータを記録する，特別な要素や属性も用意されている．この情報は，当該表の目的を記録したり，検索ソフトや点字ソフトを使うときに便利である．表を，文書内容の，レイアウトを規定する手段として使うことは，推奨されない．これは，多くの問題の生むことになるからである(詳細は，http://www.w3.org/TR/WCAG10-HTML-TECHS/#tables を参照のこと)． HTMLやXMLのレイアウトや視覚的な特性を管理する，より効果的な手法は，スタイルシートを使うことである．

14.2 式TEI: Formulae andMathematical Expressions¶

数式や化学式は，表と同様に，内容と分かち難い表現そのものを符号化する難しさがある．また，数式や化学式には多くの特別な記号が含まれている．その多くは，規格化された実体名として，ISOが規定する実体集合(vi 言語と文字集合と5 標準化されていない文字と字形の表現を参照)の中にある．

式や表には，共に，TEI以外で既によく検討された，詳細なDTDが用意されている．また，極めて詳細な，非SGMLではあるが，広く使われているテキストデータによる記法が(少なくとも数学では)存在している．それは，TeXシステムのことで，これを使ったマクロ集であるLaTeX や，AMS-TeX，AMS-LaTeXなどもある．

14.1 表で紹介したAAPや ISOは，表と同じように，式向けのDTDも提示している．現在，これはISO 12083の一部となっている．ヨーロッパの数学研究を支援する団体である，ヨーロッパ数学団体 (The European Mathematical Trust)は，EuroMath(http://www.dcs.fmph.uniba.sk/~emt/)として知られる一般的な数学向けDTDを定義し，これに対応したソフトウェアや各種サービスが提供されている．

これらのDTDにある，全てではないにしても，殆どの機能は，現在，以下で紹介するOpenMathやMathMLといった，XMLベースのシステムでも使うことができる．

式をSGMLやXMLで表現しようとするときには，表の場合と同様に，式が書かれている様子を記録することと，それが示す意味内容を記録することは，対立関係となる．異なるソフトウェア間でデータを交換する目的であれば，符号化したデータには，式が表示する数学上の意味を記録する必要はない．しかし，記録されたデータが，代数処理システム(例えば，MathematicaやMaple)の入力として使われるような場合には，下付記号や上付記号などは，不要である．

本ガイドラインでは，既存の式向けDTDに，新しい提案を加えることはしない．本ガイドラインでは，これらを選択する際に，十分な情報の元に選択することを推奨する．本章で解説するモジュールでは，以下の要素を使うことができる．これは，どの様な記法に対しても，式を符号化するときに使うことができる．

formula 数式を示す．

notation

当該要素の内容にある既定表記法の名前を示す．

初期値として，要素formulaには，XMLデータとして妥当性が検証されない文字データが記録されるとする．

但し，文字データは，整形式である必要はあるので，<や&はエンティティ参照，つまり，数値による文字参照でエスケープされる必要がある．

<formula notation="TeX">$\matrix{0 &amp; 1\cr&lt;0&amp;>1}$</formula>

必要であれば，要素formulaの内容として，他のモジュール，例えば，ISO 12083や，より最近のOpenMathやMathML DTDなどで定義されている要素を使えるよう，定義することもできる． ⁴⁵

要素formulaの内容がXMLデータではない時，その表記方法は，以下にある例のように，属性notationで記録されるべきである．

参考文献

<p>Achilles runs ten times faster than the tortoise and
gives the animal a headstart of ten meters. Achilles runs
those ten meters, the tortoise one; Achilles runs that
meter, the tortoise runs a decimeter; Achilles runs that
decimeter, the tortoise runs a centimeter; Achilles runs
that centimeter, the tortoise, a millimeter; Fleet-footed
Achilles, the millimeter, the tortoise, a tenth of a
millimeter, and so on to infinity, without the tortoise ever
being overtaken. . . Such is the customary version.


The problem does not change, as you can see; but I would
like to know the name of the poet who provided it with a
hero and a tortoise. To those magical competitors and to
the series
<formula notation="TeX">$$
   {1 \over 10} +
   {1 \over 100} +
   {1 \over 1000} +
   {1 \over 10,\!000} +
   \dots
   $$</formula>
the argument owes its fame.</p>

この例で，属性notationは，アノテーションの名前(TeX)を記録し，これは，当該文書のメタデータにあるデータと一致することが期待されている．

数学向けマークアップ言語(MathML)(Carlisle et al. (eds.) (2003)は，数学表現の構造や内容を記述するための語彙集である． MathMLには，2種類のマークアップがある．ひとつは，表示マークアップで，「web向けTeX」のようなものとして，表示構造を示すものである．もうひとつは，内容マークアップで，これは数学構造を示すものである．これらのマークアップの内容は，高校数学にある，演算，関係，関数などに相当するものである．上の例にあるTeXで表現されているものを，MathMLで表現すると，以下のようになる．

<m:math>
<m:mfrac>
  <m:mrow>
   <m:mn>1</m:mn>
  </m:mrow>
  <m:mrow>
   <m:mn>10</m:mn>
  </m:mrow>
</m:mfrac>
<m:mo>+</m:mo>
<m:mfrac>
  <m:mrow>
   <m:mn>1</m:mn>
  </m:mrow>
  <m:mrow>
   <m:mn>100</m:mn>
  </m:mrow>
</m:mfrac>
<m:mo>+</m:mo>
<m:mfrac>
  <m:mrow>
   <m:mn>1</m:mn>
  </m:mrow>
  <m:mrow>
   <m:mn>1000</m:mn>
  </m:mrow>
</m:mfrac>
<m:mo>+</m:mo>
<m:mfrac>
  <m:mrow>
   <m:mn>1</m:mn>
  </m:mrow>
  <m:mrow>
   <m:mn>10000</m:mn>
  </m:mrow>
</m:mfrac>
<m:mo>+</m:mo>
<m:mo>…</m:mo>
</m:math>

MathML 2.0では，'SemanticMath-Web'をサポートし，XML名前空間や，他のXMLの関連規格類，例えば，DOM，OMG IDL, ECMA Script，Javaなどをサポートしている．また，XHTML 1.1に部分的にMathMLの記述を挿入できるよう，MathMLの DTDをモジュール化している．

OpenMathプロジェクト(http://www.nag.co.uk/projects/OpenMath.html) は，OpenMath協会(OpenMath Society)(http://www.openmath.org/)で管理され，欧州情報技術開発戦略(ESPRIT)の，1997年9月に始められたマルチメディア規格団体(Multimedia Standards Initiative)が資金運営したものである．これは，web上に限らない，高い表現力を持つ，数学上のオブジェクトの意味を交換する，殆ど中心的な規格となっている．

OpenMath規格(http://www.openmath.org/V2/standard/index.html )は，以下のものから構成されている．

OpenMathオブジェクト．式の構造を示す(http://www.openmath.org/V2/standard/objects.html)．
内容辞書．意味内容を示す(http://www.openmath.org/V2/standard/cd.html)．
符号化方法．バイナリ形式(http://www.openmath.org/V2/standard/binary.html) とXML形式(http://www.openmath.org/V2/standard/xml.html) がある．

OpenMathとMathMLには，共通する点もある．共に，既定の要素名を使う，XMLデータで，規則を再帰的に当てはめて，オブジェクトを構造化している．これらの共通点により，この2つの規格は，対応付けは容易である．この2つの規格には，もちろん相違点もある．例えば，OpenMathでは，数的オブジェクトの表示をサポートしていない．また，OpenMathは，計算機数学の全範囲を賄うほどの記述力があるので，意味的な要素は，MathMLよりも多い．実際，内容辞書の特別な集合であるMathML CDは，MathML 2.0の内容マークアップ要素が対応する数学領域と同じ領域に対応している．

OMDoc(http://www.mathweb.org/omdoc/)とは，OpenMathを拡張し，公理，定理，証明，定義，(数式と数的な文を伴う)解説を構造化するマークアップを含めたものである．

式を，行中に挿入するのか，または段落として挿入するかの選択は，グローバル属性rendで指定することができる．グローバル属性nとxml:idは，以下の例のように，当該の式にラベルや識別子を記録するために使うことができる． ⁴⁶

<p>The volume of a sphere is given by the formula:
<formula xml:id="f12" n="12" rend="inline">
  <m:math>
   <m:mi>V</m:mi>
   <m:mo>=</m:mo>
   <m:mfrac>
    <m:mrow>
     <m:mn>4</m:mn>
    </m:mrow>
    <m:mrow>
     <m:mn>3</m:mn>
    </m:mrow>
   </m:mfrac>
   <m:mi>π</m:mi>
   <m:msup>
    <m:mrow>
     <m:mi>r</m:mi>
    </m:mrow>
    <m:mrow>
     <m:mn>3</m:mn>
    </m:mrow>
   </m:msup>
  </m:math>
</formula>
which is readily calculated.</p>
<p>As we have seen in equation
<ptr target="#f12"/>, ... </p>

14.3 画像データ向けの要素TEI: 画像データ向けの要素¶

以下の要素は，文書中に画像を挿入するときに使うためのものである．

figure 図表を示すまたは含む要素をまとめる．
graphic/ テキスト列中にある図，絵，図表の場所を示す．
binaryObject 行中の画像やその他のオブジェクトを示す，符号化されたバイナリデータを示す．
figDesc 図表の内容や現れ方について簡単な散文で解説を示す．当該図表を示さないで記録する場合に使用される．

要素graphicと要素binaryObjectは，コアモジュールの一部であり，この詳細は，3.9 図等の非テキスト内容で解説されている．

要素figureは，画像と，キャプション，その解説文を記録するものである．画像そのものは，要素graphicで示され，属性 urlで画像データの場所が記録される．例えば，以下のようになる．

要素figureには，3種類の内容を記録することが出来る．要素head を使い，当該画像の，説明調の見出しやタイトルを転記(または記録)することができる．例えば，以下のようになる．

<figure>
<graphic url="Fig1.pdf"/>
<head>Figure One: The View from the Bridge</head>
</figure>

図は，タイトルや見出しに加えて，コメントやキャプション扱いの段落を伴うこともある．複数の要素p や要素abを使い，当該図のキャプションや解説を記録することができる．

参考文献

<figure>
<graphic url="pullman.png"/>
<head>Above:</head>
<p>The drawing room of the Pullman house, the white and gold saloon
   where the magnate delighted in giving receptions for several
   hundred people.</p>
<figDesc>The figure shows an elaborately decorated room, at least
   twenty-five feet side to side and fifty feet long, with ornate
   mouldings and Corinthian columns on the walls, overstuffed
   armchairs and loveseats arranged in several conversational
   groupings, and two large chandeliers.</figDesc>
</figure>

上の例では，'The drawing room ... several hundred people'で始まる段落は，元の資料から転記されたもので，続いてある解説は，符号化する人が，ソフトウェアが図を表示出来ないときの為に用意した解説である．図を見ることに問題がある利用者を想定した電子版の場合には，要素figDescは，符号化する人ではなく，作者が書いたものを記録することもある．

<figure>
<graphic url="Fig1.jpg"/>
<head>Figure One: The View from the Bridge</head>
<figDesc>A Whistleresque view showing four
or five sailing boats in the foreground, and a
series of buoys strung out between them.</figDesc>
</figure>

画像に長いテキストが含まれている場合，恐らく，そのテキストは複雑な構造を取り，また，画像とテキストを分けるのは難しいだろう．この様な場合，符号化する人は，テキストを含む画像と見なすか (この場合，要素figureの中に，入れ子化した要素textを含める)，または，画像にあるテキストを，当該画像を含む要素の中に，独立した部分として要素textを使うか，決める必要がある．後者の場合，適切なdivn要素を使い，画像中にあるテキストを示し，その中で要素figureを使うことができる．この判断は，図とテキストの関係を，符号化する人がどの様に理解するかによって決められることになる．

図の中に，図の部分を見いだせるようなもの，つまり，下位図を含むものは，要素figureを入れ子化して記録することが可能で，例えば，以下のようになる．

参考文献

<figure n="6.45">
<figure n="a">
  <graphic url="./figs/6.45a.png"/>
  <ab type="caption">Parallel</ab>
</figure>
<figure n="b">
  <graphic url="./figs/6.45b.png"/>
  <ab type="caption">Perspective</ab>
</figure>
<ab type="caption">The two canonical view volumes, for the (a) parallel
   and (b) perspective projections. Note that -z is to the right.</ab>
</figure>

TEIスキームにおける他の要素と同様に，図にも識別子を付与することができる．これにより，他の要素と関連したり，リンクを張ることが出来る．この詳細は，16 リンク，分割，統合にある．詳細はそこで解説することにして，ここでは，よくある例を考えてみる．

2つの異なる画像を，ひとつの電子版に載せたいことは良くある．例えば，ひとつの画像は，低解像度の，いわゆる「サムネイル版」に相当するもので，これは，ユーザーが選択する為ものである．これが選択されると，高解像度の別の画像にアクセスすることになる． TEIでは，このサムネイル画像を，他の画像への「参照」と，捉えることになる．例えば，先の例を参照する為に，実体Fig1thに，完全なfig1のサムネイルが含まれているとしよう．この様な場合，3.6 簡単なリンクと相互参照で解説する要素refを使い，当該画像への参照を表現することができる．

<ref target="#IM1">Click here
<graphic url="fig1th.png"/>
for enlightenment
</ref>
<figure xml:id="IM1">
<graphic url="fig1.jpg"/>
</figure>

次に，画像の一部または全体を，それとは必ずしも隣接していないテキストと関連づける事を考えてみよう．これは，「コールアウト(callout)」と呼ばれることがある．転記モジュールがスキーマに組み込まれている場合には，テキストの部分や，画像の一部または全体を記録する属性を使うことができる．これらの詳細は，11.1 Digital Facsimilesで解説されている．また，ここで使える，その他の機能が16リンク，分割，統合でも解説されている．

以下の例では，画像fig1を，あるテキストの2章の一部と，3章にある一部と，関連づけるようとしている．ブラウザーのようなソフトウェアの場合，テキストの一部としてある画像を選択すると，次のテキストに進むことになるが，この様な仕組みは，特定のソフトウェアに依存するようなものではない．

必要なことは，まず，画像を特定することであり，続いて，画像の下位部分を参照することである．例えば，XMLによる画像表示方法であるSVGを参照することが考えられる．例えば，以下のようになる．

ここにある2つの要素ptrは，XMLファイルFig1.svgとしてある画像Fig1の，2つの領域を参照している．参照されるXMLデータは以下のようになっている．

次に必要なことは，リンクを構成する，文書中のテキスト部分を指定する方法である．一番簡単な方法は，グローバル属性xml:idを使うことである．

これらの領域と，関連する章にリンクを張るには， 16.1 リンクで解説する要素linkGrpを使うだけでよい．

この例では，SVGで表現されている画像は，XML文書とは独立したデータとしてあり，それがポインタによりリンク付けされている． SVG記述を，直接，TEIデータに埋め込むことも可能で，これは，名前空間SVGにある要素svgを使えるよう，要素figureの内容モデルを拡張することで，可能となる．これは，TEIスキーマをカスタマイズする他の場合と同じく， 1.2 TEIスキーマの定義で解説される方法で実現される．他の例は，16 リンク，分割，統合で解説されている．

14.4 画像データについてTEI: 画像データについて¶

画像の表現方法の，主要な分類として，ラスタ型とベクトル型がある．ラスタ型画像は，点の集合から構成されている．ラスタ型の電子画像は，スキャナやファックスなどの簡単な機器を使い，容易に作ることが可能で，とても一般的な画像データである．一方，ベクトル型画像は，例えば，線，円，矢，立方体といった，幾何学的単位の集合から構成されている．このような単位は，作ることが難しいので，ベクトル型画像は，高度なソフトウェア，例えば，建築工学で使われるCADシステムのようなものの，出力形式として使われている．

ラスタ型画像は，修正することが難しい．理由は，これが，点の集合で定義されているからである．例えば，線を拡大・縮小するにしても，ラスタ型のデータは，線としては特定されていないので，不可能である．作用を施す構成部分が特定できなければ，作用を施すことは出来ない．ラスタ型画像では，解像度，つまり，点の大きさが重要になってくる．これは，ベクトル型画像では，重要ではない．ベクトル型画像をラスタ型画像に変換するよりも，ラスタ型画像をベクトル型画像に変換する方が，より困難である．ラスタ型画像は，ベクトル型画像よりも，データサイズは大きくなる．また，ラスタ型画像には，各種の圧縮方法が存在する．これは，ラスタ型画像を保存・転送する方法が多様であることに依るものである．

動画像は，一般に，一連のラスタ型画像から構成されている．動画像に使われる圧縮法は，ラスタ型の静止画像で使われる圧縮方よりも，効率が高い(その主な理由は，隣接するフレームの似た部分にある冗長性による)．動画像の表現方法は，近年のホットな話題であり，本ガイドラインの読者も，自分たちでも使う前に，最新の情報を専門家から得たいと思うかもしれない．

圧縮方法には，主な分類として，「ロッシー」と「ロスレス」がある．ロッシーな圧縮法では，画像の詳細に関する情報，例えば，陰の境界の詳細を捨てることで，データ量を減らしている．従って，ロッシーに圧縮されたデータを展開すると，展開された画像は，元の画像と近似のものとなり，同じものではない．一方，ロスレスな圧縮法では，圧縮された画像と，元の画像は，同じものであることが保証されている．本当に，余分な情報しか削除されていない．従って，一般に，ロスレスな圧縮法は，元の画像と同じものを保証する代わりに，データ量は減らないことになる．

ラスタ型画像は，解像度で特性を決めることが出来る．解像度とは，インチあたりの，画像を作る点の数である．従って，解像度が2倍になると，データ量は4倍になる．これにより，画像の処理，例えば，表示には時間がかかることになる．動画像の場合には，時間の解像度に相当するものがある．１秒あたりのフレーム数のことである．符号化する人は解像度やフレーム数を，使用するソフトウェアのことを考えて，注意深く決める必要がある．本ガイドラインでは，これに関して何も推奨するものはない．ただ，その使用の一貫性とドキュメンテーションを求めるだけである．

どの様な画像であれ，一般には，デカルト座標を使い，場所を指定する．つまり，x軸とy軸，時にz軸や時間軸を使うことになる．但し，表現方法によっては，座標の方向が異なり，左から右，上から下，その他の方向性が使われている．また，座標も，物理的な単位か(例えば，インチ，ミリなど)または仮想的な単位か(例えば，点)のように異なっている．本ガイドラインでは，これらの中から特定のものを推奨することはしていない．但し，一度使ったものは，一貫すべきであり，また，そのことは，TEIヘダーーにある要素encodingDescに記録すべきである． ⁴⁷

画像とテキストを関連づける方法は，11.1 Digital Facsimilesで解説してある．

画像の色の表現方法も，多様である．白黒画像の場合，各点は白か黒のいずれかである．グレー画像の場合，各点はグレー程度で表現され，その程度は，システム毎に異なっている．カラー画像の場合，各点は各色で表現され，その程度や表現方法には，様々な制約により，異なっている．

14.5 画像データ形式TEI: 画像データ形式¶

先に紹介したように，画像形式には，途方に暮れるほどの種類がある．従って，以下にあるリストは，網羅的なものではない．また，このリストにあるものも，TEIが是とするものではない． SMILやCGM,JPEG,PNG, SVGなどを除き，リスト中にあるデータ形式は，多かれ少なかれ，私的なものである．従って，とても規格と呼べるようなものではない．但し，これらは，多くのソフトウェアで広く使われている．

以下にあるデータ形式は，現在，広く使われているもので，複数のソフトウェアでサポートされているものである．

BMP: Microsoft bitmap format
CGM: Computer Graphics Metafile
GIF: Graphics Interchange Format
JPEG: Joint Photographic Expert Group
PBM: Portable Bit Map
PCX: IBM PC raster format
PICT: Macintosh drawing format
PNG: Portable Network Graphics format
Photo-CD: Kodak Photo Compact Disk format
QuickTime: Apple real-time image system
SMIL: Synchronized Multimedia Integration Language format
SVG: Scalable Vector Graphics format
TIFF: Tagged Image File Format

これらのデータ形式について，以下で簡単に解説してある．出来る限り，各データ形式についての問い合わせ場所を示している．公式なデータ形式，とりわけISOや国家レベルの団体(ANSI, DIN, BSIなど)で公表されているものの多くは，その団体から情報を入手することができる．規格団体の住所は，当該国の団体一覧から見つけることができるだろう．

» 14.5.2 ラスタ型
Home | 目次

14.5.1 ベクトル型TEI: ベクトル型¶

CGM: コンピュータグラフィックメタファイル: ベクトル型画像形式で，ISO 8632:1987として制定され，1990 に改正されている．バイナリ形式，文字形式，テキスト形式による符号化がサポートされている．バイナリ形式以外の方が，データ交換形式として，特に，ネットワークで使う場合には，より安全である． CGMに関する資料は，ISOから入手することが出来る．また，ISOに参加する国家レベルの代表機関，例えば， AFNOR, ANSI, BSI, DIN, JISなどからも，入手可能である．
SVG: スケーラブルベクター形式: SVGは，2次元のベクトル型画像のデータ形式で，XML中にベクトル型とラスタ型のデータを混ぜて使うことができる． SVGは，the ScalableVector Graphics (SVG) 1.0 Specificationとして，2001年9月4日に，W3Cから勧告された．規格は，http://www.w3.org/TR/2001/REC-SVG-20010904/ から入手できる．
PICT: マッキントッシュドローイング形式: PICTは，マッキントッシュでサポートされているデータ形式で，他のシステムにおいても，限定した範囲で表示は可能である．関連資料は，Apple Computer Company, Cupertino,California USAから入手することが出来る．

14.5.2 ラスタ型TEI: ラスタ型¶

PNG: ポータブルネットワークグラフィックス形式: PNGは，ラスタ型形式の中で，唯一，私有でないデータ形式で，現在，広く使われている． PNGは，ラスタ型画像向けの，ロスレスで，軽量で，圧縮率もよいデータ形式である．また，PNGは，GIFに代わる，特許にはなっていないデータ形式であることから，TIFFに代わるデータ形式として使うことができる．インデックスカラー，グレースケース，フルカラーに対応し，アルファチャンネルにも対応している．サンプリング値は，1bitから16bitまで選択可能である． PNGは，1997年3月にIETFでRFC 2083として制定されている．
TIFF: タグ付き画像ファイル形式: TIFFは，現在，一番使われているラスタ型画像データ形式である．特に，白黒の画像ではよく使われている．また，複数のOSでサポートされている数少ないデータ形式のひとつでもある． TIFFの欠点は，複数のデータ形式のラッパーとして使えることである． TIFFに対応するソフトウェアの中でも，全ての多様な組み合わせてに対応していないものがある． TIFFでは，圧縮方法として，LZW, CCITT Group 4, PackBits を使用している．圧縮しないことも可能である． TIFFは，白黒，グレースケース，カラーに対応している． TIFFで使われたオプションは，全てTEIヘダーにある要素 encodingDescの最後に，散文形式で記録すべきである． TIFFはAlus社が権利を保有している． TIFFに関する資料は，Craigcook Castle,Craigcook Road, Edinburgh EH4 3UH, Scotland，または，411 First AvenueSouth, Seattle, Washington 98104 USAから入手することが出来る．
GIF: グラフィックス交換形式: ラスタ型画像データ形式で，カラー画像ではよく使われている． GIFは，CompuServe Information Servicesで開発されたものだが，現在では，多くのシステムで使うことができる． GIFに関する資料は，CompuServe Incorporated, GraphicsTechnology Department, 5000 Arlington Center Boulevard, Columbus, Ohio 43220, USAから入手することが出来る．
PBM: ポータブルビットマップ: PBMは，処理が簡単なデータ形式で，データ形式の透明性を保つために，圧縮をしないものである． PBMのデータは，一般的なファイルの圧縮ソフトを使えば，保存や転送のために，データを圧縮することは可能である． PBMデータを他の形式に変換する，またその逆の変換をする，パブリックドメインのソフトウェアが存在している． PBMに関する資料は，Jeff Poskanzerが著作権を持っているが，インターネット上から入手することが出来る．
PCX: IBM PCラスタ形式: PCXは，主にIBM PCで使われるデータ形式で，白黒とカラー画像に対応している． PCXに関する資料は，Technical Reference Manualとして，ZSoft Corporation, Technical Support Department, 450 Franklin Rd. Suite 100, Marietta, GA 30067 USAから入手することが出来る．
BMP: マイクロソフトビットマップ形式: BMPは，ラスタ型のデータ形式で，マイクロソフトのウィンドウズとプレゼンテーションマネージャーでサポートされている． BMPに関する資料は，マイクロソフト社から入手することが出来る．

« 14.5.2 ラスタ型
Home | 目次

14.5.3 静止画と動画のデータ形式TEI: 静止画と動画のデータ形式¶

JPEG:: JPEGは，CCITTとISOが支援する規格である． JPEGは，ISO/IEC Draft International Standard 10918-1と CCITT T.81として，規格化されている． JPEGは，多様な圧縮方法と共に，白黒とカラー画像を扱うことができる． JPEGは，データを移動する際には，CCITT Group IVと同様，カプセル化する必要がある．このカプセル化には，インターネット上では，TIFFまたは JFIF(JPEG File Interchange Format)がよく使われている．
QuickTime: アップルリアルタイム画像システム: QuickTimeは，アップル社が開発したデータ形式で，各種データと同期を取ることが出来る． QuickTimeには，動画，音声，ライトの管理などの情報を記録することが出来る． QuickTime形式のデータは，アップルやその他のコンピュータで再生することができる． QuickTimeに関する情報は，アップル社，10201 North de Anza Boulevard MS 23AQ, Cupertino,California 95014 USAから入手することが出来る．
Photo-CD: コダック写真CD形式: Photo-CDは，コダック社が開発したもので，写真を，ラスタ型画像データ形式で，CD-ROMに保存するためのものである(100枚の35mmフィルムを，1枚のCDROMに収めることができる)．データは，テレビやCD-Iシステム上で再生することができる． Photo-CDに関する情報は，コダック社，Research and Development, Headstone Drive, Harrow, Middlesex HA1 4TY, UKから入手することが出来る．
SMIL:: SMILは，W3Cが勧告する，マルチメディアデータを，同期を取りながら表現するためのデータ形式である． SMILは，簡単に時間合わせを定義することが可能で，細かな同期を取ることができる．また，空間レイアウトや，非テキスト・非画像データも直接取り込むことが出来る．また，時間軸を持つデータにリンクを張ることが出来る．また，各種のシステムにも対応している． SMIL 1.0 (http://www.w3.org/TR/REC-smil/ )は，1998年6月15日に，W3Cから勧告され，その後，SMIL 2.0 へと開発が進められている． SMIL 2.0では，場面転換，アニメーション，イベント駆動のインタラクション，拡張レイアウト機能，高度な同期機能が，SMIL 1.0に加えられている．また，他のXMLアプリケーション，特に，同期を取る必要があるものの中で，SMILデータを使うことができる．例えば，SMIL 2.0の部分データは，XHTMLデータやSVGデータに，同期情報を埋め込むために使うことができる． SMIL 2.0は，SMIL 2.0 Modulesのデータ(http://www.w3.org/TR/smil20/smil-modules.html )として使うことができる．例えば，そのようなデータとしては，SMIL 2.0 Language Profile(http://www.w3.org/TR/smil20/smil20-profile.html) がある．ここでは，SMIL 2.0のほぼ全ての機能がサポートされている．例えば，アニメーション，内容管理，レイアウト，リンク，メディアオブジェクト，メタデータ，構造，タイミング，場面転換効果などがある．そして，ブラウザが直接SMIL 2.0データからデータを再生出来るように考えられている． SMIL 2.0(http://www.w3.org/TR/smil20/)は，2001年 8月7日に，W3Cから勧告され，XMLスキーマを使う初めての規格となり，その後のXMLスキーマの地位を決めたものとなった．