diff --git a/publishing/ja/fxl/html.html b/publishing/ja/fxl/html.html new file mode 100644 index 00000000..68fdcb6a --- /dev/null +++ b/publishing/ja/fxl/html.html @@ -0,0 +1,50 @@ + + + + + HTMLレイアウト + + + + + + +
+
+

概要

+

固定レイアウトの出版物は、HTMLドキュメントを使ってテキストと画像を組み合わせて作成できます。各ドキュメントには、コンテンツが配置されるキャンバスである固定の高さと幅が割り当てられます。CSS を使用して、この表示領域内でコンテンツ要素を絶対的に配置したり、寸法に合う画像をページに埋め込んだりします。

+

固定レイアウトにHTMLを使用する利点は、各ページのテキストコンテンツが支援技術で利用できる点です。画像の場合は、HTMLにもともとあるアクセシビリティ技術である代替テキストや拡張説明が利用できます。

+
+
+

EPUB

+

Web上で固定レイアウトを作成することは可能ですが、ブラウザでは自然にサポートされません。ブラウザはデザインどおりにページをレンダリングしますが、レンダリングをサポートするための最適化は行いません。

+

出版におけるこの問題を解決するために、EPUB3では、リーディングシステムが各固定レイアウトページに適切な表示領域と特性を作成できるように支援するメタデータが導入されました。

+

EPUB出版物は、固定レイアウトのXHTMLページで完全に構成される場合も、リフロー型の出版物内にいくつかの固定レイアウトページが散在しているだけの場合もあります(たとえば、地図は、リフロー型の出版物に固定レイアウトを用いて組み込まれる場合があります)。

+

SVGの固定レイアウトページとXHTMLの固定レイアウトページ、あるいは、画像を直接EPUBの読み取り順序で並べて混在できます。

+
+

注記

+

固定レイアウトの出版物の作成方法の詳細については、固定レイアウトの概要ページを参照してください。

+
+
+
+

アクセシビリティ

+

リフロー型の出版物のアクセシビリティ対応をするのと同じ手法を、アクセシビリティを最大限に高めた固定レイアウトのHTMLページの作成にも利用できます。主な手法としては以下のものがあります。

+ +

上記のような手法に従ったとしても、リーディングシステムではしばしばコンテンツ製作者によるレイアウトが維持されるため、ユーザーによる文書の見た目の変更ができず(たとえば、フォントサイズを大きくしたり、テキストの色を変更したりする機能が無効になるなど)、固定レイアウトによってアクセシビリティが制限される問題が生じます。その結果、固定レイアウトの出版物をアクセシビリティ対応にするために最大限の努力を払っても、一部のユーザーには読めないままになる可能性があります。

+
+
+ + diff --git a/publishing/ja/fxl/img-spine.html b/publishing/ja/fxl/img-spine.html new file mode 100644 index 00000000..f43be5ea --- /dev/null +++ b/publishing/ja/fxl/img-spine.html @@ -0,0 +1,71 @@ + + + + + Spine内の画像 + + + + + + + +
+
+

概要

+

固定レイアウトのEPUB出版物を作成する非公式な方法として、パッケージドキュメントのspineに画像(SVGを除く)を直接組み込む方法があります。ただし、フォールバックなしではspineに画像を組み込めないため、一般的にはこの方法で固定レイアウトページを作成することはありません。ほとんどの場合、XHTMLまたはSVGの固定レイアウトページに画像を埋め込む方がシンプルです。

+

spineに画像を使用すると、固定レイアウトのメタデータは設定されず、バリデーションエラーが発生します(例えば、必要とされる寸法はXHTMLとSVGでのみ規定できます)。リーディングシステムが出版物をレンダリングしない原因となる場合もあるでしょう。

+

関連する問題として、この方法では固定レイアウトのメタデータを指定できないため、ページの表示をほとんど制御できません。また、アクセシビリティの問題も深刻です。

+
+
+

製作

+

spine内に画像を配置することは、spine内にXHTMLまたはSVGドキュメントを配置することと変わりません。manifest内で画像が宣言されている場所を参照するには、 itemref要素を使用します。

+
<package …>
+   …
+   <manifest>
+      <item id="pg01" src="pg01.jpg" media-type="image/jpeg"/>
+      …
+   </manifest>
+   <spine>
+      <itemref ref="pg01"/>
+      …
+   </spine>
+</package>
+

ただし、前述の例をEPUBCheckで検証すると、spineでJPEGがサポートされていないため、エラーが発生します。

+

出版物のエラーをなくすには、manifestエントリでXHTMLまたはSVGドキュメントへのフォールバックを指定しなければなりません。

+
<manifest>
+   <item id="pg01" src="pg01.jpg" media-type="image/jpeg" <strong>fallback="pg01-fb"</strong>/>
+   <item id="pg01-fb" src="pg01.xhtml" media-type="application/xhtml+xml"/>
+   …
+</manifest>
+

リーディングシステムがspineの画像をサポートしていない場合には、これで代わりにフォールバックのXHTMLページをレンダリングできるようになります。

+
+
+

アクセシビリティ

+

spineの画像は、固定レイアウトを作成する方法としては最もアクセシブルでないものです。

+

画像の代替テキストや拡張説明は、フォールバックを通じて提供しない限り、提供できません。そのため、リーディングシステムが画像のレンダリングをサポートしている場合、ユーザーが代替テキストにアクセスする方法はありません(つまり、ユーザーには通常、フォールバックを表示するオプションは提供されず、リーディングシステムが自動的に何を表示するか選択します)。結果として、支援技術のユーザーが出版物を読むときに何も読み上げられません。

+

また、ユーザーが代替手段にアクセスできるという保証がなければ、代替手段がWCAGに準拠しているとしても、WCAGに準拠していると主張することはできません

+

固定レイアウトページごとにバックアップを作成するコストを回避するために、出版物がリーディングシステムでサポートされていないことを伝える一つのフォールバックドキュメントを使用する場合があります。この方法は、基本的に、テキスト代替を提供しないのと同じくらい読者にとって役に立ちません。

+

同様に、固定レイアウトページとコンテンツのテキストシリアライズの間に一対一の相関関係がない場合があります。この場合、読者を混乱させることなく各ページにフォールバックを設定することはできません (たとえば、一連のページが同じテキストシリアライズにフォールバックする場合、リーディングシステムはページをめくるたびに同じテキストをレンダリングし続けてしまいます)。

+

マルチレンディションの使用は、代替シリアライズの必要性の解決を意図していましたが、仕様に対するサポートは事実上ありません。

+

以上の理由により、常にXHTMLあるいはSVGによる固定レイアウトページを推奨します。

+
+
+

関連リンク

+ +
+
+ + diff --git a/publishing/ja/fxl/img.html b/publishing/ja/fxl/img.html new file mode 100644 index 00000000..d07ae688 --- /dev/null +++ b/publishing/ja/fxl/img.html @@ -0,0 +1,61 @@ + + + + + 画像 + + + + + + +
+
+

概要

+

固定レイアウトの出版物では多くの場合、画像が不可欠です。固定レイアウトの出版物は、漫画のように完全に画像で構成されている場合もあれば、児童書のように物語の背景として画像が使用される場合もあります。

+

したがって、背景が認識できなかったり、画像を処理するのが難しい可能性のあるユーザーが、画像で伝えられる情報を利用できるようにすることが、固定レイアウトを可能な限りアクセシブルにするための優先事項です。

