新年あけましておめでとうございます。 今年もLibreOfficeやApache OpenOfficeの動きを紹介します。

昨年のLibreOfficeはあまり大きなトピックはなく，むしろ現段階ですでに今年に期待が持てるくらいです。 Apache OpenOfficeは，昨年も変わらず低調でした。

では，今年も2017年の振り返りと2018年の動きを詳しく見ていきましょう。

注意

本稿で記述している日付はJSTであったりUTCであったり，はたまたほかのタイムゾーンであったりするため，最大で1日程度の差があることをご了承ください。また多数リンクがありますが，中にはご覧になっている時点でリンク切れのものもありえます。こちらもあらかじめご了承ください。そのほか，行き交うメールの量が膨大すぎて全部に目を通せないため，見落としているものもあるかもしれません。何かお気づきの点があればコメントいただけますと幸いです。

2017年のLibreOffice

リリース状況

LibreOfficeは昨年もたくさんのリリースが行われました。以下が一覧です。開発版は含んでおらず，あくまでリリース版のみです。

このように16回のリリースが行われました。一昨年は行われなかったX.Y.7のリリースが2回あったのが特徴でしょう。しかし5.2.7も5.3.7も現在はサポート期間が終了しているため（※1⁠）⁠，5.4.4（またはそれ以降）を使用するのが推奨です。

※1

The Document Foundationが提供しているバイナリを使用している場合です。Linuxディストリビューションなどで提供されているバイナリはこの限りではありません。

Linux用パッケージの配布方法の多様化

Linux用のパッケージは従来の形式であるRPMとDebのほか，Flatpak，snap，AppImageでも配布されています（図1⁠）⁠。

Flatpakとsnapに関しては以前から用意されていましたが，より安心してインストールできるようになったという変化があります。具体的には，Flatpakではバイナリをダウンロードしてインストールする方式だったのがFlathubというリポジトリからインストールできるようになりました。snapでは昨年までベータ扱いだったのが今年からはstable（安定版）扱いになりました。

AppImageはThe Document Foundationがリリースしているバイナリを再パックし，一つのバイナリにすることによってポータブルに使用できるというメリットを生み出しています（※2⁠）⁠。

※2

これが実に便利で，かつさまざまなバージョンでリリースしているため，後に紹介する図3と図4はAppImage版を使用しています。

ミュンヘン市での動き

Linux Daily Topicsの「2017年11月27日　ミュンヘン，LinuxからWindowsへの移行を決定，移行費用は5000万ユーロ」で既報ですが，LibreOfficeを採用しているドイツのミュンヘン市がプロプライエタリなソフトに回帰することになりました。

ミュンヘン市はただLibreOfficeを使うだけでなく，The Document Foundaionのアドバイサリーボード，すなわちスポンサーにもなっています。個別にはLibreOfficeのQt/KDE5へのポーティング作業のスポンサーもしているようです（※3⁠）⁠。

※3

ちなみに現段階では使いものにならないそうです。

The Document Foundationも2月に声明を発表したり，「⁠ミュンヘン市を自由なままに」キャンペーンに賛同したりしていますが，政治的な決定はたとえどんなに誤ったものであっても覆すのは難しいです。

救いがあるとすれば，これまでの成果はソースコードという形で残されており，オープンソースライセンスの下で利用できることでしょう。

台湾での動き

すでに台湾ではLibreOfficeが広く使われるフェーズに入っています。LibreOffice Conference 2017（後述）で行われたFranklin Wengさん（リンク先はインタビュー）による「Migrating LibreOffice to Organizations ‑ What's Still Needed?」を読むとそれがよくわかります。

また，Cheng-Chia Tsengさんによる「The Localization (CJK) Challenges and Possibilities in Taiwan」とMark Hungさんによる「Overview of Writer Text Grid Formatting」は日本語でも抱えている問題を含めて発表しています。特にMarkさんはたくさんのCJK関連バグを修正しており，その内容も発表しています。

同じCJKとしてまとめられる台湾の状況から，日本でもLibreOfficeが普及するために必要なのは

• 政府や地方自治体など，広く公共団体で使われるようになる
• 翻訳者や言語固有のバグを修正する開発者を増やす
• 普及・啓蒙活動

であるという認識を新たにします。現状はどれも全く足りていません（※4⁠）⁠。

※4

日本語の組版処理を仕様のまま実装してくれる人とかいないものでしょうか……。きれいに組めなくて頭を抱えることが多いです。

余談ではありますが，開発者は無償で開発を行う必要はなく（※5⁠）⁠，どこかの企業から依頼を受けてバグを修正し，それを取り込んでもらってもいいわけです。また，大規模導入でサポートサービスを購入し，そこでバグを直してもらう，という手も考えられます。

※5

ついでにいうと翻訳者も無償でやる必要はなく，恩恵を受けている企業が人を出して行うのがベストだと思います。安定的にできるのと，オフィススイートに精通していることがその理由です。筆者を含む現在のボランティア翻訳者は，必ずしもオフィススイートに精通しているわけではありません。