*PC・Webにおける訓点文処理の諸問題 [#l3728ee7]
RIGHT:千田 大介
#contents
**はじめに [#ca910b12]
***目的 [#u1abb211]
Unicodeへの収録漢字数の増加やソフトウエアの対応が進むにつれて、東洋古典文献のコンピュータ処理は格段に容易になった。文献のデジタル化については、障害はほぼクリアされたと言ってよいほどである。しかし、それでもまだ処理が困難な文献もある。その一つが訓点をともなう漢文文献である。
言うまでもなく、我が国では中国古典を漢文訓読という方法によって受容したばかりでなく、明治期以前には多くの文学作品や文書が漢文によって書かれていた。そのような文化的蓄積をデジタル化という現代的手法によって継承・発展していく上で、白文に訓点を付したいわゆる訓点文の処理は大きな障害となっている。我が国では漢文という文化の継承・発展への意識が薄弱でありデジタル化も進められていないからこそ、漢文文献の処理技術が確立されていない、と言い換えることもできよう。いずれにせよ、パソコンにおける訓点文処理方法の確立は、東洋学における大きな課題であると言えよう。
筆者は、パソコンにおける訓点文処理の問題への対策として、ワープロやWeb上で訓点を表現するためのツールを作成してきた。それらのツールは、ワープロ・メール・インターネットを使う程度のスキルの一般ユーザーでも手軽に漢文の処理ができることを目標に作成したものである。本稿では、それらのツールを紹介するとともに、ツール作成の経験をふまえて、将来的な大規模漢文文献コーパス構築をも視野に入れ、効率的な訓点文テキストのフォーマットについて考察してみたい。
***訓点文処理の現状 [#g8661cc3]
ワープロ・DTPソフトなどで訓点文を処理するのは少々難しい。返り点そのものは、縦書きで文字を下付にすることで大抵のソフトで問題なく表示できる。しかし、再読文字では文字の左右に同時にルビをふる必要があるが、それが少々特殊なテクニックを使わないと実現できないことが多いのである。
訓点文処理が可能なシステムとしてよく知られるのが、TeXである。大阪大学の金水敏氏による訓点用マクロがあり(( http://www.let.osaka-u.ac.jp/~kinsui/ ))、返り点・左右のルビなどを組み版することができる。ただし、TeXは理数系のドキュメント作成に向いたDTPソフトである一方、WISIWYGに対応していないなど人文系ユーザーが利用するには少々敷居が高いことも事実である。
新世代の日本語DTPソフトとして利用が広がっているAdobe InDesignでは、文字列の左右にルビを振ることができるが、左右同時に振ることはできない。しかし、ルビ文字列の位置の詳細な調整が可能であるため、再読文字の下の返り点もしくは本文の文字にルビを設定し、それを上の文字の左にまでオフセットさせることで、左右ルビを表現することができる。図の例では「未」の左ルビ「ず」を「レ」点に対して設定し、上にオフセットさせている。なお図の例では、返り点が本文文字の幅にほぼ収まるように、下付文字の左オフセット幅を、編集→環境設定→テキスト 以下で10%に設定している。
InDesignでは独自のタグ付きテキストデータによる文書のインポート・エクスポートが可能であるが、ルビを左右に付けた箇所は、以下のようになっている。
><ParaStyle:>萬里<cRuby:1><cRubyString:シテ><cRubyAlignment:AlignEdgeOneRuby><cMojiRuby:0><cRubyXOffset:9.921260>長征<cRuby:><cRubyString:><cRubyAlignment:><cMojiRuby:><cRubyXOffset:> 人<cRuby:1><cRubyString:いまダ>未<cRuby:><cRubyString:><cPosition:Subscript><cRuby:1><cRubyString:ず><cRubyXOffset:-9.212598><cRubyYOffset:-0.708661><cRubyPosition:1>レ<cPosition:><cRuby:><cRubyString:><cRubyXOffset:><cRubyYOffset:><cRubyPosition:><cRuby:1><cRubyString:かヘラ>還<cRuby:><cRubyString:>
オフセットの大きさはInDesign上では歯単位で指定するが、InDesignタグではmmになっている。この数値があらかじめわかっていれば、テキストベースで漢文を編集できることになる。
ワープロソフトで訓点文を作成するには、細かに文字のプロパティーを弄る必要が出てくる。一太郎の場合は、文字の行の左右へのシフト幅・上下文字間隔の設定の自由度が高いので、左ルビを振る場合、普通に入力した文字のサイズを下げ、行の左側（プロパティーでは下側）に100%シフトさせ、文字列がルビを付けたい文字の横に来るように文字幅を調整すればよい。そのような入力を支援するマクロも公開されている((訓点付け機。http://www.vector.co.jp/soft/win95/edu/se196381.html ))。
このほか、高校の漢文教師のニーズを念頭に置いた第一学習社の漢文エディタのようなソフトも存在する(( http://www.daiichi-g.co.jp/soft/kanbun/index.html ))。しかし、主に漢文試験問題の作成を目的としたものであり、大量の訓点文を組み版するような使い方には適さない面もある。
***Wordにおける訓点文処理 [#j5b16775]
国際的なデファクトスタンダードワープロソフトであるMS Wordは、本来が欧文用ワープロソフトであるため、縦書き処理はいささか苦手である。訓点文の処理については、文字列の左右ルビがやはりネックになる。
Wordでは、標準では文字列の右にしかルビを振ることができない。しかし、標準ではサポートされていない方法であるが、文字列の左にルビをふることができる。Wordではルビはフィールドコードで記述される。図のルビの場合、フィールドコードは、例えば以下のようになっている。
#ref(wr1.png)
{EQ \* jc2 \* "Font:ＭＳ 明朝" \* hps24 \o\ad(\s\up 23(ごとシ),猶)}
フィールドコードのプロパティは、それぞれ以下の意味を持つ。
>●jc2：ルビの文字揃え方法
>●"Font:ＭＳ 明朝"：ルビに使用されるフォントの指定
>●hps24：親文字のフォントサイズ
（）内
>●\up：ルビ位置の指定
>●23（ごとシ）：括弧内文字列「ごとシ」のベースラインからのシフト量
この「\up」の部分を「\do」もしくは「\down」に書き換えると、ルビを文字列の左に移動させることができる。
#ref(wr2.png)
ただし、この方法を使うとルビメニューを呼び出せなくなるし、ルビの文字そろえは均等割付に固定されてしまう。
文字列の左右ルビ振りは、組み文字のフィールドコードをアレンジすることで実現される。組み文字とは、行の中に小文字二行を挿入する場合に使用するが、例えば単位を「㌔」のように一文字幅で斜めに表示するときに用いられるもので、この点、割り注とは扱いが異なる。
組み文字のフィールドコードは、以下のようになる。
#ref(wr3.png)
{eq \o(\s\up 12(組み),\s\do 4(文字)) }
それぞれのプロパティーは以下の意味を持つ。
>●\up・\do：直後の括弧内文字列の位置
>●12(組み)・4(文字)：括弧内文字列のベースラインからのシフト量。「\do」の場合はベースラインからマイナス方向へのシフト量になる。
組み文字のフィールドコードでは、「\o(xx)」の中に入る「\s\yy (zz)」の数は二つに限定されない。フィールドコードを直接編集すれば、組み文字の行数を増やすことが可能なのである。これを利用すると、以下のように再読文字の左右ルビを表現することができる。
#ref(wr4.png)
このとき、再読文字部分のフィールドコードは以下のとおり。
#ref(wr5.png)
{eq \o(\s\up27(まさニ ), \s\up 0(將レ),\s\do 27( スルヤ)) }
ルビの部分は、それぞれ正・負の方向に27ポイントシフト、シフト無しで「將レ」を挿入している。なお、Wordのフィールドコードでは、括弧内の文字列は実際に表示される文字スタイルで、図のように表示される。
の方法は、しかし、正規にサポートされない裏技に属するので、Wordの動作が不安定になるなどの問題が発生する場合がある。最新版のWord 2003では比較的安定的に動作するようである。
また、フィールドコードを直接編集するのは、一般のユーザーにとって少々敷居が高い。そこで、筆者は、所定のタグ付き白文を訓点文に一括変換するWordマクロ、「訓点マクロ」を作成、配布している(( http://wagang.econ.hc.keio.ac.jp/index.php%E4%B8%AD%E6%96%87%E9%9B%BB%E8%84%B3%2F%E8%A8%93%E7%82%B9%E3%83%9E%E3%82%AF%E3%83%AD ))。
訓点マクロ用のタグ付き白文は、前掲の例であれば以下のようになる。
>鳥之<再>將、レ、まさニ、 スルヤ</再><読>死、しセント</読>、<読>其、そノ</読>鳴<読>也、ヤ</読><読>哀、かなシ</読>。
タグの体系は、以下の通り。
>●ふりがな用タグ：<読>漢字、振り仮名・送り仮名</読>
>●返り点タグ：漢字<点>返り点</点>
>●再読文字左右ルビ用タグ：<再>漢字、返り点、右ルビ、左ルビ</再>
タグに漢字を使用している点、入力は少々やっかいであるが、わかりやすさを優先した。タグ内部では、必要な要素を「、」区切りで並べる。ふりがな・訓点用のタグを用意したのは、一々書式設定を呼び出す手間を省くためである。また、入力支援のために、タグの整合性チェック用マクロも添付している。タグ付きの白文に対して訓点マクロを実行すると、訓点文に自動で置換される。
訓点マクロを利用すると、Wordで比較的容易に訓点文を作成することができる。ただし、整形された訓点文をもとのタグ付き白文に戻す機能をまだ実装していないため、タグ付き白文のバックアップは欠かせない。こういった問題点は、今後改善する必要がある。
以上のように、多少のテクニックが必要な場合であったり制限もあるが、印刷ドキュメント作成環境では縦書き訓点文を表現することができる。しかし、これまでに見てきたように、左右ルビの設定方法はアプリケーションによってさまざまである。このため、アプリケーション間でのデータ共有が困難であるという問題点も存在する。
**Webにおける訓点文表示 [#k745f159]
***縦書きWebページ [#h4ddbca9]
縦書きでWebページを読みたいという欲求は一定程度あるようで、インターネットが我が国に導入された当初から、縦書き表示したページや対応スクリプトが公開されてきた。それらは、透明テーブルを用いて擬似的に縦書き表示を実現したもので、ブラウザを選ばずに縦書きを実現できるという特色があるが、しかし、文字の並び順そのものを入れ替えるため、テキストのコピーが困難であるという欠点もあった。
その後、Internet Explorerはバージョン5.5で正式に縦書き表示をサポートした。FireFoxやOperaなどのブラウザで縦書きがサポートされていないとはいえ、IEは90%を超える圧倒的シェアを誇っているのであるから、Webページの縦書き表示に実用上の問題は無くなったと言ってよかろう。それにも関わらず縦書きWebページは一向に増える気配を見せない。
その原因は、IEで縦書き表示が可能なこと、および縦書き対応HTMLの記述方法が知られていないことにあるのではあるまいか。一般のユーザーがHTMLを編集する際にはHTMLエディタを利用するのが一般的であり、そこで提供されていない機能を利用することは稀であると思われるが、FrontPage・ホームページビルダーといった主要HTMLエディタは縦書き編集をサポートしていない。また、HTMLを直接編集して縦書きHTMLを記述しようとしても、市販のHTML解説書で縦書きの設定方法を詳細に解説しているものは稀である。
もう一つの、より重要なファクターは、そもそも縦書き表示へのニーズが乏しいことにあると思われる。実際、論文・文芸作品・新聞記事などなど、大抵の文献は横書き表示であっても何ら問題なく読むことができる。しかし、縦書きでなくては表現できない文献があるのも事実である。例えば、モンゴル語などの縦書きでしか記述されない言語がある。訓点文も縦書きでしか表現し得ない典型例である。しかし、従来縦書きが困難であったこと、また、返り点・左右ルビなどの処理が難しいことから、訓点文のWebにおける表現は画像やPDFに頼らざるを得ず、情報発信はあまり進んでいない。従って、縦書きWebページの普及は、情報流通の国際化・多様化を進める上で不可欠のものであると言えよう。
***WikiWikiと縱ゐき [#iba997d4]
筆者は、縦書きWebページに存在する前述のような敷居の高さを緩和する方法として、WikiWikiを活用することを着想し、縦書き対応Wikiクローン「縱ゐき」を開発した(( http://wagang.econ.hc.keio.ac.jp/tatewiki/tatewiki.cgi ))。
近年、Weblog（ブログ）とともに利用が広まっているWikiWikiとは、Webサイトマネージメントツールの一種である。Webサーバ上に設置したWikiWikiにアクセスすれば、だれもが自由にページを作成・編集することができる。また、それぞれのページはWikiWiki独自の簡略な整形ルールに従って記述するだけで正確なHTMLに変換・表示されるので、HTMLの知識が無くともWebページを簡単に作成することができる。
WikiWikiのこういった特色は、縦書きWebページのようにやや特殊な知識を必要とするHTMLを容易に実現させるのにも好適であると言える。つまり、縦書きHTMLの面倒な定義部分はWikiWikiのプログラムに自動生成させるようにしておけば、ユーザーは普通にWikiWikiのルールに従ってテキストを記述するだけで縦書きWebページを作成できるという塩梅である。
筆者が開発した縱ゐきは、日本語Wikiクローンの草分けとして知られるYukiWiki（バージョン2.0.5）をベースとして改造したものである。YukiWikiはPerlによって記述されたCGIであり、文字コードはEUC-JPになっている。これをまず、UTF-8にコンバートしてHTML生成部分のヘッダ情報などを書き換えた。その上で、HTML生成部分を改造して、縦書き表示に対応させるとともに、訓点文の表示をも実現した。
***縦書きHTMLの実際 [#l5672f42]
IEで実現された縦書きHTMLは、記述方法が少々込み入っており、原則を理解せずにHTMLを書くと、期待通りの視覚的効果が得られない。縦書きHTMLについては、マイクロソフトの公式解説(( http://www.microsoft.com/japan/msdn/web/ie/ie55/verticaltext.asp ))が参考になる。また、「縦ルビ」というサイト(( http://www012.upp.so-net.ne.jp/tateruby/ ))の解説もわかりやすい。以下、それらのサイトの解説と、筆者自身の実験結果をもとに、縦書きHTMLの記述方法についてまとめておく。なお、縦書きの表示確認はWindows XP SP2、Internet Explorer6.0で行った。
#ref(t1.png)
****基本設定 [#k6df85fe]
縦書きHTMは、CSS属性の「writing-mode」で設定する。具体的には、
><div style="writing-mode:tb-rl">&br;<p>縦書きHTMLドキュメントは、このように表示されます。</p>&br;</div>
のように、タグ内にstyleで指定するか、カスケードスタイルシートで、writing-modeを設定する。writing-modoは、縦書きの場合は「tb-rl」となる。即ち、トップからボトムへ、右から左へ、の意味である。横書きの場合は「rl-tb」。理論的には「tb-lr」で満州語のように縦書きで左から右に行を送れることになるが、執筆時点では前記2パターンにしか対応していない。
writing-mode属性を適用できる要素は、div・input・p・span・textareaなどだが、body要素には適用できないため、divやspanでブロックやインラインごとに指定することになる。
****テキストの高さ [#wb066d9f]
しかし、divで記述方向を指定しただけではまだ不十分である。上記の例では、以下のように表示される。
#ref(t2.png)
段落の高さが非常に低いのがわかる。これは、縦書き時の上下の高さは、デフォルトではウインドウの高さにはなっておらず、段落の文字列の長さに応じて自動調整される仕様であることに起因する。このため、文字列の長さが長くなるにつれて、段落の高さも変化する。
この問題を回避するためには、div要素でheight属性を指定し、ブロックの高さを指定する。前の例では、以下のように書き換えればよい。
><div style="writing-mode:tb-rl;height:100%">
#ref(t3.png)
****directionの指定 [#k5735441]
ウインドウに収まりきれない縦書きHTMLドキュメントを表示すると、IEは以下のように文章末尾を表示する。
#ref(t5.png)
縦書きHTMLでは、body要素でWriting-modeを指定できない。すなわち、HTMLドキュメントそのものは横書きとして扱われることになる。このため、縦書きHTMLを開いた際にも、横書きドキュメントの起点である左上から表示されてしまうのである。
この問題は、body要素とdiv要素の両方でdirection属性を指定することで回避できる。
><body style="direction:rtl">&br;<div style="height:100%;writing-mode:tb-rl;direction:ltr">
#ref(t6.png)
「rtl」とは「Right to Left」のことで、オブジェクトを読む方向が右から左であることを示す。
***縦書きHTMLの問題点 [#e160934b]
縦書きHTMLにも多くの問題がある。例えば、前の『吾輩は猫である』を開いた状態で、ホイールを回転させても、画面は上下にしか動かない。画面をホイールやキー操作で左右にスクロールさせるには、ページにヘッダブロックを挿入するなどして、複数ブロックに分けなくてはならない。
また、テーブルにも問題がある。以下のテーブルは、後図のように表示される。
><table border=1 height=50%>&br;<tr>&br;<td style="writing-mode:tb-rl">いち</td>&br;<td style="writing-mode:tb-rl">に</td>&br;</tr>&br;<td style="writing-mode:tb-rl">さん</td>&br;<td style="writing-mode:tb-rl">よん</td>&br;<tr>&br;</tr>&br;</table>
#ref(t7.png)
テーブルの開始位置が、常に左上に固定されているために、各セルの順序がソースと表示では逆になってしまう。このため、縦書きテーブルを作成する際には、データの並べ方に注意する必要がある。
***訓点文の表示設定 [#g2e25561]
縦書きHTMLを利用しても、IEは文字の左右にルビを振る機能を実装していないため、そのままでは訓点文を表現することができない。そこで、縱ゐきでは、罫線無しのテーブルを使って、擬似的に返り点および左右のルビを表現する方法を採った。以下に、訓点文の表示例と、少々長くなるがそのソースの一部を掲げる。
><table cellspacing="2" cellpadding="0" summary="「學而時習之、不亦說乎。">&br;<tr><td class="hidari"> </td>&br;<td class="naka">「</td>&br;<td class="migi"> </td>&br;</tr>&br;<tr><td class="hidari"> </td>&br;<td class="naka">學</td>&br;<td class="migi">まな</td>&br;</tr>&br;<tr><td class="hidari2"> </td>&br;<td class="naka"> </td>&br;<td class="migi2">ビテ</td>&br;</tr>&br;<tr><td class="hidari"> </td>&br;<td class="naka">而</td>&br;<td class="migi"> </td>&br;</tr>&br;<tr><td class="hidari"> </td>&br;<td class="naka">時</td>&br;<td class="migi">とき</td>&br;</tr>&br;<tr><td class="hidari2"> </td>&br;<td class="naka"> </td>&br;<td class="migi2">二</td>&br;</tr>&br;<tr><td class="hidari"> </td>&br;<td class="naka">習</td>&br;<td class="migi">なら</td>&br;</tr>&br;<tr><td class="hidari2"> </td>&br;<td class="naka"><span class="ten">レ</span></td>&br;<td class="migi2">フ</td>&br;</tr>&br;<tr><td class="hidari"> </td>&br;<td class="naka">之</td>&br;<td class="migi">これ</td>&br;</tr>&br;<tr><td class="hidari2"> </td>&br;<td class="naka"> </td>&br;<td class="migi2">ヲ</td>&br;</tr>&br;<tr><td class="hidari"> </td>&br;<td class="naka">、</td>&br;<td class="migi"> </td>&br;</tr>&br;<tr><td class="hidari"> </td>&br;<td class="naka">不</td>&br;<td class="migi">ず</td>&br;</tr>&br;<tr><td class="hidari2"> </td>&br;<td class="naka"><span class="ten">二</span></td>&br;<td class="migi2">ヤ</td>&br;</tr>&br;<tr><td class="hidari"> </td>&br;<td class="naka">亦</td>&br;<td class="migi">また</td>&br;</tr>&br;<tr><td class="hidari"> </td>&br;<td class="naka"><a title="" href="tatewiki.cgi%E8%AA%AA">說</a></td>&br;<td class="migi">よろこ</td>&br;</tr>&br;<tr><td class="hidari2"> </td>&br;<td class="naka"><span class="ten">一</span></td>&br;<td class="migi2">バシカラ</td>&br;</tr>&br;<tr><td class="hidari"> </td>&br;<td class="naka">乎。&br;</td>&br;<td class="migi"> </td>&br;</tr>&br;</table>
#ref(t8.png)
td要素は、CSSによってwriting-modeと文字寄せの方向を指定してある。ルビのセルでは相対サイズで55%に設定し、返り点は下付ではなくフォントサイズを下げ文字揃え位置を左上にすることで表現している。なお、セル内で文字寄せを指定する際にも、テーブル開始位置が左上になっている影響を被り、見かけ上の左右の文字寄せは「vertical-align」で、上下の文字寄せは「text-align」で指定する。例えば、「vertical-align:bottom;text-align:left」であれば、セルの上左詰めということになる。
テーブルは、罫線をゼロ、背景を透過色に設定し、前述のセル表示順序の問題を回避し適正な位置にルビが表示されるように順序を調整した。
以上のように、従来画像でしか表現できなかったWebページにおける訓点文表示を、縱ゐきではテキストによって表示することに成功した。縱ゐきの最大の長所は、以上の非常に込み入った縦書きHTMLや訓点文を、HTMLの知識が無くとも比較的簡単な整形ルールに従って記述するだけで表現できる点にある。
縱ゐきでは、以下のルールに従って訓点文を記述する。
>●行頭に「<<」を記述し、その行を訓点ブロックに指定する。&br;●基本形：&kt(右ルビ,右送り,左ルビ,左送り){漢字}[返点]&br;●省略形a：&kt(右ルビ,右送り,左ルビ,左送り){漢字}&br;●省略形b：漢字&kt[返点]
前図の例は、以下の通り。
><<「&kt(まな,ビテ,,){學}而&kt(とき,二,,){時}&kt(なら,フ,,){習}[レ]&kt(これ,ヲ,,){之}、&kt(ず,ヤ,,){不}[二]&kt(また,,,){亦}&kt(よろこ,バシカラ,,){説}[一]乎。
「說」はハイパーリンクを設定したため、[[]]でくくってある。一々タグ付けするのは少々面倒であるものの、ルール自体はそう複雑ではない。
***縱ゐきの長所と課題 [#ldd7d5db]
縱ゐきでは、整形ルールに従って作られたテキストをCGIプログラムが自動変換して縦書き・訓点文をWebページ化する。このため、PDFや画像を利用したWebページよりも遥かに軽快に動作する。
Webでの訓点文表現は、XHTML1.1で勧告されているruby要素の左ルビ属性を実装するユーザーエージェントが登場すれば、テーブルを用いずとも表現可能になるものと期待される。そのようになっても、縱ゐきの場合は、もとのテキストデータから訓点文への変換ルーチンを見直すだけで対応できるから、データが無駄になることはない。また、Wikiの整形テキストをコピーすることで、他の縱ゐきとデータ交換することも可能である。
しかし、縱ゐきではテーブルを用いて擬似的に訓点文を表現しているため、ワープロソフト等へのコピー＆ペーストができない。この問題は、前に紹介したWord用訓点マクロを書き換え、訓点生成用タグの書式を縱ゐきと統一することで改善をはかっていきたい。
また、縱ゐきは現状では縦書き未対応のユーザーエージェントでの表示について考慮していない。ユーザーエージェントを認識して異なる訓点文生成ルーチンを実行するように改造する必要があろう。プログラミング上の問題点としては、このほか、訓点文部分の改行をユーザーが手動で設定しなくてはならない点がある。単文や詩歌であればこれでも構わないが、長文を載せる場合は手間がかかる。この点も、将来、改善する必要があろう。
**おわりに [#w738b458]
以上、パソコンおよびWebにおける訓点文処理環境について、筆者の作成したツールの詳細を紹介しつつ検討してきた。TeXの金水マクロを除けば、難易度の差こそあれ、いずれも何らかの裏技に属する方法で左右ルビなどを表現しなくてはならないのであり、このことが訓点文のデータフォーマットの統一、ひいては共有化を進める上で一つの障害になっていることがわかる。
しかし、縱ゐきや訓点マクロのように、独自のマークアップを施したテキストを、プログラムによって訓点文に変換・表示するシステムの場合、このデータ共有の問題を解決できるばかりか、将来ソフトウエアの仕様変更によってより簡単な訓点文表示が可能になったとしても、プログラムの改編だけで対応できるという利点もある。
はじめに述べたように、訓点文文献は我が国の貴重な知的財産であり、その保存および有効活用をはかるためにも、大規模デジタルデータベース化は欠かせないと考える。大規模データベースのデータ形式は、XMLなどによるマークアップテキスト以外の選択肢はあり得ないが、そのデータのより広範な流通をはかり、有効なデータベースとするるためには、マークアップテキストを印刷・Web表示用に自動変換するプログラムについても併せて作成・配布する必要があろう。逆にいえば、マークアップテキストの企画統一がなされてはじめて、訓点文のデジタル化および流通の基盤がようやく整うのである。本稿で紹介してきた訓点文処理のための試みは、そのような総合訓点文処理システムを構想する上で、重要な視座を提供しているといえよう。
>※平成14～平成16年度科学研究費補助金（基盤研究(C)）研究成果報告書『次世代中国古典文献データベース構築の基礎的研究』（平成17年3月）、pp121～120～136
![[PukiWiki]](image/logo.png "[PukiWiki]"){kind=logo}