+

画像が出版物の内容理解に必要な情報を含んでいる場合は代替テキストや拡張説明を提供するという、すべての画像の基本的な要件は、固定レイアウトにも適用されます。たとえば、どのキャラクターが何を言っているかというコンテキストが、画像上の配置によってのみ伝わる場合、テキストデータが画像にオーバーレイされていれば読者は物語のセリフを追えるでしょう。

+

ページ上にはユーザーがアクセスする説明を配置できる追加の領域が無いので、画像を説明し、コンテキストを提供する方法をひねり出さなければならないのが、固定レイアウトにおける課題です。

+
+
+

SVG

+

SVGには、画像を説明するための二つの要素があります。

+ +

出版物が固定レイアウトのSVGページで作成されている場合、これらの二つの要素を使ってコンテンツを説明できます。SVGはまだ十分にサポートされていないため、支援技術のサポートを改善するためにARIA属性( roleおよびaria-describedby )が追加されています。

+
<svg xmlns="http://www.w3.org/2000/svg" xml:lang="en" …
+     <strong>role="group" aria-describedby="svgtitle svgdesc"</strong>>
+   <title id="svgtitle">The Hydrologic Cycle</title>
+   <desc id="svgdesc">The continuous cycle by which water …</desc>
+   …
+</svg>
+
+

注記

+

この画像にはユーザーが操作できる追加のテキストコンテンツ(非表示)が含まれているため、groupロールが画像に付与されています。画像が完全にグラフィカルである場合は、代わりにimgロールを使用します。

+
+

titledesc要素は、大きな画像のコンポーネントに注釈を付ける場合にも使用できます。

+
<g fill="lightgray" stroke="gray" role="img" aria-describedby="gtitle">
+      <title id="gtitle">Rain clouds</title>
+      …
+</g>
+

これらの要素を使用してSVG画像に注釈を付けた場合の問題は、通常そのコンテンツが支援技術のユーザーに対してのみ利用可能になるという点です。

+

より高度なアプローチとしては、スクリプトやアニメーションを使用して説明を表示するリンクまたはボタンを設ける方法があります(例:ポップアウトのように説明を開く)。ただし、EPUB 3.2まではアニメーションなどが完全に制限されていたため、EPUBリーディングシステムのこのようなアプローチに対するサポートは制限されるかもしれません。

+
+
+

HTML

+

画像がHTML固定レイアウトページに埋め込まれている場合には、アクセシブルな説明を付与する方法がもっと沢山あります。SVG固定レイアウトの場合と同様に、説明を組み込むための画面スペースが限られているという制限が主たる考慮事項です。

+

そのため、説明は通常、さまざまなHTML、ARIA、CSSテクニックを使用して非表示にします。説明は、隠したり、クリッピングしたり、不透明度を設定したり、画像の下に重ねたりできます。非表示コンテンツに関するナレッジベースページでは、これらの可能性についてさらに詳しく説明しています。

+

EPUBのXHTMLコンテンツドキュメントでのスクリプトのサポートは、一般的にSVGで利用できるものよりはるかに優れているので、より幅広いユーザーが説明を表示するのに利用できる信頼性が高い方法があります。たとえば、画像をクリックまたはタップするとその説明を表示できます。Voyage of Life サンプルEPUBには、この手法の実験的な例が含まれています。

+

リフロー型の出版物とは異なり、固定レイアウトでページの背景画像を設定するのにCSSのbackground-imageプロパティが使用できます。ただし、この方法では、すべてのユーザーに対してアクセスできる説明を提供するのが難しいため(つまり、多くの場合、非表示の支援技術に対する説明のみを提供することになります)、この方法は、できるだけ純粋にプレゼンテーション用の背景に限定することをお勧めします。

+
+
+ + diff --git a/publishing/ja/fxl/index.html b/publishing/ja/fxl/index.html new file mode 100644 index 00000000..a2e8edfd --- /dev/null +++ b/publishing/ja/fxl/index.html @@ -0,0 +1,22 @@ + + + + + 固定レイアウト(Fixed Layout) + + + + + + + +
+
+ + diff --git a/publishing/ja/fxl/orientation.html b/publishing/ja/fxl/orientation.html new file mode 100644 index 00000000..b2e4deaf --- /dev/null +++ b/publishing/ja/fxl/orientation.html @@ -0,0 +1,65 @@ + + + + + 画面の向き(Orientation) + + + + + + +
+
+

要約

+ +

固定レイアウトページのレンダリングを単一の画面の向きに制限しないでください。

+
+ +
+

テクニック

+ + +
+ +
+

よくある質問

+ +
+
+rendition:orientationプロパティは設定しなければなりませんか?
+
+

いいえ。デフォルトの設定では、コンテンツの表示方向は単一の方向に制限されません。パッケージドキュメントでプロパティを明示的にautoに設定できますが、デフォルトの設定と変わりません。

+
+
+
+ +
+

解説

+ +

EPUB3では、コンテンツ製作者はrendition:orientationプロパティを使用して、固定レイアウトページを単一の画面方向(縦または横)に固定できます。しかし、単一の方向を強制すると、デバイスを回転できないユーザーはコンテンツを読めなくなる問題が生じます。

+ +

たとえば、身体障害や運動障害のあるユーザーは、デバイスの向きを常に変更できるとは限りません。ユーザーがデバイスを取り付けているマウントを調整できない場合や、サポートなしでは調整できない場合もあります。

+ +

デフォルトでは、EPUB3固定レイアウトページは方向の制約を受けません。ロックは、コンテンツ製作者がrendition:orientationプロパティの値をportraitまたはlandscapeに明示的に設定した場合にのみ発生します。したがって、このWCAGレベルAA違反の簡単な解決策は、このプロパティをグローバルにも特定のページにも設定しないことです。

+
+ +
+

関連リンク

+ + +
+
+ + diff --git a/publishing/ja/fxl/overview.html b/publishing/ja/fxl/overview.html new file mode 100644 index 00000000..bd9b5ee8 --- /dev/null +++ b/publishing/ja/fxl/overview.html @@ -0,0 +1,144 @@ + + + + + 概要 + + + + + + +
+
+

レイアウト

+

固定レイアウトの出版物は、各ページのサイズ(高さと幅)が固定されている出版物です。これらのページのコンテンツはピクセル単位でレイアウトされ、要素にはレンダリングされる固定座標があります。

+

固定レイアウトは、一般的に画像を使用して作成されますが、CSSによる絶対位置指定を使用してHTMLでも作成できます。固定レイアウトは、コミック、マンガ、子供向けの絵本、料理本、教科書の作成によく使用されますが、ピクセル単位の正確なレイアウトを再現しようとするあらゆる書籍で使用されています。

+

EPUBでは、固定レイアウトを作成するための、主に二つのアプローチがサポートされています。

+
    +
  1. +HTMLベースのレイアウト- HTMLページに高さと幅を設定し、コンテンツをその領域内に配置します。
  2. +
  3. +SVGベースのレイアウト- コンテンツの作成に画像形式(SVG、JPEG、PNGなど)を使用します。
  4. +
+

場合によっては、これらのアプローチが混在します。たとえば、HTMLまたはSVGドキュメントを使用して画像形式を表示すると、代替テキストや拡張説明も提供できます。

+
+

注記

+

