短期集中連載？ LibreOfficeをWindowsで開発してみよう：その① ビルド環境の構築
GWでヒマ？ なのでLibreOfficeの開発というかバグ直しみたいなのに挑戦してみたいですね。 先日買ったThinkpad T470は結局しばらくWindowsで運用することにしたので、じゃあWindowsで開発に挑戦してみましょうと。
ということで短期集中連載開始。途中で力尽きたらごめんなさい。
有識者が皆様にノウハウをご教示するみたいなものではなく、むしろ私の作業メモ。なので嘘とか間違いもあるかも……。
さてと。初回のこれはビルド環境の構築。
といってまだビルドはできてません。 ./autogen.sh が通ることを確認したところまで。
Windowsの環境作ったの記憶にないほど昔か、もしかして初めてなのですが、今はlodeあるんで楽ですね。
でもlodeだけでは環境できないので、以下も参照して必要なものも入れないといけません。
Visual Studio 2019 Communityのインストール
最初はBuilding LibreOffice on Windows with Cygwin and MSVC: Tips and Tricksの方を参照しつつ。
Visual Studioをインストールします。私はchocolateyでさくっと。 管理者モードで実行したコマンドプロンプトにて：
C:\WINDOWS\system32>choco search visualstudio2019 Chocolatey v0.10.15 apincoree-vsix 3.9 [Approved] ... visualstudio2019-workload-nativedesktop 1.0.0 [Approved] ... visualstudio2019teamexplorer 16.5.4.0 [Approved] visualstudio2019professional 16.5.4.0 [Approved] visualstudio2019testagent 16.5.4.0 [Approved] visualstudio2019testcontroller 16.5.4.0 [Approved] visualstudio2019buildtools 16.5.4.0 [Approved] visualstudio2019community 16.5.4.0 [Approved] visualstudio2019enterprise 16.5.4.0 [Approved] 38 packages found.
ドキュメントによれば「Desktop development with C++」ワークロードも導入せよとのことですので、 たぶん「visualstudio2019-workload-nativedesktop」を一緒に入れることもできると思いますが、 私はいったん本体だけ入れて各種コンポーネントは後入れすることにしました*1。
C:\WINDOWS\system32>choco instal -y visualstudio2019community
次はコンポーネントのインストール。ドキュメントによれば以下のものが必要だそうです。
- MSVC v142 - VS 2019 C++ x64/x86 build tools (v14.2x)
- C++ core features
- Windows 10 SDK (10.0.xxxxx.x)
- Windows Universal C Runtime
- C++ ATL for v142 build tools (x86 & x64)
- .NET Framework 4.x.x SDK
- C++ 2019 Redistributable MSMs (only required to build MSI installer; not part of the "Desktop development with C++" workload)
- C++ Clang Compiler for Windows (9.0.0) (not part of the "Desktop development with C++" workload)
Visual Studio 2019起動して、「コードなしで続行」選んで、ツール > ツールと機能の取得 を開きまして。
ついで「個別のコンポーネント」で、「.NET Framework 4.8 SDK」および「C++ 2019 再頒布可能パッケージ MSM*2」の二つを選んで。
これで「ダウンロードしながら変更する」して「変更」を押下するとよい……はず。
JDKのインストール
お次はJDKを入れます。ドキュメントによれば：
Java Development Kit (JDK) Version 8 or later. Make sure to get a 32-bit SDK if you are building for 32-bit Windows, and a 64-bit SDK if you are building for 64-bit Windows (with --enable-64-bit). Grab it from http://www.oracle.com/technetwork/java/javase/downloads/index.html.
とあります。 JDK8以降ならいいみたいなので13EAとか入れるのが男なのかもしれないですが、 弱気なのでJDK8です……へたれ*3。 上を見るとOracleJDKを使うように読めますが少なくともAdoptOpenJDKはいける……はず*4。
あとぼーっと読んでたら 「Make sure to get a 32-bit SDK」って部分が目に飛び込んで、えってなったんですが（私だけ？）、 後ろに「if you are building for 32-bit Windows」ってあるので、普通に64bitで大丈夫です。
ということでこれもChcocolateyです。
C:\WINDOWS\system32>choco install -y adoptopenjdk8
インストールできたら確認しましょう。別途コマンドプロンプトを開けて、 java コマンドと javac コマンドの両方が使えればOKと。
C:\Users\naruhiko>java -version openjdk version "1.8.0_252" OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_252-b09) OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.252-b09, mixed mode) C:\Users\naruhiko>javac -version javac 1.8.0_252
ポリシーの確認
ここからは再びlodeのドキュメントを参照しつつ。
最初にlodeの導入手順ではPowerShellスクリプトを実行しないといけないので、ポリシーで許可されてるか確認して、必要なら許可してあげます。
PowerShellにて：
PS C:\Users\naruhiko> Get-ExecutionPolicy RemoteSigned
で、ドキュメントを見るとUnrestrictedにしなさいと書いてありますが、たぶんRemoteSignedでも問題ない……というか、私はうまくいったのでそのまま。
cygwinの導入
そして、
https://git.launchpad.net/~documentfoundation/df-libreoffice/+git/lode/plain/bin/install_cygwin.ps1
を取ってきて c:\cyginstall において、PowerShellを管理者モードで起動して実行してあげると。するとcygwinが必要なパッケージともどもインストールされます。
おまけ：CygwinをWindows Terminalで使えるように
これで使えるようになったんですがminttyが気に入らんので（？）、 WSLでも使ってるWindows Terminalを使えるようにしました。
手順はQiitaの記事：
のとおりですけど、chere 入れるための setup-x86_64.exe は c:\cyginstall\packages 以下にあること、cygwin bashのパスは c:\cygwin\bin だということだけ。快適。
lodeの導入
次もドキュメントの通りにやるだけ。cygwin開きまして、
git clone https://gerrit.libreoffice.org/lode cd lode ./setup --help
これでヘルプが出て、
./setup --prereq
これで「Done.」と出れば依存関係チェック含めてオッケーと。
そしたらお次は
./setup
しまして*5、
これも正常に終わったら、ドキュメント通り ~/.bash_profie に以下の内容を書いて source するかcygwin bash抜けて入りなおします。
export LODE_HOME=/home/<user>/lode
PATH="${LODE_HOME}/opt/bin:${PATH}"
「環境」の作成
lodeには「環境（environment）」という考え方がありまして、 まあ要は開発してるとmasterブランチをビルドする場所と例えば6.4系をビルドする場所を両方維持しておきたいなーとか思うわけですけどそういうのを切り替えるってことですかね。
ドキュメントにしたがって dev/core という環境を作りましょう。
./setup --dev --force
するとLibreOfficeのソースコード・レビュー管理システムGerritから ./dev/core にLibreOfficeのコードが一式cloneされてビルドできる環境が整うはず。 Gerritちょっと遅いのでclone結構遅いので、ご飯食べに行くなりお風呂入るなりする前にやっとくといいでしょう。
ウィルススキャンソフトの例外フォルダの設定
で、ウィルススキャンソフトの例外設定しないとパフォーマンスつらいので設定します。
と、あたかも自分はちゃんとやったかのように書いてますが、私自身は後述の autogen.sh のときに怒られて*6、あっと思ってやりました。
具体的な手順は環境によって異なるでしょうから省略。 C:\cygwin\home\<username>\lode\dev 以下を例外フォルダに入れとくとよいと思います。
./autogen.sh の実行
ここまで来たら ./autogen.sh が通れば、まあ必要なものはそろってるんじゃないかといえるので。結果的に私のオプションこんな感じで通りました。
./autogen.sh --with-lang=ALL --enable-64-bit --with-jdk-home=/cygdrive/c/Program\ Files/AdoptOpenJDK/jdk-8.0.252.09-hotspot/
--with-lang=ALLは全言語有効にしてビルド。まあenとjaだけでもいいんですけどね。--enable-64-bitは前述の「64ビットビルドするならJDKは64ビットね」に書いてあったやつ--with-jdk-homeAdoptOpenJDKのインストールした場所
はーやれやれ。
ということで次の記事はデバッグして動いたやつを起動する、ぐらいかなー。 それは（ビルド待ってる時間はかかるけど）手間としては一瞬なはず。
*1:……というか、オンラインイベント参加しつつ作業してたらワークロードなどなど必要だよって記述を見落としてました。間抜け。
*2:こっちはインストーラ開発するんでなければ不要らしいですが、まあいちおう。
*3:8から上のバージョンで何が変わったのか追っかけてないんですよねー。モジュールとかvarとかGraalVMとか？名前しかしらない。
*4:LibOは内部でJDKの名称見てるところがあるので、OpenJDKの全ディストリビューションがOKだとはいえなかったはず。
*5:ここら辺ビール飲みながら作業してたのでちゃんと覚えてない……。
*6:autogen.sh のなかでeicarファイルというダミーウィルスを突っ込んで検知するっぽい、かしこい。
OmegaTのチームプロジェクトでちょっとハマった話
最近お仕事でOmegaT:
を使い始めました。で、社内のGitLabをホストにしてチームプロジェクトを作ったのですが、若干ハマったのでここでメモっておきます。わかってみれば大したことではないんですけどねー。
なお検証したのは今のStandard VersionであるところのVersion 4.3.2です。Latest Versionではどうなのか確認してません。
結論から言うと：
ってーことです。以下時系列。
お断りですが、これ試してたのは会社環境で、この記事書いているのは個人PCなので、メッセージその他は記憶で書いてます。実際のものとは異なることはご了承くださいませ。
GitLabにpushしたリモートリポジトリと紐づけたチームプロジェクトがぶっ壊れる
（注：後から考えると、正確にはぶっ壊れてたわけじゃないんですが、そのときにはそう思ったんですよ……）
手元でOmegaTで翻訳できるプロジェクト作って、まあまあ快適に翻訳できるようになったわけです。
でもほかのメンバーでも作業できるようにするにはチームプロジェクトを作る必要があるらしい。さてどうやって作るのかな。で、ドキュメント調べたら：
あーふむふむ、要はGitリポジトリ作ってそこにいろいろぶち込んでpushして、それをチームプロジェクトとしてダウンロードすればいいのね*1。
で、手元のプロジェクトを git init して一式コミットして、社内で立ってる、社内N/WからしかアクセスできないGitLabにリポジトリ作って、そこを git remote add origin git:// ってして push して、じゃあこれを「プロジェクト」＞「チームプロジェクトのダウンロード」のURLに指定すればよいと。
……ん？ 「.... Auth fail」？？？ どゆこと？ 普通に自分がpushできてる自分のリモートリポジトリなんだから、認証に失敗するとかないと思うんですけど……。
まあとにかく、リポジトリがOmegaTからcloneできないってことね。なんだろう、もしかしてやり方がまずいのかな、一度OmegaTで読み込んでごにょごにょする必要があるってことなのかな。 ということで、チームプロジェクト化したと思われたローカルのプロジェクトをOmegaTで開いてみますと、
このチームプロジェクトはバージョン２*2 形式の古いやつだから、今の形式にします？
あ、なるほど、さっきのドキュメントは古いってことか……確かにホームに戻ると「OmegaT 3.1 - 取扱説明書」って書いてあるし。
まあでも移行機能ついてるんだ親切だな、ぽち……え。同じエラーで落ちる。そして、「サーバーと同期できませんでした」といって、OmegaTで開くこともできなくなりましたよ……と。え。マジで。
いやいやいやいや。大丈夫。Gitリポジトリなんだから中に入ってcheckoutなりなんなりすれば元に戻るでしょ……え？ Gitリポジトリじゃなくなってる？？？ .git ディレクトリがないじゃん。えーまじか。
……もちろん、リモートリポジトリからcloneしなおせばモノは残ってるわけですが、翻訳作業が進められなくなる。それは困る。で、ちゃんと調べることにしました。
チームプロジェクトでHTTPSプロトコル使うと動かない
まずは雑に "omegat git auth fail" とかでググる……けど、全然情報がない。
でまあもっと単純に "omegat team project" とかで検索すると……たとえばここ、を参照すると、 大体の例はHTTPSになってる……なるほど。そうなのかな。
じゃあ、URLに https:// を指定すれば……ぐぐ。エラーになりますね。
種を明かせばこれは本当に当たり前な話で、社内GitLabがオレオレ証明書だったから*3。
なので、普通に git clone とかも跳ねられちゃう。普段 git:// でしか使ってないから気づかなかったからというだけ。
Auth failの謎に迫る
しょうがない。このGitLabを使う以上はなんとかしてgitプロトコルを使うしかないわけで、そうなるとAuth Failの謎を解かなければいけません。でもググっても情報がない。
しかしですね、わたくし技術屋としてあるまじき見落としだったんですが、さっきのダイアログ、実は
jgit: .... Auth fail
ってなってたんですよね。jgitっていかにもJavaのgitライブラリじゃないですか。だからきっとこのダイアログはこいつが吐く例外メッセージとかをママ出してるんじゃないか。
ということで "jgit auth fail" でググると……色々出てきた。 で、ヒットした記事をチェックしたら、「鍵にパスフレーズありの場合はこういうコーディングでパスフレーズ渡さないとだめだよ」みたいなStackOverflawの記事を見かけました。 ん？パスフレーズあり？俺の鍵はもちろんパスフレーズありだよ。そしてOmegaTでパスフレーズ入れた記憶も、やっぱりないぞ……。
さてはということで "omegat ssh passphrase" とかで検索した……ら。
ちょっと古いけど（2015年）、やり取り見てると：
Keys with passphrases will be supported after this development hits trunk. In the meantime, you can use public key authentication now if you remove the passphrase from your key.
ってい書いてあって、
It is nonsense to remove passphrase.
うんうん、ナンセンス！ と思ったんですが、どうなんだろ、2015年だしなあ、治ってるかもわからんけど……。
情報見当たらなかったのでまあ試してみようということで、パスフレーズなしSSH鍵ペアを生成しなおして、~/.ssh/config でGitLabのときだけはそいつ使うようにした……ら。
無事OmegaTでも使えるようになりました！ やった！ ばんざい！
Macで同じことやると「invalid private key」と言われて動かない
で、同僚に「使えるようになったよー」といったら、「なんかうまく動かないんですけど……」とクレームが。
同僚はMacだから？ なんだろ？ と思いつつ私も検証機でMacあるので、やっぱりパスフレーズなし鍵ペアを使うように ~/.ssh/config 設定し、
リポジトリのcloneできることは確認して、オッケー、ではOmegaTで「チームプロジェクトのダウンロード」する……と、「jgit: ... invalid privatekey」とな。
あわてず騒がず "jgit invalid privatekey" でググりますと……
この記事がヒットしまして、要は：
- OpenSSHの7.8以降は
ssh-keygenで生成するデフォルトの鍵ペアが ed25519 になりました - 判断するのは秘密鍵の頭が
-----BEGIN OPENSSH PRIVATE KEY-----となってるかでわかる - 少なくともOmegaTのjgit（バージョンなのか使う側の実装なのか）ではこの形式の鍵が食えない
- なので以下のようにして鍵形式を切り替えてあげればOK
ssh-keygen -p -f 【鍵ファイル名】 -m pem -P "" -N ""
で、うまくいきました。
おまけ：環境によってはMac版OmegaTのJREありバージョンは動かない
これは私じゃなくて同僚がハマったんですが、OmegaT 4.3.2のJREありバージョンが起動時に例外吐いて死ぬという問題があるようです。
ぐぐったら上記JREありバージョンに同梱されてるOpenJDK 1.8.0 u201の問題みたいで、JREなしバージョン使うか、5.2.0ならJRE新しくなってるのでそれを使えばいいみたい。
【執筆報告】日経Linux 2020年5月号
大変久しぶりの執筆報告です。そんなにいろいろ書けるほどネタが豊富な人間ではないからですけど。
ということで、日経Linux 2020年5月号の特集１「Linux&Windows 共存テクニック」に記事を書かせていただきました。
https://www.amazon.co.jp/dp/B086C9YK5W/
- 発売日: 2020/04/08
- メディア: 雑誌
この号は日経Linuxさん的にもけっこうなチャレンジとのことで、なんと特集が７個！ 通常の特集だと取り上げきれないようなテーマであっても取り上げたいトピックはあって、それをなんとかできないかということで試行されたとのこと。そんなチャレンジの号にお声がけいただいてありがたい限り。
そもそも今回の特集は、入社入学進級卒業引退など新しい環境になるのを機に、あるいは１号前の3月号：
- 発売日: 2020/02/07
- メディア: 雑誌
を読んだりして、Linuxを始めてみた、あるいは始めてみたい、そういう人のフォローアップのためを狙っているそうで、せっかくだから活用したいけど、自分のうちにはWinowsマシンもあるし家族友人同僚はWindowsだし、自分一人でLinuxって使いきれるの？ そういう不安を払拭してLinuxをよりいっそう活用できるようになればって狙いなのだそうです。
そんななかでわたくしのネタとしては毎度おなじみ、プリンター＆スキャナーネタです。まあずっとLinuxデスクトップを使っているような人ならさておき、WIndowsで使うつもりで買ってたプリンターとか、ちゃんと使えるの？ ってことはやっぱりみんな思うので、そういう人に向けて書いてもらえればということで打診を受けて、わたくしなんぞでお役に立てれば……ということで引き受けた次第。もうプリンターベンダーやめて何年もたつので昔の遺産で食べてる感があってよくないのですけど、ここらへんもっとちゃんと書いてくれる現役の人いませんかしらね？ まあそれでもいちおう、今でもLinux印刷標準化とかはゆるふわっとウォッチしてますし、それなりなことは書けたんじゃないかと思います。
今回取り上げた２台のプリンターですが：
エプソン プリンター インクジェット複合機 カラリオ EP-882AW ホワイト(白) 2019年新モデル
- 発売日: 2019/08/01
- メディア: Personal Computers
Canon プリンター A4インクジェット複合機 PIXUS TS8330 ブラック 2019年モデル
- 発売日: 2019/09/05
- メディア: Personal Computers
完全に編集さんにお任せで、とても間違いない選択をしていただいたかと。それぞれ広報器をお借りして我がアパートまで送っていただきました。部屋がとても散らかっているので、ちゃんと使えるように設置するのが一苦労。でもやっぱりモノがあってちゃんと手を動かしたほうが説得力ありますしね。ドライバーレス印刷がUbuntuにやってきて結構経ちますけど、手順を改めてさらえたのはよろしかったかなと。ちまちまさらっていたら字数大幅に超過して、3ページというお約束が4ページになってしまったのはどうもすみませんでした。
この手の記事を書くときはまっさらな環境で構築しないと読者のみなさんと差異がでちゃうので検証環境はVMになります。そのVMの構築とか少し手間取ったのですがそのあたりはまた別の記事で、ですかねえ。
なお、この特集ではLibreOffice日本語チームの一人として、もう一つの記事にも協力させていただきましたけど、それについてはLibreOffice日本語チームのブログ記事をご参照くださいませ。こっちはとてもよくまとまっていておすすめ。
2020年「フリーソフトウェアを愛していますの日」（野良翻訳）
この記事はFree Software Foundation Europeの：
このページの冒頭部分の野良翻訳です。いちおう私FSFEの翻訳MLとか取っててやろうと思えば公式な翻訳もできるんですけどね、怠惰ですみません。
私たちはしばしば、単に「ありがとう」ということの力を過小評価しがちです。フリー（自由）ソフトウェア（訳注；以下単にフリーソフトウェア）の貢献者は私たちの社会に対して重要なことをしており、注目を浴びるに値します。2月14日の「フリーソフトウェアを愛しています」の日（バレンタインデーとしても知られています）は、特別な感謝を示すことができる絶好の機会です。
フリーソフトウェアのコミュニティでは、プロジェクトのメンテナーに多くの圧力をかけてしまっています。フリー（自由）ソフトウェアの開発、翻訳、テスト、デザインなどにボランティアの空き時間をしばしば捧げている人たちに、バグレポートを書き、あらたな機能を要求しています。これはまったく悪いことではありません。なぜなら建設的なフィードバックはさらなる進化の助けとなるからです。しかしながら、感謝の意を示すこともまた、大切なのです！
毎年の「フリーソフトウェアを愛していますの日」では、ポジティブで、創造性に満ち、素敵なメッセージをコミュニティ全体に届けることができます。みんなで一緒に、私たちに力を与えてくれる、ソフトウェアの自由を祝うことができるのです。
ということで、誰も私にチョコをくれる人はいなかったですが（って、それはどうでもいいね）、Happy I love Free Software Day!
OpenDocument Format（ODF）の標準化について雑な補足説明
この記事は、先日TDF Blogで公開された記事「ODF 1.3 approved as OASIS Committee Specification」（日本語訳「ODF 1.3、OASIS委員会の標準として承認」）の補足説明的ななにかです。
ほんとうは、標準化とかそういう「きちんとした」世界についてなにかものを申すには、きちんと下調べをして裏付け取ってなるべく正確なものいいをすべきだと思うのですが、正直、「ちゃんとする」には現状気力体力が足りないため、他人様の受け売りその他で雑に述べます。なので眉につばをたっぷりつけてお読みくださいませ……。
じゃあなんでそういう雑な記事を書くかというと、ちょっとウェットな物言いをすると、標準化で提供しようとしている価値に対して色んな人が色んなことをしてくれているんだなあという私個人の感謝の気持ちをみなさんと共有できたらなあという動機です。
OpenDocument Formatとは
LibreOffice*1 のネイティブドキュメントフォーマットで、いわゆるオフィスアプリケーション向け文書のフォーマットです。通称ODF。ファイル名として「*.odt」とか「*.ods」とかなってるやつです。
中身は概ねZIP圧縮されたXML（と、添付されたコンテンツ、たとえばビットマップなど）の塊です。
ODFの特徴は前掲サイトなどを見ていただくとして、一言で言ってしまえば、
真に相互運用することを考えたフォーマットであること
で、もう少し細かくいえば：
- 人類でも読める程度の仕様
- 人類にわかりやすく機械加工も容易な構造
- 豊富な操作ライブラリ（参考サイト）
あたりでしょうか。
ここで本来はODFについての説明をひとくさり書くべきで、というか実際ちょっと書きかけたのですが、わたしの理解が覚束なくて書き上げるのにそうとう時間がかかりそうなのと、あと長くなるので今回は割愛して裏付けのない雑な説明。
ODFを構成するXMLですが、見た目はこんな感じのやつですね。
<?xml version="1.0" encoding="UTF-8"?> 〜略〜 xmlns:text="urn:oasis:names:tc:opendocument:xmlns:text:1.0" 〜略〜 office:version="1.2"> <office:scripts/> 〜略〜 <office:body> 〜略〜 <office:text> </text:sequence-decls> <text:p text:style-name="P1"> <text:span text:style-name="T4">井神陽吉は風呂が好きだった。</text:span> </text:p> <text:p text:style-name="P1"> <text:span text:style-name="T4">殊に、余り客の立て混こんでいない昼湯の、あの長閑な雰囲気は、彼の様に所在のない人間が、贅沢な眠から醒めたのちの体の惰気を、そのまま運んでゆくのに最も適した場所であった。</text:span> </office:text> </office:body> </office:document-content>
（テキストは海野十三「電気風呂の怪死事件」より。青空文庫リンク）
XMLはHTMLとかと同じでタグで文書の構造を定義します。例えば <text:p> は、テキストであってさらに段落（ParagraphのP）であるということを意味するタグです。このような「どんなタグがあって、それがどんな意味を持つのか」が、ODFのようなXML文書の仕様を定義するってことです。
「どんなタグがあって」ってのがいわゆるスキーマ定義。XMLでスキーマ定義をする方法にはいくつかあって、ODFの場合はRELAX NGというスキーマ定義言語を用いてます。
で、スキーマ定義はタグの定義だけじゃなくて、例えば同じ <text:p> を違う意味で使うXML文書と混在したりしたら困る。で、「ODFでは*2」 <text:p> タグはこういうふうに意味を決めるからね、というのを定義するのが名前空間というやつで、 xmlns:text="urn:oasis:names:tc:opendocument:xmlns:text:1.0" とか書いてるのがそれですよと。
もちろんスキーマ定義、名前空間だけじゃダメで、それぞれのタグの持つ意味も定義しないといけない。例えばODF 1.3の <text:p> タグの定義は：
The <text:p> element represents a paragraph, which is the basic unit of text in an OpenDocument file.
つまり段落を表す要素ですよと書いてあると。
ともかく、文書フォーマットとしてはスキーマと意味がそろってればよく、それにしたがってアプリケーションを実装すれば、異なるアプリケーションでも文書交換が可能で、相互運用可能になる……と、いうわけです*3。
相互運用うんぬんについて補足すると、例えばODFにはODF Validator ってサービスがあって、これは適当なファイルを放り込むと、ODFのスキーマ定義ファイルに照らし合わせてODFの定義に従ってるかを判定してくれるサービスです。このバックにいるのはODF Toolkitってライブラリで、こいつは単なるODFの操作ライブラリではないさらに先を目指して開発されてる……とか。こういう取り組みがあることが、ODFが単なる「LibreOfficeのファイル形式をなりゆきで文書化しただけ」というもの以上を目指していることを示してると思います。
ODFが「国際標準」であるということ
大事なことはODFはLibreOffice専用のフォーマットでなければLibreOfficeコミュニティあるいはその支援を行う非営利組織The Document Foundation（TDF）のものではなくて、その他のアプリケーションも自由に使えるってことです。現にMicrosoft OfficeもGoogleドキュメントもODFは扱えますし。
それを保証してるのが、ODFが「国際標準」であるということ。つまり、LibreOffice/TDFが手前勝手に仕様をどんどん変えていくのではなくて、オープンな場所で「標準」として仕様を管理して、それを公開して、色んな人が使えるようにするということです。
例えばHTMLがどんなブラウザでも正しく表示できるように、PNGがどんなビューアでも表示できるように。
でもそれって、LibreOfficeの進化を妨げるようなことはない？
でも、あれですよね、新しい機能を追加すると、当然その機能によって追加されたなにがしかをファイルに保存したくなるわけですよね。それがこれまでにあったXMLタグで表現できない場合は、タグをあらたに追加しないといけない。しかし、いちいち標準化団体にお伺いを立てないと新規にタグを追加できない……そんなことしてたらソフトウェアは進化できない。ですよね。
なので、ODFにはOpenDocument Extended Documentというやつがあって、要はODFの仕様に準じて、さらに独自のタグを追加できるよということ……だと私は理解してます。LibreOfficeの場合は loext というprefixがついたタグは独自拡張です。どんな独自拡張があるかはWikiに記録されてます。
で、当然ですが、「私たちはこういうふうに思ってこういう独自タグを定義したけど、それをODFの標準に入れてよ」という働きかけをするわけですね。ODF 1.3は、そういう取組みであらたにタグが定義されましたと。
なので、ODF1.2には存在しなくて、でもLibreOfficeには存在して、ODF 1.3で追加されたものは、ODF 1.3に対応したLibreOffice、つまりLibreOffice 6.4のさらに次のリリースでは、独自タグからODF 1.3で定義されたものに移行されるはずです。
こうやって、アプリケーションと標準が共に進化をしていくよというのが、ODFが「正しく」標準であるということ、だと思います。
具体的にODF 1.3って何が変わったの？ という人は、「Open Document Format for Office Applications (OpenDocument) Version 1.3. Part 3: OpenDocument Schema」の「Appendix G Changes From ODF 1.2 (Non Normative) 」を参照してくだされ。
ODFとOASIS、ISO、JIS
ODFの仕様は、OASISという標準化団体で策定されています。
前述のように標準化とかについては私ぜんぜん詳しくないのでアレなんですが、もともとOASISはSGML関係の標準化とかをやってたSGML-Openという団体が元で、SGMLからXMLを含んだ形で活動を広げるためにOASISって名前になったんだそうな。Wikipediaより。たぶん富士通さんのワープロとは関係がないです。ODF以外だとCMISとかDocBookの標準化が有名かしら。
で、OASISに限らないですが、標準化団体というのはそれぞれの標準に対して技術委員会（Technical Committee）というのがあって、個別の標準はそこで議論され策定されていくということになってるらしい。で、ODFについてのTCが Open Document Format for Office Applications (OpenDocument) TCです。で、そこで「こいつは標準文書とするよ」というプロセスに従って定められた標準が「委員会標準」という……らしい。前述の記事の
OASISは、OpenDocument TC（技術委員会）からのOpen Document Format for Applications (OpenDocument) v1.3がOASIS委員会標準（OASIS Committee Specification）として承認された
っていうのはそういうことです。
前述のようにLibreOfficeがODFに対して独自に拡張した部分に対し、必要と思われるものはOASISに提案して仕様に取り込んでもらう努力をしております。その取り組みは前述のODF拡張のWikiページでも見られますし、また去年のLibreOffice Conferenceの資料なんかも参考になるかもしれないです。
また国際標準というとぱっと頭に浮かぶのはISOかと思いますが、
ISOも必ずしも直接規格を議論するわけじゃなくて、ODFの場合だとOASISの委員会標準をISOの議論に乗せて、それを標準として策定する……ってプロセスを踏むっぽいです*4。ISOの場合は、TCの下にSub Committee（副委員会？）、さらにその下にワーキンググループがあって、ODFの場合はISO/IEC JTC 1/SC 34/WG 6ってワーキンググループで作業されてるらしい。ISO/IEC JTC 1が情報技術のTC、SC 34がドキュメント記述および処理言語（Document description and processing language)ですね。
でまあ、ODFはISO標準でもありますよ……と言われます。ISO/IEC 26300というのが規格番号で、現在の最新は ISO/IEC 26300-1:2015、ISO/IEC 26300-2:2015、ISO/IEC 26300-3:2015の三つで、これがODF v1.2という規格に対応してます。
いまのところ私が聞いてるところでは、今回ODF v1.3は今回の委員会標準化を経てISOのWGに議論が移され、2020年中の改定（ISO/IEC 26300-n:2020?）となる……んだと、思います。
なお、国内で規格といえばJISでございますが、残念ながらJISのODFについての規格JISX4401ってODFのバージョンでいえばv1.1の翻訳なんですよねえ……。なのでこれが早晩改定されるのは期待薄かも。
まとめ
ということでODFは真に相互運用可能であることを目指したオフィスアプリケーション向け文書フォーマットの国際標準なのです。ODFを選ぶことはLibreOfficeも含むあらゆるアプリケーションにロックインされないという意思決定なのです。大げさにいえば。
そんなわけでODF 1.3、OASIS委員会標準化おめでとうございます！
ISOの更新に向けてもがんばってください！ Love! ODF!
*1:もちろん、前身プロジェクトであるOpenOffice.org、およびその商標を受け継いだApache OpenOfficeも。
*2:厳密には「ODFのこの部分では」ですかね。
*3:もちろん、スキーマ定義と各タグの意味だけでは表現しきれない、アプリケーション仕様というのも、もちろんあります。
*4:すべてのWGで同様かどうかは、まったく存じません。
LibreOffice Asia Conferenceを開催してみた（あるいは、そういうのがあったらいいなと口走ってみた）
この記事はLibreOffice Advent Calendar 2019の24日目の記事です。なんと完走間近！ 何年かやってますけど初めてです。うれしい。
さて今日のお話は、結論から先に書くと「こういうことできたらいいなー」と思ったら思いつきでも口走っておくと、行動力があるひとがなんか動いてくれていつのまにか実現したりするので、思慮浅く口走るの大事。って、内容です。むやみに長いです。
本題。タイトルのとおり、今年2019年は5月の25日、26日の両日、LibreOffice Asia Conference 2019（以下AsiaCon）というイベントを開催いたしました。
タイトルの通り、アジアにおけるLibreOfficeの関係者がいろいろ集まっていろいろセミナーを行ったり議論したりなんだりするというものです。
これはなんどかいろんなところで書いたり言ったりしてますが、LibreOfficeコミュニティにとっては「地域的であるけれども国際的」というイベントは初めてだったのです。
もちろんLibreOffice Conference（以下LibOCon）という年次カンファレンスがありますし、例えばヨーロッパのFOSDEMや台湾のCOSCUPのような国をまたいで参加者が集まるイベントにコアメンバーが登壇したりブース出したりはしてたのです。が、LibreOffice単独開催という意味では初。
このイベントがどういうきっかけでどんなふうに行われてどんなことを達成できたかって話は、今年のLibreOffice Conference 2019で発表したので、
LibreOffice Asia Conference 2019 Tokyo; what we had achieved, and what's next from Naruhiko Ogasawara
www.slideshare.net
まあそのスライド読んでいただければいいのですが、ここではだらだらと日本語で思いつくことを書きたいと思います。
なおAsiaConそのもののレポートについては、日本語チームのブログの開催レポートおよびその写真レポート（前夜祭, 25日 カンファレンスデー, 26日 ビジネスデー＆CJK HackFest, カンファレンス公式ツアー)、そしてgihyo.jpさんに掲載いただいた基調講演についてのレポートなどを参照してください。
なぜ今年にAsiaConが初開催？
雑にいってしまうと、「やろうぜ」って言われたから。誰からかって？ 台湾のLibreOfficeコミュニティのリーダー格であり、TDFのマーケティング担当Board of DIrectorでもあるFranklin Weng氏にです。
じゃあ彼は唐突にそれを言ったかというと、きっかけがあって。ちょっと時間軸を逆に戻りつつ説明します。
2018年12月、OSC福岡の翌日に次のようなイベントをやりました。
ここに、台湾からFranklinが、韓国からDaeHyun Sungさんが来てくれまして。Franklinが「日本でもTDFのメンバーになることの重要性や寄付、認定制度といった内容について話すべきだ」というので私がそういう発表をしまして。
www.slideshare.net
そのときに「2017年にアジアで初めてのLibreOffice認定専門家向けの面接が台湾で行われたのだけど、来年の5月25日に東京でLibreOffice Kaigiやるんで、そこでリモートでもいいからアジア2回目の面接とかできたらいいんじゃないか、って個人的に考えてる」ってことをちらっと言ったんですね。
そしたら、2019年1月に、Franklinから「今年のKaigiを二日開催にしてAsiaConにしようぜ、そこにTDFから人呼んで認定面接もやろうぜ」ってメールが来たと。
って、俺がきっかけだったんだぜアピールになってますが、もちろんその更に前がありまして。2018年のLibOConで小笠原が日本と海外をつなぎたいよねみたいな発表をしまして*1。
それを聞いてたLibreOffice/TDFの創始者メンバー、マーケティング・広報リーダーのItalo Vignoli氏が「我々ヨーロッパ人から見るとアジアは異質で、もっとローカルメンバーと話したい*2 からぜひ呼んでくれ」って言われたのと、そのとき一緒だったFranklinが「今年台湾は少し予算が余ってるから、なんか一緒にやろうぜ」って言ってくれて、まあItaloを呼ぶのはすぐはできないけどFranklinとなにかするぐらいはできるかなって、急遽企画したのが九州LibreOffice勉強会だったというわけ。
が、Franklinのその発言のさらに前には、2018年のCOSCUPにあわせて台北で開催されたLibreOffice meetupというイベントがあり、インドネシアのLibOコミュニティメンバーと台湾勢、そして日本からは榎さんが参加してくれて*3、そこでAsiaConやるのはどう？ みたいな話は出ていたのです。なので「なんか一緒にやろうぜ」って話の土壌はそこ。
ではなぜCOSCUPにインドネシアからたくさん人が行ったか、Italoがなぜアジアに急に関心を寄せるようになったか。それは2018年1月のLibreOffice Conference IndonesiaってイベントにFranklinとItaloが参加して、さらにいうとItaloは2017年のCOSCUPにゲストとして呼ばれていて（もちろん呼んだのはFranklin）、……と。
そんなこんなで種まきは前からあったにせよ、2018年に一気につながって2019年に開催されたのですね。
なんで「Asia Conference」？
他のメンバー（日本語チームだけでなくFranklinなどグローバルのメンバーも）の思惑はわからないですが、私の発想は、はい、パクリです。どこからのパクリかというとそもそもはGNOME.Asia Summit。わたくしたまたま2014年、北京開催のときに行きまして。あーなるほどAsiaとかAPACみたいな枠で国際イベントって組み立てがあるんだいいなーって思ったのです。
日本からの唯一の一般参加者ということでスピーカー・スタッフ懇親会にも呼んでもらって（ありがたいことです）、「俺達共通語は英語になっちゃうけど、CJKとか共通の問題あるしタイムゾーンも地理的にも近いから、もっといっしょにできたら良いよね」みたいは話で盛り上がった。あと、けっこうみんな東京に来たがってるってことがわかったというですね。「次は東京開催で手を挙げろよ！」と言われたり。
話戻って、そのときにSUSE Chinaな人たちがブース出してて、「日本から来たの？ 我々も今度Asiaイベントやるから運営手伝ってよ！」みたいな話に（なぜか）なり、で、同年のopenSUSE.Asia 2014も手伝ったと。
ということで、少なくとも私は折りに触れて「LibOでもAsiaなイベントあったらいいかもね」みたいなことは周囲に言っていたというのはあります。
イベントの裏側
あんまり裏話みたいなことを書いてもという気もするのでさらっと箇条書き。
- Kaigi向けに25日だけおさえてたのに翌日26日でもいいですよと許可いただいた上、「できれば複数トラック開催できたら」「すみません言うの忘れてましたがプログラム組んでたら3トラックになっちゃいましたが可能ですか」みたいな酷い申し出も快く受けてくださったサイボウズの風穴さん、本当にありがとうございました。めちゃくちゃよい会場で参加者みんなめっちゃテンション高かったです
- 我々団体格がないのでスポンサーさまからお金受け取ったりできないため、びぎねっとの宮原さんにOSPNとしてお財布をお願いしました。とても助かりました。コミュ症でちゃんとお礼できてなかったのでこの場にて改めまして。ありがとうございましたありがとうございました
- 開催決まってからTrelloでタスク管理してたんですがカード減らなくてねえ……ちっともDONEにならない。そして長期化する週次ミーティング。つらかった
- コアでうごく人いなくてスピーカー担当とスポンサー担当、会計という超重いタスクが榎さんに集中してしまって、それでもこなしてくれて、あらためてありがとうございました＞榎さん
- デザインワークは野方さんにおんぶにだっこ。忙しいようなのでWeb制作ぐらいわたしがやろうかなって思ったんですが20世紀的なHTML手書きしかできなかったので5秒で捨てられました。ははは。Middleman + Netlifyという技術選定だけは私がしました
- TDF（Italo、Lothar）とのコンタクトを安部さんがやってくれたのはありがたかったです
- 私は……前の月にSeleniumConf 2019の招致もちょっと手伝っていて。わたし健康不安*4 もあって、そっちもあんまり動けてなかったこともありギリギリまでタスク消化できなくて。前夜祭と懇親会、翌日のツアーぐらいがやったことかな
- イベントレポートにも書きましたけどMark Hung氏に日本で話してもらおうというのはずっと願ってきたことなので実現できてほんとうによかったです。面白かったと思うんだけどなあ、SNSとかでも反響がイマイチ薄かったのが不思議
- 26日のHackFest、集客がイマイチ＆ちゃんと課題に取り組めた人があまりいなかったのがとても残念。あんなに東京でLibO開発者がそろうことはめったにないのに……自分自身がなにもできなかったことも含めもったいなかったです。これは東京ローカルな私の責任は大きくて、メンターお願いしたMarkには申し訳なかった
- 大変でしたけど、久しぶりに一緒に活動できた人、名前だけ聞いたことあったけどちゃんと話したことなかった人と触れ合えてそれはとてもよかったですね
日本のLibreOfficeイベント〜歴史的な流れ〜
話戻して。2018年はAsiaCon開催のきっかけとなる年だよというのは書いたのですが、その前史というか。国内のLibOイベントの歴史を少々。
不確かな記憶では、私が初めてLibOConに参加した2011年秋よりあと、確かオープンソースカンファレンス2012 Aizuかな？ でブース展示してたときに、日本語チームの大森さんとLibOConの話をして、「海外のカンファレンス一度は誘致したいね」「とはいえ一足飛びに海外はねえ」みたいな会話になって、そうそう2009年に台湾でDebian Miniconf Taiwanってイベントやったらしいっすよ、我々もまずはminiから初めて、コミュニティを大きくしたらいいんじゃない？ みたいな話をするともなしにしたことをぼんやり覚えてます。
で、2013年の春のOSC東京にて「コミュニティ企画」というのを募集してて、それではそこでこないだ話してたmini conferenceやろうよってことで企画したのがLibreOffice mini conference 2013。なので最初から国際化は視野に入れてたのです。ほんとかな。個人的にはほんとうなんだけど。
それから2014年に第2回、ちょっと準備に手間取って2016年1月に第3回をやって、次はってことになったら2016年12月開催って話になり、そしたらminiconf 2016が二個になっちゃうじゃん、どうしよう、ってことで、「Kaigi」を名乗ることにしました。
もちろんこの名前はRubyKaigiからのパクリですが、（少なくとも私の脳内では）最初から世界を向いてたminiconfに対して、「日本語話者のための日本語話者によるイベント」で「会議」ってのはいいなあというのはありました。個人的にはそういう使い分けをしたいなと思ってます。なので2017年、openSUSE.Asia Conference 2017の中でやったのはminiconfとまあ、そういうわけ。
で、なんでここで歴史の話をするのかというと。
さきほど2018年にLibreOffice Conference Indonesiaというイベントがありましたという話をしました。その首謀者のAhmad Haris氏のブログ記事にこんな一節があります。
So we decide to organize conference about LibreOffice but small one (we can call it mini conference). But time flows, and we kick out “mini” and become normal conference.
彼らが最初「mini」って言ってたのは、どうやら我々の活動を見てたから、らしいんですね。
終わりに
なお今年は、6月にLibreOffice Latin America Conferenceというイベントも開催されましたが、どうやらこのイベントは2019年のFOSDEMにて「アジアがこういうイベントやるんだって？」「じゃあ、俺達もそういうイベントやろう」って始まったらしいです（FOSDEMは2月開催なので、そこから初めて6月にイベント実施するラテンパワーもまたすごい）。
こうやってぐるぐるつながってるのはホントに楽しいし、最初に書いたとおり、「こんなふうになってるといいな」って気軽に口走ったら、なんか世界がガンガン動いてて、自分がすべてのきっかけになったというつもりはないですが、まあ、その中の一つの要因ぐらいにはなってるのかな……と、少し嬉しい気持ちです。
まーとにかく、大変だったけどそれ以上に楽しかった。やってよかった！
来年のAsiaConはまだ公式のアナウンスは出てませんが9月に台湾の嘉義市で行われます。大仰な物言いをすれば思いの連鎖をうまいことつないでいきたいですねー。
さて、明日のAdvent Calendarはいよいよオオトリ。meguro.junさんの「CALCで窓口省力化！」です。よろしくおねがいします！
*1:この発表はまあ、ぶっちゃけた話、LibOCon行きたいけど最近なんもしてないし発表するネタないなー、じゃあなんというかふわっとした観念的な話でもするかってことで苦し紛れなテーマです。内容はそんなに面白くないです。
*2:わざわざヨーロッパまでやってくる私みたいなやつは典型的な日本人ではないので……ということ。
*3:私もいくつもりだったんですが、金曜日成田発最終便のJetStarがまんまと門限に引っかかって飛ばなくて行けなかったんですよね……。
*4:そんな、大げさなもんじゃないですが。怠惰に病名がついてるようなもんか。SeleniumConfでもご迷惑おかけしました。すみません。ぺこり。
ポエム：LibreOfficeの相互運用性について
この記事はLibreOffice Advent Calendar 2019の17日目です。
本記事はLibreOffice日本語チームあるいはThe Document Foundation、その他いかなるLibreOfficeコミュニティの意見を代表したものではない私見です*1。さらにいうと私はLibreOfficeの認定ほげほげではないので、ビジネスとしてガチに相互運用を検討したい場合はぜひ認定移行専門家にご相談ください。
さてと。
よく「LibreOfficeはMicrosoft Officeとの互換性がね……」という意見を目にします。そのたびに私みたいなうるさ型から「いやいや別にLibreOfficeはMS Officeとの互換製品だとは言ってないし」とか言われたって人もいるんじゃないでしょうか。
とはいえLibreOfficeはMicrosoft Officeと「互換」ではないのか。そんなことを先日Twitterで書いたので引用しておきます。
相互運用のためにはインポート・エクスポートという「機能」の互換性（もとのデータが持っているものがなるべくそのままであること）は高いことが望ましいというのはもちろんそうだしLibO開発者は少なくともそれを高める努力をしてるとは思うよ、でもそれは「互換アプリ」であることを意味しないよね
— Naruhiko Ogasawara (@naru0ga) 2019年12月7日
繰り返すと相互運用（という言葉については後述）のための「機能」の互換性は大事に思ってるけど、互換アプリではないよと。そこは、例えば機能や文書フォーマットだけでなく積極的に操作性も揃えようとしているこういうソフトウェア（あくまでも一例ね）とは立ち位置は違うんじゃないかなと。
とはいえ、現実的な問題として、
Microsoft Officeのユーザーから受け取った、あるいは自分が作った文書をLibreOfficeで開いたら開けなかった、あるいはぶっ壊れた
というのは、まあ、あんまり幸せではないわけです。少なくともそれを良しとしている人は誰もいないんじゃないのかな。
そんなわけで、その点について思いつくことをちらちら書こうと思います。あ、主にMS Officeを相手にした話となります。
「互換性」（compatibility）ではなくて「相互運用性」（interoperability）？
前述のように、私はしばしば「LibreOfficeはMicrosoft Office互換ではないが、Microsoft Officeと相互運用性があるソフトだ」みたいな言い方をします。ん？ 相互運用性？ それはなんぞ？
互換性ってのはWikipediaの記事によると：
互換性（ごかんせい、英語: Compatibility）とは、ある部品やコンポーネント（構成要素）などを置き換えても同様に動作させることができる性質のこと。
だそうです。それに対して相互運用性というのは、同じくWikipediaの記事によると：
相互運用性（そうごうんようせい、英: interoperability）とは、さまざまなシステムや組織が連携できる (相互運用できる) 能力に関する特性である。（略）
ですよと。つまり「同じであることを目指している」か「異なるモノを使いつつ一緒に連携できることを目指している」かということ。なんですよ。
「互換性」と言う言葉から期待される「何もかも同じでなければ文句を言われる」ところから、ちょっと踏み込んで、使い方の工夫とかも含めることができる、と思って、私は原則として「相互運用性」って言葉を使ってます。言葉遊びと言われればそうかもですが。
相互運用とインポート・エクスポートとファイルフォーマットの話
さて、相互運用というのは少なくとも二者間との連携ですよという話をしました。つまり「LibreOfficeしか使ってない私」と「MS Officeしか持ってないあなた」が、一緒に作業してアウトプットを出す……ってことです。
しかし、MS OfficeとLibreOfficeは、違うファイルフォーマットを利用しています。MS Officeの場合はOOXML（Office Open XML、 .docx とか .xlsx とか）、LibreOfficeの場合はODF（Open Document Format、 .odt とか .ods とか）ですね。なので、この二人が共同作業するには、
- LibreOfficeがOOXMLを読み書きするか
- MS OfficeがODFを読み書きするか
どちらかしかないわけです。こういう、ネイティブなフォーマットじゃないフォーマットを読むことを「インポート」、書き出すことを「エクスポート」といいます。言葉通り、輸入・輸出ですね。
ところで、MS OfficeとLibreOfficeは似たような機能は提供していますが、もちろん異なるソフトウェアです。
異なるというのはどういうことかというと、同じような見た目、同じような機能であっても、たとえば段落とか、箇条書きとか、表とか、そういうの。それを内部でどうやって扱うか、その仕組みは全然違うってことです。
わかりやすい話でいうと、ExcelとCalcの罫線。
Excelは、一つのセルに着目したとき、セルの4辺それぞれに罫線が引いてあるというモデルになってます。一方でLibreOfficeは、二つの隣接するセルがあるとき、その境界線に罫線が引かれてるというモデル*2。
各アプリケーションの標準フォーマット、つまりはODFとかOOXMLは、こういった内部表現を比較的忠実に表現しています。
なので、インポート・エクスポートってのは、こういう違う世界を読み替えるってことなのです。情報の欠損や置き換えが起きて、ある意味当然なのです。
でもその被害？ は、いくつかの工夫で減らすことはできるはず。さくっと箇条書きで。
- バックアップは取ろうね
- 最新を使おう
- 出し入れを繰り返すのはやめよう
- スタイルを活用する
- フォントを揃える、代替フォントを活用する
- ODF？ OOXML？ どっちがいい？
以下さらっと解説します。
バックアップは取ろうね
LibOでOOXMLを読んで、編集して、そのまま書き出すという行為。これは、インポートとエクスポートが両方走るわけです。事故の確率が2倍。
なので、最低でも「この文書めっちゃ大事で壊れたらぜったいまずい」かつ「LibOで編集するのは初めて」って場合は、バックアップとっとくと後悔しないんじゃないですかね。
っていうと「壊れるの前提だなんて！何事！」みたいなことを言う人がいるかもですが、同じことはMS OfficeでODF読んで書くときだっていえるはず。単に世の中にはODFが正本であるというケースが圧倒的に少ないので、それで文句を言う人が少ないというだけなんじゃ……と、思います。
最新を使おう
OOXMLはけっこうバージョン間でほいほい変わったりします。わかりやすいのはExcelのセル関数ですね。「新たにExcelにこんな関数が増えた！」みたいにニュースになったりしますし。でも当たり前ですがそういうものを使うと、LibOだけじゃなくて古いバージョンのExcelでもうまく扱えないです。
でまあ、LibOは「半年に１回メジャーリリースをする」という開発スタイルを生かして、ここらへんの新たな機能をキャッチアップしたり、相互運用に関わる不具合を直したりを積極的に行っています。なので、なにか変……という場合は、LibreOfficeの最新版を試してみるといいのではないかな。
とはいえ手元のバージョンを検証なしにほいほい最新にすることが難しいというのもあるとは思いますので、その場合は、インストールしないで使えるパッケージ、つまりWindows版の場合はポータブル版を、Linuxの場合はAppImage版の利用を推奨します。Macの場合はこのWikiの記事に従って並列インストールするのがよいですね*3。
出し入れを繰り返すのはやめよう
出し入れってのはようは「インポート・エクスポート」のこと。それを繰り返し続けるのはよくないって話。繰り返しになりますけどインポート・エクスポートは情報の欠落や置き換えが起きる可能性が常にあるわけですから、それを繰り返し続けるのはよくないってのはまあそうだよね、と。
なので、例えばMS Officeで作業している人からファイルを受け取って、それをLibOで作業する場合、一度OOXMLからインポートした後、「名前を付けて保存」でODFにして、それを触り続けるほうがいいです。で、最後の最後、MS Officeしか持ってない人に渡すときに、再度OOXMLにエクスポートして返す。
いや、共同編集なので、私がちょっといじって直したやつを、この人に渡して、って作業したいから、出し入れ避けられない……という場合。うーん、本当にそれが必須でかつ大事な作業なら、向こうにLibreOffice入れてもらうなり、こちらが１ライセンスだけMS Office買うなり、するほうがいいんじゃないかなーと思います。
互換品じゃない、そうはいっても代替品として入れたとき
LibreOfficeはMS Officeの互換品ではないですよ、とは書きましたが、同じような機能をする「代替品」（Alternative）ではあると言えると思います。なのでMS Officeあるいはその他のオフィスソフトの代わりにLibreOfficeを導入することは、できなくはないです。
その場合、社内の既存の資産の扱い、まあこれも過去の自分たちとの「相互運用」ですね。
なのでこの場合も、いったんはOOXMLの過去資産をすべてODFにして、以降はODFで一貫して触り続けるのがよいと思います。もし、マクロの利用や外部システム連携などでOOXMLを維持し続けなければいけない……のであれば、その分だけMS Officeを、少なくとも短期的には残すのが無難じゃないかなーと。
スタイルを活用する
さて、少し視点を変えて、インポート・エクスポートをしても壊れにくい文章ってどうやって作ったらいいかという話。
それには、スタイルをちゃんと作って、文書の修飾はスタイル側に寄せるってのが有効です。スタイルの利用については書き出すときりがないので深入りはしませんが、特にWriterの場合は、直接の書式適用は原則禁止！ ぐらいにすると、結構きれいにインポート・エクスポートできると思います。
フォントを揃える、代替フォントを活用する
もひとつ、問題になるのがフォントの扱い。正しくフォントが選択されている場合、レイアウトが大きく崩れることってそんなにないのですが、文書に含まれているフォントがシステムに存在しない場合は、フォールバックフォントの扱いでけっこう崩れる……という印象が、私にはあります。
なので可能ならば各プラットフォーム共通で導入できるフリーフォント（Noto fontとかIPAフォントとか）の利用を検討するのが良いと思います。
あるいは、環境ごとの設定が必要になってしまいますが、LibreOfficeのi ツール ▶ オプション ▶ 置換テーブル で、代替フォント（あるフォント名が指定されたときに別のフォントを割り当てる）を指定してあげるのも有効です。
ODF？ OOXML？ どっちがいい？
さて相互運用においてプチ悩ましいのが、
- MS OfficeでODFとしてエクスポートする
- LibreOfficeでOOXMLをインポートする
の、どっちがいいかという話。
これって結局はMSさんのODFエクスポートとLibOのOOXMLインポートどっちを信じる？って話だと思うのですが、私はこの点に対してちゃんとした答えを持ってないです。身も蓋もないことをいえば「どっちも試して結果がいいほうを選ぶ」がいいんじゃないかと思いますけど。
いちおう、与太話的に書いておけば。
イギリス政府が政府内のオフィスフォーマットとしてODFを義務化していることをご存じの方もいるとは思います。しかし、これはODFネイティブなLibreOfficeの利用を強制してないことには注意が必要です。要はODFを正しく扱うことさえできれば別のソフトでもよいわけです。そしてMSさんにとってもイギリス政府からbanされることは望ましくないので、ODFの扱いはそれなりにちゃんとする動機はあるはず。
一方で、ハンガリー政府は「プロプライエタリ（独占的）なオフィスソフトの利用を段階的に削減すること」というポリシーを掲げています。ファイルフォーマットではなくてアプリケーションを指定しているわけです。で、このサポートを請け負っているNISZという組織では、「MSのODFの扱いが改善されるかどうかは自分たちで制御できないが、LibOのOOXMLの扱いは自分たちで改善できる余地があるから」という理由で、内部フォーマットはOOXMLのままにLibOに移行するという決断をし、そのためにLibOの開発者を内部で育成するという活動をしています。（2019.12.18追記：もちろん、LibreOffice有償サポートベンダーの活動の多くもまた、顧客から求められた相互運用性の向上です。またそれ以外の多くのボランティア貢献者もこの部分にコミットしています。）
そんなわけで両者頑張っているので、現時点でどっちが絶対の正義ってのは簡単には言えませんよと。
あーもう一点、もし編集が不要で見るだけであれば、PDFにして渡すのが一番良いですね。LibreOfficeの「ハイブリッドPDF」（埋め込みドキュメントとしてODF形式を丸ごと抱いたPDF。LibOで開けば編集可能文書、そうでなければPDFとして見られる）を活用しましょう。
おわりに
ということで埋め草なポエムでした。もうちょっとちゃんと裏付けがある話を書くべきなのですが、思いつくままの書き散らしですみません。
明日は空席ですが、Advent Calendar自体はこれから先も面白そうな記事が予告されてるので楽しみですね！
……以下おまけ。
*3:Applicationフォルダー以下のフォルダー名をリネームするだけだと、設定が混じっちゃいますが、雑にやるならそれでも可です。
