HOME > 電算 > Inkscape メモ（旧）

概略

Inkscape は、Linux, Windows, Mac OS X などのプラットホームで動作するオープンソースかつフリーのドローイング・ツール（ドロー・ソフト）である。SVG という形式にネイティブに対応しているのが著しい特徴。私は今は Linux でバージョン 0.46 を使いはじめたが、このページの記述はまだ 0.43 あるいは 0.44に対してなされたもののままのものが多い。とくにユーザインターフェースについてはバージョンによりかなり変わっている。まあ、いじっていて気づいたことを備忘録ついでにメモしておく。（当然誤りも含まれているかと思われる……）

本家は http://www.inkscape.org/index.php

現在（2008-5-16(Fri)）における最新の安定版は 0.46 で、http://wiki.inkscape.org/wiki/index.php/ReleaseNotes046 にリリースノート。

Inkscape のマニュアルは http://www.inkscape.org/doc/ からたどることができる。

画面の説明は http://ja.wikibooks.org/wiki/Inkscape/%E7%94%BB%E9%9D%A2%E8%AA%AC%E6%98%8E などを見れば一応了解されるであろう。

SVG については、http://www.w3.org/Graphics/SVG/ 。

SVG の現在最新の完成バージョンは 1.1。Inkscape 0.44 で作成した文書は名前空間として SVG 1.0 を宣言している。なお、Inkscape のテキスト流し込みの機能は SVG に準拠していない。

Inkscape 雑感

Linux で動くフリーのドローソフト（ドローイング・ツール）のなかで、最も使いやすいように思える。ちょっとした図を作成して LaTeX に張り込むような場合にまず選択できる。

SVG は XML なので、基本的にテキストエディタでの編集が可能である。Inkscape は手書きした SVG を読み込んで、必要な編集を加えるという使い方とも相性が良い。

簡単に拡張スクリプトが書ける。たとえば、pstoedit と skencil（元 sketch） に下請けさせて Postscript を読み込むスクリプトなどがもれなく（？）ついてくるぞい。（手書きポストスクリプトを GUI で編集できたりして感動的だぞ）。

「職人の業をコンピュータ上で再現できるようにまずユーザ・インターフェース考えて、それを実現するためにデータ構造が決められているのがお絵描きソフトというものだ」と考えていると、Inkscape は実際以上に質素なものに見える。むしろ、SVG というデータ構造が先にあり、これを操作するための GUI を備えた実装が Inkscape であると考えるとしっくりいくし、ユーザインターフェースも合理的であるということに気付く。また、最初の印象よりもずっと多くの場面で使えるということを発見する。

とにかく Inkscape は Adobe Illustrator 嬢ほど微笑んではくれないが、付き合ってみるとなかなか話のわかるオッサンだ。

おまけ

Inkscape で作成した SVG ガラス玉。（改変するなりして自由に使う可）

ball.svg (12KB)

id="stop7629" と id="stop10344" の stop エレメントがもつ style 属性の stop-color に #00FF00 といった RGB 形式の色を指定してやると、玉の色が変わるよ（どちらも同じ色でよし）。エディタで編集して遊ばう。

Inkscape と SVG

標準保存形式 Inkscape SVG はどんなものなりや？

Inkscape の標準的な保存形式（Inkscape SVG）は、たいへんキュートなものである。

Inkscape の標準的な保存形式は、SVG である。しかし、これは保存されたファイルから SVG の規格に定められているエレメントだけを拾って読んでも期待した通りにラスタライズできるという意味であり、実際には独自に定義したエレメントを含んでいるし、属性も追加されている。これらの追加されたエレメントや属性は、もっぱら Inkscape の GUI を使い勝手がよいものにするために用いられている。

たとえば、Inkscape で円は circle エレメントではなく、path エレメントとして作成される。この path エレメントは、円弧曲線を描くための M コマンドを 1 回、A コマンドを 2 回用いる（緑字まはた斜体部分）。

    <path
       sodipodi:type="arc"
       style="opacity:1;fill:none;fill-opacity:1;
              fill-rule:evenodd;stroke:#000000;stroke-width:1;
              stroke-linecap:round;stroke-miterlimit:4;
              stroke-dasharray:none;stroke-dashoffset:0;
              stroke-opacity:1"
       id="path7567"
       sodipodi:cx="-17.172863"
       sodipodi:cy="236.15866"
       sodipodi:rx="125.25864"
       sodipodi:ry="125.25864"
       d="M 108.08577 236.15866 
          A 125.25864 125.25864 0 1 1  -142.4315,236.15866 
          A 125.25864 125.25864 0 1 1  108.08577 236.15866 z" />

（M コマンドは現在位置を移動する。A コマンドは、現在点を始点としたうえで、終点を定め、それらを結ぶ楕円の弧を描く。これを描くために、楕円の二つの半径、円弧を楕円のどの部分から切り取って使うのかを示す角度（あるいは、楕円を回転させる角度）、右まわりに行くか左まわりに行くかを示すフラグ、長いほうの弧を使うか短いほうの弧を使うかを示すフラグ、という情報を用いる。面白いことに、楕円の二つの中心（円ならばこれらは同じ点になる）の座標データは使われない。）

だが、Inkscape SVG は、この円を特定するために必要な情報をそっくりもう一組み保持している（赤字または太字部分）。これは、楕円の中心と二つの半径を持っている。

実際に Inkscape を使ってみてわかることは、Inkscape はファイルの読み込み時に後者の情報を利用していて、前者の情報はたんに保存時にファイルが SVG としても読めるように付加されているらしいということである。

なお、Inkscape は独自のエレメント定義や属性定義を使うために、最上位にあたる svg エレメントの中で名前空間を追加している。

<!-- Plain SVG で保存した場合の名前空間 -->
   xmlns:svg="http://www.w3.org/2000/svg"
   xmlns="http://www.w3.org/2000/svg"

<!-- Inkscape SVG で保存した場合の名前空間 -->
   xmlns:dc="http://purl.org/dc/elements/1.1/"
   xmlns:cc="http://web.resource.org/cc/"
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:svg="http://www.w3.org/2000/svg"
   xmlns="http://www.w3.org/2000/svg"
   xmlns:sodipodi="http://inkscape.sourceforge.net/DTD/sodipodi-0.dtd"
   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"

SVG の 「XML 名前空間」

xmlns 属性は XML名前空間を識別するために用いられる。Inkscape はこの属性を厳格にチェックするので、手書きした SVG ファイルを Inkscape で読み込むような場合には注意が必要となる。

SVG でデフォルトの名前空間は http://www.w3.org/2000/svg である。しかし、名前空間の宣言が xmlns="http://www.w3.org/2000/svg" だけで済むとは限らない

たとえば、use エレメントを用いて、パスを再利用するような場合、 href という属性を使い、他の部分ですでに定義したパスを引用する（この仕組みは Inkscape の GUI インターフェースで「クローン」と呼ばれている）。しかし、ここでの href という属性はデフォルトの名前空間にはなく http://www.w3.org/1999/xlink という名前空間に属している。

そのため、use エレメントかそれより上位のエレメントで（たいがいは svg エレメントで）xmlns:xlink="http://www.w3.org/1999/xlink" のように名前空間の接頭辞を宣言しておき、use エレメントの中では xlink:href="#g2115" のように用いる必要がある。

クローンとコピー

クローンとコピーは異なる。あるパスをコピーすると、オリジナルとそっくり（しばしば位置だけ異なる）の path エレメントがもう一つ作成されるのに対して、クローンの場合は use エレメントと使って、オリジナルのオブジェクトが引用されるに過ぎない。

オリジナルのパスをそのまま移動させたり拡大してもクローンの大きさには変化がないが、オリジナルのパスを構成するノードのうちの一つを動かしたり、ノードやセグメントの削除・追加を行うと、これはすぐさまクローンにも反映される。

これは、use エレメントは、オリジナルのオブジェクトとはべつに、独自に transform 属性を持っているからである。

レイヤーのこと

レイヤーは、SVG に規定がない。Inkscape のレイヤーは、SVG 的にはただのグループに過ぎない。Inkscape では、グループオブジェクトに独自の名前空間で定義したプロパティを追加してユーザインターフェース上で特別な扱いがなされるようにして、それをレイヤーと呼んでいるのである。

Inkscape 0.44 で新規に文書を作成すると、デフォルト・レイヤーとして Layer1 というものが用意される。xml エディタなどで、SVG エレメント直下に、オブジェクトを配した場合、Inkscape はこのオブジェクトが載るレイヤー名として (root) を表示する。

Inkscape で作成したレイヤーつきの文書を Plain SVG で保存し、これを再度 Inkscape で開くと、独自定義のプロパティが失われた結果、一般的なグループが (root) 上に載っている状態として読み込まれる。

