8月 31

「アクセシブルなデジタル教科書(マルチメディア版DAISY)製作と普及活動の報告」(井上芳郎さんの日本デジタル教科書学会報告)

 大阪大学で8/17、8/18に行われた日本デジタル教科書学会での井上芳郎さんによる以下の報告がSlideshareで公開されています。

 特別支援教育におけるデジタル教科書の法的、政策的動向や特別支援教育におけるDAISY教科書の活用事例、DAISY教科書の活用の効果などがまとめられています。

8月 27

Unicode点字と点字フォーマットPEF(Portable Embosser Format)

いきなりですが、貴方の端末では、以下のフォントはどのように表示されているでしょうか。

——-ここから
 ⠘⠀⠙⠀⠚⠀⠛⠀⠜⠀⠝⠀⠞⠀⠟
ここまでの間———-

 以下のように表示されているならば、貴方の端末(OS)Unicode点字に「対応」しています。

上で表示したユニコード点字の画像

Unicode点字

 点字記号は、1999年に公開されたUnicode 3.0から割り振られています。U+2800からU+28FFまで割り振られ、Braille Patternsと呼ばれています。

Unicode 6.2のBraille Patterns

 文字コードレベルで点字に対応できるならば、特定のフォーマットを使用しなくても、テキストファイルやワードファイル、PDFファイル、EPUBファイルなど幅広く利用されているフォーマットでも点字を利用することができ、点字データの作成・交換・配布も行いやすくなると思われます。残念ながら対応しているのは、最新のOSに限られてしまうようです。対応を確認できたOSは以下のとおりです。※1
 
 表示できることを確認できたOSは以下のとおりです(ご協力いただいた方には感謝感謝です!)。

表示できた
  • Windows 7 Home,Pro(表示できなかった端末もあり)
  • OS X v10.8 Mountain Lion
  • iOS 6.1.4
表示できなかった
  • Windows XP
  • Windows Vista
  • Android 4.1.1(HTC J butterfly )

Unicode点字への「対応」について  ※1 2013/08/27 追記

 @momdo_さんからいただいた以下のご指摘で、私が「Unicode点字に対応」という言葉を安易に使用しているが判明しました(汗)。整理します。

 Unicode点字に対応ということを問題とする場合、以下の2つの段階があります。

  1. OSとアプリケーションがUnicode 3.0以降に対応している
  2. Unicode点字フォントを搭載している

 1については、Unicode 3.0は1999年に公開されていますので、今、動いているほとんどの端末がその条件を満たしているはずです。

 最近の晴眼者が使用する端末でUnicode点字の対応が問題となるのは、2の点字フォントの有無の問題です。点字フォントを自分で追加すれば、Unicode点字にも対応できるはずです。上で確認したように最近のOSでは点字フォントを標準で搭載されるようになっているようです。

 ここで気になるのが、点字プリンタや点字ディスプレイなど点字機器類への入出力です。例えば、Unicode 3.0対応有り、点字フォントなしのOSの端末へ繋いだとしても、点字機器そのものがUnicode 3.0に対応し、点字記号の情報を持っていれば、そのまま使えるのではないかという気がします。どうなのだろう?

※ 2013/08/28 追記の追記
 @momdo_さんに以下のエントリの追記でご指摘いただいたので、修正しました。

  • Unicode 3.0以降→Unicode
  • Unicode点字フォント→点字フォント

 
 Unicodeのこれまでのバージョンアップで、Unicodeの前方互換性がきちんと担保されているのか否かについてよくわからなかったため、「Unicode 3.0以降」という書き方をしてしまいましたが、Wikipediaを見る限り、点字についてはUnicode対応が3.0以前のものでも大丈夫そうでしたので、この項でのUnicodeのバージョン番号は削りました。「点字フォント」の修正についても@momdo_さんのご指摘の通りです。

点字プリンタや点字ディスプレイなど点字機器類への入出力の問題についてですが、私もよく分かっていませんので、自分に課した宿題かなと思っています。

 

