オープンソースのオフィスソフトであるLibreOfficeの日本語コミュニティは、LibreOfficeを支援する非営利団体The Document Foundationの全面的な協力の下、2019年5月25日（土）と26日（日）の日程で、「⁠LibreOffice Asia Conference 2019 Tokyo」を開催しました。会場は日本橋・サイボウズ株式会社東京オフィスです。

アジア圏のLibreOfficeコミュニティとビジネスを活性させることを目的とした本イベントは、本年が記念すべき初の開催であり、またLibreOfficeコミュニティ自体にとっても初の国際地域カンファレンスとなります[1]⁠。

参加者は登壇者・ゲストも含めて、アジア圏から6カ国、ヨーロッパから3カ国、アフリカから1カ国[2]の計80名を集め、成功裏に終えることができました。

25日は年次カンファレンス「LibreOffice Kaigi」を含む「カンファレンスデー」であり、日本語1トラック、英語2トラックで、多数のトピックが話し合われました。

本稿では、Mark Hung氏による基調講演「LibreOffice CJK Bugs, Fixes, and Stories.（LibreOffice CJK不具合、修正、そして物語⁠）⁠」についてお伝えします。世界中で2億ユーザーがいるとされる大規模アプリケーションのCJK開発の一端を垣間見える、興味深い講演でした。

多彩なCJK関係機能を持つLibreOffice

Mark Hung氏は台湾在住のLibreOffice開発者で、主にWriterのCJK（Chinese/Japanese/Korean）問題を多数解決してきた、アジアを代表するLibreOffice開発者の一人です。

アジアを代表するLibreOffice開発者、Mark Hung氏
（⁠撮影：LibreOffice日本語チーム 近藤昌貴）

LibreOfficeは、プロジェクト創設時のマニフェスト（PDF）（日本語参考訳）に、ユーザーがその母語で利用できることを掲げています。そのために、ユーザーインターフェイスや各種ドキュメントを翻訳することはもちろん、CJK言語の正しいサポート、また和暦など地域独自の機能を用意することも大事だと考えています。

Hung氏は「LibreOfficeには特にCJKユーザー向けにデザインされたいくつかの機能がある」との切り口で、LibreOfficeが用意している以下のような機能を順に紹介しました。

• アジア言語向け組版（Asian Typography）
• 段落の「両端揃え」（⁠Paragraph Justified Alignment）
• テキストのマス目配置（Text Grid）
• 縦書き（Vertical Writing）
• ルビ（Asian Phonetic Guide）
• その他の言語ツール（Other Language Tools）
• ユーザーインターフェイスに現れないその他の機能
  • インプットメソッド対応
  • 欧米テキストとの混植
  • 異体字（IVS; Ideograph Variance Sequence）
  • 基本多言語面（BMP, 0x0000-0xffff）外のUnicode文字の扱いなど

そしてHung氏は「これらの機能はCJKユーザー向けにデザインされていています。言い換えれば、その他の国、特に欧米の開発者にとっては、これらの機能がどう動くべきで、どういうふるまいが期待されているかを理解し、不具合を修正するのは難しい」と述べました。

Hung氏の物語 〜なぜLibreOfficeの不具合を修正することになったか

2014年、400ユーザー、600PCクライアントほどを有するApache OpenOffice（以下AOO、※3）を展開していた組織内で、オフィスソフトの移行を推進する部署で働いていたHung氏。しばしばユーザーから、似たような質問を受けたそうです。

例えば「DOCX形式の漢数字の番号付箇条書きが、なんでアラビア数字になってしまうの？」「⁠なんで句読点の割付がおかしいの？」といった内容です。

それに対してHung氏の部署では、番号付箇条書きの問題について、AOOであらかじめスタイルを用意してそれを適用し、AOOの標準フォーマットであるOpen Document Format（ODF）で保存し直す、といった回答を用意し、質問を受けるたびにそれを教えていました。しかしスタイルの利用はユーザーにとって負担が大きいのではないかとHung氏は考えていたのだそうです。

そんなある日、「⁠簡体字中国語ならDOCX形式からインポートしても漢数字のままだ」ということを同僚に教えてもらい、箇条書きに使うような小さな数については簡体字も繁体字も同じ文字なのだから、振る舞いが異なることは奇妙だと考えたとのこと。

きっとこれはとってもとっても簡単に直せる問題に違いない、そう考えたHung氏は、DOCXをZIP展開して中身を見ることにしました。DOCXは（ODFもそうですが）複数のXMLファイル群をZIPアーカイブしたものであり、展開して適当なテキストエディタで開くことができるのです。そこで、簡体字文書と繁体字文書との差異を発見し、Google検索で意味を調べ、繁体字のときでも正しく動くパッチを作成してAOOに投稿しました。

しかしAOOでは、2014年8月に投稿したパッチが、レビューされるのには3ヶ月を要しました。そこでHung氏は、同じパッチを兄弟プロジェクトであるLibreOfficeにも投稿してみようと考えました。すると、なんと投稿の翌日にはレビューされ、3日後にはマージされました。このスピード感の違いにHung氏と同僚は興奮し、所属組織で翌年AOOからLibreOfficeに切り替えることに決めたそうです。

この変更で、組織内でのサポートコストは大幅に減り、Hung氏はLibreOfficeに継続的に貢献するようになりました。

CJKの問題から活動エリアを広げて、継続的な貢献