HTMLおよびSVG固定レイアウトの代替として、EPUBのspineに直接画像を組み込む方法があります。このアプローチのサポートとアクセシビリティは限定されているので、このトピックは「spine内の画像」ページで最小限の説明のみを行っています。

+
+
+
+

製作

+
+

パッケージメタデータ

+

主に固定レイアウトでできている出版物と、全体のうちの数ページのみが固定レイアウトである出版物との唯一の違いは、パッケージドキュメントのメタデータにあります。

+

出版物が完全に、または大部分が固定レイアウトページで構成されている場合、 rendition:layoutプロパティのグローバル宣言が一度だけ必要です。

+
<metadata>
+   <meta property="rendition:layout">pre-paginated</meta>
+   …
+</metadata>
+

リフロー型のドキュメントがある場合は、そのドキュメントのspine項目参照でrendition:layout-reflowableプロパティを使用して上書きできます。

+
<spine>
+   …
+   <itemref ref="p211"/>
+   <itemref ref="index" property="rendition:layout-reflowable"/>
+</spine>
+

固定レイアウトを使用するページが少数の場合は、前述のプロセスを単純に逆にします。リフロー型の出版物ではグローバルにrendition:layoutプロパティを指定する必要はありませんが(EPUBではこれがデフォルトです)、次のように追加できます。

+
<metadata>
+   <meta property="rendition:layout">reflowable</meta>
+   …
+</metadata>
+

固定レイアウトページは、関連するspine項目参照のrendition:layout-pre-paginated値を使用してこの設定を上書きします。

+
<spine>
+   …
+   <itemref ref="c01"/>
+   <itemref ref="plate-01" property="rendition:layout-pre-paginated"/>
+   <itemref ref="plate-02" property="rendition:layout-pre-paginated"/>
+   <itemref ref="c02"/>
+   …
+</spine>
+
+
+

ページサイズ

+

パッケージメタデータ宣言は、どのページを固定レイアウトとしてレンダリングするかをリーディングシステムに伝えるだけです。リーディングシステムがページを適切なサイズの領域にレンダリングできるように、ページのサイズは指定する必要があります。

+

固定レイアウトのXHTMLとSVGのページサイズは、それぞれのフォーマットのマークアップ機能に依存するので異なります。

+

HTMLレイアウトの場合、ページの高さと幅は、HTMLヘッダーのviewport宣言を使用してピクセル単位で指定します。

+
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
+   <head>
+      <title>Page 1</title>
+      <meta name="viewport" content="height=1200,width=800"/>
+      …
+   </head>
+   …
+</html>
+

SVGレイアウトの場合、ページの高さと幅はviewBox属性を使用してピクセル単位で指定します。

+
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 800 1200">
+   …
+</svg>
+
+
+
+

表示メタデータ

+

EPUB3には、固定レイアウトページのレイアウトと表示を制御するための、次のメタデータプロパティがあります。

+
+
rendition:orientation
+
+

rendition:orientationプロパティを使って、固定レイアウトページを表示するための画面の優先方向を、コンテンツ製作者が指定できます。

+

値は、 portraitlandscape 、またはauto(優先なし)のいずれかになります。

+

このプロパティは、 metaタグを使用してすべてのページに対してグローバルに宣言できます。

+
<meta property="rendition:orientation">landscape</meta>
+

または、properties属性を使用して、spineの特定のページに設定できます。

+
<itemref idref="pg22" <strong>properties="rendition:orientation-portrait"</strong>
+
+
rendition:spread
+
+

rendition:spreadプロパティを使って、固定レイアウトのページを合成された見開き(つまり、隣り合う2ページにまたがったレイアウト)で表示する箇所を、コンテンツ製作者が指定できます。

+

値はlandscape(デバイスが横向きに保持されている場合のみ)、 both(デバイスが横向きまたは縦向きのいずれかの場合)、 auto(優先なし)、 またはnoneのいずれかになります。

+

このプロパティは、 metaタグを使用してすべてのページに対してグローバルに宣言できます。

+
<meta property="rendition:spread">landscape</meta>
+

または、properties属性を使用して、spineの特定のページに設定できます。

+
<itemref idref="pg124" <strong>properties="rendition:spread-both"</strong>/>
+
+
rendition:page-spread-left, -right または -center
+
+

rendition:page-spread-*プロパティを使って、固定レイアウトページを2ページの見開きのどのスロットに表示するかを、コンテンツ製作者が指定できます。

+

-rightや-leftプロパティと異なり、 page-spread-centerプロパティでは、見開きページの中央の単一のスロットにページを表示します。

+

page-spreadプロパティは、 properties属性を使用して、spine内の特定のページに対してのみ設定できます。

+
<itemref idref="pg2" <strong>properties="rendition:page-spread-left"</strong>/>
+<itemref idref="pg3" <strong>properties="rendition:page-spread-right"</strong>/>
+
+
+
+
+

アクセシビリティ

+

固定レイアウトの出版物には、次のような、アクセシビリティに関するいくつかの課題があります。

+ +

達成できるアクセシビリティの程度は、使用されるレイアウトの種類とコンテンツの複雑さの組み合わせに大きく依存します。たとえば、複雑な教科書を作成するよりも、単純な児童書をアクセシビリティ対応にする方が簡単でしょう。多くの場合、固定レイアウトのコンテンツは、代替のシリアライズが提供された場合にのみアクセシビリティ対応になります。

+
+

注記

+

WCAG 2.1では、レベルAA適合のための新しいリフロー型の達成基準が導入されていますが、ほとんどの固定レイアウトの出版物ではその標準に準拠するのは困難です。

+
+

ナレッジベースのこのセクションでは、固定レイアウトの出版物のアクセシビリティを向上させる手法について説明しますが、出版物を広くアクセシブルにする必要がある場合は、通常、リフロー型のコンテンツを作成することをお勧めします。

+
+
+

関連リンク

+
    +
  1. EPUB 3 —固定レイアウト +
  2. +
  3. EPUB 3 —パッケージレンダリング語彙(package rendering vocabulary) +
  4. +
+
+
+ + diff --git a/publishing/ja/fxl/spreads.html b/publishing/ja/fxl/spreads.html new file mode 100644 index 00000000..4aa25355 --- /dev/null +++ b/publishing/ja/fxl/spreads.html @@ -0,0 +1,60 @@ + + + + + 見開きページ + + + + + + +
+
+

要約

+

一つの画像が2ページにわたって表示される場合は、最初のページに代替テキストと説明を入れて、2ページ目には、その説明への参照を設けます。

+
+
+

解説

+

固定レイアウト、特に印刷物を複製するレイアウトでは、例えば地図のような、2ページにまたがる画像は一般的です。隣り合わせのページで合成された見開き(synthetic spreads)を使用すると、コンテンツ製作者は両方の画像を同時にリーディングシステムの画面に配置できます。

+

分割された画像を効果的に説明するにはどうしたら良いかが問われます。それぞれ半分ずつを別々に説明しますか。画像の半分だけでは意味をなさない場合はどうしますか。どちらか片方だけを説明しますか。そうであれば、もう片方の半分はどうしますか。

+

一般的なWebテクニックでは、一つのページに関連する画像のグループがある場合、最初の画像のみを説明して、他の画像は装飾として扱うことで、ユーザーが重複した説明に遭遇しないようにします。

