おおしま しゅんすけ / Shunsuke Oshima
しゅんしゅん / Shunshun
1988年12月13日 / Dec. 13. 1988
日本語 あなたの御言葉は、わたしの道の光
詩篇 119:105
わたしの歩みを照らす灯。
English Thy word is a lamp unto my feet, and a light unto my path.
Psalms 119:105
עברית נר־לרגלי דברך ואֹור לנתיבתי
תהלים 119:105
学士論文。以下にアブストラクトを引用する。
私たちが普段用いる日本語や英語は左から右に記述される．しかし，ヘブライ語やアラビア語といった言語においては右から左に記述される．この二種類の方向を持つ文字を同時に表示する際，どのように表示するのかを定めたものとして Unicode Bidirectional Algorithm が存在する．しかし，これを XML を初めとするマークアップ言語に適用した場合，表示に問題が発生する．これは Bidi 問題と名付けられている．
本研究は プレーンテキストエディタ Emacs において Bidi 問題の解決を提案，実装する．
Paper for Internationalization and Unicode Conference 35. Below document is the abstract.
The Unicode Bidirectional Algorithm (UBA) is tailored for running text such as letters and newspaper articles. However, it is not suited directly for structured formats such as XML, HTML and programming languages. The source is often reordered in unpredictable ways that are unrelated to the logical structure of these formats, and therefore, source editing was essentially impossible. In this paper, we present a solution to this problem and its implementation in the text editor Emacs.
Emacs is a very flexible and extensible text editor providing an integrated environment for a wide variety of development tasks. Extensibility is based on Emacs Lisp, which we also have used for our research. While there have been some experimental implementations of bidirectional rendering in Emacs in the past, a full implementation of the UBA has only become available recently in Emacs version 24.
In earlier research, we implemented a Web-based simulation for XML and XHTML source rendering (IUC28) and a JavaScript-based experimental editor (IUC32). These implementations, however, were standalone and did not reach the level of practical usability.
The problem of bidirectional source editing for structured formats such as (X)HTML and XML can be divided into three areas. The first area is the treatment of syntactically significant characters, for example the ubiquitous angle brackets in HTML and XML. The UBA classifies them as neutral so that they follow the direction of their surrounding text, including potential mirroring, which is appropriate for running text. However, in HTML and XML they define the overall structure of the markup and therefore have to be treated as strong.
The second area is the treatment of bidirectional control characters such as LRM and RLM in source editing. Without intervention, such characters can be entered either literally, in which case they show their effect but are invisible and therefore difficult to edit, or they can be entered in escaped form (e.g. ‎ or ‏) in which case they are visible but not effective. Ideally, they would be both visible and effective.
The third area is bidirectional markup such as the 'dir' attribute or the <bdo> element in HTML, which for ease of editing should be reflected in the layout of the element content during source editing.
All the above areas can be addressed by carefully placing additional bidirectional control characters into the source text. We already had worked out much of the details of this placement in our earlier research. The main difficulty with using additional bidirectional control characters is that they are not part of the actual source text and therefore have to be distinguished from the same characters when they are part of the source, and have to be carefully removed for operations such as copying and saving. We implemented two different ways of doing this. One way uses a special Emacs property to distinguish these characters so that they can be removed before the relevant operations. The other way uses Emacs overlays, which by definition are not part of the text proper. In many ways, this would be the ideal solution, but overlays currently are not taken into account for bidirectional rendering.
Another problem is that the inserted bidirectional control characters have to be recalculated for every single editing operation. Limiting insertion to the currently visible part of the text being edited makes sure that we achieve acceptable performance even for very long source files. We are currently extending our implementation to work with TeX, and are looking into ways to fine-tune our implementation based on user feedback.
修士論文。以下にアブストラクトを引用する。
本研究は双方向文字列を含む XML の編集及び双方向文字列を使った IRI の構成要素の検証により，構造的言語における双方向文字列の可用性向上を目的とする．双方向文字列はアラビア文字などの右から左に読み書きする文字と左から右に読み書きする文字が混在する文字列である．その一般文書における表示について定めた Unicode Bidirectional Algorithm (Bidi アルゴリズム) が Unicode Consortium によって定義されている．しかし，構造的言語に適用すると表示に問題が生じるため構造的言語では双方向文字列の使用が困難となる．この問題は構造的言語が含む区切り文字に起因する．
双方向文字列を用いた XML においては，山括弧を始めとする XML の区切り文字を無視してBidi アルゴリズムが動作するため表示に問題が発生する．そこで区切り文字の持つ方向を固定するために，Bidi アルゴリズムで定義された制御文字を挿入する手法を採用した．HTML における Bidi アルゴリズムに関連した要素と属性についても実装を行った．これらの実装によって表示の問題を解決し，双方向文字列を用いた XML の編集を可能とした．本実装はプログラマに広く使われているプレーンテキストエディタ Emacs を対象とした．これは実用的エディタにおける初の実装である．加えて，同様の手法を用いることで TeX における問題も解決し，双方向文字列を含む他の構造的言語についても，この手法の有効性を示した．
IRI は非 ASCII 文字も利用可能な URI として定義されている．IRI において文字列の許容範囲が広すぎると表示に混乱が発生するが，狭すぎると不便になる．本研究では混乱なく，より多種の文字列が利用可能となることを目標とした．そのために IRI の区切り文字を考慮したシミュレーションを実施し，どのような文字列の利用を許可できるかを検証した．シミュレーション結果をX3D 出力フレームワーク Sardonyx を使って視覚化したことにより許可できる構成要素について二つの新たな知見を得た．構成要素の位置によるものと用いられる文字に関する知見である．今後はこれらを IRI における双方向文字列に関する新しい提案に応用していく予定である．
本研究では以上のように二種類の構造的言語を取り上げ，構造的言語特有の区切り文字に着目し，双方向文字列の可用性向上に貢献した．XML 及び TeX について編集を可能にし， IRI について許可できる文字列の性質を解明した．以上により，双方向文字列の利用が従来と比較して容易となった．
| 時代 | 所属部活 |
| 中学 JHS |
マイクロコンピュータ部 Computer Club |
| 高校 SHS |
演劇部 Drama club |
| 大学 Bachelor |
ACF |
| 大学院 Master |
AGGM |
東京都23区外 / Tokyo
shunshun9460 [at] gmail [dot] com