一般的なグループをレイヤにするためには、XML エディタを使い、グループオブジェクトに inkscape:groupmode プロパティを作成し値を layer にセットして、さらに inkscape:label プロパティを作成し値に任意のレイヤー名を与えてやればよい。（GUIファンは「グループの切取り、新レイヤ作成、同じ場所にペースト、グループ解除、レイヤの階層を移動」）

レイヤーがグループオブジェクトである以上、入れ子にすることができるかもしれないと思い、Inkscape 0.44 で試みてみた。できた。ウィンドウのレイヤー表示部には親レイヤーも子レイヤーも同等に表示されるが、親レイヤーを不可視にすると、それは子レイヤーにも及び、親レイヤーを削除すると子レイヤーも削除される。

「変形」

「オブジェクト」→「変形」で出てくるダイアログボックスには 5 つのタブがある。「移動」「スケール」「回転」「傾斜」「変形」である。このうち、はじめの 4 つでできることは、みな「変形」でできることである。

これらのメニューに数値を入れて「適用」すると、そのたびにオブジェクトが変形（移動・回転・傾斜）するが、最終的にオブジェクトにどのような変形が加わったかのかは「オブジェクト」→「プロパティ」を見るとわかる。

こうした「変形」は、対象となるオブジェクトの transform 属性を書き変えることによって実現している。

transform 属性は、matrix, translate, scale, rotate, skewX, skewY という 6 種類の "transform difinitions" （いい訳思いつかぬ。変換指定といったところ）によってどう「変形」するかを指定することができる。

ここでの translate, scale, rotate, skewX, skewY は、みな結局 matrix ひとつで指定できる変換である（ただし、計算を要する）。

マウスを用いたオブジェクトの移動や回転は、この matrix を書き換えることによる実現する。ただし、「Inkscape の設定」→「変形」タブから、「transform 属性を使わない」をオンにしておくと、できる限りオブジェクトの他の属性によって変形を実現しようとする。

なお、transform 属性を用いた場合、オブジェクトを拡大すると、輪郭線も太くなるのが SVG 通りであるが、Inkscape では、特に「Inkscape の設定」→「変形」ダイアログボックスから、「線の幅を拡大／縮小」のチェックを外し、輪郭が太くなったり細くなったりしないよう輪郭線の太さを調節するよう設定することもできる。

Inkscape の拡張

Inkscape はスクリプトを書いてやることにより、容易に拡張できる。この仕組みをエクステンションと呼んでいる。http://wiki.inkscape.org/wiki/index.php/ScriptingHOWTO あたりを見ると概略がわかる。

エクステンションをその働きにより分類すると、
(A) ファイルを読み込む
(B) ファイルを書き出す
(C) 編集中に SVG を受け取り SVG を返す、
という 3 つのタイプがある。
はじめの二つのタイプの場合、ファイルを開く／保存する時にファイルタイプの判別／選択により起動されるので、ユーザはそれが外部スクリプトであることに気付かないかもしれない（というか、気付かないよねふつう）。もし Inkscape がどういうファイル形式を読み／書きできるのかに関心があるのなら、この種類のエクステンションが何をしているか（たとえば、どんな外部プログラムに下請けに出しているか）を知っておく必要がある。
さいごの (C)は effects というメニューに現れるので、それと知れる。

エクステンションを実現手段により分類すると、
(甲) C や C++ による内部的な方法。いわゆるネイティブで対応していると考えられているものは、これを使っているそうで、そういう意味では一般にエクステンションと考えられているものとは違うかな。
(乙) (一時的に作成された) SVG ファイルのパスをコマンドライン引数として受け取り、あらたな SVG を標準出力に出力すような形で書くスクリプト向けのやり方。これは、さまざまな言語で書くことができる。多くの人が Python で書いているのは、たんに SVG が扱い易いからであらう。Perl もよく使われる。シェルスクリプトから外部プログラムを呼び出している場合もある（pstoedit 経由で Postscript が読み込めるのはこの仕組みだ）。
(丙) XSLT による方法。未実装？（Inkscape 0.46 でサポートされたもよう。リリースノートに XSLT is now supported for input, output and effect extensions. ）
(丁) DOM による方法。私は試してない。
がある。

参考、http://wiki.inkscape.org/wiki/index.php/ExtensionArchitecture#Functionality_Provided

こうしたエクステンションを Inkscape から使えるようにするためには、INX ファイルという形で必要なことを書いておいてやる。働きによるとどれに分類されるのか、実現手段によるとどれに分類されるのかということも、これに書いておく。また、スクリプトの場所だとか、Effect をつくる場合にユーザに問う値だとかもこれに記す。INX ファイルの置き場所は、私の環境では、/usr/share/inkscape/extensions になっている。

こうしてみると、われわれが「拡張してえ」と感じる日常用途では、(C) を（乙）で処理するためのスクリプトを書いておくことになりそうだ。そして、そうしたスクリプトを書くために、Python のクラスが用意されているから、利用すると楽。この便利なクラスは、effect といい、inkex.py というファイルに書かれている。これを使うと、GUI の Effects メニューからスクリプトを引っ張り出したときに選択されているオブジェクトに対して処理をしたりするのも簡単だぜ。

今日の一言：シェルスクリプトの終了コードは数字でないと駄目。

他のファイル形式の読み書き

Inkscape は、さまざまなファイル形式の読み書きができるが、その多くは外部プログラムを利用して SVG 形式に変換しているのである。ユーザはそれと気付かずに利用することができる。（Inkscape の拡張参照）。Linux 環境の話であるが、Windows 版でも dill 版の python などが（たしか）標準でついてくるので、これを利用してかなりのことが行えると思うが、実際確かめてないよ。

Adobe Illustrator 形式

読み書きとも外部エクステンションを利用。

読み込み：ai_input.inx の指示により、処理が perl のスクリプトである ill2svg.pl （Inkscape についてくる）で行われる。これは、シェルからも使える独立したもので、多量に処理するときにはいいかも。でも試してない。

書き出しは、ai_output.inx の指示により処理が Ghostscript により行われる。コマンドは gs -q -dNODISPLAY -dSAFER ps2ai.ps

Adobe Illustrator の SVG

読み込みはネイティブで対応。ただし……

Illustrator の人が作った SVG のサイズがひどく大きいので、エディタで開いてみた。やたら未知のエレメントがあて、何がなんだかわからぬ。未知の名前空間がどっさり定義されていて、デフォルトの名前空間ですら、見なれた例のやつではない。

http://wiki.inkscape.org/wiki/index.php/FAQ#I_exported_an_SVG_file_from_Adobe_Illustrator.2C_edited_it_in_Inkscape.2C_and_imported_back_to_AI.2C_but_there_my_changes_are_lost.21

（和訳している人いた http://wikiwiki.jp/inkscape/?FAQ#uc6ab4c7）

てな頁を発見。ようするに、(1) Illustorator が生成した SVG は、SVG として読むことができる (2) しかし、独自定義のエレメントを追加して、Illustrator 用のバイナリをそっくり保持している、というのだ。ちなみに、Illustrator で保存するときに、Preserve Adobe Illustrator Editing と Optimize for Adobe SVG viewer のチェックを外せば、この太っちょな形式にはならないらしい。

Inkscape には XSLT で Illustrator が作った重い SVG 書類から不要な部分を削除するスクリプトがついてくる。私の環境では、/usr/share/inkscape/extensions/aisvg.xslt というのがそれだ。これは、「.ai.svg」 で終わるファイル名を読み込むときにフィルターとして作用するよう設計されているらしいが、私のところでは、ファイル名をそのやうに変えても機能しなかった。（※これは Inkscape 0.46 で使えるようになったもよう。リリースノートに This is used to support the XAML file format (both import and export) and the Adobe Illustrator SVG import which removes Adobe's stuff from SVG. とある）（余談：この inx ファイルのDescription によると、「Adobe Illustrator SVGs を開く前に cruft を削除する」と書いてある。cruft をリーダーズ（第 2 版）で引くと、「いやなもの; 粗末な作りの結果」とある。）

http://wiki.inkscape.org/wiki/index.php/ExtensionArchitecture#Implementation_Types によると、XSLT プロセッサには libxml のやつをリンクして使っているそうだが、I am not aware of the status of the XSLT implementation. としっかり書いてあるから、未実装なのかなあ。実際にやってみたけど動かなかったよ。仕方ないから、自前の xsltproc で、

$ xsltproc aisvg.xslt large_ai_file.svg > modest_one.svg

などとやってやったら、たとえば 1.9M あるファイルが 602 KB になった。

Plain SVG

W3C が定義しているエレメントや属性だけを SVG 書類だけ（ちょっと例外あり）を使った形式を、Inkscape では、Plain SVG と呼んで、デフォルトの Inkscape SVG と区別している。読み込み、書き出しともネイティブで対応。