+
<figure aria-details="map-desc">
+   <figcaption>…</figcaption>
+   <img src="map-pt1.jpeg" alt="World Map" />
+   <img src="map-pt2.jpeg" alt="" />
+</figure>
+

ただし、この手法は出版物ではうまく機能しません。なぜなら、見開きページ内の関連する画像が別々のページにあるためです(つまり、一つの画像のみが説明されている場合、支援技術のユーザーには空のページのように見えます)。

+

この問題の解決策は、最初の画像に説明を提供し、代替テキストを使用してユーザーに画像が分割されていることを案内することです。

+

たとえば、見開きの最初の画像の代替テキストに、画像がいくつに分割されているかの合計数を入れます。

+
<body>
+<img src="map-pt1.jpeg" alt="World Map (Page 1 of 2)" aria-details="map-desc" />
+…
+</body>
+

2ページ目には、それが見開きの2ページ目であることを示し、説明については最初のページを参照します。

+
<body>
+<img src="map-pt2.jpeg" alt="World Map (Page 2 of 2). Refer to previous page for description." />
+…
+</body>
+

この方法は、テキストを直線的にたどるユーザーにとっては、既に説明を見ているために多少の冗長性がありますが、特定のページにジャンプするなどして、最初に見開きの2ページ目を開いたユーザーがコンテキストを失わないように保障できます。

+
+

注記

+

拡張説明を追加する方法の詳細については、固定レイアウト画像のナレッジベースページを参照してください。

+
+
+
+

関連リンク

+ +
+
+ + diff --git a/publishing/ja/fxl/svg.html b/publishing/ja/fxl/svg.html new file mode 100644 index 00000000..1e7aa492 --- /dev/null +++ b/publishing/ja/fxl/svg.html @@ -0,0 +1,50 @@ + + + + + SVG(スケーラブル ベクター グラフィックス) + + + + + + +
+
+

概要

+

固定レイアウトの出版物は、SVGを使用してテキストと画像を組み合わせて作成できます。各画像には固定の高さと幅が割り当てられ、コンテンツはこのキャンバス領域内に配置されます。

+

固定レイアウトにSVGを使用する利点は、SVGでは他の画像形式と違ってテキストコンテンツを画像データとして書き込むのではなく(訳注:テキスト情報のまま)埋め込める点です。このようにマークアップされたテキストは支援技術で読み取れます。SVGでは、画像の代替テキストや拡張説明を組み込む方法も提供されています。

+

弱視の読者にとっては、画像の拡大の際に、ピクセル画素化されて見にくくなることなく、画像の大きさの変更ができる(スケーラブル)というのも、SVG画像の利点です。

+
+
+

EPUB

+

SVGは固定レイアウトコンテンツに最適ですが、WebブラウザーはSVGを出版物の一部としてレンダリングするように最適化されていません。たとえば、サイズや向きの制御は制限されます。

+

出版におけるこの問題を解決するために、EPUB 3では、リーディングシステムが各固定レイアウトページに適切な表示領域と特性を作成できるように支援するメタデータが導入されました。

+

EPUB出版物は、固定レイアウトのSVGページで完全に構成することも、リフロー型の出版物内にいくつかの固定レイアウトページを散在させることもできます。

+

SVGの固定レイアウトページや、XHTMLの固定レイアウトページを混在させたり、また、画像を直接EPUBの読み取り順序に並べた固定レイアウトを混在させたりもできます。

+
+

注記

+

固定レイアウトの出版物の、作成方法の詳細については、固定レイアウトの概要ページをご覧ください。

+
+
+
+

アクセシビリティ

+

リフロー型の出版物をアクセシビリティ対応にするのと同じ手法が、アクセシビリティを最大限に高めた固定レイアウトのSVGページの作成にも使用できます。主な手法には次のようなものがあります。

+ +

SVGをスケーラブルでない画像形式(JPEG、GIF、PNG など)のラッパーとしてのみ使用する場合、スケーラブルである利点は失われます。これらの画像形式がスケーラブルでない点はSVGでは改善されません。スケーラブルでない画像形式を使うならば、画像を記述する方法がより多く提供されているHTMLラッパーの方が適しているでしょう。

+

SVGが有するアクセシビリティ機能にもかかわらず、SVGコンテンツは画像ベースという制約により、完全にアクセシブルなSVGページは作成できないことがあります。EPUB3リーディングシステムでは固定レイアウト出版物の外観を変更する際に制限があるため、読みやすさも損なわれます。

+
+
+ + diff --git a/publishing/ja/fxl/wcag.html b/publishing/ja/fxl/wcag.html new file mode 100644 index 00000000..d00c50f2 --- /dev/null +++ b/publishing/ja/fxl/wcag.html @@ -0,0 +1,103 @@ + + + + + WCAG 適合 + + + + + + + +
+
+

WCAG 2.0に準拠した固定レイアウトのEPUB出版物を作成することはできるかもしれませんが、2.1で追加されたリフロー要件により、最新バージョンの規格への準拠はさらに困難です。

+

次の表は、固定レイアウトを使用すると達成できないかもしれない一般的なレベルAおよびAAの達成基準の一部を示しています。

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
達成基準WCAGバージョン問題点
1.1.1 非テキストコンテンツ(A) +2.0+ +

コミックやマンガなどの画像ベースの固定レイアウトでは、代替テキストや説明では画像を通じて伝えられるストーリーのすべてを表現できないため、通常この要件を満たしません。多くの場合、別のシリアライズされた表現が必要です。

+
1.3.1 情報及び関係性(A)2.0+ +

spandivなどの汎用要素は、よくページ内でテキストを静的にスタイル設定および配置するために使用され、ユーザーがコンテンツをナビゲートするための構造的な補助がほとんどありません(例:見出しや表はありません)。

+
1.3.2 意味のある順序(A) +2.0+ +

コンテンツ要素は視覚的に必要な場所に配置できるため、マークアップ内で論理的な順序が維持されるように常に注意が払われるわけではありません。支援技術を通じてそのような図書を読み取ると、情報や会話が順序どおりにレンダリングされません。

+

コンテンツが2ページに渡ってレイアウトされている場合に、視覚的に読み取る読者が論理的な読み順ではページ間を行ったり来たりする必要があることがあります。このようなタイプの順序は、マークアップでは表現できません。

+
1.3.4 表示の向き(AA) +2.0+ +

固定レイアウトのページは通常、特定の方向でレンダリングされるように設計されており、コンテンツ製作者は、リーディングシステムがその方向でのみコンテンツをレンダリングするように指定できます。

+

しかし、WCAG 2.0に準拠するには、コンテンツの向きは読みやすさに影響を与えてはなりません。

+
1.4.3 コントラスト(最低限レベル) (AA) +2.0+ +

固定レイアウトで画像にテキストを重ねると、コントラストが不十分になり、読者がテキストを認識しにくくなる可能性があります。

+
1.4.5 文字画像(AA) +2.0+ +

文字画像は、ユーザーがフォントを変更したり、固定レイアウトページのデザインを変更したりするのを防ぐためによく使用されます。

+
1.4.10 リフロー(AA) +2.1+ +

固定レイアウトページではサイズが固定されているので、この達成基準の拡大要件を満たすには、通常、ユーザーはコンテンツを読むために両方の軸(訳注:水平方向、垂直方向)をスクロールしなければならなくなります。

+
1.4.12 テキストの間隔(AA) +2.1+ +

