SVG：いいヤツ、悪玉、醜い奴

2021/02/22 07:34

Nicolas Lenz
ドイツ・ドルトムント工科大学コンピューターサイエンスの学生

この記事は、著者の許可を得て配信しています。
 SVG: The Good, the Bad and the Ugly

SVGは「スケーラブル・ベクター・グラフィックス（変倍ベクタ図形）」の略で、スケーラブル・ベクター・グラフィックスのためのフォーマットです。この記事では、このフォーマットについての私の意見、問題点、改善点やまた改善のためにすべきことなどをまとめました。

私は数年前からInkscapeと共にSVGをスケッチやグラフィックのために定期的に使っています。私はコードを通して精密さを追求し、アートへの愛を満たすために手書きで書くのが好きです。SVGと私はある種の愛憎関係にあります。SVGはパワフルで、オープンソースの素晴らしい無料ツールがありますが、フォーマット自体はかなり醜いです。

メリット

vector graphicsのフォーマットです。Adobe IllustratorからInkscapeまで編集用のプログラムや様々なブラウザに対応しています。
Web 標準規格なので、Web サイトで直接使用することができます。また、CSSも一緒に使うことができます。
XML ベースなので、シンタクスが馴染みやすく、拡張性があり、広大な XML エコシステムが役に立ちます。例えば、XLinkを使ってSVGファイル内の他の要素や定義を参照することができます。また、Inkscape はカスタム XML タグを使用して SVG をエディタの交換フォーマットに拡張しています。
とてもパワフル。これで多くのことができます。様々なパスタイプや図形に対応し、テキストなどにも対応していますが、アニメーション、グラデーション、エフェクトなどにも対応しています。

デメリット

これはWeb標準です。そして、Web標準の慣例として、SVG は非常に肥大化しています。SVG の仕様書は、なんと826 ページもあります。それだけでは十分説明できないほどで、SVG は XML ベースであり、他の Web 標準とのクロスリンクもされているため、あらゆる実装の範囲が驚くべき範囲まで拡大しています。

すべてのSVGファイルを正しくレンダリングするためには、826ページのSVG仕様書だけでなく、例えばXLink仕様書の20ページなども読まなければなりません。ああ、そしてCSSも。あと、JAVASCRIPTもね。そうなんです。SVGファイルには<script>タグを含めることができます。

SVGはWebブラウザにぴったりフィットします。既にCSSやJavaScriptのようなものを実装しており、完全なSVGの実装に必要なものは既に実装されています。このSVGの問題は、実はWeb全般の問題なのです。SVGの範囲は広く、肥大化していて、作業が大変なのです。

SVGを1日で実装することはできません。あるいは一週間、あるいは一ヶ月でも無理かもしれません。膨大な量の特徴があり、ほとんどの場合は部分的にしか実装されていないため、何が何をサポートしているのかを概観することが非常に難しく、SVG ファイルを全体的にサポートしたい場合、実際にどのような機能を使用できるのか分かりにくく、ユーザーを混乱させてしまいます。

さらに、XMLベースのシンタックスはかなりひどく、無駄に冗長です。手書きで書くのは疲れるし、自動でパースしたり生成したりするのも疲れるほどです。

最悪な点

上記の点から考えられる中心的な問題は、機械 VS 人間の言語設計についての私の記事で詳述したものです。SVG は、機械に焦点を当てた言語なのか人間に焦点を当てた言語なのか、どちらの方向に向かっているのかが分からず、中途半端な結果になっています。

SVGは機械処理可能な言語なのでしょうか？それにはあまりにも肥大化しすぎています。SVG用のパーサ、レンダラー、ジェネレータを書くのは膨大な作業です。シンタックスは反復的で複雑です。もっと基本的な機能で表現できる機能がたくさんあります。

それは人間が直接使用するのに適したフォーマットでしょうか？いいえ、適していません。第一に、疲れるシンタックスとその複雑さは、人間のユーザにとっても良くありません。第二に、人間が直接使うのに適した多くの機能を外しています。人間が直接使うことを目的としたグラフィック言語としては、LaTeXのTikZがあります。私の考えでは、ユーザーエクスペリエンスに関しては優れた言語ではありませんが、間違いなく人間のためのものであり、複雑なグラフィックスを簡単に作成するのに必要な機能が兼ね備わっています。しかし、完成したグラフィックの交換フォーマットとしてTikZコードを使おうという発想は誰も持っていないでしょう。グラフィックを見るためだけに1300ページに及ぶTikZのマニュアルを読んで実装したいと思う人はいないでしょう。その代わりにPDFにコンパイルしてしまうのです（これもひどいフォーマットで、ひどく肥大化していますが、まあいいでしょう）。もしSVGが人間の使うための言語だったら、機械に焦点を当てたフォーマットにコンパイルするのが良いでしょうが、さきほど私が言ったように、そうではありません。どちらでもありません。

次は何？

機械で簡単に処理できるように設計されたシンプルなベクターグラフィックスの交換フォーマットを開発することが最善策でしょう。それも可能な限り最小限の機能で。たぶんJSONベースですが、XMLベースではないでしょう。基本的なレンダラーを数日、あるいは数時間で実装できるはずです。ベジェ曲線、楕円曲線、塗りつぶし、アウトライン、グラデーションがあれば、ほぼすべてのSVGを表現するのに十分なはずです。拡張子は、別のファイル拡張子でアニメーションを許可することができます。

このように最小限に抑えられたフォーマットには、厳格なテストスイートがあり、ブラウザや画像ビューアに比較的簡単に実装することができます。ユーザーはグラフィックがどこでも動作するということを信頼し、実装者は XLink、CSS、JavaScript の実装を心配する必要がありません。帯域幅と計算パワーを節約できます。SVG との互換性を保つために、SVG との間のコンパイラを書くことができます。

これは、InkscapeやAdobe Illustratorのようなユーザー向けプログラムのエクスポートフォーマットとして使用することができます。コードを通してグラフィックをマークアップしたい人のために、TikZやHaskellのダイアグラム、Pythonのmatplotlibのようなものがすでにありますが、これらも新しい最小交換フォーマットにエクスポートすることができます。

実は、将来的には大学の学生研究プロジェクトとして、自分の目的に合わせて、機械に特化したスリムなベクターグラフィックス形式（SlimSVGという名前が提案されています）を作って、人間に特化したHaskellグラフィックス作成ライブラリを書こうと考えています。

まとめ：言語が人間のためのものなのか機械のためのものなのかを決めて、どちらの方向に進むかを決めることが大事なのです。そして、両方ではなく、どちらか一方のことをうまくやるようにすればいい結果が出るはずです。