Inkscape SVG を読み込んで、Plain SVG で保存し直すといくらかの情報が落とされて、ファイルサイズは小さくなる。ただ、たとえば、Adobe Illustrator で作成した SVG を読み込んで、Plain SVG で保存してもサイズは（ほとんど）変わらない。予想していない名前空間に属するエレメントや属性は Plain SVG で保存するときに、そっくり残しておいて安全を図っているらしい。

以下は、接頭辞のないエレメントと、接頭辞が svg のエレメント以外をすべて削除してして無理やり Plain SVG っぽいものにする XSLT スクリプト。（属性のほうには手を触れない。）なお、Adobe Illustrator の SVG の減量については、最初から Inkscape におまけ XSLT スクリプトがついてくる。

<?xml version="1.0"?>
<xsl:stylesheet
	xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"
	xmlns="http://www.w3.org/2000/svg" 
	xmlns:svg="http://www.w3.org/2000/svg" >
  <xsl:output method="xml" indent="no" />
  <xsl:template match="/">
    <xsl:apply-templates select="svg:svg" />
  </xsl:template>
  <xsl:template match="@*|svg:*">
    <xsl:copy>
      <xsl:apply-templates select="@*|svg:*" />
    </xsl:copy>
  </xsl:template>
</xsl:stylesheet>

参考
http://www.w3.org/TR/1999/REC-xslt-19991116#copying
（同邦訳 http://www.infoteria.com/jp/contents/xml-data/REC-xslt-19991116-jpn.htm#copying）
http://www.asahi-net.or.jp/~ps8a-okzk/xml/xslt10_1/copying.html の使用例

たとえば、プロセッサに xsltproc を使うなら、

$ xsltproc script.xsl old.svg > new.svg

てな感じで。うまくいくかどうか保証の限りにあらず。

Postscript

書き出しはネイティブで対応。

読み込みは外部エクステンションを利用。ようするに、「Postscript --(pstoedit)--> sketch,skencil 形式 --(skconvert.py)--> SVG 形式」ということですな。Inkscape が Postscript を読み込めないようなら、pstoedit と skencil をインストールしろということです。細かく見ていくと……

ps_input.inx の指示により pstoedit -f sk を実行。sk というのは、Sketch Format のこと。Scketch Format とは、以前 sketch と称されえた skencil というドローイング・プログラムで使う形式のこと。次に、ps_input.inx は、その Scketch Format を sk_input.inx という inx ファイルに任せる。この inx ファイルは、sk2svg.sh というシェルスクリプトを起動。これは skconvert というプログラムを起動するが、この skconvert というのは skconvert.py という python のスクリプトで、sckencil をインストールすると同時にインストールされるもの。これによって SVG ファイルに変換される。あーめんどい。

Dia 形式

Dia というのは、ダイアグラムエディタ。フローチャートなんか書くのが楽なやつ。Inkscape にもコネクタというのがあるが、Dia のほうが特化しているのでよい場合がある。

読み込みは dia.inx が dia2svg.sh に任せる。dia2svg.sh は、なんのことはない Dia を起動して SVG で保存するだけのもの。最初から Dia で SVG 保存したのと何ら変わることなし。

書き込みはできない。

DXF 形式

CAD が使うファイル形式だそうだが、私には未知のフォーマット。

読み込みは dxf_input.inx が dxf2svg というプログラムに下請けに出す。このプログラムの正体は私には不明。

書き出しは dxf_output.inx に指示が書いてあって、まず Postscript で出力してから、ps2dxf.sh という Inkscape 付属のシェル・スクリプトを使う。このシェル・スクリプトは pstoedit -f dxf をやるだけのもの。

書き出しらしきものにもう一つあって、dxf_outlines.inx が dxf_outlines.py という Inkscape についてくるプログラムを起動。これが何なのかは、私にはさっぱりわからない。

その他

まだまだいろいろあるが、またの機会に。

単位のこと

どうも、ピクセルという単位が気持ち悪いので、メモを作成して整理。（私の誤解、胡麻化し、誤解を生む表現などに満ちているはず。正しい情報は SVG と CSS2 の仕様書から得て頂きたく存じ候）

まず、あたり前の話

ピクセルとは、一般に出力デバイスが作りうる最小限のユニットということになってゐるやうである。つまり、それは「物」であり、一個二個と数えるものである。一方、この「物」の一辺の長さを一単位として、長さを測ることが行われる。それを○○ピクセルと表現し、この場合はピクセルは「物」ではなく、長さの単位である。とうぜん、1 ピクセルが何ミリメートルにあたるかは、出力デバイスに依存する。また、出力デバイスの解像度などを表現するために、1 インチあたりにいくつのピクセルが入るかという表現が行われる。dpi というのがそれである。ここで dpi が既知であれば、ピクセルをいくつつなげた長さであるかによって、出力デバイスに依存しない絶対的な長さを表現することができる。90 dpi で 90 ピクセルの長さといえば、1 インチというのと同じである。このように dpi とピクセル数で長さを表現するというのは、広く行われている。

Inkscape の仕様は質素か

私の環境の Inkscape は、1/90 インチを 1 ピクセルと定義し、これをデフォルトの単位としている（ビルドによってこれが異なるのかどうか、私は知らないので、以下読み替える必要があるかもしれない）。この関係は Inkscape では常に一定であり、設定し直すことはできない。これは、人気ペインティング・ツールの Gimp で、長さの単位であるピクセルとインチの関係を自由に設定することができるのに比べて、一見質素な仕様のように見える。

CSS2 にいうピクセル

まず、Inkscape は SVG 準拠である。その SVG にはピクセルというときは CSS2 の定義によるとある。CSS2 では、ピクセルを出力デバイスの解像度に依存しない単位として定義し、出力デバイスの最小単位としてのピクセルのほうは、デバイス・ピクセルと呼んでこれを区別している。

では、CSS2 では 1/90 インチを 1 ピクセルの長さと定義しているのかというと、そう単純なものではない。CSS2 は 1 ピクセルを「90 dpi の解像度をもつ出力における 1 デバイス・ピクセルを 28 インチ離れたところから見たのと同じ視角になる長さ」と定義している。

視角とは何ぞや

視角（visual angle）というのは、対象の端から端までが視る者にとってどのくらいの角度の中におさまって見えるかということで、これは対象の大きさと対象までの距離に依存する。

対象の大きさ、対象までの距離と視角の関係は

視角 = 2 arctan (対象の大きさ / 2 / 対象までの距離) 

のようになる。（図に描くと単純なことなんだが、難しそうに見えるぞ）

28 インチ離れたところから、1/90 dpi の出力デバイスによる 1 デバイス・ピクセルを眺めると、視角は約 0.0277 度である。つまり、これが CSS2 のピクセルの正体だ。

（ここで、細かいツッコミをさせてくれ。CSS2 の規格では 1 ピクセルの長さを定めて、それが 10 個集まったら 10 ピクセルということになっているのであって、10 ピクセルの視角が 1 ピクセルの 10 倍の視角だと言っているのではない。もし、後者のような定義であったならば、視界の周辺部では 1 ピクセルの絶対的な長さがひどく大きなものになってしまい、ピクセルとミリメートルの変換なんてできたもんじゃない。それはそれで、プラネタリウム向きの規格かもしれないけどね）

ためしに、地球から太陽を見たとき何ピクセルになるか計算してみやう。地球から太陽までの距離はおよそ 1 億 4900 万 Km であり、この距離における 1 ピクセルの大きさは、7 億 2034 Km である。太陽の大きさは 139 万 Km であるから、これは 約 19.2 ピクセルにあたることになる。

ふたたび Inkscape のこと

そういうわけなので、Inkscape で 1 ピクセルが 1/90 インチに固定されていて、かつ、Inkscape が CSS2 に準拠しているということは、目と出力の距離に 28 インチが想定されていることを意味しているとも言える。

なお、「1 ピクセル ＝ 1/90 インチ」というのは、Inkscape のディスプレイ上の表示にも、印刷の場合にも用いられる。もっとも、ディスプレイ画面の場合は、（プラットホームによって違いそうではあるが、私のところでは）解像度に 90 dpi のディスプレイ装置を想定していて、私の 85 dpi のディスプレイ装置では実際より若干大きく表示される。プリンタで印刷する場合には、たとえばポイントなどの絶対的な単位に換算して命令を送るなどするので、その長さは正確である。

ピクセルによる長さ指定の問題

版下（製版するための原稿）を作成するような場合、CSS2 に定めるピクセルで長さを指定すると困ることになる。CSS2 のピクセルで表現されたものは、目から出力物までの想定された距離に応じて出力物のサイズが変わってしまうからだ。こうした場合、ミリメートルやインチなどの絶対的な長さを表わす単位が望ましい。

ところが Inkscape では、デフォルトの単位をピクセルからミリメートルやインチに変えることはできない（「本当？」）。どうするか。