(参考)Braille ASCII

 英数字では現在、Braille ASCIIという表示方式がよく使われているようです。Braille ASCIIは文字コードASCIIの0x20から0x5Fに割り当てられた64文字を上書きする形で点字に置き換える方式です。なお、Braille ASCIIで作成された点字文書はBRF形式で保存されることが多いようです。

  
 例えば、ASCII文字で「3」を表すコード0x33には、点字で「3」を意味する点字記号「⠒」、「B」(大文字のB)を表すコード0x42には、「b」をあらわす点字「⠃」が割り当てらています。通常のテキストエディタで開くと、0x33、0x42はそれぞれ「3」、「B」ですので、それぞれ「3」と「B」が表示されます。しかし、Braille ASCIIに対応したアプリケーションで開くと、それぞれ「⠒」、「⠃」という点字記号に置き換えられて表示されます。

サンプルBRF形式ファイル

 TSBVI Libraryが公開しているBRFファイルです。

点字フォーマットPEF(Portable Embosser Format)

 
 このUnicode点字を活用したPEF(Portable Embosser Format)がスウェーデンから提案されています。

 このフォーマットの特徴は主に以下の3つです。最大の特徴はやはりUnicode点字を前提としていることです。

  • XML形式
  • Dulin Coreメタデータ
  • Unicode点字対応

 PEF(Portable Embosser Format)という名称からもわかるように、PDF(Portable Document Format)のように環境、言語環境に依存しない点字フォーマットを志向しており、正確かつ一義的に点字を表示することが可能なために電子文書の交換や長期保存に向いたフォーマットであることをウリにしています。

 利用事例はまだ多くないようですが、先のエントリで紹介したNLBのJacobsen氏にあるようにすでに北砲諸国ではすでにPEF形式が利用されているようです。また、このブログで何度も紹介しているコンバーターDAISY Pipelineのアウトプット点字ファイルとしてPEF形式が使用されています。

(参考)PEFファイルサンプル

[Example PEF document: Extending PEF]”examples/extended.pef”. Demonstrates how a PEF-file can be extended.

表示

 Mobile Safariでの表示例です。
写真

ソース