ついでHung氏は、氏がいままで実施してきたさまざまな貢献のなかから、いくつかをピックアップして詳細を説明しました。最初は主にWriterのCJK問題に取り組みましたが、近年はCJK以外の機能、またはImpressやCalcといったコンポーネントにも活動のエリアを広げています。

例えば、繁体字における句読点は、日本語とは異なり中央に打たれます。そのため、和文の割付ルールをそのまま適用すると繁体字ではレイアウトがおかしくなってしまいます。歴史的にオフィスソフトにとっては日本市場が重要だったためでしょう、多くのCJK機能は日本語前提になってしまっていたとのこと。繁体字の場合はそのルールを適用しないようにするだけで、いくつかの問題を解決できたのだそうです。

テキストのマス目配置は非常に多くの問題があり、とても実用に耐えられませんでした。そこで2017年にまとめて解析し、可能なかぎりの修正を行いました[4]⁠。

また異体字セレクタがついた文字の後ろでバックスペースを押下すると、異体字セレクタだけが消えてしまう問題は、LibreOffice日本語チームの榎真治氏が2017年のLibreOffice Conferenceで報告した不具合を元にHung氏が解決したものです。

ルビは、日本語では広く用いられますが、繁体字でも国語教育などで利用されるのだそうです。2015年にDOCXからのインポート問題を解決しました。さらには2018年には、台湾 繁体字の横書き時に必要とされるルビのレイアウトに対応しました。不具合解消ではなくあらたなレイアウト処理、UIの追加、ODF仕様への追加も伴う本格的な機能追加であり、Hung氏にとっても大きなチャレンジだったとのことです[5]⁠。氏の娘さんが小学校に上がって文字を学ぶ前に完成させて、LibreOfficeを使えるようにしたかった（が、間に合わなかった）という微笑ましいエピソードで会場の笑いも誘っていました。

CJK問題についてのこれから

Hung氏の活動によりLibreOfficeは、CJKの扱いに関して堅牢になり、また機能面でも少しずつですが進化してきています。しかしながら、まだまだやるべきことがある、とHung氏は言います。

LibreOfficeの不具合を管理するBugzillaには、不具合をグルーピングするための仕組みMETA Bugというものが存在します。CJKに関するバグを登録したCJK META Bugには依然として90個近くの未解決な不具合があります。

Hung氏が取り組んだ課題の一つはCalcのルビ対応。これについては、UI周りはWriterから流用することができるものの、内部表現やExcelからのインポート処理、当然テキストレイアウト処理、そしてODFへの仕様追加など、やることが多く、現在は中断中とのことでした。なお、Hung氏がこの問題に取り組むことを決めたのは、どうやら筆者が「日本ではExcelが愛されていて、たくさんのExcel文書が存在する」と言ったからだそうです。

その他、ルビ、均等割付、縦書きといった機能にもまだまだ欲しい機能や不具合が多くあります。特に縦書きは専用のMETA Bugに40個ほど不具合が登録されていて、なかなか安定しない状態です。現在、LibreOfficeはテキストレンダリングエンジンにHarfbuzzを用いていますが、不具合を直してもHarfBuzzのバージョンが上がると壊れる、ということの繰り返しが続いています。それでもWindowsとLinuxはそこそこですが、macOSについてはHung氏がMacを保有していないためお手上げで、より多くの開発者の手助けが必要だと言っていました。

最後に、Hung氏は「どうか私たちに加わってほしい、ついては翌日（5月26日）のCJK HackFest（CJKの問題を一緒に解決しようという集まり）に参加してほしい」と呼びかけて講演を終えました。

まとめ

Mark Hung氏は、控えめであまり強いメッセージを発しないタイプですが、それでも氏が活動してきた内容により、LibreOfficeのCJK環境が改善されてきたことに、語り口が淡々としているからこその凄みというものを感じました。このような地道な努力に、またそれを東京という場所で多くの人に説明してくれたことに対しても、日本のコミュニティから最大限の感謝を送りたいと思います。ありがとう、Mark!

Hung氏が何度か述べていたように、CJK機能はやはり当事者である我々が自分たちで問題を解決するしかないところがあり、今のところ、この領域で継続的に関わっているのが氏ひとりしかいない状況は改善しなければいけないと痛感しました。

そこで残念だったのが、せっかくアジア地区で開発を行っているメンバーが複数いるという絶好の機会であったのに、翌日のCJK HackFestにあまり人が集められなかったことです。今回のAsia Conferenceを機会に、アジア圏の、LibreOfficeのCJKに関心を持つ開発者を戦略的に増やしたいと感じますし、筆者自身もなにか挑戦する機会を、熱が冷めないうちに改めて作りたいと思います。そのときは、ぜひ多くの方に集まっていただけたら幸いです。

また、今回ご報告した基調講演以外にもLibreOffice Asia Conference 2019は、初回にふさわしく素晴らしいトークが多く、内容も開発、ODF標準化、移行、コミュニティビルディングと多岐に渡っていました。このような素晴らしいイベントを開催できたことを嬉しく思うとともに、ゲスト・登壇者・スポンサー・スタッフ、そしてもちろん参加者のみなさまにお礼を申し上げます。ありがとうございました。

現在、スライドとビデオの公開に向けて準備を進めていますので、公開の暁にはぜひ楽しんでいただけたらと思います。

• スライド公開： http://conf.libreoffice.jp
• ビデオ：YouTube「LibreOffice日本語チーム」チャンネル