（じつのとろ、CSS2 が定めるピクセルというのは、出力デバイスに合わせて若干の出入りを許すものであるから、この面からもピクセルの使用は版下作成には向かない。一方で、ピクセルで指定しておいたほうが有利な場合もある。解像度の低いデバイスで出力する場合には、整数個のデバイス・ピクセルをまとめて CSS2 のピクセルを表現したほうが美しい。単位をピクセルのまま用いておけば SVG を読み込んだユーザ・エージェントが出力が美しく見えるようにうまく換算してくれる可能性がある。CSS のピクセル定義に若干の出入りが許されているのはこのためである）

そもそも Inkscape のデフォルト単位は本当にピクセルなのか

いきなり変なことを言い出すなら、Inkscape において、そしてそれが準拠している SVG において、ユーザがお絵描きする空間におけるデフォルトの単位はピクセルなんかではない。それは本当は、ユーザが勝手にこしらえた単位であって、SVG ではこれをユーザ・ユニットと呼んでいる。

ユーザ・ユニットで表現されたユーザ空間は、印刷される領域たるビュー・ポートと呼ばれる矩形内に写像される。このとき、初期（initial）の状態では、ユーザ・ユニットはピクセルに等しいと仮定したうえでビュー・ポートに写像されるから、これを簡単に「デフォルトはピクセルである」と言っているわけである。

また、「ユーザユニットはピクセルである」という初期の仮定を、「ユーザユニットはミリメートルである」とか「インチである」とかには変更できない。このことを簡単に、「デフォルト単位を変更することはできない」と言っているのである。

しかし、これはあくまでも初期の仮定であり、実際には SVG が読み込まれた後に起こる複雑な過程によって、ユーザユニットはさまざまに解釈されることになる。典型的には、SVG をより上位の SVG に埋め込んだ場合で、上位の SVG との交渉（ネゴシエーション）が起こり、これが変更される。

ビュー・ボックス

SVG 書類の製作者はユーザ空間をどうビューポートに写像するかを明示的に定義してやることも可能である。ビュー・ボックスと呼ばれる矩形を設定すると、ユーザ空間からビュー・ボックスで切り取られた範囲がビュー・ポートにフィットするように写像される。これにより、デフォルトの写像のやり方を変更することができる。

たとえば、ビューポートの大きさが 210 mm × 297 mm (A4) のとき、ビューボックスの大きさを 210 ユーザユニット × 297 ユーザユニットに指定しておけば、ユーザ空間における 1 ユーザユニットは、ビューポートにおける 1 mm に写像される。

ビューボックスとビューポートの縦横比が異なる場合、前者を後者にフィットさせるやり方がいくつか考えられる。SVG では、preserveAspectRatio と呼ばれる属性を svg エレメントに与えることにより、フィットの仕方をコントロールできることになっている。ただし、Inkscape 0.43 では、preserveAspectRatio 属性はサポートされていないし、この属性を指定しなかった場合の動作も SVG 通りにはなっていない。そのため、現在のところビューポートとビューボックスのそれぞれの縦横比が完全に等しくなるようにしておくのが無難であろう。

もっとも、Web 上で画像を公開するような場合、正確なサイズよりもユーザエージェントの計算量の削減が優先されるだろうから、ビューボックスを使わずに表示できるようにしたほうがいいように思われる。

なぜか、Inkscape の GUI メニューからはビューボックスを定義することができない。「編集」メニューから XML エディタを引っ張り出してきて手書きで加える必要がある。これはあるいは、複雑な画像の場合にビューボックスを作っておくことより生じるユーザエージェントの負担増を嫌っているということなのかもしれない。

余談ながら、ごく一般的な使用法においても、ビューボックスを追加しておくとよい場合がある。ビューボックスを作成しておくと、ＧＵＩメニューから「用紙サイズ」を変更しただけで、自動的に作画内容が用紙にフィットするように拡大されるからだ。こうしたことが SVG ファイルの受け取り手の便宜にかなうこともあるだろう。たとえば、この白地図はＡ４判だが、Inkscape でこれを開き、GUI メニューで用紙サイズをＡ３に変更しただけで、そのままＡ３判の白地図として利用することができる。

「でも、Inkscape には単位を設定するメニューがあるぜ」

変形ツール（黒矢印）選択時には、ツールコントロールバーに選択されたオブジェクトの位置と大きさが表示され、数字を入力することができる。この右側に、ピクセル、ミリメートルなど単位を選べるメニューがある。

このメニューで単位をミリメートルにしたとしても、内部的には相変わらずピクセルが用いられている。そして、保存したファイルをのぞいてみても、単位はピクセルのままである。これは、ユーザインターフェースの気配りというやつで、ユーザに示すときだけ選択された単位に換算した数字を見せているのである。

ついでに言っておくと、この欄に示される寸法は、パスの輪郭をストロークした外縁の大きさであり、x-min と y-min は原点をページ（ビューポート）の左下にして測ったものである（内部的にはビューポートの左上が原点）。

また、Inkscape 0.44 で、Document Properties ダイアログを開くと、Default Units という設定項目があり、mm とか inch とかさまざまな選択肢がある。しかし、これもやはり上記の設定メニューと同様に、ユーザに見せる単位だけお好みの単位に換算（1 ピクセル＝1/90インチで）してくれるだけの話だ。

次のようなケースを考えてみよう。たとえば、Inkscape の Dafault Units を mm に設定し、10 mm の線を作成したとする。これを SVG ファイルに保存し、そのファイルを 1 ピクセルを 2/90 インチに換算する別のユーザエージェントで読み込むと、この線の長さは 20 mm で出力されるはずである。

「ビューポートのサイズをミリメートルにしとけばビューボックスはいらねんじゃない」

ビューポートのサイズをミリメートルで指定しただけで、ビューボックスを作らないでおくと、ユーザ空間における 1 ピクセルが何ミリメートルに当たるかということについては、ユーザエージェント任せになってしまう。Inkscape 以外のユーザエージェントでの読み込みを考慮すると不安。

かりに、ユーザエージェントが SVG に準拠していたとしても、CSS2 では 1 ピクセルの絶対的な大きさは出力デバイスの物理的な条件によっていくらか伸縮してもよいことになっているので、やはり不安が残る。

ビューボックスのかわりに「transform 属性を使うというのはどうよ」

そのうち書くよ。

矢印、というかマーカー

SVG での鏃（やじり）の実現

SVG では、シンボルというエレメントでひながたとなる図形オブジェクトを定義して、use エレメントによってこれを引用（正確には instantiate）することができる。同じ図形を複数回使うような場合、この symbol と use を使って実現すると楽ができる。

さらに、SVG は矢印の頭（鏃：やじり）を実現するために、シンボル機能を特殊化させた手段を用意している。こんな具合だ。

まず、marker というエレメントで、被引用側の図形を定義する。つぎに、path, line, polyline, polygon といった鏃をつけたいオブジェクト（を表現しているエレメント）に、marker-start, marker-end, marker-mid といったプロパティを与え、この値として先に定義したマーカの id を指定する。ここで、marker-start, marker-end, marker-mid の違いは、鏃を付加する場所の違いで、それぞれパス始点、終点、それ以外のポイント（ノード）に対応する。これで、鏃が実現される。（鏃はパスに対してつけられるものであり、サブパス——部分パス——に対してつけることはできない）

Inkscape における鏃（やじり）

Inkscape では、パスを選択したうえで、「フィル／ストローク」ダイアログの「ストローク・スタイル」タブを選ぶと、上述のマーカ機能を利用した鏃を付加する手段が提供される。

Inkscape 0.43, 0.44 日本語版を見る限り、このダイアログボックスはなかなか理解が難しい。

まず、「先端」「中心」「終端」という項目がある。それぞれ、パス始点(Start Markers)、パス中間点(Middle Markers)、パス終点(End Markers)、を意味し、どの場所に鏃（marker）をつけるかを示している。始点（Start）がどうして「先端」と訳されているのかは謎であるが、ともかく誤解を与えやすい。（これは start という英単語が先端という日本語の単語に自動的に訳されるものであり、コンテキストを考えて人間が翻訳した結果ではないらしいんだが）

「先端」「中心」「終端」のそれぞれには選択メニューがあり、Arrow1LStart, Arrow1LEnd ... などと名前のついた鏃（マーカー）が示してある。この名称がまた誤解を与えやすい。

名称をいちいち見ていくことにする。最初の Arrow というのは矢であるからよい。それに続く 1 とか 2 とかいうのは、鏃（やじり）の形状を示していて、2 は 1 よりも太っちょである。次の L とか M とかいうのは、パスのストローク幅に対する鏃（やじり）の相対的なサイズである。最後の Start とか End という部分は、鏃（やじり）の方向を示している。ここで、Start というのは、始点を向いている鏃、End というのは終点を向いている鏃である。これはちょっと直感的にはわからない。