ユーザーが外観を変更できる場合でも、(訳注:文字間、行間などの)スペースを追加すると、テキストがコンテナ要素やページの境界を超えてしまいます。この場合、はみ出したテキストはしばしば見切れてしまいます。

+
+
+
+ + diff --git a/publishing/ja/text-to-speech/index.html b/publishing/ja/text-to-speech/index.html new file mode 100644 index 00000000..92d009de --- /dev/null +++ b/publishing/ja/text-to-speech/index.html @@ -0,0 +1,22 @@ + + + + + テキスト読み上げ(Text-to-Speech / TTS) + + + + + + + +
+
+ + diff --git a/publishing/ja/text-to-speech/overview.html b/publishing/ja/text-to-speech/overview.html new file mode 100644 index 00000000..82431ffd --- /dev/null +++ b/publishing/ja/text-to-speech/overview.html @@ -0,0 +1,84 @@ + + + + + 概要 + + + + + + + +
+
+

出版物を合成音声で読み上げる機能は、人間によるナレーションも提供されるかどうかに関係なく、多くのユーザーが頼りにする重要なアクセシビリティ機能です(たとえば、多くのユーザーは、TTSエンジンによる高速再生を好みます)。

+ +

リーディングシステムに音声読み上げ(TTS)機能が含まれているか、または支援技術による音声読み上げが可能であれば、基本的な再生は可能ですが、使用されている語彙が複雑だと、通常、強化されていない合成音声エンジンでは発音を間違ってしまう場合があります。

+ +

コンテンツ製作者によってTTS再生の質を向上できる三つの技術があります。

+ +
+
+ PLS辞書(lexicons) +
+
+

発音辞書仕様(Pronunciation Lexicon Specification)で、国際的に使用できる発音をXML形式で定義できます。定義されたエントリーに一致する単語が文章内に見つかると、エンジンのデフォルトのレンダリングの代わりに定義された発音が使用されます。この辞書で、文脈によって意味が変化しない単語の発音を簡単に定義できます。

+
+ +
+ SSMLマークアップ +
+
+

合成音声マークアップ言語(Synthetic Speech Markup Language / SSML)を使用して、発音をマークアップに直接埋め込めます。要素にSSML属性が検出されると、エンジンのデフォルトのレンダリングやPLSエントリーの代わりに提供された発音が使用されます。SSMLですべての発音を定義することもできますが、PLS辞書の補足として使用する方が適しています(異音語や曖昧な数値形式を明確にするなど)。

+
+ +
+ CSS Speech(音声)プロパティ +
+
+

CSS speechモジュールには、音声再生を制御できるさまざまなプロパティが含まれています。単語や数字を一文字ずつ読み上げる制御から音声キューや一時停止の挿入まで、これらのプロパティを使用すると、従来の発音の強化を超えて、再生を制御できます。

+
+
+ +

ただし、これらの技術はいずれもリーディングシステムではサポートされていません。W3C Web Accessibility Initiative(WAI)には現在、発音タスク フォース(Pronounciation task force)があり、これらの技術のサポートについての問題を検討しています。発音タスクフォースの作業から新しい方向性が出てくれば、このページは更新されます。

+
+ +
+

サンプル

+ +

拡張TTS機能を実装した出版物がEPUBサンプル プロジェクトにあります:

+ + +
+ +
+

関連リンク

+
    +
  1. EPUB 3 TTS拡張機能 —発音辞書(Pronunciation lexicons) +
  2. +
  3. 発音辞書仕様(Pronunciation Lexicon Specification)(PLS)バージョン1.0 +
  4. +
  5. EPUB 3 TTS拡張機能 — SSML属性 +
  6. +
  7. 音声合成マークアップ言語(SSML)バージョン1.1
  8. +
  9. EPUB 3 TTS拡張機能 — CSS speech +
  10. +
  11. +CSS Speech モジュール( EPUB 3で参照される作業草案)
  12. +
  13. +IPAのコンピュータコーディング:SAMPAの拡張案(X-SAMPA)
  14. +
  15. 国際音声記号(IPA)のリプロダクション(2005年改訂版)
  16. +
+
+
+ + diff --git a/publishing/ja/text-to-speech/pls.html b/publishing/ja/text-to-speech/pls.html new file mode 100644 index 00000000..baf07ce0 --- /dev/null +++ b/publishing/ja/text-to-speech/pls.html @@ -0,0 +1,235 @@ + + + + + 発音辞書(Pronunciation Lexicons) + + + + + + + +
+
+

注意

+

現時点では、PLS辞書はリーディングシステムでサポートされていません。

+
+ +
+

要約

+ +

発音辞書で、テキストの音声読み上げを改善できます。

+
+ +
+

+ +
+
+

例1 — 最小の辞書ファイル

+
+ +
<lexicon
+  version="1.0"
+  alphabet="x-sampa"
+  xml:lang="en"
+  xmlns="http://www.w3.org/2005/01/pronunciation-lexicon">
+   <lexeme>
+	  <grapheme>acetaminophen</grapheme>
+	  <phoneme>@"sit@'mIn@f@n</phoneme>
+   </lexeme>
+</lexicon>
+
+ +
+
+

例2 — 地域による綴りの違いへの対応

+
+ +
<lexeme>
+   <grapheme>defence</grapheme>
+   <grapheme>defense</grapheme>
+   <phoneme>dI'fEns</phoneme>
+</lexeme>
+
+ +
+
+

例3 — 代替の綴りへの対応

+
+ +
<lexeme>
+   <grapheme>vitæ</grapheme>
+   <grapheme>vitae</grapheme>
+   <phoneme>vitaI</phoneme>
+</lexeme>
+
+ +
+
+

例4 — 複数の発音表記の組み込み

+
+ +
<lexeme>
+   <grapheme>defence</grapheme>
+   <grapheme>defense</grapheme>
+   <phoneme>dI'fEns</phoneme>
+   <phoneme alphabet="ipa">dɪˈfɛns</phoneme>
+</lexeme>
+
+ +
+
+

例5 — ある用語の別の用語への置き換え

+
+ +
<lexeme>
+   <grapheme>50-50</grapheme>
+   <phoneme>fifty fifty</phoneme>
+</lexeme>
+
+ +
+
+

例6 — マニフェストにPLS辞書を追加する

+
+ +
<item
+	  id="pls"
+	  href="#EPUB/lexicon.pls"
+	  media-type="application/pls+xml"/>
+
+ +
+
+

例7 — PLS辞書とコンテンツ文書とのリンク

+
+ +
<html … xml:lang="en">
+   <head>
+	  …
+	  <link
+		 rel="pronunciation"
+		 href="#lex/en.pls"
+		 type="application/pls+xml"
+		 hreflang="en" />
+	  <link
+		 rel="pronunciation"
+		 href="#lex/fr.pls"
+		 type="application/pls+xml"
+		 hreflang="fr" />
+	  …
+   </head>
+   …
+</html>
+
+
+ +
+

解説

+ +

PLS辞書は、対応するリーディングシステムでのテキスト読み上げ (TTS) 再生レンダリングを制御できます。辞書ファイル(lexicon file)は辞書や検索ガイドのようなもので、一致する単語が見つかると、デフォルトのレンダリングの代わりに定義されている発音が使用されます。辞書で単語を定義すると、リーディングシステムのTTSエンジンによる推測に基づいたな読み上げではなく、意図した読み上げをユーザーに提供できます。

+ +

