翻訳開始日:2010 年 9 月 23 日
翻訳更新日:表紙ページ冒頭に記載
訳者:連絡先
これは仕様書であり,一般の文章ではないので、内容を正確に伝えることは言うまでもないですが、解り易くかつ読み易くすることを基本方針としています。 仕様書の性格上,正確さや厳密さが要求されるので、曖昧さを排除するために句読点や言い回しなど多少くどくなっていますが、正確さやニュアンスを損なわない形でなるべく簡潔かつ平易な表現にしていくつもりです。 翻訳は完了していますが、所々変更/修正されることがあります。
当訳に対するご指摘 — ここはこう解釈すべき,ここが間違っている等々 — あるいはご意見、ご感想などを歓迎します。 この仕様は多数の他の仕様( CSS 他)に立脚している所があり、その全てを訳者が把握できているわけではありません。また、訳者の英語力も万全とはとても言えないので,意味論を把握しきれていない部分があります。 そのような部分にはできる限り注釈を付けていますが、それらについての正しい解釈の仕方/ヒントなどを訳者までご一報下されば助かります。
この日本語訳には原文によるものに加えて、以下のスタイル付けとマーク付けが施されています:
スタイルシートの末尾に当訳固有のスタイルを追加しています。
(翻訳部分のマークアップには class="T"
がタグに与えられ、原文には <span lang="en">
のマークアップが施されています — span は HTML のインライン要素ですが display:block のスタイル付けも施されています)。
当訳のすべてのファイルの文字符号化法は UTF-8, 改行コードは LF に設定してあります(例示用の SVG ファイルなど、翻訳対象でないファイルは,原文そのままの状態です)。
原文の文書形式は XHTML ですが、当訳では HTML5 に適合するように,かつ HTML4 との互換性を保つように、多少マークアップを変更しています( HTML5 の新機能は利用されていません)。
終了タグを必ず付加/空タグは <XXX />
のように記述する点では XML との互換性についても一応考慮されています(しかし XHTML ではありません)。
HTML の検証には
Total Validator
を利用しています(検証オプションは HTML5 )。
原文の用語定義で説明されていない用語も含め、この文書の文脈で解釈すべき語/頻出する語/基礎的な語の一部の対訳と,その簡単な説明/訳語の選択意図を以下に挙げます。 一部の用語に対する対訳は変更されることがあります。
原文 | 対訳 | 頻出する章 | 説明 |
---|---|---|---|
accessibility | アクセシビリティ | 身体的不利を持つ人にも利用し易くするといった文脈で特に用いられる。 「アクセス性」という訳でも良さそうに見えるが、今述べた含意が薄れるためか,あまり使われていないようだ。 「アクセス容易性」という対訳もある。 こちらの方がわかり易い/言い易いと思う。 | |
active end | 停止 | アニメーション | アニメーションの活動終了 |
additive | 加法的 | アニメーション | SMIL 仕様にて定義される。 一つの対象が,同時に複数のアニメーションの対象にされているとき、それらの効果が合算されて表示に反映されることを意味する。 例えば、対象をそれぞれ 垂直/水平 方向に動かす2つのアニメーションがある場合、加法的アニメーションの下では,対象は斜めに動くことになる。 (「加算的」という訳語も見られるが、「加算が可能」という観点からは「加法的」の方が適切に思えたので「加法的」を採用。) |
advance | アドバンス | テキスト, フォント | 一般訳は「前進/進捗」。 テキスト描画の際、1個のグリフを描画後に次のグリフの描画に移る前に行内進行方向に描画位置がずらされる量を表す。 文字間隔の調整(カーニングなど)を無視すればグリフが描画されるときの文字幅と同義になる。 |
alpha | アルファ | RGBA 画像の個々の画素の不透明度を表す, A 成分を意味する。 | |
ancestor | 先祖 | 要素Aが要素Bの「先祖」であるとは、XML 文書木の木構造においてAがBの根元側に位置する(AがBを直接的/間接的に含む)ことを意味する。 | |
angle | 角度 | 角の大きさを表すが、単位に度( deg )が指定されていることを含意するわけではないことに注意。 | |
animation, animate, animatable | アニメーション, アニメートする, アニメート可能 | アニメーション | 「動画」と訳すことも考えられるが、 SMIL アニメーションの本来の定義は時経過に伴う属性/プロパティ値の変化という抽象的なものであり,メディアとしての概念を含む「動画」は相応しくない(動画はむしろ SVG Tiny 1.2 で新たに導入された video 要素の対訳に相応しい)。 "animation value" はアニメーション値。 これは SMIL 仕様の "presentation value" (現在表示中の値)と同義である。 |
anti-aliasing | アンチ エイリアス | 低解像度の表示装置に出力されたとき、文字や図形の輪郭が粗く見えるのを緩和するために境界部分に中間色を補間して,なめらかに見せる技法。 訳語としては「アンチエイリアシング」より「アンチエイリアス」の方が一般的のようだ。 | |
aspect ratio | 縦横比 | 座標系, 変換, 単位 | 「アスペクト比」という対訳も一般的だが、より平易な「縦横比」を採用。 (厳密には、(比率としてスカラー値化する際に)「縦横」比と「横縦」比の使い分けがあるらしいが,この仕様では特にこの区別を意識する必要はない。) |
attribute | 属性 | XML の属性は、要素を修飾する付加的な情報。 例えば HTML (XHTML)のアンカータグ(A タグ)のリンク先を指示する href="http://www..." など( href が属性名、"http://www..." が属性値)。 IDL インタフェースを実装するオブジェクトのデータメンバも「属性」と呼ばれる。 (両者の区別が必要な所では、他の仕様等では,前者は「内容( content )属性」, 後者は「 IDL 属性」と記されることが多いが、この仕様での後者は「 DOM 属性」と記されている)。 プロパティとの概念的な相違/使い分けはプロパティの項を参照。 | |
author, authoring tool | 文書作成者, 文書作成ツール | 前者は SVG 文書を作成する側を指す。 後者は文書を作成/編集するためのプログラム(人からの利用(対話的操作)が含意されている)。 仕様の中で記述されるふるまいの主体として主なものには、他に “UA” (ユーザエージェント — User Agent ), 実装( UA も含めた SVG を処理するプログラム全般), 利用者( user )などがある。 | |
-base | -基点 | アニメーション | (アニメーションの文脈で)アニメーション始動時機の時間軸上の基準点を指定するもの。 「同期基点」, 「イベント基点」, 「 DOM 基点」, 等々。 この訳語は他サイトの SMIL 2.0 の邦訳から借用している。 |
baseline | 基底線 | テキスト, フォント | 頻出する用語なので、「ベースライン」より短く「基底線」とした。 フォントに詳しい方には「ベースライン」の方が通りが良いかもしれない。 現れる場所はテキストとフォントの章のみなので戸惑われることはないように思われる。 「並び線」「整列線」などの対訳も見られる。 フォント情報処理用語 では「並び線」と訳されているが CSS2.0 仕様の日本語訳 では基底線とも訳されている。 SVG はウェブ利用が主なので後者に倣う事にした。 |
base value | 基底値 | アニメーション, uDOM | SMIL 用語。 アニメーションが適用される前の属性/プロパティの値。 "underlying value" (下層値)も参照。 |
begin | 始動 | アニメーション | アニメーションの活動開始 |
Bézier | ベジェ | パス | ベジェ曲線は,代数曲線の一種であり、ベクターグラフィックスの世界では曲線の表現に最も多用されている。 フランス人数学者 Pierre Bézier により考案された。 発音に倣うなら「ベジエ」と記すべきようだが、訳語としては「ベジェ」の方が定着している。 |
bidirectional | 双方向 | テキスト | 双方向テキストとは、横書きにおいて,左→右(欧文など)と左←右(アラビア語など)の両方向が入り混じったテキストを指す。 略して “bidi” とも称される。 「両方向」と訳されることも多いようだが、どちらが適切なのか判らない。 対話性(interactivity )も双方向性と訳されることがあるので区別するためにむしろ「両方向」の方が良いかもしれない。 |
(language) binding | 言語束縛 | binding の一般訳は「束縛」「結びつけ」。 言語束縛とは、何らかの仕様(この仕様では主に SVG の DOM インタフェース)を特定のプログラム言語から利用できるようにする目的で,言語依存の形で結び付けたものを指す。 (言語)バインディングと訳される方が多いが、「束縛」の方が簡潔でもあり,「言語束縛」と記される場合、ほぼ意味が特定されるので。 その意味で、“binding” が単体で現れる所でも「言語束縛」としている。 | |
blend | 混色 | 「混色」とは言ってもアルファチャンネルも関る。 そのまま「ブレンド」と訳される事も多い。 | |
bounding box | 限界ボックス | 「バウンディングボックス」では長いので「限界ボックス」。 以前は「包含ボックス」と訳していたが、「 contain 」と紛らわしいので変更した。 (「境界ボックス」という対訳も見かけるが CSS の “border box” と紛らわしい)。 | |
cascade | カスケード | CSS 用語(定義)。 一般訳は「階段状に連続した滝」。 CSS によるスタイル付けを個々の要素に適用するために,要素に適用されるスタイル規則を見出す処理を指す。 その処理のされ方(どのスタイル規則を優先させ, どのように値を継承させるかの仕組み)が階段状の滝を連想させる所から命名されたと思われる。 | |
cell | セル | テキスト, フォント | グリフのセルとは、グリフが描画される際に基準とする矩形領域を指すと思われる(厳密な定義は見当たらない)。 |
character data | 文字データ | XML においては、 Unicode 文字の並びで構成されるデータを指す。 | |
channel | チャンネル | RGBA 色の各成分、赤(R), 緑(G), 青(B), 不透明度=アルファ(A) を表す。 「チャネル」という訳が正しい気もするが、普及率は「チャンネル」の方が高い。 | |
child | 子 | XML 文書木において要素Aが要素Bの「子」であるとは、AがBに直接的に包含されていることを意味する。 | |
clipping path | クリッピングパス | 定義は 14.1 を参照。 「切り抜きパス」とする方が解り易いと思うのでそちらを採用したい気もするが、「クリッピングパス」という訳語が定着している。 動詞の "clip" は「切り取る」等に訳している。 | |
code point | 符号位置 | Unicode 用語。 Unicode 文字の一つの文字を表すコード(どの文字なのか識別する数値)。 | |
collection | コレクション | 一般訳は「収集物」。 データとしては集合と同義になるが、特定の目的で関連するものを集めたものといった含意がある。 通常は「collection of 」を「一連の」などと訳しているが、関連する属性やプロパティの集まりを指すモジュールの文脈では「コレクション」としている。 | |
color | 色/カラー | 主に「色」と訳しているが、 "color profile" については「カラープロファイル」が普及しているので、そちらを採用している。 | |
computed value | 算出値 | CSS 用語) 算出値とは、プロパティの値が、百分率や em など相対的な単位を持つ場合,あるいは inherit 等の継承を通して指定されている場合、算出値はその値を(プロパティの定義で指定される規則に従って)絶対的な値に換算した値を表す( SVG の場合、 HTML と異なり,レイアウトが絶対的なので、概ね,描画処理に際して実際に利用される値になると考えられる)。 「計算値」という訳も見かける(が, “calculation” の対訳と衝突するので避けた)。 | |
content | 内容 | 文書構造 | XML 用語。 XML 要素の内容は開始タグと終了タグの間に挟まれた部分のデータを指す。 「内容」では一般的に過ぎる嫌いもあるので,専門用語らしく「コンテンツ」とすることも考えらるが、頻出する語でもあり、他の意味で用いられることもほとんど無く,文脈からも容易に判別できるので(出現するときは常に,「〜(要素)の内容」)。 |
coordinate | 座標/座標成分 | 座標系, 変換, 単位 | 「座標」と記すと日本語では空間の点を指定する複数の値の組を指すようだが、英語では "coordinate (x, y)" とか複数形の "pair of coordinates" などと書かない限り,座標を指定する個々の成分の意味になるようだ。 "odd number of coordinates" を「奇数個の座標」などと記すと意味が曖昧になるので、個々の成分を指す場合は「座標成分」と記すことにする。 |
cumulative | 累積的 | アニメーション | SMIL 仕様にて定義される。 同じアニメーションが複数回に渡り反復されたときに,その効果が累積されながら表示に反映されることを意味する(加法的アニメーションとの相違に注意)。 |
current | 現在の | ||
descendant | 子孫 | 要素Aが要素Bの「子孫」であるとは、XML 文書木の木構造においてAがBの下位(末端側)に位置する( XML ソーステキストの中ではAがBの内部にある)ことを意味する。 | |
declarative | 宣言的 | 何らかの効果を得るための処理を記述するのに、言語に備わる汎用的な語彙の組み合わせではなく,その目的のために特別に用意された専用の言語機能/キーワード等を用いて記述することを指すようだ。 宣言的プログラミング には、「ある出力を得るにあたって、それを作成する方法ではなく,出力の性質を記述する」と記されている。 | |
default value | 既定値 | XML 属性に値が指定されていない(属性が与えられていない/省略されている)場合に暗黙的にその属性に設定される値。 (特にこの種の技術仕様では)“既定” の同音異義語には “基底”, “規定” も頻出するためか、一般的には「デフォルト」の方が定着している。 | |
device | 装置 | 入出力に利用される物理的な装置/ハードウエア。 | |
dispatch | 配送する | 対話性 | 発生したイベントをそのときの状況に応じて適切な要素へ送る(要素に結び付けられたイベントハンドラに渡す)処理を指す。 正確な処理モデルは DOM イベントモデルの仕様に定義されているが, SVG ではインスタンス木に関連して拡張されている。 「配送する」という訳は訳者が適当に思われるものとしてあてがったもの。 |
distance | 距離 | 座標系, 変換, 単位 | 「distance-along-the-path 」は「パスに沿う距離」(パスの始点からパスに沿って長さを計量していくことによる距離)としているが、今ひとつしっくりしない。 |
document | 文書 | 文書構造 | 具体的には XML 文書を指す(より広い意味では HTML なども含め,文書木( DOM 木)としての構造表現を持ち得るリソースを指す)。 「ドキュメント」と訳されることも多いが、基礎的で頻出する語でもあり,他の意味で用いられることも無く,いかにも長いので。 |
duration | 持続時間 | アニメーション | アニメーションが実行される時間の長さ。 |
element | 要素 | 文書構造 | XML 用語。 XML 文書の構造を組み立てる基本的な部品( HTML のタグと同様)。 要素には,いくつかの他の要素を含ませる(入れ子にする)ことができ、全体として要素の木構造が構成される。 「 SVG 要素」は、 SVG 言語(の名前空間)に属する要素の総称。 |
entity | 実体 | 文書構造 | XML 用語。 「エンティティ」とも訳される。 例えば HTML のタグ区切り文字 <, > のように,構文上本文に直接記述できない文字を記述可能にするために特別に用意された参照用の文字列 <, > など、文書内に元々のデータとして存在しているかのような内容の参照を行なう単位を意味する。 参照先の特定に利用される名前を実体名(先の例では lt, gt )と呼び、参照先の中身(先の例では <, > )を実体の内容と呼ぶ。 |
event | イベント | 対話性 | 利用者の行為(例えばマウスクリック)あるいは何らかの状態変化が生じた時にシステムやプログラム(のオブジェクト)へ通知されるもの(どのような種類の行為あるいは変化であるかなどの情報を包み込んだオブジェクト)。 イベントリスナ( event listener )は、通知されたイベントを処理するための(通常は文書/スクリプト作成者が用意する)ルーチン。 |
establish | 確立する | ||
exception | 例外 | 「例外が投出される」,「例外処理」といった句として用いられる。 意図されていないパラメタがプログラムに与えられたなどの理由で,正常な実行が継続できないときに、プログラムあるいはプログラムを動かしているシステムが(正常な状態を保つためにその処理を中止した上で)生じさせるもの。 通例的には、その状況の詳細情報が一定の形式のオブジェクトにくるまれ,システムまたはプログラムに用意された例外処理機能に渡される。 | |
facility | ファシリティ/機能/枠組み, 他 | 一般訳は扱いやすさとか容易さ,特定の目的(を達成するのを容易にする)のために用意された施設/設備などといった意味で、対応する和訳は無いようだ。 文脈によって「機能」,「枠組み」などと訳しているが、今述べた含意がどうも伝わりにくい感じですっきりしないものがある。 | |
feature | 特能 | 一般訳は「特色」, 「呼び物」。 他の仕様に無い様な新たな機能。 専門用語としての「特能」という命名は聞いたことが無いので、"feature string" などは「フィーチャ文字列」などとした方がよいかもしれないが、「フィーチャ」という訳語もあまり普及していないようなので,「特能」を採用させてもらうことにする(また、単に「機能」では,語義が広くなり過ぎる)。 | |
fill | フィル/内部への塗り | 「塗り潰し」と訳すのは、「paint = 塗り」と紛らわしいので避けた。 「ストローク」と並立する用語でもあり、外来語のまま「フィル」を採用。 塗りという操作と塗りの対象とを分けて示したいこともあるので、そのような所では「内部への塗り」としている。 | |
filter | フィルタ | フィルタ効果 | “filter effect” は「フィルタ効果」としている。 “filter primitive” は逐語訳的に「原始フィルタ」としている。 「フィルタプリミティブ」の方が適切かもしれないが、いかにも長いので。 |
fragment, document fragment | 素片, 文書片 | 文書構造 | XML 用語。 XML 文書木において1個の部分木をなす文書の構成部分を指す。 XML の構文上、部分木は文書内で連続するテキストになるので「 fragment (片)」という語が利用されているようだ。 専門用語らしく「フラグメント」と訳されることも多いが、基礎的な用語でもあり,簡潔にするため "fragment" 単独で現れた場合は「素片」( JIS でも利用されている)、 "document fragment" は「文書片」と訳すことにする(つまり「素」は修飾の無い汎的な「片」を表すと解釈)。 |
generator | 生成器 | 一定の形式のデータ生成を目的とするプログラム。 利用者との対話性は意識されない。 | |
gradient | グラデーション/勾配 | 一般訳は「傾き・勾配」など。 ここでは色を徐々に変化させる塗り方を指す。 グラフィックスの世界では「グラデーション」と訳されるのが一般的のようだ。 "radial gradients" は「放射型グラデーション」、 "linear gradients" は「線型グラデーション」としている。 (発音的にも意味的にもグラデーションは "gradation" なのにどうして "gradient" なのだろう?) しかしながら, "gradient vector" や "gradient normal" の "gradient" は、より数学的な文脈で解釈したいので「勾配ベクトル」, 「勾配法線」としている。 | |
grammar | 文法/構文 | 「文法」と訳されるのが普通なのだが、文脈によってはなんとなく「構文」と訳している部分もあり,正直言って訳者の認識には混乱がある。 (一般的には、自然言語における grammar はより形式的な構文規則の意味合いが強く,文章に "それ以上の" 意味を持たせるものではない一方、 syntax には「言い回し」による意味の追加も含意されているらしい: 参考) | |
graphic | グラフィック/グラフィックス | 複数形の "graphics" はグラフィックス全般を指していると思われる所ではそのまま「グラフィックス」としている一方、個別のグラフィックを指すような所では「グラフィック」としている。 | |
handler | ハンドラ | 対話性 | イベントハンドラとは、イベントが通知された時に一定の処理を行うために用意されたプログラムのルーチンを指す。 |
hint | ヒント | フォント | ヒントとは、ソフトウェアの文脈では、何らかの処理を行うプログラムに対し,その速度や品質向上の目的で与えられる情報で、その処理にとって本質的ではない類のパラメータを特に指すようだ。 例えばフォントのヒント情報は、フォントを低解像度の表示装置に描画する際に,文字のつぶれを可能な限り回避して視認性を高めるためにフォントに付加される,補助的な情報を意味する。 |
identify, identifier | 識別する/特定する, 識別子 | ||
ideographic | 表意文字 | テキスト | ideographic は、いわゆる Unicode の CJK 統合漢字あるいは Ideograph 領域に割り当てられた文字を明示的に指しているのかもしれない。 日本の読者なら「統合漢字」の方がしっくりするであろう。 しかしながら、この仕様書の文脈においてはより一般的概念を表す「表意文字」の方が適切に感じるので、こちらを採用。 (公式サイトの Unicode 用語の対訳 でも「表意文字」とされている。) |
IDL | IDL | インタフェース記述言語 (インタフェースの記述に利用される言語)。 SVG 1.1 仕様では OMG IDL と呼ばれる IDL が利用されている。 近年のウェブ関連仕様の IDL は、より Javascript に適化された Web IDL が主流になっており, SVG 2.0 の IDL も Web IDL に変更されている。 | |
image | 画像 | 必ずしもラスター画像を指すわけではないことに注意。 | |
implementation | 実装 | 「実装する」とは、ある機能または仕様を現実に動作するプログラムとしてソフトウェアに追加する、あるいはソフトウェアを新しく開発すること。 | |
inherit | 継承する | CSS のプロパティの 継承 とは、その値が親要素から暗黙のうちに子要素のプロパティの値として利用(継承)されることを指す(正確には親要素のプロパティの算出値が継承される)。 あるインタフェース A が基礎となる別のインタフェース B を拡張している場合も「 A は B を継承する」などと記される(この場合は「 A は B の派生インタフェース( derived interface )である」とも記される)。 | |
initial value | 初期値 | CSS プロパティの 初期値 とは、そのプロパティに値が指定されておらず,かつカスケード処理/継承を通して値が取得されることもない場合に,指定されたものとみなされる値である。 初期値はプロパティの種類ごとに個別に定義される。 | |
inline | インライン | AをBにインラインに埋め込むとは、Bの中にAへの参照ではなく,Aそのものを記述すること。 ほとんど見かけないが「行内」という訳も考えられる。 | |
inline-progression-direction | 行内進行方向 | テキスト | 文字通り、テキスト(の個々のグリフ)が描画されるときに行が延伸する方向を意味する。 すなわち縦書なら上から下へ等々。 「書字方向 ( writing direction ) 」という語も現れるが、こちらは描画ではなく自然言語に備わる特徴を表すものになる(アラビア語の書字方向は右から左等々)。 |
interpolation | 補間 | アニメーション, フィルタ | 補間とは、離散的なデータ(飛び飛びの値)が与えられたときに、個々の値の間を合理的につないで連続的なデータを復元する,あるいはより稠密なデータを作り出すことを意味する。 |
instance | インスタンス | 一般訳は「実例」。 インスタンスとは、ひな形から複製された実在としての(実際に機能する)オブジェクトを意味する。 | |
interact, interactive, interaction, interactivity | 対話する, 対話的, 対話, 対話性 | 対話的(インタラクティブ)であるとは、利用者とプログラムとの間で対話的操作(プログラムが利用者の操作を受け付けてその反応を返す)が可能であることを指す。 「双方向」という訳も一般向けに使われていたりするが、こちらは離れた通信端末どうしあるいは端末とサーバとのやりとりに重きが置かれているように感じる。 また、動詞のときに「双方向する」などと書くのも変だ。 | |
interface | インタフェース | 一般訳は(相互に)作用を及ぼす境界あるいは接点。 ソフトウエアの文脈では、システムのプログラムやライブラリが別のアプリケーションプログラムから利用される目的で、外部に提供/公開している規約,具体的には一連の 定数, 変数, 関数やその引数,の組を意味する。 ユーザインタフェース( UI )とは、プログラムを人から利用し易くするように設計された,プログラムと人間の操作を仲介するプログラム(あるいはその設計理念)を意味する。 この語は「インターフェイス」「インターフェース」など表記揺れが多い。 | |
kerning | カーニング | フォント | フォント用語。 一般に文字配置バランスの向上目的で、字送りの際に文字固有の字幅と異なる字幅(通常は固有の字幅より狭い)による字送りを行って文字間を調整すること。 例えば文字列 "VALLEY" (峡谷)を通常の字送りで描画すると "V" と "A" の隙間が広く見えて "V" と "ALLEY" (路地)に誤読されるおそれも生じる。 こうした場合に対処するためにも "V" と "A" がカーニングの対象になる。 |
layout | 配置, レイアウト | テキスト | 「配置」では意味が広過ぎるきらいもあるので文脈によっては「レイアウト」。 |
linear | 線型 | 一般的な意味は変化の量が一定でグラフにすると直線になることを表す。 「線型空間」という場合は、加算/スカラー積が可能で,それらの演算に関して閉じていることを意味する。 「線形」という訳もあり,こちらの方が広く使われているが、元々は「線型」と訳されていたらしい。 "shape" = 「図形」と区別させるため、当訳では「線型」とした。 | |
marker | マーカ | 当該章を参照。 | |
mask, masking | マスク, マスキング | 定義は 14.1 を参照。 | |
magnify | ズームとパン | 対話性 | "magnify" の一般訳は「拡大」。 利用者による文書の拡大(縮小)表示またはその行為を指す。 拡大操作には一般的にその原点を表示域の原点と別にとることも含まれるので、数学的には(変換としては)並進も含意される。 単に「拡大」「拡大縮小」のように記すと意味が正確に伝わらなくなるおそれがあるので、「ズームとパン」と訳させてもらうことにする。 |
media | メディア | 「媒体」という訳もあるが普及度の観点からメディア。 | |
method | メソッド | DOM で定義されているインタフェースのメソッド(一定の処理を行うサブルーチン)を指す。 function や procedure もほぼ同義であるが、オブジェクトのメンバを指すときはこの名称が用いられる事が多いようだ。 "method call" は「メソッド呼び出し」としている。 | |
module | モジュール | 一般的には何らかの構造物を組み上げるための素材となる規格化された基本単位を意味する。 ここでは仕様を関連する機能のまとまりに分割したものを指すと考えれば良いだろう。 | |
motion | モーション | アニメーション | 当該章を参照。 |
namespace | 名前空間 | 文書構造 | 同じ文書の中で異なる XML 言語を組み合わせて利用するときに、それぞれの語彙が衝突しないようにするために考え出された枠組み。 Namespaces in XML 仕様( 和訳 )で規定されている。 それぞれの言語が固有の「名前空間」を持つ。 言語間で同じ名前の語彙は、名前空間接頭辞を付けることにより,どちらの言語に属するか区別できるようになる。 |
node | ノード | 一般的には木構造などの グラフ構造 における頂点(枝分かれの分岐点や端点)を指す。 SVG のような XML 文書では、通例,その文書木( DOM 木)を構成する,個々のオブジェクト(それぞれが,文書の個々の要素, あるいは要素タグ間に挟まれたテキストなどに対応する)を指す。 | |
normalize | 正規化 | (抽象的な)データとその表現は、必ずしも一対一の対応関係にはならない(例えば,テキストデータとして表現する際に、人から読み易くする整形目的で,余分なスペースや字下げが入れられるなど)。 正規化とは、この対応関係が一対一になるように(例えば構文解析処理や元データの同一性を容易に検証できるようにする目的で),表現されたデータを一定の “規範的” 表現に一元化する処理を意味する。 | |
normative | 正式な | 仕様の一部として見なされるべきもの(規定)。 | |
object | オブジェクト | 一般訳は「物」「対象」。 ここでは概ねインスタンスを指すものと考えてよさそうだが、訳者にはこの語が表す概念をきちんと説明できる自信はないので,その使われ方から理解していただくというより他ない。 強いて述べれば操作の対象, 一定のふるまいを持つ何かといった、外から眺めてみたときの「モノ」を表すのではないだろうか。 | |
one corner | 第一頂点 | "one corner of a rectangle"(矩形の第一頂点)とは、矩形の4頂点のうちX,Y座標がともに小さい方をとった頂点(矩形が座標系変換を加えられずに,そのまま表示されたときの,左上頂点)を指すものと思われる(この句の定義は見当たらないが,多くの要素で矩形の指定に利用される x, y 属性の定義から明らかであろう)。 | |
opacity | 不透明度 | フィルタ効果,クリッピング, マスク, 組成法 | グラフィックスの世界では透明度( transparency )よりも多用される。 色の「実効値」を単に不透明度との積で表せて便が良いためと思われる。 |
orientation | 方位 | 塗り, テキスト, フォント | マーカやグリフなど、単体として扱われるグラフィックシンボルが描画される際の(何らかの基準方向に相対的な)方向を表すときに特に用いられる。 |
outermost | 最も外側の | 文書構造 | XML 要素の文書内での位置についての記述であり、XML 文書木で言えば最も根本側に位置することと同義である。 ちょうど XML 文書をテキストデータとして眺めたときに、要素の開始タグ/終了タグが先頭側/末尾側に最も近いことに対応する。 木構造として見れば “rootmost” と同義になる。 |
outline (of a shape) | 外形線 | 図形の外形線は図形の内側を通ることもあることに注意(例えば自分自身と交差するパスによる図形など)。 そんなわけで、「輪郭」ではなく,より汎的ニュアンスが感じられる「外形線」を採用。 | |
paint, painting | 塗る, 塗り | フィルまたはストロークを図形に適用すること。 ただし、「paint server 」は「ペイントサーバ」と訳している。 | |
pan | パン | 対話性 | 一般的な意味は、カメラの向く方向を変えながら撮影すること。 具体的にはウィンドウに表示されている画像などをマウスで掴んで動かす等の操作でスクロールさせることを指す。 スクロールにはいわゆるスクロールバーあるいはウインドウやフレームの存在が意識されているが、パンにはそれが意識されていない。 SVG の文脈では2次元なので、このこと以外に違いは無いと思われる(3次元の場合のパンとスクロールは物理モデルとして意味が異なり得る)。 |
parent | 親 | XML 文書木において要素Aが要素Bの「親」であるとは、AがBを直接的に包含していることを意味する。 | |
parse, parser | 構文解析する, 構文解析器 | 構文解析 とは、一般に,一定の構文規則に基づいて記述された(直列化された)データを走査して、その構造を解読する(直列化される前の,元々のデータ構造を復元する)処理を指す。 構文解析器はそれ専門に行うプログラムを指す。 ( parser の対訳は「パーサ」も一般的だが、統一性の観点から「構文解析器」。) | |
path | パス | パス | 一般訳は一本の道とか筋といった意味。 グラフィックスの世界ではそのまま「パス」と訳されるのがほとんどのようだ。 「経路」では決められた何本かの道から選ぶような含みも感じるのでそのまま「パス」を採用。 |
pixel | 画素 | 単位としては、物理的な表示装置の画素あるいはラスター画像の画素とは必ずしも一致しないことに注意。 | |
polyline | 折線 | 「多角形( polygon )」との違いは、“開いた” 図形であること。 始点と終点が同一であっても,開いている(始点と終点が “無限に近い”)ものとみなされ、端点の形状が指定されていれば,それが始点/終点に描かれることになる。 | |
premultiplied | 乗算済み | フィルター効果 | 画像の組成等における色の計算公式において、色チャンネルを表す値が,あらかじめ元の色チャンネル値にアルファチャンネル値(不透明度)を乗算した結果にされていることを意味する。 |
presentation | 呈示 | スタイル付けなどによる表示上の効果を意味する。 呈示属性はそのような効果を指示する XML 属性。 長いので「プレゼンテーション属性」から改称( 2013-12 ) (「呈示」という語が他の意味で使われている箇所はない)。 | |
profile | プロファイル | 一般訳は「横顔」「概観図」といった意味だが、ここでは,仕様や機能などを他から参照/利用し易くする目的で一定の形式にまとめたものと考えれば良いだろう。 人物紹介などに用いられる「プロフィール」は、どうもフランス語の発音から来ているようだ。 | |
property | プロパティ | 一般訳は「所有」「資産・所有物」あるいは「ものの性質」といった意味。 SVG 用語としての定義は、概要章の用語定義のプロパティに記されている。 「属性( attribute )」とよく似た概念だが、属性は、値が指定されていなくても既定値があてがわれるなど、一定の型の要素やオブジェクトには,常に存在する種類の性質(値は個々の要素ごとに専属的になる)に用いられる語であるのに対し、プロパティは,継承やスタイル付け等の仕組みにより後付け/オプションで値があてがわれるような種類の性質(その結果,値は複数の要素に共有され得る)、という使い分けがあるようだ。 | |
raise | 投出する | 例外を発生させること(「例外」参照)。 プログラムがその例外処理機能に渡された例外をより上位層(プログラムの呼び出し元など)に伝達させる場合も投出と称される。 他の仕様類では "raise" でなく "throw" が用いられるのが通例だが、(このバージョンの) SVG 仕様が利用している OMG IDL の例外投出を指示するキーワード "raises" に揃えたためと見られる。 "raise" はイベントの伝播を表す語にも用いられているが、訳では別の語を用いている。 | |
raster image | ラスター画像 | ベクター画像とは対照的に、 JPEG や PNG 形式など,色を持つ点の集まりで構成された画像を指す。 拡大するとドットが目立つようになる。 | |
rectangle | 矩形 | 「長方形」と訳すことも考えられるが、「矩形」には回転されていない状態(辺が座標軸に並行)も含みに感じるので。 ここでの "rectangle" は矩形の第一頂点の座標と矩形の大きさ(幅と高さ)で指定されるものであり(基本図形の場合は角の丸め方も)、幾何的な意味でより汎的でプレーンなニュアンスが感じられる「長方形」と区別したつもり。 | |
render, rendering | 描画する, 描画 | render は一般的には「翻訳・解釈して(最終的な媒体に)表現・演出する」といった意味。 ここでは主に内部的な処理を施した後、視覚表示装置/キャンバスに描画出力する意味に用いられているので、解り易く「描画する」とした。 一般概念的には外来語のまま記すべき所かもしれないが、ごく少数の例外(音声などでは「出力する」等としている)を除き,「描画」で不自然になる箇所はない。 "rendering" の訳には「レンダリング」が一般的に用いられているので、 "render" も「レンダリングする」と訳すことも考えられるが、頻出する語だけにかなりまどろっこしい(私見だが、抽象的/デジタルデータを人の知覚に馴染み易い形で表現するときに、特に用いられる語とも考えられる)。 よって統一性の観点から "rendering" も「描画」とする。 "draw" などの語は「描く」と訳すなど、意識的に区別している。 | |
resampling | 再標本化 | 「sample — 標本」参照。 | |
resource | リソース | 文書構造 | 「資源」という訳もある。 ソフトウェアの文脈では、(複合的な)データを構成する素材を意味する。 ウェブの文脈では URL により識別し得る対象を特に指すらしい( 参考 )。 |
root | ルート | 木構造(tree を見よ)における根元のノードを指す。 例えば「ルート要素」は「文書木」における根元の要素を指す。 | |
sample, sampling | 標本, 標本化 | 標本化とは、連続的なデータ(すなわち連続的な写像)が与えられたとき、近似的なデータ(目的に見合った,実用的に処理し得るような、有限個のデータ)を得るために,一定の間隔ごとに区切った代表値の集まりを抽出することであり、標本化された結果を標本と呼ぶ。 現実の風景をデジタルカメラで撮影したラスター画像データは標本の一例である。 再標本化( resampling )とは、(例えば,処理や入出力装置の都合に合わせる目的で)一度標本化された結果を補間などを用いて連続的なデータに戻してから,別の間隔を用いて標本化することを指す。 前述の画像データをプリントしたものをスキャナーで読み取って再びデジタル化する作業は再標本化の一例である。 | |
scale, scaling, scalable | 拡縮させる, 拡縮, スケーラブル | 座標系, 変換, 単位 | 拡縮(変換)とは、X軸/Y軸あるいはその両方向に沿って,拡大/縮小させることを意味する。 SVG の "scaling" には、X軸とY軸で不均等な倍率の変換も含まれることに注意。 「スケーラブル」については「概念」の章を参照。 |
schema | スキーマ | この仕様の中では、 メタデータスキーマ 以外のスキーマは スキーマ言語 を指す。 概念的には「枠組み」が近いように感じられる。 | |
scope | スコープ(有効範囲, 可視範囲) | この語には、ある宣言について、その効力が及ぶ範囲(有効範囲)について述べる場合と,効力が及び得る対象から見てその対象に影響し得るための宣言の存在範囲(可視範囲)について述べる場合、の2通りの用法がある(後者は,「〜からのスコープ」と記している)。 例えば、要素の style 属性に直接指定される(継承可能な) CSS スタイルのスコープは,その要素自身とその要素の子孫に渡る。 この場合、ある要素がその種のスタイル宣言に影響され得るための「可視範囲」(宣言の存在範囲)は、その要素自身とその要素の先祖要素に渡ることになる。 | |
script | スクリプト | スクリプト | 主に Javascript のようなインタープリタを介するプログラミング言語を指す。 |
script | 用字系 | テキスト | 人が話す自然言語の文脈の script は、一定の自然言語圏の表記に使用される文字やグリフとその表記規約の組を指す(ラテン (ローマ) 文字を使用する西欧諸言語はローマン用字系,等々)。 |
(path) segment | 区分 | パス, 塗り | パス区分とは、パスの中のある頂点から次の頂点までの部分を指す。 |
selector | セレクタ | スタイル付け 文書構造 | CSS 用語。 スタイル付けが適用される対象範囲(通常は要素の集合)を指定するもの。 「選択子」という訳もある。 |
semantics | 意味論 | データや規則などにあてがわれた「意味」。 syntax(データや規則の形式や構造)に対立する概念。 栗原潔氏のコラム に解り易い解説が載っている。 | |
serialize | 直列化 | 「シリアライズ」, 「シリアル化」とも訳される。 直列化 とは、(複雑な構造も持ち得る,より広い意味では抽象的/概念的な)データを,一定の規則の下に整列して,一次元的なストリームデータに変換する処理を指す(例えば、 10 進記数法は,概念としての 数 を直列化する — 通常、出力されるデータには,構文解析により元のデータを正確に復元できることが要求され、その意味で,構文解析と対立する概念になる)。 計算機間のデータ交換では,限られた本数の“回線”を通してデータを読み書きするので、この種の変換が自然な要求として存在する。 人が話す言葉も,時間と順序の同期が必然的に備わるので、同様になる。 | |
shape | 図形 | 「形」では語義が広過ぎるので「図形」と訳してより幾何的意味に限定させた。 「形状」という訳も考えられるが何らかの特徴が類似した一定の範疇の形といった含みを感じる嫌いもある。 | |
skew | 斜傾 | 座標系, 変換, 単位 | 「斜傾」(変換)という訳語は訳者が適当にあてがってみたもの。 「スキュー」,「シアー」と訳されるのが一般的だが、なじみの無い方にとっては「斜傾」の方が感じを掴み易そうだ(もっともこの仕様を読まれるような方には常識的だろうが)。 他の変換(拡縮, 回転, 並進)と同じように二字熟語にすることにもこだわった。 「せん断」(剪断)という対訳もあるが、物理的なニュアンスも入るので,より平易で汎的な「斜傾」を採用。 |
stand-alone, standalone | 独立 | 部品として利用されるものではなく、それだけで完結していて利用できるという意味。 XML の文脈では特別な意味もあるらしく、スタンドアロンと訳されることが多いようだ。 | |
stroke | ストローク/外形線への塗り | 一般訳は一描きで線を一本描くといった意味。 「外形線への塗り」としている箇所もある。 | |
styling | スタイル付け | スタイル付け | 当該章を参照。 |
sub-element | 下位要素 | 特定の型の要素の内容として特に許容されている要素を指す場合に用いられる(その要素型の内容モデル専用の要素)。 例えば text 要素下であれば tspan 要素, tref 要素など。 | |
syntax | 構文 | semantics 参照。 「構文」と訳している所が多いが、単なる文字や記号の並べ方の規則以上の,データのやり取りの規則など,より形式的/抽象的な記号の扱い方の枠組みなどの意味合いも含まれているようで、「構文」では不十分にも感じる箇所もある。 (言語学では "semantics" と "syntax" は「意味論」と「統語論」と訳されているようだ。もっとも、「統語論」では,いかにも大仰な感もあるが。) | |
target | 対象/標的 | 何らかの効果が適用される対象を指す場合は「対象」、イベントの配送先となる要素を指す場合は「標的」としている。 | |
transform | 変換 | (座標系の)アフィン変換(平行移動(並進)を伴う線型写像) | |
translation | 並進 | 座標系, 変換, 単位 | 並進(変換)は平行移動による変換と同義。 物体の運動に用いられる語であるが、他の変換(拡縮, 回転, 斜傾)と同じように簡潔な二字熟語に統一することにこだわった。 |
transparent black | 黒地透明 | 描画モデル, フィルタ効果 | 訳者が適当に思える訳としてあてがってみたもの。 「黒地透明に初期化されたキャンバス」とは、色チャンネルもアルファチャンネルも値が 0 に初期化されたキャンバスを意味するものと思われる。 すなわち、その上に描画しても/それを背景に組成しても実質的な混色は行われないことになる。 |
tree | 木 | 「ツリー」とも訳される。 「文書木」とは、 XML 文書における要素の包含関係に基づく包含階層の 木構造 を指す(要素が枝分かれ部分、要素の子要素を各枝に比喩させた意味において)。 文書木は「 DOM ( Document Object Model )木」とも呼ばれる。 「描画木」, 「インスタンス木」という語も現れるが、いずれもこのような木構造を表す。 描画木は、描画の対象とその処理手順の構造を表すものと考えて良いだろう。 インスタンス木は、(他の XML 言語に比して) SVG 特有の概念であり、他の要素を参照して複製する機能を持つ use 要素の存在に起因する — すなわち,その複製により得られた(元々の文書木には無かった)部分木を指す。 インスタンス木がグラフィックス要素など描画対象の要素の複製であれば,描画木の一部を成すことになり、描画される以上,マウスなどのイベントの対象にもなるため、 SVG のイベント処理は,( HTML などの)通常の DOM イベント伝播処理より拡張されている。 | |
trigger | 誘発する | 対話性 | イベントを生じさせることを指す場合に特に用いられている。 似たような意味で "fire" (「発火」)という語も用いられているが、"trigger" はイベントを生じさせる誘因が論の対象であるのに対し、 "fire" はイベントを実際に生じさせる処理を指している。 |
underlying value | 下層値 | アニメーション | SMIL 用語。 加法的アニメーションの下での,アニメーションの起点にされる値であり、下層値は,この文脈において基底値(属性の元々の値)を一般化した概念を表す。 |
Unicode, Unicode code point | Unicode, Unicode 符号位置 | テキスト | Unicode はそのまま Unicode とされていることが多いようだ。 "Unicode code point" は、 Unicode の文字集合の中の一つ一つの文字を表すコード(どの文字なのかを特定/識別するための数値)と考えればよいであろう。 SHIFT-JIS など,他の文字符号化体系の「符号点」にあたるが、「符号位置」という訳語は Unicode の 公式サイトの対訳表 から採用している。 ウェブの文脈下では Unicode は特別な地位にあるので、この区別は妥当とも考えられる。 |
user | 利用-/利用者 | "user coordinate system", "user space", "user units" は、利用座標系, 利用空間, 利用単位等々。 「利用者」は主に末端利用者(エンドユーザ)の意味で用いられている。 むしろ “ユーザ” という対訳の方が多い(おそらく,抽象的な意味で動作の主体を指す含みも込めて? — プログラム側から見れば,利用者も入出力の相手の一種に過ぎないので)。 | |
version | バージョン/版 | 「将来版」など、どのバージョンか特定されないものを指す場合は「版」、バージョン番号や実在する文書など特定のバージョンを指す場合は「バージョン」、あるいはバージョン番号が記されている所では自明なので省略している。 尚、バージョンの違いと第1版, 第2版, 等々の版( edition )の違いは別物で、仕様等の文脈では前者は機能追加などの本質的な違い、後者は不具合の修正等,編集上の違いとして用いられていることが多いようだ。 | |
view | SVG ビュー | リンク | SVG 文書の表示状態(ズームとパンの状態)を指す。 |
viewer | ビューア | 文書を表示するためのプログラムを指す。 (編集機能については言及されないことが含意される。) | |
viewport | ビューポート | 座標系, 変換, 単位 | 「表示域」という訳もある。 「表示」という語はソフトウェア側(表示する側)から,ビューは利用者側から、という視点の違いがあるようだ。 |
Web | ウェブ | World Wide Web を指す。 その意味で "Web" の頭文字は常に大文字(であったが、一般化が進んだためか,次第に小文字で記されることも増えているようだ)。 「ウェブ」と「インターネット」は混同されがちだが、背景にある概念は異なる様に感じる。 (敢えてなるべく大雑把な説明を試みるなら、後者はインフラ的な意味合いが強く,前者は文字通り その上にある「巣」のようなもの?) | |
writing direction | 書字方向 | テキスト | 文章が綴られる方向。 例えばアラビア語は右から左へ書かれる。 したがって、テキスト描画においては,文字やグリフのデータだけでなくテキストが主にどの言語に属するかも重要になる。 |
zoom | ズーム | 対話性 | 縦横いずれの方向にも一様に、拡大/縮小させて表示することを意味する。 一様であることが、拡縮と異なる。 |
(訳者独り言:訳語にカタカナと和文のどちらの表記を採用するかは悩ましい所である。 カタカナ表記には、訳語としての表記がほぼ統一され,原語での名称が明らかになる利点もある:例えば「ベースライン」の対訳には「基底線」, 「並び線」, 「整列線」などがあり、他の仕様の日本語訳と一貫性がとれないおそれがある。 また、それが専門用語らしく見え,メタ的な言及との区別が付き易い利点もある: 例えば、あまりにも一般的な対訳 — 「 path 」を「パス」でなく「経路」などと表記するのでは、何かの文章で「経路」という語が現れた時に、それが SVG の path を指していることが判り難かったり,検索が難しくなる欠点もある。 しかし、その一方でカタカナ表記は冗長で, 漢字表記による意味/背景概念の読み取り易さが得られない欠点もある — 例えば「バウンディングボックス」より「限界ボックス」の方が解り易いであろうし, 「文書片」が「ドキュメントフラグメント」ではいかにも長く馴染みが悪い。 この点について、この翻訳では明解な基準は設けていない(強いて言えば上で述べた様なそれぞれの表記の長所/短所を総合的に判断している)。 こうした用語に統一された対訳をあてがう動きはあって欲しくもある。 (特に IT 関連の語はカタカナが多く、新たな概念を表す語が日々創出され続け,日本語化が追いついていないのが実情と見られる。メタ的な言及との区別に関して言えば、ある文脈では専門用語とされるものが,別の文脈では基礎的な知識/前提(その文脈下の新しい概念/用語を説明するための語)にもなるので、「カタカナ=専門用語」のような区分け方針をとる場合,(変化の速い IT 関連の文書では特に)文書間で対訳の統一がとれなくなる。) 訳者としては、あまりカタカナ語が氾濫し過ぎるのでは,日本語の利点も失われることになる — いっそのこと用語/フレーズは漢字もカタカナもやめてそのまま英単語で記してしまえ(突き詰めれば、和訳など無駄な行為,英文を読め — それも一つの考え方ではあるが),ということにもなるので、なるべく和文表記も使いたい所ではある( 英単語をそのまま利用するのも一つの選択肢と言え、特にコード類との対応が判り易い点でむしろ好ましい面もある。 例えば、対訳が意味論的に適切でない場合,誤った概念で捉えられたまま普及してしまうかもしれない。適切であったとしても、元の原語に新たな用途が創出され,整合しなくなることもあり得る。 また、この種の仕様は英語文書がほとんどなので,わざわざカタカナにせず直接的に英単語から概念をイメージできるようになった方が後々有利な面もあるだろう。 あるいは、例えば語彙対訳データを外部ファイルに分離し,必要に応じて、ブラウザに表示される時点でスクリプト処理で語を置換するような手法をとることも考えられる。 この場合、外部の対訳データファイルを置換/更新するだけで、それぞれの利用者に適した,あるいは時代の変遷に適応する訳文の生成も可能になるだろう。)
この翻訳は 2010 年に当ページで公開した第2版草案(2010-06-22)の翻訳をベースに、勧告(2011-08-16)までの修正部分をツールで検出して統合したものです。 統合作業は作業量の観点から、勧告案(2011-06-09)までの変更点については主に( HTML ソースではなく)テキスト(およびリンク)の修正部分の検出結果を元に行っています。 そのため、マークアップには一部更新漏れが残っているかもしれません。 この SVG 仕様固有のスタイルシートも草案のものを流用しています。 勧告案から勧告までの変更点の更新作業は HTML ソースの修正部分の検出結果を元に行っています。
その他、誤訳の修正など随時更新。
index ページによる記述 に準じるとします。