利用例を考える。「ベジエ曲線」ツールで、点Ａ、点Ｂの順にポイントを打ち、線分を描いたとする。点Ａが始点で、点Ｂが終点というわけだ。点Ｂの先っちょに、ＡＢ方向のやじりをつけたいとしたらどうしたらよいだろう。

まず、点Ｂにやじりをつけるのだから、「終端」の項目をいじればよい（「先端」というのを選ぶと点Ａにやじりがついてしまう！）。鏃は終点を向いているものだから、名称の最後が End で終わっている図形（マーカー）を選べばよい。

同じ線分で点Ａに矢羽（矢のうしろについている羽根）のような三角形を描くにはどうするか。点Ａは始点だから「先端」という項目をいじる（なんてわかりにくい！）。そして、矢羽は（鏃同様）終点を向いているものだから、（やはり鏃同様）End で終わっている名前をもつ図形（マーカー）を選択すればよい。

「矢印の先っちょがカラーにならないよ」

矢の棒の部分を箆（の）というそうである。この棒の部分（パス）にストロークペイントを施しても、鏃（やじり）の部分の色が変わらない。たとえば、赤い箆（の）に黒い鏃（やじり）の矢ができてしまう。

原始的なやり方：「パス」カスケードメニューから「ストロークをパスに変換」すると、矢は、箆（の）と鏃（やじり）のふたつのパスからなるひとつのグループに変換される。あとは、鏃をフィルすればよい。

エレガント（？）なやり方：XML エディタで、path エレメントの marker-end プロパティの値を読み、それが指す marker エレメントを探す（marker エレメントは、defs エレメントの下位に見つかるだろう。）当該 marker エレメントの fill プロパティの値は色を示しているので、これをいじる。ただし、Inkscape 0.44 Linux 版で試したところ、この変更は即座には画面に反映されない。一度保存して、再び読み込んでみると（「ファイルに復帰」）はじめて反映された。もっとも、これでは、以後同じ鏃（マーカ）を使うと、みなこの色が変わったものになってしまう。それが嫌ならば、該当する marker エレメントをコピーしてから変更し、その marker の id を鏃をつける path の marker-end プロパティに記してやればよい。

「オリジナルの鏃（やじり）っていうかマーカーを作りたいぜ」

私の環境では、/usr/share/inkscape/tutorials/making_markers.svg というチュートリアルがインストールされていた。それによると、marker エレメントを書いて（XML エディタを使い既成の marker をコピーして編集、svg で保存してエディタで読むと楽のようだ）、marker.svg というファイル（私のとこでは /usr/share/inkscape/markers/markers.svg にあった）に追加しておくと、のちのち使いまわしができるとのこと。暇がないので試してないけど。ところで、このファイルをホームディレクトリ以下に置くことはできるのかなあ？

パスを塗りつぶす

Inkscape で複雑な形のパスを思い通りに塗りつぶすためには、SVG がパスの「内側」と「外側」をどう定義しているのかを見ておく必要がある（よね？）。

用語

SVG では、ポイントをつぎつぎにセグメントでつないで作ったひと続きの線をサブパスといい、パスは一つ以上のサブパスの集合であるとしている。参考のため Gimp のマニュアルでの用語と対比しておくのだ。

閉じたサブパスと開いたサブパス

SVG では端点が閉じていないサブパスは、フィルを行う（塗る）ときには、端点が閉じていると仮定される。Inkscape で V 字型のサブパスを塗りつぶすと、逆三角になるのは、これによるもの。

内側と外側

SVG において、パスはその内側を塗りつぶすことができる。外側を塗りつぶすということはできない。これは、お絵描きをする面は無限の広がりを持っていて、プリントアウトされるのはたまたまその一部であるという SVG の考え方に対応しているのだろう。

パスの内側を塗りつぶすときのやっかいな問題は、パスが自分自身を横切っていたり（ＮＴＴのマーク）、内部にサブパスを含んでいたり（ドーナツ型）する場合に起こる。「内側を塗る」のであるから、これはキャンバス上の任意の点を当該パスの「内側」と考えるか「外側」と考えるかという問題だと言い換えることができる。

内側・外側を決めるのは、パスを構成するセグメントの方向（自身と交じわらない閉じたサブパスの場合、これは時計まわりとか反時計まわりとかいう問題である）と、fill-rule というプロパティが考慮される。

SVG は、path エレメントと polyline エレメントは fill-rule プロパティを持つことができると定めている。fill-rule プロパティは nonzero もしくは evenodd という値をとる。これらの値の示す意味は以下の如し。

キャンバス（無限の広がりを持つのだ）上の任意の点から、無限の彼方に向けて半直線を引くことを想像する。SVG はこれを ray と表現している（たんに数学用語で半直線のことを ray というわけなのだが、光線だから方向があると考えると趣き深いか）。

ray は、はじめ 0 というカウントを持っている。

ray の進行方向に向かって右手を右側、左手を左側と呼ぶことにする。

問題となるパスを構成するセグメントが（これは方向を持っているので） ray の左側から右側に横切る場合、カウントに 1 が加算され、右側から左側に横切る場合カウントから 1 が引かれる。

こうして ray が無限の彼方に到達したときのカウントによって、ray の出発点が当該パスの内側であるか外側であるかが定まる。

fill-rule プロパティが nonzero の場合、カウントが 0 なら外側、そうでなければ内側と定義される。

fill-rule プロパティが evenodd の場合、カウントが奇数なら内側、偶数なら外側と定義される。

SVG では、fill-rule の初期値は nonzero である。

いずれの方向に向けて RAY を照射するかによって、その点が当該パスの「内側」であるか「外側」であるかの決定に違いは起こらない。前述のごとく、サブパスは必ず閉じていると仮定されているからである。

次の例は、いちばん小さい円の内部が「内側」か「外側」かを調べるために、同心円の中心から RAY を照射してカウントを調べている様子の図。いちばん大きい円の円周まで RAY が達してはじめて、いちばん小さい円の内部が「内側」か「外側」かが定まる。

なお、1 を足しても引いてもそれが偶奇に与える影響は同じなので、fill-rule が evenodd であればはパスの方向はまったく問題にならぬということになる。

蛇足ながら、SVG で塗りつぶしが定義されているのは、あくまでも一つのパスに対してであり、複数のパスに対してではない。上に掲げた同心円の例では、円ひとつひとつをサブパスとして、これらを一つのパスに結合しある。

Inkscape での実装

パスの方向は、もっとも単純な例では、「ベジエ曲線／直線ツール」でポイントを打つ順番によって決まる。最後に打ったポイントを終端とするようにそのサブパスの方向が決まる。パスの方向を視覚的に確認したいと思うならば、ストロークスタイルで矢印を選択してやればよい。

Inkscape 0.44 からは、カスケードメニューのパスを引っ張ると「逆転」というのがあり、これを使うと方向を反転させることができる。

「円／弧」ツールで円や楕円などを作成すると、パスの方向は時計まわりになる。

evenodd か nonzero かを選択するためには、「フィル／ストローク」ツールの「フィル」タブを選択したときに右上に出てくるハートじるしのようなもの二種のいずれかを選ぶ。左側のが evenodd で、右側のが nonzero。あるいは、XML エディタを起動して手動で fill-rule プロパティを修正することもできる。

Inkscape では、fill-rule プロパティがないパスエレメントを読み込むと nonzero と解釈されるが、これは SVG 通り。

文字

日本語入力

私のところの Linux 版 0.43 は SCIM 1.4.4 でうまく入力できている。

文字コード

SVG1.1 では、XML1.0 の文字を使うということになっている。（http://www.w3.org/TR/SVG11/text.html）。XML の規定（http://www.w3.org/TR/REC-xml/）を見ると、すべての XML プロセッサは、UTF-8 と UTF-16 を理解できなくてはならぬ、とある。そして、Inkscape のデフォルトが UTF-8 であり、何も考えずに Inkscape で新規書類をつくり、日本語を入力すると UTF-8 を用いて保存される。

こうした SVG ファイルを、UNICODE をサポートしていないテキスト・エディタで開いて、変更を加えて保存したりすると、悲惨なことになるかもしれない。（事実、そうなったことあり）。

とはいっても、SVG は必ずしも UTF-8 を使わなければならぬというわけではない。XML のほうでは、"ISO-2022-JP", "Shift_JIS", and "EUC-JP" のことも書いてあり、じじつ SVG ファイルの先頭に

<?xml version="1.0" encoding="Shift_JIS"?>

などと書いておいたら、テキストエレメントの中身がシフト JIS で書かれても Inkscape （少なくとも私の使っている Linux 版 Inkscape 0.44）はちゃんと読み込んでくれた。

しかーし！　そのファイルを Inkscape の GUI を使って変更後再度保存したら、しれっと UTF-8 に戻っていました。じつはデフォルトにするコーディングシステムをどこかで設定できるのかもしれないけれど、私にはわからぬ。やっぱり Inkscape では UTF-8 が無難か。

