【執筆報告】日経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フォルダー以下のフォルダー名をリネームするだけだと、設定が混じっちゃいますが、雑にやるならそれでも可です。
Acrobatが買えなくても安心、PDFの墨消し
この記事はLibreOffice Advent Calendar 2019の15日目の記事です。昨日はhajime_nakagamiさんのLibreOffice の Base と Firebirdでした。
さて。お手元にある特定の文書。誰かにお渡しなければならないのだけど、あるいはWebなどで公開する必要があるのだけど、いやーこの一部の情報だけは隠さないといろいろまずい。そんな状況に急に追い込まれることが、この複雑な社会で生きていると、あるかもしれません。
要は見えなきゃいいんでしょ？ じゃあ黒いオブジェクトを上に乗せて、PDFにして編集不可にすればいいじゃない。
ほら、これで大丈夫！
けど、このPDFをLibreOffice Drawで開くと……
動かしたら情報丸見え！
そう、単にPDF化しただけでは、オブジェクトとしては残っちゃってるんですねー。
ナニナニ？ Acrobatには「墨消し」機能があるからそれを使え？ はいはい、結構ですね、でもそれだけのためにAdobeさんに課金するのも少々シャクじゃないですか？
そんなあなたに。LibreOfficeの「墨消し」機能をご紹介。6.3の新機能です。
こうやって、ツール ▶ 墨消し、を選びますと、おもむろにDrawが起動して、墨消ししたいドキュメントが転記されてます。が、一つ、見慣れないフローティングなツールバーが。
こいつ。これが「墨消し」ツールアイコンです。この左端のアイコンを選ぶと長方形が書けるようになるので、こんなふうに隠したい部分に重ねます。フリーハンドでヌリヌリしたい場合はその右のフリーハンドアイコンを使えばOK。
透けてるじゃないかって？ これは意図的です。消すべきものをちゃんと消しているかを判断するため。
そして、右から二番目のアイコンをクリックしますと、PDFエクスポート機能が起動して、出力されたファイルを確認すると：
ちゃんと墨消しされてますね！
……いやいや、だからオブジェクト重ねてるだけじゃダメって話だったじゃん？ PDFとしてどうなってるかわからん、信用ならん。そんなあなたに、今街で話題のこのツール
で見てみましょう。
> hpdft -r 1 suminuri-sample.pdf [ /Type: /Page /Parent: 7 /Resources: 9 /MediaBox: 0.0, 0.0, 595.303937007874, 841.889763779528 /Group: /S: /Transparency /CS: /DeviceRGB /I: True /Contents: 2] > hpdft -r 2 suminuri-sample.pdf [ /Length: 3 /Filter: /FlateDecode, 0.1 w q 0 0.028 595.275 841.861 re W* n q 595.304 0 0 841.89 0 0.028 cm /Im4 Do Q Q ]
私のPDF知識は限りなくゼロに近いですが*1、ページの中にあるコンテンツはテキストじゃなくてイメージがべったん貼ってあるだけなんですね。これなら安心！
逆に言うと：
> pdftotext suminuri-sample.pdf >
なんにも出ないわけで、セキュリティ面はバッチリですが、PDFとは……というお気持ちになります。まあ、それはしょうがないというか、なんというか。こういう用途だとテキストいっさい抽出できないほうがほうがいいというのはそのとおりですね。
最後に小ネタ。「墨消し」ですが、墨じゃなくて白に塗ることもできます。
ということでちょい遅れでしたが時事ネタでした。 明日はEiichiroKさんの「writerでスタイルを使って文章を書くと楽になる」です。よろしくおねがいします。
続きを読むNextcloud+LibreOffice Onlineの検証環境をdockerでさくっと立てる
この記事はLibreOffice Advent Calendar 2019の12/8分の記事となります。昨日はアイクラフト村上さんの「LibreOffice Conference 参加報告と珍道中」でした。わたくしの台風大変でした記事より遥かに面白かったですね。
今日は小ネタ。みなさんに公表したいというより、わたくしの個人的メモ。忘れそうなのでね……。
LibreOfficeくんには、LibreOffice Onlineという「オンラインで（ブラウザ越しに）使えるLibreOffice」があります。通称LOOL（ろーる）。
こいつ実用的にもきっと便利だと思うのですが*1、それよりも実装がなんというか大胆で、個人的にはそこがキュートだと思っております。そんな話をこないだオープンソースカンファレンス2019 Tokyo/Fallで話をしたんですが、いやー人来なかったですねｗ せめてスライドのPVだけでも上げたいのでリンク貼っときます*2。
さらばデスクトップ？モバイル・クラウド時代のLibreOfficeの挑戦/LibreOffice current status, or the challenge in the new mobile/cloud era from Naruhiko Ogasawara
www.slideshare.net
まあともかくそんなかわいいLOOLちゃんをちょっとさわってみたい、デモりたいとき。むかしはPCでLibO本体含めビルドしてたんですが（それはそれで、実装まで見られて面白い）、スライドにも書きましたがLOOLちゃんは単独で動作するとたんなる生々しい部品で、ほかのソフト……典型的なのがNextcloudですけど、の中に組み込むと威力を発揮するので、そういう環境のほうがデモ映えするじゃないですか。なのでNextcloud+LOOL作りたい。
で、わたくしコンテナとかの分野には明るくないのですが、さくっと検証環境作ってすぐ捨てるみたいなときはdockerとか使うし使いたいなと*3。で、前述のOSCのスライド作るために重い腰をあげてやってみたら一瞬で、なんだ簡単じゃんってなりました。なのでみなさんも簡単にLOOL立てて遊んでみてほしいなと。
あ、これから書くやりかたはあくまでも検証用・デモ用です。普通に外部にLOOLのポートさらしたりするので、遊び終わったら捨てる感じでお願いします。本番向けの手順は昔の記述はチョロチョロあるけど結構変わっている感があるので、だれか今年のカレンダーで書いてくれないかしら……。
用意するもの
- なんか固定IPまたは外部解決可能な名前をもった環境
- わたしはAWS上でt2.medium借りました。メモリは2GBぐらいあったほうがいいです
- そのなかにUbuntu 18.04LTS
- ポート22、80、9980を開放
- docker入れる（
sudo apt install docker.ioで入るやつで十分）
あ、Ubuntuじゃなくてももちろんお好みのディストリビューションで良いですよ。
手順
お断りですが、実は今回のお試しはLOOLそのものではなくて、LOOLを元にした商用版Collabora Onlineの開発者向けディストリビューションCODEというのがありましてそいつを使いました。
LOOLのdockerイメージも配られてるので手順一緒だとは思うんですけど未検証なので……違いがあったら後ほど別記事でフォローします or 誰か書いてください。
で、基本的にはCODEの解説ページ
にある手順なんですけどこのページ微妙に情報足りない気がする*4のでそれだけ……。
まずはNextcloudをdockerで上げます。雑にHTTPで。
docker run -d -p 80:80 nextcloud
で、http://ホスト名/ でNextcloud 起動して初期設定済ませたら、「アプリ」で「Collabora Online」を入れます。プラグイン名はこうだけどオープンソースなLOOLも使えますのでご安心を。
Collabora Online - Apps - App Store - Nextcloud
次はCODEをdockerであげるのですが、前述ページにしたがってコマンド叩くと、後の手順でLOOL君がNextcloudからの接続拒否るのでしばらく悩みました。話は簡単で、Nextcloud-LOOLの接続を外部名でするのですが、LOOLのデフォルト設定はlocalhostまたはプライベートアドレスからの接続以外を拒否るようになってるからですね*5。なので外部名を環境変数で指定してあげればOK。
docker run -t -d -p 9980:9980 -e "domain=<your-dot-escaped-domain>" -e "extra_params=--o:ssl.enable=false" collabora/code
<your-dot-escaped-domain> はたとえばIPアドレスだったら 203\.0\.113\.123 みたいにドットをバックスラッシュでエスケープしてあげたやつ。
で、docker attach でLOOLのコンテナにアタッチしてログ見て、LOOL起動するまで待ってあげたほうが無難。ちょっと時間かかるので。
最後にNextcloudに戻って、設定 > Collabora Onlineにて、ここで指定したドメインまたはIPアドレスを http://203.0.113.123:9980 のように設定すればOK！
簡単でしょ。ぜひ、遊んでみてください。そして、本番向け手順をAdvent Calendarに書いてくれるとうれしいです。
なんかうまく起動しないなーという場合はさっきアタッチしたところでなんかログが出てると思うのでそれを確認してみると参考になるかもです。
明日はbaffclanさんです。よろしくです！