<?xml version="1.0" encoding="UTF-8"?>
<pef version="2008-1" xmlns="http://www.daisy.org/ns/2008/pef" xmlns:ext="http://www.example.org/my-pef-extensions" ext:version="1">
	<head>
		<meta xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:org="http://www.example.org">
			<dc:title>Extending PEF</dc:title>
			<dc:creator>Joel Håkansson</dc:creator>
			<dc:date>2009-01-20</dc:date>
			<dc:format>application/x-pef+xml</dc:format>
			<dc:identifier>org.pef-format.00004</dc:identifier>
			<dc:description>Demonstrates how a PEF-file can be extended.</dc:description>
			<org:paper-size value="A4"/>
			<org:grade value="1"/>
			<org:margin-top value="5cm"/>
			<org:margin-left value="2cm"/>
			<org:binding content="coil"/>
		</meta>
	</head>
	<body xml:lang="en">
		<annotation xmlns="http://www.example.org/my-pef-extensions" style="default.css">
			<p>This is an <b>extended</b> <dfn>PEF</dfn> 1.0 example. It demonstrates how a PEF-file can be extended.</p>
		</annotation>
		<volume cols="20" rows="29" rowgap="0" duplex="true">
			<ext:volume-label>
				<ext:row>⠀⠀⠀⠀⠁⠀⠂⠀⠃⠀⠄⠀⠅⠀⠆⠀⠇⠀</ext:row>
				<ext:row>⠀⠀⠈⠀⠉⠀⠊⠀⠋⠀⠌⠀⠍⠀⠎⠀⠏⠀</ext:row>
				<ext:row>⠀⠀⠐⠀⠑⠀⠒⠀⠓⠀⠔⠀⠕⠀⠖⠀⠗⠀</ext:row>
			</ext:volume-label>
			<section ext:section-type="toc">
				<page ext:page-number="i">
					<row>⠀⠀⠀⠀⠁⠀⠂⠀⠃⠀⠄⠀⠅⠀⠆⠀⠇⠀</row>
					<row>⠀⠀⠈⠀⠉⠀⠊⠀⠋⠀⠌⠀⠍⠀⠎⠀⠏⠀</row>
					<row>⠀⠀⠐⠀⠑⠀⠒⠀⠓⠀⠔⠀⠕⠀⠖⠀⠗⠀</row>
					<row>⠀⠀⠘⠀⠙⠀⠚⠀⠛⠀⠜⠀⠝⠀⠞⠀⠟⠀</row>
					<row>⠀⠀⠠⠀⠡⠀⠢⠀⠣⠀⠤⠀⠥⠀⠦⠀⠧⠀</row>
					<row>⠀⠀⠨⠀⠩⠀⠪⠀⠫⠀⠬⠀⠭⠀⠮⠀⠯⠀</row>
					<row>⠀⠀⠰⠀⠱⠀⠲⠀⠳⠀⠴⠀⠵⠀⠶⠀⠷⠀</row>
					<row>⠀⠀⠸⠀⠹⠀⠺⠀⠻⠀⠼⠀⠽⠀⠾⠀⠿⠀</row>
				</page>
			</section>
			<section>
				<page ext:page-number="1">
					<row ext:row-type="header">⠀⠀⠀⠀⠁⠀⠂⠀⠃⠀⠄⠀⠅⠀⠆⠀⠇⠀</row>
					<ext:new-para type="heading" text="  A 1 B ' K 2 L"/>
					<row>⠀⠀⠈⠀⠉⠀⠊⠀⠋⠀⠌⠀⠍⠀⠎⠀⠏⠀</row>
					<ext:new-para type="p" text="@ C I F / M S P &quot; E 3 H 9 O 6 R ^ D J G > N T Q , * 5 &lt; - U 8 V . % [ $ + X ! &amp; ; : 4  0 Z 7 ( _ ? W ] # Y ) ="/>
					<row>⠀⠀⠐⠀⠑⠀⠒⠀⠓⠀⠔⠀⠕⠀⠖⠀⠗⠀</row>
					<row>⠀⠀⠘⠀⠙⠀⠚⠀⠛⠀⠜⠀⠝⠀⠞⠀⠟⠀</row>
					<row>⠀⠀⠠⠀⠡⠀⠢⠀⠣⠀⠤⠀⠥⠀⠦⠀⠧⠀</row>
					<row>⠀⠀⠨⠀⠩⠀⠪⠀⠫⠀⠬⠀⠭⠀⠮⠀⠯⠀</row>
					<row>⠀⠀⠰⠀⠱⠀⠲⠀⠳⠀⠴⠀⠵⠀⠶⠀⠷⠀</row>
					<row>⠀⠀⠸⠀⠹⠀⠺⠀⠻⠀⠼⠀⠽⠀⠾⠀⠿⠀</row>
					<ext:new-para type="p"/>
					<row>⠀⠀⠀⠀⠁⠀⠂⠀⠃⠀⠄⠀⠅⠀⠆⠀⠇⠀</row>
					<row>⠀⠀⠈⠀⠉⠀⠊⠀⠋⠀⠌⠀⠍⠀⠎⠀⠏⠀</row>
					<row>⠀⠀⠐⠀⠑⠀⠒⠀⠓⠀⠔⠀⠕⠀⠖⠀⠗⠀</row>
					<row>⠀⠀⠘⠀⠙⠀⠚⠀⠛⠀⠜⠀⠝⠀⠞⠀⠟⠀</row>
					<row>⠀⠀⠠⠀⠡⠀⠢⠀⠣⠀⠤⠀⠥⠀⠦⠀⠧⠀</row>
					<row>⠀⠀⠨⠀⠩⠀⠪⠀⠫⠀⠬⠀⠭⠀⠮⠀⠯⠀</row>
					<row>⠀⠀⠰⠀⠱⠀⠲⠀⠳⠀⠴⠀⠵⠀⠶⠀⠷⠀</row>
					<row ext:row-type="footer">⠀⠀⠸⠀⠹⠀⠺⠀⠻⠀⠼⠀⠽⠀⠾⠀⠿⠀</row>
				</page>
			</section>
			<section>
				<page ext:page-number="A">
					<ext:tactile-image src="map.svg"/>
				</page>
			</section>
		</volume>
	</body>
