Drafts

@cm3 の草稿置場 / 少々Wikiっぽく使っているので中身は適宜追記修正されます。

Markdown as Word Processing Format

Markdown の GUI エディタ

非技術者がMarkdown をオフラインで書くのにはやっぱりちゃんとソフトウェアが必要な気がしてきたのだが、そうするといいのがない。Tools to support your markdown authoring · karthik/markdown_science Wikiをみて MarkRight と CuteMarkEd を試してみたけれど、Ｄ＆Ｄでの画像埋め込みとか対応してないし、そもそもインタフェースが使いにくすぎる。上に、Word と似たようなアイコンが並んでいてほしい。有料のソフトの中にはそれを満たしているものもあるようだ。

ここに書いていないものでも

など山ほどプロジェクトがあって、「markdown editor」の検索結果 - B!KUMA【ビークマ】なんかを見ているともう把握するのが嫌になるほどたくさん流れてくる。

結局最大限だと HTML を扱えなきゃいけないので、そういう意味でも HTML の GUI エディタの亜種として実装するのが賢い気がする。

でだいたいできるんだけど、これってブラウザ上の技術。だから、オフラインでシンプルなCMSを立ち上げて、そこにこういうタイプのエディターが組み込まれている必要がある。まあ、CMSと言わずとも、TextArea を保存、読み込みできるだけで良いので、作ろうと思えば作れるだろう。m0g/andikaみたいに electron で実装するのがスマートに思えるがこのプロジェクトは放棄されている。

ちなみに、CKEditor にこだわらなくともdraft-jsSummernoteやTrumbowyg、scribeといった新時代のツールはいろいろあるが Markdown の扱いがしっかりしているものは CKEditor とmedium-editor with medium-editor-markdown くらいだろう。

また、超高機能な StackEditみたいなのもあってこちらはMarkdownが使える。これはローカルで使う場合 Chrome アプリとして使うことが想定されているようで、そこから ssh サーバなどにアップロードすることもできるので、カスタマイズの必要性がなければ圧倒的にこれだと思う。

あと、ゆっくり調べていないが、Inside the Guardian’s CMS: meet Scribe, an extensible rich text editor | Info | The Guardianによると、いくつかのWYSIWYGエディターは出力するHTMLコードが汚いそうだ。…ああ、だから Markdown だったのだ。

  • 出力するコードの綺麗さ
  • タグの制限や、よく使うコンポーネントの登録などの拡張性
  • どのＯＳでも使えるか、Ｗｅｂでも使えるか。
  • ちゃんとメンテされているか

あたりが指標になるのだろうか。

Markdown のシングルファイルフォーマット

Markdown で 1ファイル提供が難しいので（その目的なら PDF とかに吐けって言われるかもしれないけれど、他の場所で編集したいことだってある）、決められた構造を zip で固めたような、つまり docx 的なフォーマットが必要だと思った。

HTMLについてはMHTMLがあり、多くのブラウザなどでサポートされている。しかし、MIMEのフォーマットに則っているため、US-ASCII以外のテキストデータや画像などのバイナリデータはQuoted-printableかBase64でエンコードする。など制約が大きい。かんたんMarkdownエディターはこの方式を採用しているのだが、それをされると、Pandoc で PDF を吐いたり他の形式に変換したり連携するときに面倒になる。

TextBundleというプロジェクトがイイ線いってる気がする。いくつかのソフトウェアで対応されている、zipで固めた形式だ。

Scholarly Markdown関連のブログIntroducing the Scholarly Markdown Bundleでは、git bundle を使えと言っている。また、Pandocでのレンダリング用の情報も含めろとも言っている。シングルファイルにしたいという欲求とgit bundleはあまり整合しないだろう（たしかにシングルファイルにはなるが、バージョン管理はそのシングルファイルの外側でやりたいわけだ、ファイルという概念の中にバージョン管理が含まれるのは非技術者には難しすぎる）。バージョン管理ができるという意味のメリットはあるが、利便性や実装の複雑さでデメリットがあるので、これはどうかと思う。Pandocでのレンダリング用の情報を含めるのはいいプラクティスだね。

ここで紹介されている Research Object Bundle はファイルフォーマットだけではなくプロジェクトとして興味深い。あとでちゃんと勉強しよう。

フォーマット方面では Adobe の Universal Container Format に独自の制約を加えたものを使う＝UCFの規格内のものを使うと言っているが、あまりUCFの情報がない。これは EPUB Open Container Format (OCF) を抽象化したものらしいが、抽象化は、複数のデファクトになった近いフォーマットから安定して策定できると思うので、直接 OCF を参考にして考えればいい気がする。つまり、container.xmlに

<?xml version="1.0"?>
<container version="1.0" xmlns="urn:oasis:names:tc:opendocument:xmlns:container">
    <rootfiles>
        <rootfile full-path="index.md" media-type="text/markdown" /> 
    </rootfiles>
</container>

とでも書いておくくらいの違いでできてしまうではないか。

…とはいってもこういうのを標準として広めるのは大変だ。横目で見ておくくらいのことしかできないだろう。

その他参考