各PLS辞書は、ルートlexicon要素を持つXMLファイルです。辞書は1つ以上のlexemeエントリーで構成されます。各エントリーは、 grapheme要素で単語を定義し、 phoneme要素で発音を定義します。(例1を参照してください。)

+ +

alias要素は、ある単語を別の単語に置き換えるためにも使用できます(例5を参照)。

+ +

辞書の言語と使用する発音記号は、両方ともルートlexicon要素で定義します。

+ +

出版物にとって重要で、TTSエンジンが誤って発音する可能性のある複雑な単語については、PLSエントリーを作成する必要があります。リストには、固有名詞、名詞、技術用語、科学用語、法律用語、複雑な合成語や、その他の語が含まれます。同綴異音異義語のデフォルトのレンダリングはPLS辞書で定義し、定義した読みと違うものはSSMLタグで定義します。

+ +

PLS辞書は、EPUBコンテナーに含めるだけでは有効になりません。各コンテンツドキュメントから該当する辞書を参照してコンテンツに適用します。また、 参照先のPLSファイルの言語にhreflang属性を設定する必要があります(例6を参照)。

+ +

埋め込まれた外国語を処理するために、コンテンツ ドキュメントに複数の辞書を添付できます。(例7を参照)。

+ +

単一のPLS辞書ファイル内でのローカリゼーションは不可能ですが、地域ごとに異なった読み上げを行うために複数の辞書を添付できます。(詳細については、以下のよくある質問を参照してください。)

+
+ +
+

よくある質問

+ +
+
発音を記述するには IPA、 X-SAMPA、またはそれ以外のどの発音記号を使用すべきでしょうか?
+
+

IPAはおそらく最も広く認識されている発音記号ですが、既存の合成音声エンジンでも完全にサポートされているわけではありません。たとえば、一部のエンジンは独自の発音記号のみをサポートしています。X-SAMPAはASCIIベースですが、IPAはUnicode文字を使用するため、入力するにはほとんどのキーボード レイアウトを変更する必要があり、X-SAMPAよりも開発者にとって使いにくいです。現時点では、内部ワークフローが決定要因となるはずです。最終的な答えは、リーディングシステムでどのエンジンが使用されているかによって異なります。

+ +

ある発音記号を他の発音記号に変換することはできるので、勝者と敗者が明確に分かれた場合でも、どちらのアルファベットでの作業も失われることはありません。

+
+ +
辞書では大文字と小文字が区別されますか?
+
+

大文字と小文字を区別した発音を定義できる必要があることは明らかですが、PLS 辞書がどのように処理されるかは明らかではありません。仕様自体には、グラフィムの大文字と小文字の区別については何も記載されておらず、参考となる付録で定義されている大文字と小文字を区別する処理の要件のみが記載されています。PLS 辞書をサポートするリーディングシステムが登場するまでは、回答は推測の域を出ませんが、大文字と小文字の区別は重要な役割を果たしているため、区別があると想定されます。

+ +

出版物では、特定の用語が小文字とタイトルケース(訳者注:単語の先頭のみ大文字)の両方で表示され、同じ発音であることがあります。この場合、両方にgrapheme要素を追加します。

+ +
<lexeme>
+   <grapheme>acetaminophen</grapheme>
+   <grapheme>Acetaminophen</grapheme>
+   <phoneme>@"sit@'mIn@f@n</phoneme>
+</lexeme>
+ +

大文字と小文字の競合が発生した場合は、一般的ではない方の発音をSSMLで定義します。たとえば、アラバマ州モービル(Mobile)における加齢に伴う健康問題を調査する文書では、mobile とMobileの両方の綴りが人間の移動性(モバイル)を指している可能性があります。Mobileの発音ˈmoʊbaɪlと定義すると、都市名が誤って発音されます(逆の場合も同様です)。

+
+ +
言語を混ぜることに危険はありますか?
+
+

はい、レンダリングエンジンが指定された言語の音声化をサポートしていない場合、ユーザーにエラーが提示されたり、テキストが読み飛ばされたりするかもしれません。このような状況でのエラー処理は保証されません。言語固有の辞書は通常読み込まれません。

+
+ +
ローカリゼーションを追加できますか?
+
+

単一のPLSファイル内ではできません。phoneme要素にxml:lang属性は付与できません。語幹言語コードphonemeを指定するコンテンツドキュメントに複数のローカライズされた辞書を添付して、ユーザーのローカライズ設定で適用する辞書を選択できます(たとえば、コンテンツドキュメントでenを指定し、辞書でen-USen-GBを指定できます)。

+ +

ローカリゼーションの指定によりユーザーを排除しないようにしてください。リーディングシステムにローカリゼーションを処理できる音声が組み込まれていない場合には、辞書は読み込まれません。

+ +

すべてのリーディングシステム向けに、地域に関係ない言語の処理ができる一つの辞書を定義するのが良いでしょう。たとえば、出版物が米国英語で書かれている場合は、標準の発音辞書にデフォルトのenコードを使用し、対象地域のみにロケールを指定するのが良いでしょう。

+ +
<html … xml:lang="en">
+   <head>
+	  …
+	  <link
+		 rel="pronunciation"
+		 href="#lex/en.pls"
+		 type="application/pls+xml"
+		 hreflang="en" />
+	  <link
+		 rel="pronunciation"
+		 href="#lex/en-GB.pls"
+		 type="application/pls+xml"
+		 hreflang="en-GB" />
+	  …
+   </head>
+   …
+</html>
+

こうすることで、英語のリーディングシステムを持つユーザーは、少なくとも正しい米国の発音が聞けます。

+
+ +
PLS辞書とSSMLのどちらを使用すればよいでしょうか?
+
+

EPUB 3に両技術が盛り込まれたのは、どちらかを選択しなければならないのではなく、これらの技術で互いを補完するためです。PLS辞書を使用すると、単語を一度定義すれば、その単語が文章中に現れるたびにTTSエンジンがその単語を置き換えます。一方、 SSMLは、辞書では不可能なきめ細かい制御ができますが、その代わり、置き換える必要がある用語の各インスタンスにタグを付ける必要があります。

+
+
+
+ +
+

関連リンク

+ +
+
+ + diff --git a/publishing/ja/text-to-speech/speech.html b/publishing/ja/text-to-speech/speech.html new file mode 100644 index 00000000..742798ed --- /dev/null +++ b/publishing/ja/text-to-speech/speech.html @@ -0,0 +1,302 @@ + + + + + CSS Speech(音声) + + + + + + + +
+
+

注意

+

現時点では、CSS Speechプロパティはリーディングシステムでサポートされていません。

+
+ +
+

要約

+ +

CSS Speechプロパティにより、音声によるレンダリングを改善できます。

+
+ +
+

+ +
+
+

例1 — 文字を一文字ずつ読み上げる

+
+ +
<abbr class="spell">IBM</abbr>
+<span class="spell">IOU</span>
+
+/* css */
+
+.spell {
+   speak-as: spell-out
+}
+
+ +
+
+

例2 — 数字を一文字ずつ読み上げる

+
+ +
<span class="digits">911</span>
+<span class="digits">416 555-0123</span>
+<span class="digits">90210</span>
+
+/* css */
+
+.digits {
+   speak-as: digits
+}
+
+ +
+
+

例3 — 句読点を読み上げる