</pef>

ソースの画像(点字を表示できなかった方はこちらをご覧ください)

関連エントリ

8月 21

私がOPDSを推す理由 – 電子出版業界にも「混沌」とした世界を

 昨日、こんなニュースが流れました。

 ウェブ上では、予想通りNTT出版に対して厳しい意見が多いですが、NTT出版の姿勢はともかく、別の出版社から出版できたという結果はもっと評価されてよいのではないかと思うのです。

 出版社の多くが私企業ですので、個々の出版社レベルではその時々における個々のいろいろな事情で、出版できるものもあれば、出版できないものが出てくるのはある程度はやむを得ないところがあろうかと思います(それが望ましいかどうかは別にして)。しかし、出版界の健全性を問うならば、その場合に、別の出版社で出すという選択肢が用意されているか否かが重要です。A出版社でだめなら、B出版社、B出版社がだめならC出版社で出版できるという選択肢が著者に用意されていることが出版界の健全さを示すものではないかと思うのです。

 経済産業省が公開している特定サービス産業実態調査報告書(平成22年度)によれば、日本の出版社は2,883社はあるらしいです。

 出版社数は統計によってかなり開きがあったように記憶していますが、それにしても3,000社弱。多いです。あえて単純化して申せば、著者にはこれだけの選択肢がある。出版社が構成する業界団体もいろいろとありますが、全出版社が参加するような業界団体は日本には未だ存在しません。出版界全体が1つとして動くことができないことは、出版業界の業界としての「統制」のなさを示すものであるかもしれませんが、その「まとまり」のなさ、「混沌」とした状態は、出版界の多様性を担保し、著者に多くの選択肢を提供するものでもあり、必ずしも否定するべきものではないように思います。

 一方で、「電子書籍」業界では、著者に対して複数の選択肢が用意されているのかというと、いささか心もとない気がします。コンテンツプロバイダである出版社の多さはある程度維持されるかもしれませんが、発行から読者への販売/配信(リーチ)に至る部分がAmazon、Google、Appleのような大きなプラットフォームに集約されていく可能性が大きくなっています。巨大プラットフォームとはいえ、一私企業であり、企業の利益や方針、その時々の箇々のの事情によってあっさりと販売・配信を拒否することもありえます。紙の世界と異なり、「電子書籍」業界では、他のところで発行できるという選択肢が極端に狭められていく危険があるように思えます。物議を醸した『完全自殺マニュアル』のような書籍を「電子書籍」として刊行することができるか否かです(『完全自殺マニュアル』そのものの是非はここでは置いとくとして)。

 「電子書籍」、後で述べるOPDSの対象となる範囲も考慮し、もう少し広く捉えて「電子出版」業界としますが、電子出版業界においても出版物の多様性を担保するためには、紙の世界と同じように、著書が読者に届くまえのルートに多くの選択肢が著者に用意される必要があります。言い換えると電子出版業界にも「まとまりのなさ」、ある種の「混沌とした世界」があってほしいと。

 私がOPDSを推すはまさにそのためです。

 先日、Open Annotationを紹介しましたが、個人的には、OPDSに対する興味と根は同じところかもしれません。大きな1つのものが世界を覆うよりは、統制されることのない個々の活動が結果として1つの世界を構成する、そういうものに興味があるようです。