文字間／カーニングを調節

Inkscape での使い方だけメモしとこう。

テキストツールのポインタを段落の中に置いて、「Alt + >」で段落ごと文字間を広く、「Alt + <」で段落ごと文字間を狭くできる。フレームに挿入したテキストにも適用できる。

テキストツールのポインタを文字間に置いて、「Alt + →」で二文字間のカーニングを広く、「Alt + ←」で二文字間のカーニングを狭くできる。ただし、これはフレームに挿入されたテキストには通用しない。

同様に、「Alt + ↑」でポインタの置いてある後ろ以後の文字のベースラインを上に、「Alt + ↓」で下に動かすことができる。これも、フレームに挿入されたテキストには通用しない。

なぜか知らぬが、これらはこのショートカットを使って〈のみ〉行うことができ、カスケードメニューにはこれに対応したものが見つからない。

行間の設定

「テキスト／フォント　ダイアログ」で「線の間隔」というのを変えてやる。「線の間隔」というのは、「行（lines）の間隔」の誤訳であらう。

文字の縦書きできる？

できはする、が、ちゃんと SVG の規定が実装されているわけではなくて、貧弱。将来期待。

「エディタから文字をコピペできない」

ひどく環境依存してそうな問題なので、一般的には答えられそうもない。めんどくさいから自分のとこの話だけしとこ。「テキスト／フォント」ダイアログの「テキスト」タブを開くと、ここにならコピペできた。

テキストの流し込み

SVG 非準拠

Inkscape は flowed text の機能を持ってはいる。flowed text というのは、「流し込まれたテキスト」。

SVG 1.1 には flowed text について定めていない。Inkscape の flowed text は SVG 1.2 の古い版の草稿をもとにしているので、今後 SVG 1.2 が確定しても、それに沿っている可能性は低い。（http://wiki.inkscape.org/wiki/index.php/FAQ#What_about_flowed_text.3F 参照）

テキスト流し込みは、Inkscape が SVG に準拠していない部分である。もちろん、他のユーザ・エージェントがきちんとこれを解釈する可能性は低い。

SVG 1.2 のテキスト流し込み

いちおう現段階の SVG 1.2 の draft くらいは見てみよう。http://www.w3.org/TR/2004/WD-SVG12-20041027/flow.html

Inkscape でのテキスト流し込み

矩形オブジェクトや円形オブジェクトなどと、テキストオブジェクトを同時に選択しておき、カスケードメニューの「テキストをフレームに挿入」を選べば、これが実現できる。

パスオブジェクトへの流し込みも可能である。パスが閉じていなければ、始点と終点が接続されていると仮定される。

面白くて有用なのは、二つ以上の流し込み先オブジェクトとテキストオブジェクトを同時に選択して「テキストをフレームに挿入」すると、一つ目の流し込み先オブジェクト（など）からあふれたテキストが、次の流し込み先のオブジェクトに流れ込むということである。このとき、後から選択した流し込み先オブジェクトに対して先にテキストが流し込まれる。これは、SVG 的には flowRegion オブジェクトの子要素に、描画オブジェクトを複数置けることに対応している。

こうして流し込んだテキストに対しては、「テキスト／フォント」ダイアログから右寄せ、左寄せ、センタリングの指定が可能。XML エディタを使って、ジャスティファイも可能（flowRoot オブジェクトの style プロパティで text-align=justify とするのが一手）である。なお、このジャスティファイはスペースの間隔を調整して行うものであり、日本語では期待通りにいかない（日本語では単語の境目にスペースを入れる習慣がないからか）。これは、flowRoot オブジェクトや、flowPara オブジェクトに style 属性を設定し、属性値で text-align を left, right, justify などに設定することに対応する。

http://wiki.inkscape.org/wiki/index.php/FAQ#What_about_flowed_text.3F では、Inkscape の flowing text を用いた SVG ファイルを他のエージェントで読み込ませるならば、あらかじめ「テキストに変換」を用いて flowing text を使わないように変換しておくよう勧めている。（私はこれを試してみたが、うまくいかない場合があった。なぜだかまだ調べていない）。

いちおう Inkscape で作成した SVG のコードを見てみる。

flowRoot オブジェクトの中に flowRegion オブジェクトと flowPara オブジェクトがある。flowRegion オブジェクトの中に rect などの描画されるオブジェクトがあればよいらしい。典型的な階層関係は、たとえば

flowRoot
  flowRegion
    rect
    circle
    etc.
    ......
  flowPara

てな具合だ。flowPara オブジェクトは流し込まれる文字列を保持し、flowRegion の子要素の rect や circle ... は、文字列が流し込まれるオブジェクトである。

整列・吸着

ノードやオブジェクトを並べたりそろえたりするには、整列を使うやり方と、吸着を使うやり方がある。

オブジェクトの整列

ノードの整列

同じパスに属するノードならば、オブジェクトと同じように整列させることができる。「オブジェクト」→「整列／配置」では、選択されているツールが「ノード・ツール」である場合、ノード整列・配列用のダイアログボックスが出てくる（他のツールが選択されていると、オブジェクト整列・配置用のものが出てくる）。

一方、異なるパスに属するノードは整列させることができない。それらを同時に選択状態にすることすらできない。そうした場合、「パス」カスケード・メニューから「連結」を行う。このとき、矩形ツールや円・楕円ツールで作成したオブジェクトを「連結」すると、失われるプロパティが出てくるので注意が必要。なお、同じパスに属していればよいのであって、必ずしも同じサブパスに属している必要はない。

ノードが同じパスに属する場合、整列を用いてそれらを重ねることもできる。ただし、Inkscape 0.44 以後なら、こうした作業は Object Snapping を用いたほうが楽。

なお、同一パスに属する a, b のノードを重ねた上で統合する場合、a, b 間を連結ツール で連結した後、a または b で不要なほうのノードを削除するほうが手数が少ない。

もちろん、こうした作業の結果「パスを閉じ」たいだけならば、たんにパス・ツールを使ってやればよい。こんなふうに。

グリッド

グリッドの設定はアプリケーションに対する設定ではなく、各ドキュメントに対する設定による。

グリッドの設定のためのメニューは、Inkscape 0.44 では、「ファイル」→「Document Properties」→「Grid/Guides」。Inkscape 0.43 では、カスケードメニューの「ファイル」から「ドキュメントの設定」で出てきたパネルから「ガイド」タブを選択。

思うように吸着しないならば Inkscape 0.44では上記メニューの Grid Snapping の項目を確認。bounding box をグリッドに合わせるか、ノードをグリッドに合わせるかを選択できる（Bounding Box についてはObject Snapping参照）。どのくらいの距離からスナップが発動するかは、Snap sensitivity で設定。

なお、吸着の設定ををオンにしているのに吸着せぬという場合は、たいがいグリッドの間隔が細かすぎるのである。あまりに細かいグリッドは表示が省略される。しかも、デフォルトのグリッド間隔がやたらと細かいという場合がある。いや、ちゃんとグリッドは表示されているぞという向きは、表示されているのが、グリッド何本かに一本引かれるメージャガイドラインだけなのではないかと疑ってみること。

Inkscape 0.43 では、

「隣り合うボックスをグリッドに合わせる」をチェックすると、輪郭線（当然太さをい持っている）の外縁または内縁がグリッドに吸着する。

「ノードをグリッドに合わせる」をチェックすると、パスのノード（これは面積を持たない点である）がグリッドに吸着する。

「隣り合う……」と「ノード……」の両方をチェックすると、輪郭線の内外とパスのノードのいずれかに吸着する。

ガイド

ガイドは、垂直あるいは水平の線で、グリッドと同じように働く。グリッドと異なり、自由な場所に置くことができる。描画面上と左に表示されるルーラーの上から、ガイドを引きたい場所までマウスをドラッグすると、ガイドを作成できる。SVG にはまったく定義のない独自定義の（正確にいえば sodipodi の定義による）オブジェクトである。

ガイドの設定はアプリケーションのに対して行うものではなく、各ドキュメントに対して行う。具体的には Inkscape 0.44 では、「ファイル」→「Document Properties」→「Snap」から「Guide Snapping」の項目。Inkscape 0.43では、カスケードメニューの「ファイル」から「ドキュメントの設定」。出てきたウィンドウから「ガイド」タブを選択。

ガイドは水平か垂直かのどちらかだけである。Adobe Illustrator のように、任意のパスをガイドに変えることはできない（Inkscape 0.44 では不完全ながら Object Snapping の機能はあるが）。Quark Xpress のガイドによく似ている。

ガイドを間違って移動させてしまわないようにロックする方法を私は知らない。

Object Snapping

Inkscape が 0.43 から 0.44 になって、一番便利になったのはこの機能が追加されたことかもしれない。