+
+ +
<p>
+   Example one is correctly punctuated as follows:
+   <span class="punctuate answer">The Franks, 
+   a warlike people of Germany, gave their 
+   name to France.</span>
+</p>
+
+/* css */
+
+.punctuate {
+   speak-as: literal-punctuation
+}
+
+ +
+
+

例4 — 句読点を無視する

+
+ +
<p>The telegram from Dr. King to President Kennedy
+   read as follows:</p>
+<blockquote>
+   <pre class="silent">
+   HOWEVER I AM CONVINCED THAT UNLESS SOME STEPS ARE TAKEN BY
+   THE FEDERAL GOVERMENT TO RESTORE A SENSE OF CONFIDENCE IN
+   THE PROTECTION OF LIFE, LIMB AND PROPERTY MY PLEAS SHALL FALL
+   ON DEAF EARS AND WE SHALL SEE THE WORST RACIAL HOLOCAUST THIS
+   NATION HAS EVER SEEN AFTER TODAYS TRAGEDY, INVESTIGATION WILL
+   NOT SUFFICE.
+   </pre>
+   <cite><a 
+	  href="http://www.jfklibrary.org/Asset-Viewer/-crU2bLgN0CcGkys8dkuHg.aspx"
+	  >September 15, 1963 Telegram</a></cite>
+</blockquote>
+
+/* css */
+
+.silent {
+   speak-as: no-punctuation
+}
+
+ +
+
+

例5 — 見出しに一時停止、合図(キュー)、休符を追加する

+
+ +
h1 {
+   pause: 50ms 25ms;
+   cue: url('audio/ping.mp3') none;
+   rest: 10ms 0ms
+}
+
+ +
+
+

例6 — 声の性別を切り替える

+
+ +
.male {
+   voice-family: male
+}
+
+.female {
+   voice-family: female
+}
+
+/* html */
+
+<p class="female">
+   Alice: But I don't want to go among mad people.
+</p>
+
+<p class="male">
+   The Cat: Oh, you can't help that.
+   We're all mad here. I'm mad. You're mad.
+</p>
+
+ +
+
+

例7 — 同性の異なる声を使う

+
+ +
.huck {
+   voice-family: child male 1
+}
+
+.tom {
+   voice-family: child male 2
+}
+
+/* html */
+
+<p class="tom">
+   "Well—I—I—well, that ought to settle it, of course; 
+   but I can't somehow seem to understand it no way.  
+   Looky here, warn't you ever murdered AT ALL?"
+</p>
+
+<p class="huck">
+   "No. I warn't ever murdered at all—I played it on 
+   them. You come in here and feel of me if you don't 
+   believe me."
+</p>
+
+
+ +
+

解説

+ +

CSS Speechモジュールにより、テキスト読み上げ (TTS) の拡張機能を追加できます。PLS辞書SSMLマークアップとは異なり、Speechモジュールのプロパティが重点をおいているのは単語の正しい発音の定義ではありません。

+ +

CSS SpeechモジュールでTTS再生を強化するために使われる主要なプロパティは、 speak-asです。このプロパティで、TTSエンジンが文字列内を一文字ずつ読み上げるようにできます。各文字の読み上げはspell-outに設定し、数字はdigitに設定します(例1および例2を参照)。また、このプロパティを使って、TTSエンジンによる信頼性の低い頭字語の読み上げをオーバーライドできます。

+ +

speak-asプロパティでは、補完的な値であるliteral-punctuationno-punctuationも使用できます。TTSエンジンが句読点を音声化するかどうかを制御できます。

+ +

このモジュールには、speakプロパティも含まれており、要素が表示されているかどうかに関係なく、コンテンツのTTSレンダリングを制御できます。none値を設定すると要素のレンダリングが無効になり、 normal値を設定すると有効になります。

+ +

次のプロパティは、TTS読み上げにおける非韻律的な側面に重点を置いています。

+ +
+
+ pause +
+
+

pauseプロパティは、適用先の要素の前後に付け加える一時停止の長さを制御します。一時停止は通常、段落間や新しいセクションの開始時など、主要な構造間の遷移を識別するために使用されます。また、TTSエンジンは句読点があると、ナレーションの流れの中で一時停止をします。

+ +

pauseプロパティの値は、一時停止の長さを示す時間値です。単一の値のみが指定されている場合:

+ +
pause: 50ms
+ +

この時間は、関連付けられている要素の前と後の両方に適用されます。

+ +

時間値を2つ指定すると、前後の一時停止時間を個別に制御できます。

+ +
pause: 50ms 0ms
+ +

指定された長さの一時停止は、音声cuerestの関連する要素の開始前と、restcueの要素の終了後に入ります。

+
+ +
+ cue +
+
+

cueプロパティは、音声によって要素を識別するために使用できます。たとえば、新しい見出しのある個所は、一時停止だけでは分かりにくいですが、キューを使って音声を鳴らすことで分かりやすくできます。

+ +

cueプロパティでは、値が1つだけ指定されている場合、関連付けられているオーディオクリップが見出しの前と後の両方でレンダリングされるので注意してください。

+ +
cue: url('audio/ping.mp3');
+ +

通常のユーザーが期待するように開始を知らせるキューのみにするには、関連付けられた要素がレンダリングされた後のキューを無効にするためにnull値を使用します。

+ +
cue: url('audio/ping.mp3') null;
+ +

音声キューは、関連する要素の開始時にpauserestの間に入り、要素の終了時にrestcueの間に入ります。

+
+ +
+ rest +
+
+

restプロパティは、音声キューと関連要素のレンダリングの間とその前後に発生する一時停止を制御します。

+ +

restプロパティの値は、一時停止の長さを示す時間値です。単一の値のみが指定されている場合:

+ +
rest: 25ms
+ +

一時停止の時間は、関連付けられている要素の前と後の両方に適用されます。

+ +

時間値を2つ指定すると、前後の一時停止時間を個別に制御できます。

+ +
rest: 25ms 0ms
+ +

指定された休止時間は、関連する要素の開始時にpausecueの後に入り、要素の終了時にcuepauseの前に入ります。

+
+ +
+ voice-family +
+
+

voice-familyプロパティは、TTS再生に使用される音声の性別と種類を制御し、コンテンツ製作者がよりリアルなTTS再生(登場人物に合わせて性別を切り替えるなど)を作成できるようにします。

+ +

使用する音声の名前も指定できます。

+ +
voice-family: 'Dave';
+ +

実際には、EPUBはさまざまなデバイスで再生できるため、すべてのデバイスで利用可能な音声の名前を知っている場合にのみ活用できます。

+ +

代わりに、パターン「年齢?、性別、整数?」を使用して音声をリクエストする方が適切です(?のフィールドはオプションです)。

+ +
.king-lear {
+   voice-family: old male 1;
+}
+ +

年齢の値は、childyoungoldのいずれかで、性別はmalefemaleneutral。また、整数で音声の順序位置が指定できます。(一致する音声が複数ある場合)。

+
+
+
+ +
+

よくある質問

+ +
+
プロパティに-epub-プレフィックスを使用する必要はありますか?
+
+

いいえ。はじめは、仕様が安定する前にプロパティが導入されたため、プレフィックスを使用する必要がありました。現在は、プレフィックスのないバージョンも使用できます。

+
+ +
TTSエンジンに頭字語を一文字ずつ読み上げずに発音するように強制できますか?
+
+

