デジタル世界でチベット語を一流の市民にする
(bdrc.io)- チベット語文献は、一般的なワープロソフトが想定する短い段落という前提に合わないため、デジタル編集・出版ツールで長らく現実的な制約を受けてきた
- BDRCは、チベット語がデジタル環境で適切に扱われるよう技術改善を進めてきており、今回はLibreOfficeの非常に長い段落への対応が重要な進展となった
- 強制改行のない長いテキストの流れと少ない空白は、英語圏の文書処理方式とは異なるため、長いチベット語文献を開いたり変換したりする際に性能問題が起きやすかった
- Jonathan Clarkによる修正により、LongchenpaのYishindzöのような153ページ分の1つの「段落」からなるテキストも高速に開いて編集できるようになり、RDFからPDFへの変換は45分以上停止していた処理が13秒で完了するようになった
- 非常に長い段落への対応は、2024年9月27日に公開されたLibreOffice 24.8.2に統合され、チベット語ユーザーが無料のオープンソース出版ツールをより現実的に活用できるようになった
チベット語のデジタル対応が重要な理由
- BDRCの重要な使命の1つは、チベット語をデジタル世界の一流の市民にするための技術革新である
- チベット人は8世紀に仏教を導入して以降、執筆、革新、技術に大きなエネルギーと資源を注いできた
- チベット文字と古典語は、サンスクリット語と中国語の仏教文献をチベット人が理解できる言語へ翻訳するために作られた
- 14世紀には、経典の翻訳本とヒマラヤの著者たちによるチベット語仏教文献数千巻を大量生産するため、木版印刷が広く採用された
- チベット語コンピュータフォントの登場とUnicode Standardへの収録は、チベット語がデジタル世界へ統合される過程における大きな飛躍だった
一般的なワープロソフトと合わないチベット語文献の構造
- チベット語文献には、まだすべてのツールやアプリケーションが十分に対応できていない特性がある
- 特に、ヨーロッパ語式の段落という概念が同じようには適用されない
- チベット語テキストは、強制改行なしに続く長い流れとして処理しなければならない場合が多い
- この流れは、時に数百ページから数千ページに及ぶこともある
- 一般的なワープロソフトは、もともと英語テキストを念頭に設計されている
- 比較的短い段落を前提としている
- 単語間に空白があり、その空白幅を柔軟に調整できると想定している
- チベット語文献は段落の長さに事実上制限がなく、空白が非常に少ないため、こうした前提と衝突する
- その結果、長いチベット語テキストを開くとワープロソフトが非常に遅くなったり、まったく動作しなくなったりすることがあり、本格的な出版プロジェクトには使いにくかった
LibreOfficeの修正と実際の性能変化
- LibreOfficeは、MS Wordに着想を得た成熟した安定的なオープンソースのワープロソフトの1つであり、Linuxを含む複数のプラットフォームで無料で利用できる
- WordやInDesignのような商用ソフトウェアは長いチベット語テキストを処理できるが、費用が高く、アジアの複数地域では海賊版として使われる場合が多い
- LibreOfficeが長い段落を処理できなかった間は、チベット語出版のための実質的な無料ツールが存在しなかった
- BDRCのCTOであるElie Rouxは、2015年にこの問題をLibreOfficeへ報告した
- LibreOfficeのコードに手を入れる作業は数週間の研究開発を要する大きなプロジェクトであり、しばらく進展がなかった
- 数週間前、Jonathan Clarkがこの問題を担当して修正した
- LongchenpaのYishindzöは、153ページ分の1つの「段落」で構成された長いテキストである
- 現在はLibreOfficeで高速に開いて編集できる
- 当該テキストはBDRCアーカイブのyid bzhin mdzodで閲覧できる
- この特定テキストのRDFファイルをPDFに変換する処理は、以前は45分後も停止したままだったが、現在は13秒で完了する
- 非常に長い段落への対応は、2024年9月27日に公開されたLibreOffice 24.8.2に統合された
- BDRCは、チベット語編集ソフトウェアで感じる不足点や利用体験に関するフィードバックを求めており、コミュニティとの協力によってチベット語のデジタルツールを継続的に改善していく考えである
2件のコメント
Hacker News のコメント
ペンシルベニア州ニュー・ホープ出身のヒッピーで、初期のコンピュータハッカーだった Jim Woolsey は、チベット語のデジタル化における重要な初期人物の一人だった
1993年のインタビュー https://www.mcall.com/1993/10/08/new-hope-man-computer-guru-... は興味深いタイムカプセルで、それ自体読む価値がある
家族の知人であり、重要だが過小評価されているこの仕事への彼の並外れた献身を、いつも尊敬していた
「文書にはほどほどに短い段落がある」も、プログラマーがテキストについて信じている誤った命題のリストに入れるべきだと思う
OpenOffice には段落あたり65534文字というハードリミットがあり、LibreOffice がこれをなくすにはかなりの作業が必要だった: https://bugs.documentfoundation.org/show_bug.cgi?id=30668
テキストの方向、発音区別符号、句読点は当然思い浮かんだが、塊の分割は普遍的だと思っていた
だが違った: 「欧州言語における段落という組版上の概念は、チベット語テキストには実際には同じ形では存在しない。その結果、チベット語テキストは強制改行なしに途切れない長いテキストの流れとして扱わなければならないことが多く、時には数百ページ、数千ページに及ぶ」
'\n'を探し、チベット語に敗北したのだろう敬意を込めて言えば、チベット人の革新性は The Nine Billion Names of God でも認められている: https://en.wikipedia.org/wiki/The_Nine_Billion_Names_of_God
そして彼らの革新は、この本、少なくとも Wikipedia のあらすじ要約よりもはるかに広い
「比較的短い段落、おそらく数ページまで」のような表現は、自分がいかに特定の視点から世界を見ているかを示していて面白い
1ページ分の段落すら書いたことがない気がする
名前は忘れたが、ある作家が数ページにわたる意識の流れを段落や句読点なしで書いていたのが、いちばん近い例として思い浮かぶ
例えば James Joyce や David Foster Wallace がいる
この取り組みはかなり昔から進められてきた
チベット語の発音を教える古い HyperCard スタックもあり、16ビットサウンドまで入っている: https://hcsimulator.com/Learn-Tibetan
いろいろな意識の流れ的な文章や関連する文体も段落、場合によっては他の伝統的な構造まで避けるのに、ワープロが長い段落で苦労するというのは少し意外だ
それほど一般的ではなくても、まったくないわけではないし、作家や出版社は何とか処理しているものだと思っていた
最近のランダムな例: https://en.wikipedia.org/wiki/Ducks,_Newburyport
超長文段落のサポート、あるいはその欠如をどう解決したのか、詳細が気になる
誰か知っている？
キャッシュで O(n^2) の影響を減らす、かなり短い変更
この変更には、極端に大きな段落を含む文書に対するスケーラビリティ改善が含まれる
LF 制御文字を考慮するようレイアウトコンテキストサイズを縮小し、段落配置中の典型的なアクセスパターンのために VCL が
vcl::ScriptRun::next()を O(n^2) で呼び出していたものを、既存のグローバル LRU キャッシュを使うように変更して、相当なオーバーヘッドを避けるベンガル語とアッサム語がチベット文字を使うと理解しているのだが、チベット人が自分たちの言語に使う文字とどれくらい似ているのか、誰か知っている？
ベンガル語とアッサム語はインド・アーリア語派で、チベット語はまったく別の語族であるシナ・チベット語族
ベンガル語話者として、チベット語と50%相互理解可能だという言語が使われているブータンに行ったとき、何も理解できなかった
仏教由来の借用語がかなりあると思っていたが、dharma や karma のような単語でさえチベット語ではまったく違って聞こえて驚いた
https://en.wikipedia.org/wiki/Tibetan_script
言語というのは本当に興味深い存在です
学びやすく、広い地域でコミュニケーションの媒介にもなり、また習得は難しいものの、非常に複雑な構造や思考を作り出し、それを話者同士で伝え合えるようにもします
チベット語は、このスペクトラムのどのあたりに位置するのでしょうか？
高度に技術的なテーマには、高度に技術的な専門用語が付きものです
ただし、ある言語が持つ微妙なニュアンスの量が、その言語で表現できる思考の複雑さと関係している、という点については確信がありません
私はLibreOfficeプロジェクトのボランティアであるEyalで、右から左へ書く文字体系と複雑文字レイアウトスクリプトに関する品質保証を多く担当しています
該当記事へのリンクを投稿してくれたthunderbong3に感謝し、チベット語の性能改善を実装したThe Document Foundationの新しいRTL-CTL-CJK担当開発者、Jonathan Clarkに心から感謝します
LibreOfficeで遭遇し報告しているバグの大半は、特定の文字体系に限られない一般的な問題です
たとえば、コンテンツが右から左であり得ることを忘れたコードが、そのような場合に誤動作する、といったものです
文字体系別のバグの多くは、最も広く使われているArabic文字に関係しており、この文字はFarsi、Urdu、Javaneseなどでも使われています
それでもTibetanやMongolianのように、比較的広く使われていない文字体系に関する課題もあります: https://bugs.documentfoundation.org/show_bug.cgi?id=115607
このメタバグは、Mongolian、Tibetan、Uyghur、Zhuang、Kazak、Xibo、Dai、Yi、Miao、Jingpo、Lisu、Lahu、Waなどの課題を追跡しています
こうした言語に特有の問題が本当に少ないのか、それとも利用が多くなく、ユーザーがバグを投稿する動機も十分ではないのかは分かりません
それでもJonathanの最近の修正が示すように、開発者の時間が確保されれば、それらを解決しようとする関心は確かにあります
こうした文字体系や国・文化間の文書編集における公平性に関心がある人は、自分の知っている言語でLibreOfficeを使ってみて、バグを見つけたらBugZillaに投稿してくれるとありがたいです: https://bugs.documentfoundation.org/
LibreOfficeプロジェクトを運営するThe Document Foundationへの金銭的支援も検討してください: https://www.libreoffice.org/donate/
私たちは世界でも大きな自由オープンソースプロジェクトの1つで、定期利用者は数千万人、もしかすると1億人以上おり、理事会メンバーも数十か国の出身者で構成されています
しかし、プロジェクトに資金や時間を大きく投じる大企業はありません
CollaboraやAllotropiaのような一部の商業企業は貢献していますが、多くの根本的な課題は彼らの顧客ニーズに十分近いものではありません
そのため、RTL-CTL-CJKサポートを強化するためにJonathanを直接雇用することにし、こうした取り組みは個人ユーザーからの寄付によって可能になっています
韓国語に分かち書きがなかったら大変だったでしょうね。