Inkscape 0.44 の「ファイル」→「Document Properties」→「Snap」に Object Snapping なる項目あり。Grid でも、Guide でもなく、なんでもない object に吸着させるための機能。

□ Snap bounding boxes to objects （ボックスを何かに合わせる）
□ Snap nodes to objects          （ノードを何かに合わせる）

のふたつの項目は「何を」合わせるか

□ Snap to object paths            （何かをボックスに合わせる）
□ Snap to object nodes            （何かをノードに合わせる）

のふたつの項目は「何に」合わせるか

わかりにくいのは、スナップの設定で Bounding Box と呼ばれるものは、本来の矩形をした Bounding Box ではなくて、その矩形を定義する右上と左下の 2 点を指しているということである。

以下、「何を」が 2 通り、「何に」が 2 通りで、2 x 2 = 4 通りの Object Snapping について図解してみむ。

ノードを円や矩形をつくる辺に吸着させることは可能だが、一般のパスに吸着させることはできないようだ。また、二本の線分（たとえそれが一つのパスに属していようと）の交点に吸着させることはできない。また、ノードをパスに吸着させながら移動させるときに、そのノード自身が含まれるパスにも吸着してしまう。

頓知

素直に CAD を使ったほうがよかったりするかも。Metapost や Asymptote の類いがいい場合もあるよね。

「3 つの円からなるベン図を作成したい」

べつに Inkscape の話題じゃないような気もするけど。任意のパスからガイドを作成する機能がない Inkscape においては、ちょっとした頓知が必要かなあ。解答案

「点を打つには？」

SVG には点というオブジェクトは存在しない。Inkscape においても然り（Illustrator には孤立点というものがありうる）。さて、どうする。

小さな円をつくるというのが正解の場合もある。しかし、位置合わせのためのノードを作りたいのだとすると、円は複数のノードを持つので不可。その場合、端点を丸くストローク描画した線分の、両端をぴったり重ね合わせて点にするのが正解。

「任意の線分を二等分せよ。また、三等分せよ」

線分の端点の間にノードを追加すると、それはちょうど中間に置かれる。この点で線分を切断すれば二等分できる。

三等分の場合、まずどこでもいいから二つのノードを線分上に作成し、その上でノードの整列を利用すればよい。

「二等辺三角形をつくりたい」

グラフ

グラフといっても、木の仲間のグラフではなくて、資料によく使う例のアレ。そんな高級（？）な機能は Inkscape にはついていない。拡張スクリプトにより対応させるつもりなのかもしれない。

gnuplot が SVG で出力できますけん。切り貼りしてはいかがです？　gnuplot で図形だけ作成し、inkscape で図形を塗ったり、タイトルやラベルや説明を入れると楽ちんかも。

gnuplot> set terminal svg
gnuplot> set output "test.svg"
gnuplot> plot(x**2)

とか。

統計ソフトの R （http://cran.r-project.org/）にも svg 出力用のパッケージがある。 http://cran.md.tsukuba.ac.jp/src/contrib/Descriptions/RSvgDevice.html （http://www.darkridge.com/~jake/RSvg/）。まだ試していないが、http://www.darkridge.com/~jake/RSvg/ には美しい出力例があるよ。

プレゼンテーション用のグラフを描くには、スプレッド・シートとの連携が便利であるが、これはたとえば gnumeric が SVG 出力をサポートしている（最近の gnumeric はずいぶん安定して、使いやすいものになっていたので驚いた）。gnumeric でグラフ・オブジェクトを選択して画像を保存せむとするときに SVG を選んでやれば、美しい形で保存できる。

って、Inkscape の話題じゃないですやん。

おまけ：円グラフ・帯グラフを描くための拡張スクリプトはこちら。

Tips

「うまくパスが閉じられないス」

いったん開放されたパスを作成した後、パス・ツールを使ってこのパスを閉じようとすると、接続点に余分なノードができてしまうことがある。パスの方向を考えれば、このようなことは起こらない。

「不要なハンドルを削除したいぞ」

「ウェブページへのリンクとか SVG 画像に貼れませんのん？」