Speechモジュールには、大文字の用語を単語として発音するようにTTSエンジンに伝える方法はありません。EPUBのような頭字語の場合は、辞書を使用するか、SSML発音属性を使って、TTSエンジンが一文字ずつ読み上げないようにする必要があります。

+
+ +
なぜ句読点の発音を制御する必要があるのですか?
+
+

ほとんどのTTSエンジンはコロンなどの重要な停止位置は音声で読み上げますが、通常は読みやすさを損なうため、文書内の全ての句読点を読み上げることはありません。しかし、文法の教科書やプログラミングガイドなどのように、ユーザーが文中のすべての句読点の聞き取りが必須な場合もあります(例3を参照)。

+

アクセシブルな技術では、precodeなどの要素内は、デフォルトですべての句読点も読み上げます。コンピューターコードではすべての句読点を読み上げるのが良いですが、フォーマット済みのテキストでは詳細なレンダリングは必要ありません。preのテキストブロックにno-punctuationを適用すると、句読点を読み上げないようにできます。

+
+
+
+ +
+

関連リンク

+ +
+
+ + diff --git a/publishing/ja/text-to-speech/ssml.html b/publishing/ja/text-to-speech/ssml.html new file mode 100644 index 00000000..acb7d4f9 --- /dev/null +++ b/publishing/ja/text-to-speech/ssml.html @@ -0,0 +1,165 @@ + + + + + SSML + + + + + + + +
+
+

注記

+

現時点では、リーディングシステムではEPUB SSML属性はサポートされていません。

+
+ +
+

要約

+ +

EPUB SSML属性により、テキストの音声読み上げを改善できます。

+
+ +
+

+ +
+
+

例1 — ドキュメントルートでSSML名前空間と発音記号を表記

+
+ +
<html …
+   xmlns:ssml="http://www.w3.org/2001/10/synthesis"
+   ssml:alphabet="x-sampa">
+   …
+</html>
+
+ +
+
+

例2 — 単語レベルでの発音記号と発音を表記

+

単一の文字は、文脈に応じて頭文字、方向、またはその他の短縮形になる可能性があるため、辞書で定義するのは適切ではありません。

+
+ +
<p>
+   … farther <span 
+   ssml:alphabet="ipa" ssml:ph="nɔrθ">N.</span>
+   another elevation begins …
+</p>
+
+ +
+
+

例3 — 同綴異音語の異なる発音の定義

+
+ +
<p>
+   The guitarist was playing a
+   <span ssml:ph="beIs">bass</span> that was shaped
+   like a <span ssml:ph="b&s">bass</span>.
+</p>
+
+ +
+
+

例4 — デフォルトのアルファベットがすでに設定されている場合に発音を定義する

+
+ +
<p>
+   The guitarist was playing a bass that was shaped
+   like a <span ssml:ph="b&s">bass</span>.
+</p>
+

PLS辞書には、デフォルトの発音を定義する次のエントリが含まれます。

+
<lexeme>
+   <grapheme>bass</grapheme>
+   <phoneme>beIs</phoneme>
+</lexeme>
+
+ +
+
+

例5 — 文脈に応じて異なる発音を定義する

+
+ +
<p>
+   You'll be an
+   <span ssml:ph="Ekstr@ lArdZ">XL</span>
+   by the end of Super Bowl 
+   <span ssml:ph="'fOrti">XL</span>
+   at the rate you're eating.
+</p>
+
+
+ +
+

解説

+ +

SSML(音声合成マークアップ言語)を使うと、コンテンツ製作者は、出版物のデフォルトの合成音声レンダリングを、マークアップレベルでさらに正確にすることができます。SSMLを十分に使用することで、TTSの読み上げで作品を聞く人は、レンダリングエンジンの推測に基づくものではなく、コンテンツ製作者が意図したとおりの文章を聞くことができます。

+ +

SSMLのphoneme要素は、マークアップレベルで発音を定義するためのペアの属性としてEPUB 3に実装されています。

+ + + +

(完全なSSML仕様のサポートはEPUB 3では利用できません。)

+ +

PLS辞書とは異なり、SSMLはマークアップレベルで発音を細かく制御できます。SSMLを使用すると、同綴異音語の発音をデフォルトから変更したり、複雑な単語や数字の発音を正しく指定したりできます。

+ +

SSML属性を使用するには、まずSSML名前空間を宣言する必要があります。宣言は通常、ルートhtml要素のドキュメントごとに一回行います(例1を参照)。

+ +

デフォルトの発音記号は通常はルートhtml要素に一回定義します。これは、単一のドキュメント内で発音記号を切り替える必要はほとんどないためです。ルートにssml:alphabet属性を追加すると、ssml:ph属性のすべてのインスタンスにスコープ内発音記号が定義されます。スコープ内発音記号なしでssml:ph属性に発音を定義するとエラーになり、レンダリングエラーが発生します(例1を参照)。

+ +

ssml:ph属性が検出されると、その値が要素のコンテンツの代わりにテキスト読み上げ(TTS)エンジンに渡され、最下位レベルのオーバーライドが提供されます。SSML属性の発音はPLS辞書エントリーよりも優先されるため、同綴異音語や規則の例外が適切に処理されます。

+ +

ssml:ph属性の値は、その属性が付けられた要素の子孫要素も含めてすべてのコンテンツを置き換えることに注意してください。段落内の一つの単語の発音を定義するために、この属性をpタグに付加しないでください。段落全体の代わりにその一つの単語だけが読み上げられてしまいます。発音の指定が必要な単語にマークアップが存在しない場合は、span要素の使用をお勧めします。

+ +

SSML属性はSVGまたはMathMLコンテンツでは有効ではありませんが、それらの文法に埋め込むことができるすべてのXHTMLコンテンツでは有効です。

+
+ +
+

よくある質問

+ +
+
発音を記述するにはIPAやX-SAMPAなどを使用すべきでしょうか?
+
+

IPAはおそらく最も広く認識されている発音記号ですが、既存の合成音声エンジンでも完全にサポートされているわけではありません。たとえば、一部のエンジンは独自の発音記号のみをサポートしています。また、X-SAMPAはASCIIベースですが、IPAはUnicode文字を使用するため、入力するにはほとんどのキーボード レイアウトを変更する必要があり、X-SAMPAよりも開発者にとって使いにくいです。現時点では、内部ワークフローが決定要因となるはずです。最終的な答えは、リーディングシステムでどのエンジンが使用されているかによって異なります。

+ +

一つの発音記号を他の発音記号に変換することは可能であるため、勝者と敗者が明確に分かれた場合でも、どちらの発音記号での作業も失われることはありません。

+
+ +
PLS辞書とSSMLのどちらを使用すればよいでしょうか?
+
+

EPUB 3にこれらの技術が盛り込まれたのは、どちらかを選択しなければならないということではなく、これらの技術が互いに補完し合うようにするためです。PLS辞書を使用すると、単語を一度定義すれば、その単語が文章中に現れるたびにTTSエンジンがその単語を置き換えます。一方、SSMLは、辞書では不可能なきめ細かい制御ができますが、その代償として、置き換える必要がある用語の各インスタンスにタグを付ける必要があります。

+ +

SSMLのみを使用することは可能ですが、製作時間の面でコストがかかり、処理する必要がある一意の用語の数と出現頻度によっては、、コンテンツ ファイルのサイズが過度に大きくなる可能性があります。

+
+
+
+ +
+

関連リンク

+ +
+
+ +