SVG 1.1 では、たんに、描画されるエレメントを a エレメントの中に入れるだけで、こうしたリンクが実現されるとある (http://www.w3.org/TR/SVG11/linking.html#AElement)。たとえば、

  <a xlink:href="http://www.pref.hokkaido.lg.jp/">
  <path id="HOKKAIDO"
        fill="#FF9999" stroke="black" stroke-width="1"
        onmouseover="this.setAttribute('fill','#AAAAFF')"
        onmouseout="this.setAttribute('fill', '#FF9999')"
        d="M 3710.00,548.00
           C 3712.67,557.33 3712.67,572.00 3720.00,580.67
             （中略）
             3046.00,185.00 3056.00,181.50 3056.00,181.50 Z" />
  </a>

という例では、path エレメントに対してリンクが作成される。Inkscape で読み込んでも、このリンクは動作しないが、ユーザエージェントによってはきちんと動いてくれる。たとえば、Firefox 2.0.0.1 では、この地図の各県をクリックすると各県庁のページにジャンプする。（面倒くさいので関東以北しか作成してないけど）

上の例では、マウスをのせると県の色が変わるが、そのへんは http://www.w3.org/TR/SVG11/interact.html を参照。

「外部にある SVG オブジェクトをダイナミックに引用できませんのん？」

use エレメントの href プロパティなんぞを使って外部ファイルにあるオブジェクトを指定しても、無視される。この点では CSS の href が使えるという SVG の規定は実装されていないのじゃ。

(1) 一方、image エレメントの href プロパティに SVG ファイルを指定するとレンダリングされたイメージをはりつけることができる。はりつけてから、もとのファイルを変更し、「ファイルに復帰」を実行すると、変更が反映されるので、これが動的に貼り付けられているということがわかる。

ただし「ファイル」メニューから SVG ファイルを「インポート」すると、（png ファイルをインポートしたときと違って）SVG オブジェクトをコピー＆ペーストしたのと同じ結果になってしまう。

  <svg:image
     id="my_image"
     x="256"
     y="256"
     height="256"
     width="256"
     xlink:href="123.svg" />

などのように XML エディタでやればよい。

href の値は、たんなるパスである必要がある。

(2) pattern エレメントの href プロパティの値として、外部にある svg ファイルを用いることができる。

  <defs
     id="my_defs">
    <pattern
       id="my_pattern"
       height="256"
       width="256"
       patternUnits="userSpaceOnUse"
       patternTransform="translate(0,0)">
      <image
         id="my_image"
         height="256"
         width="256"
         xlink:href="123.svg" />
    </pattern>
  </defs>

とか。href の値は、たんなるパスである必要がある。

「貼りつけた png 画像が消えちまったぜ」

png ファイルをインポートすると、img プロパティの href 属性にパスを与えて別ファイルを引用するという形でこれが実現する。

    <image
       y="100"
       x="100"
       id="image1234"
       height="128"
       width="128"
       sodipodi:absref="/your/directory/your_picture.png"
       xlink:href="/your/directory/your_picture.png"
/>>

のような形で引用される（ビルドによって違うかも）。xlink:href の値が絶対パスで書かれるので、引用した png 画像の場所が変わると読み込めなくなってしまう。友だちにこんな SVG 書類をあげたりしたら、当然彼の Inkscape からはその png が見えない（firefox でも見えない）。SVG ファイルと同じディレクトリに png を置いておいてもだ。

xlink:href の値には相対パスを与えることができるので、従者たる png 画像を主人たる SVG 画像と同じディレクトリに放り込んでおいて、xlink:href の値にただファイル名だけを書いておき、そのディレクトリごと友だちにあげれば、うまく読み込める。xlink:href の値は、XML エディタで編集してもいいが、画像オブジェクトを選択して左クリック（Windows ではどうかな）で「イメージのプロパティ」を表示し、URL のところを編集すると簡単。

SVG では xlink:href の値には URL を与えることができる。しかし、Inkscape でそれを表示できない。ようするに Inkscape は http クライアントになっていないんだ。firefox の新しいやつとかで読むと、画像が表示できたよ。

余談ながら、友人から送られてきた SVG 画像に、君が秘密にしている写真がはりつけてあったとしても、あわててはいけない。彼は君のパソコンのどこにその画像があるかということだけを知っていて、それを SVG にはりつけただけのことかもしれない。そういうわけで、SVG は jpeg や ping より緊張感をもって扱わなければならないんだ。もう一つ言っておくと、Inkscape のデフォルトで xlink:href に絶対パスが書き込まれるということは、そのファイルを友人にあげると、彼はあなたのパソコンのディレクトリ構成の少なくとも一部を知ることになるよね。もっとも、これは非常に多くのアプリケーションにある罠なんだが。

「png データを SVG に直接埋め込めないかしら」

うちの Inkscape には、拡張スクリプトで Embed All Images （Effects → 画像）ってのがついてきてる。これを実行すると、

    <image
       height="136"
       width="136"
       id="image1928"
       xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAIgAAACICAYAAAA8uqNSAAAABHNCSVQICAgIfAhkiAAAAAlwSFlz
AAAN1wAADdcBQiibeAAAABl0RVh0U29mdHdhcmUAd3d3Lmlua3NjYXBlLm9yZ5vuPBoAAB00SURB
（中略）
i9Xu7/8Hkv5/AB6zObkAAAAASUVORK5CYII=
"
       y="370.07657"
       x="277.71426" />

などとなって、xlink:href の値がデータそのもととなり、かくしてイメージデータが SVG に埋め込まれる。また、Extract One Image で、選択中のイメージから png ファイルを作成することもできる。

これがどう規格されているか、このスクリプトが何をやているかについては、そのうち調べてみます。でわ。

パスの外側（または内側）に輪郭線を描きたいのだが？

できない。

ノードって同時にいくつも選択できないの？

シフトを押しながらノードをノード・ツールでクリックしていくか、オブジェクトが選択された状態で「パス／ノード」ツールを使って矩形選択してやればよい。

重なったふたつのノードを選択すると、まるで何も選択していないかのように見えるので注意。

それでも同時に選択できないノードたちは、別々のパスに属している。「パス」→「連結」を使い、一つのパスのサブパスとして双方を取り込んでやれば選択できるようになる。ただし、「連結」を使うと、円や四角形といった特別な性質を持っていた図形が一般的なパスに置き変わるので注意を要する。

オブジェクトをロックしたら選択できなくなったぞ

オブジェクトを選択して右クリックすると、「ロック」チェックボックスがあるので、これにチェックを入れると、そのオブジェクトはいかなる操作も受けつけなくなる。しかし、そのオブジェクトは選択さえできなくなるので、ロックを解除するために右クリックを使うこともできない。

方法 1。「Inkscape の設定」から「選択」タブを押し、「ロックされたオブジェクトを選択しない」のチェックを外す。

方法 2。「編集」メニューから「XML エディタ」を選択してウィンドウを開き、sodipodi:insensitive 属性の値を true から false にすることである。

見えないオブジェクトは選択できない？

オブジェクトが見えないゆえに（フィルなし、輪郭なしなどで）選択できない場合は、そのオブジェクトを含むように矩形選択してやるとよい。あるいはカスケードメニューの「すべて選択」を行うと、選択される。奥の手としては「XML エディタ」が使える。

Adobe Illustrator の「アートワーク」表示モードみたいなのはないのか？

Adobe Illustrator には、プレビューとアートワークの二つの表示方法があり、出来上がり画像表現を、後者は太さや塗りのない表現を得る。後者を使えば太さゼロの線分も見ることができる。

Inkscape でも、0.44 以後これに似た機能が加わった。

「変形」（トランスフォーム）を使わないでオブジェクトを移動・変形させたい

「Inkscape の設定」から「変形」タブ。「transform属性を使わない」をチェック。

拡大・縮小については、私の環境では Inkscape を再起動する必要があった。

「ベジエ曲線／直線」「長方形や正方形」には効いたが、グループ化されたものや、「円／弧」、「星型／ポリゴン」には効かなかった。

オブジェクトを拡大すると、輪郭線まで太くなっちまうんだが？

「Inkscape の設定」から「変形」タブ。「線の幅を拡大／縮小」のチェックを外す。（私の環境では Inkscape を再起動する必要があった。）

クローンには、これが効かない。

オブジェクトを拡大するとき、オブジェクトの中心を基準にしたいぞ

シフトキーを押しながらマウスを使って拡大してやる。

円の中心をグリッドやガイドに合わせたい

グリッドの設定で「ノードをグリッドに合わせる」にすると、中心がグリッドに吸着。円を移動するときに中心が表示されないのが残念。

円／楕円でも、クローンには、これが効かない。

円／楕円以外のオブジェクトには、これが効かない。

裏技的には、目的の点を中心に円なり四角形なりダミーのオブジェクトを作成して「オブジェクト」→「整列／配置」を使って、ダミーを基準に縦横両方向にセンタリングを行う。これは、さまざまなオブジェクトについて可能。

円と四角形の中心をそろえたい

「オブジェクト」→「整列／配置」を使って、縦横両方向にセンタリングを行う。

Adobe Illustrator のブレンドのような機能はあるのか？

そんな洒落たものはない。

グループ化された内側にあるオブジェクトを選択したい

選択したオブジェクトがパスであるなら、単純な矢印で表現されている選択ツールでなく「パス（／ノード）」ツールでそのオブジェクトの輪郭をクリックしてやればよい。

コネクタって何？

二つのオブジェクトをつなぐ線である。オブジェクトを移動させると、コネクタもそれを追って移動する。コネクタは必ず接続されるオブジェクトの中心を通るように引かれるので、dia のようなダイアグラムエディタで作業したほうが意に添うこともあるかも。（ちなみに dia は SVG 出力できます）。

コネクタは、指定されたオブジェクトを自動的に避けて通るようにもできる。コネクタツールで始点と終点を指定して作成。コネクタをオブジェクトを避けるかどうかは、オブジェクトの属性らしい。

避けさせるには以下のようにする。まず避けたいオブジェクトを選択しておき、コネクタツールを選び二つのツールバーボタンを表示させる。そのうえで「避けている」アイコンをクリックすると、以後そのオブジェクトはコネクタに避けられるようになる。

○角形を作りたい

ポリゴンツール（星型のボタン）を選択し、ツールバーの「角：」のところに、数字を入れてやる。

たとえば、ツールバーのチェックボックスでポリゴンを選択すると、単純な五角形ができる。チェックを外すと、星型を作るためのコントロールポイントができる。オブジェクトを選択した状態で、チェックボックスをチェックしたり外したりすると、この二つの状態を相互に行き来できる。

「背景色を設定したいんじゃが」

SVG には背景色という概念がない。背景色はユーザエージェントに任されている。

一方、Inkscape の Document Properties ダイアログ・ボックスには、General のセクションに Background という項目があり、背景色とその不透明度を設定できるようになっている。

この「背景色」は、SVG の規格にはない情報を Inkscape が書き加えているのである。これを Inkscape SVG で保存したものを見ると、たとえば次のように保存されていることがわかる。

  <sodipodi:namedview
     （中略）
     inkscape:pageopacity="0.7254902"
     （中略）
     bordercolor="#666666"
     （中略）
   />

このエレメントは SVG 外であるから、他のユーザエージェントで読み込んだ場合には、ほとんどの場合無視される。また、Inkscape でも Plain SVG で保存すると、この背景色情報はファイルに書き込まない。

なお、この「背景」設定は png 形式にエクスポートするときの背景にも使われるので、賢く活用すれば便利なもンです。また、この色を設定しておくと Inkscape での作業中、フィルが「なし」か「白」かが見た目で区別できるようになるので便利なこともある。

「オブジェクトがコピペできないよ」

コピー対象のオブジェクトが、クローンだと駄目だよ。クローンを解除してみよう。

「クローンが解除できないよ」

グループを解除してみるといいかも。

「別のファイルを開いたウィンドウからコピペできないよ」

私の使っている Linux 版の話をしませう。すまん。ウのつくＯＳのことはわからん。

同じプロセスで二つのファイルを開いても、別のプロセスで二つのファイルを開いても、見かけは変わらんのですよ。たんに、二つのウィンドウがあるのですから。でも、別プロセスのウィンドウからは、オブジェクトのコピペはできませぬ。ちなみに、同じプロセスで開いた複数のウィンドウは、「表示」カスケードメニューから「前のウィンドウ」「次のウィンドウ」でウィンドウを切り替えられます。

二つ目のファイルを、コンソールから新たな Inkscape を起動して開くのではなく、すでに立ち上がっている Inkscape の「ファイル」→「開く」を使って開くようにすれば、コピペできるってこと。

「別の SVG ファイルをインポートしたら色が変！　コピペしてもやっぱり変！」

こんなことも考えられるかも。たとえばグラデーションをオブジェクトに適用しているとしませう。グラデーションエレメントには id がある。インポートされるオブジェクトにもともと適用されていたグラデーションの id とちょうど同じ名前の id を、インポートした側でもグラデーションの id として使っていた場合、後者のグラデーションががインポートされたオブジェクトにも適用されてしまうのだ。

今のところ、私はこの解決方法を知らんです。グラデーションエレメントもオブジェクトといっしょにインポートして、id が衝突したときに新たな id を割り振るようなことができるとよいのじゃが。

とりあえず、xslt とか、もっと原始的には sed なんかを使って、二つのファイルの間で id が重ならないように id を変更してしまえばよかろうかと思う（id の前にファイル名をくっつけて新しい id にするとか）。