- From: MURATA Makoto <eb2m-mrt@asahi-net.or.jp>
- Date: Tue, 3 Aug 2021 23:50:54 +0900
- To: 田嶋 淳 <tajima@sanyosha.co.jp>
- Cc: Yasuo Kida <kida@mac.com>, JLReq TF 日本語 <public-i18n-japanese@w3.org>
- Message-ID: <CALvn5EBOoEUrAK+QbeOWR7wR-nARz_S7mLjk-O3i+OggDA0cSA@mail.gmail.com>
2021年8月3日(火) 13:21 田嶋 淳 <tajima@sanyosha.co.jp>: > みなさま > > > 注の相互リンクについては数年前にKindleがパブリッシングガイドラインで「要件」扱いにしました(なっていないとリジェクトの可能性がある)ので、新しく作られた電子書籍についてはほぼ設定されているのではないかと思います。ただ、制作側の負荷が大きいので(訳注と原注など複数の種類の注が付いている場合などを想像してみてください)、わかっていて付けないケースもあるかと思います。 > どうなんでしょうね。JDC技術委員会の人(ただしボンクラ委員長を除く) はみんなこの戻りリンクのことを知ってましたし、実際につけている ようです。その一方で、良い方法だとは言い切れないという感じでした。 > > もともと脚注などの扱いで同一ページ内に注のテキストが配置されていたものの場合、出版社的な要望としてはできればEPUBでも同様のレイアウトを再現したいはずですが、現状リフロー型EPUBではコンテンツ側でのマルチカラムレイアウト指定ができませんので、章末に移動させて相互リンクさせる等の方策を取らざるを得ません。過去には注のポップアップ表示などという話もあり、iBooksやiOS版Koboでは表示できたのですが、その後各ビューアで実装が進んでいるというような話にはなっていないようです。 > そもそも注を読みに行ったら、その注の終わりで原文に戻ってくる のが当然で、次の注に行くのがデフォルトという現状はおかしい と思っています。EPUB用Open Annotationの普及が期待されたん ですが、いまのところダメです。 村田 真 > > 2021/08/03 11:18、木田泰夫 <kida@mac.com>のメール: > > なるほど! > スクリーンリーダが目的の注で終わらずに、そこから後をどんどん読んでしまうということですね。確かに、何らかの仕組みが必要そうに思えますね。言語かかわらず同じ問題がありますね。 > > Apple Books の voice over > ではどうなってるんだろう。このチームは障害者の方達がほとんどなので問題のあること自体は見逃していないと思います。直せたかどうかは別ですが。あとで試してみます。 > > 木田 > > (JLreq TF 英語の方に流れていましたので。日本語の方に戻しました) > > 2021/08/03 9:45、MURATA <eb2mmrt@gmail.com>のメール: > > 木田さん、 > > 2021年8月3日(火) 9:39 木田泰夫 <kida@me.com>: > >> リンクを戻って来れるかというのは、アプリケーションの問題ですよね。 >> > > ところがそれだけでもないようなんです。注を読み上げ始めると、 > 次の注、次の次の注と進んでしまって、どこで戻るか分からない > ようです。iBooksでは、注がどこで終わるか分かります? > > そもそも注というものが本当の意味でHTMLにはないと思います。アンカーが > あるだけで。 > > 村田 真 > > >> >> 例えば Apple Books >> では戻れます。同じ書籍内を指すリンクをクリックすると、飛んだ先のページの下に、xxページに戻る、というナビゲーションが表示されるので、そこをクリック。 >> >> 問題1のほうは、"13"ではなく"注13"と書けばいいのかも知れません。 >>> >> >> これ、英語での状況はどうなんでしょうね。視覚的な問題なのか、慣れの問題なのか(日本語の印刷された書籍では括弧がつく vs >> 電子書籍は英語のレイアウトで番号のみ)… >> >> 木田 >> >> 2021/08/03 8:52、小林龍生 <tlk@kobysh.com>のメール: >> >> 村田さま、 >> 小林龍生です。 >> >> 面白い。 >> >> まあ、技術的には、ジャンプするときに、下のポジションをスタックに積んでおけばいいだけの話だけれど、《注に飛んだ後、元の文脈に戻らなければならない》という、ある意味、常識以前の前提への想像力が、開発者に欠如しているのだろうね。 >> このあたりの《要件》を機能論的に展開していくと、面白い(というか画期的な)ドキュメントになる。 >> >> 2021年8月3日(火) 8:43 MURATA <eb2mmrt@gmail.com>: >> >>> 小林さん、 >>> >>> 蛮勇は功を奏しそうですね。 >>> >>> 1つコメントします。いま、EPUB出版物には注が入っている >>> ことがあります。結局<a href="..">13</a>のように書いて、 >>> 章の末尾にある注に飛んでいます。 >>> >>> アクセシビリティの点から二つ問題が指摘されています。 >>> >>> 1) 注がついていることに気が付かない >>> >>> 2) 注を見に行くと戻ってこられない >>> >>> 問題1のほうは、"13"ではなく"注13"と書けばいいのかも >>> 知れません。 >>> >>> 問題2のほうは、いまは戻るためのリンクを張って対処する >>> こともあるようです。ユーザエージェントもしくはEPUB >>> リーダの問題かもしれません。 >>> >>> しかし、注のありかたを見直す(線形である文書のなかに >>> 押し込むのをやめる)のも手ではないかと思うのです。 >>> >>> 村田 真 >>> >>> 2021年8月2日(月) 8:26 小林龍生 <tlk@kobysh.com>: >>> >>>> 木田さま、みなさま、 >>>> 小林龍生です。 >>>> >>>> 木田さんに頂戴した宿題の答案。 >>>> JLreq(次期ヴァージョンのスコープ) >>>> >>>> 現行版のJLreqは、まず、活字の大きさ、1行の字数(行長)と1ページの行数を決定する基本版面の設計を冒頭に置いている。 >>>> >>>> 一方、電子書籍ビューアーも含め、現今の電子化文書の閲覧環境は、ディスプレーや閲覧矩形(ウィンドウ)の大きさも、フォントサイズも多様であり、行間も含め、プリファレンスも含め、ユーザー側で選択できるようになっている。 >>>> 次期JLreqは、このような情報の送り手側/コンテンツ制作側では、すべてをコントロールすることが出来ない環境での、〈読みやすく〉〈弱者に優しい〉読文環境(reading >>>> environment)を目指すべきだと考える。 >>>> このような視点から、従来のJLreqの目次を見ると、不要な項目や重要度が下がる項目を定めやすくなる。 >>>> 不要な項目(版面設計) >>>> >>>> 2.2 日本語文書の基本となる組体裁 >>>> 2.2.1 組体裁の設計 >>>> 2.2.2 基本となる組体裁 >>>> 2.2.3 基本となる組体裁の主な設計要素 >>>> 2.2.4 基本版面の設計要素 >>>> 2.2.5 基本版面と実際のページの設計例 >>>> 2.4 基本版面の設計 >>>> 2.4.1 基本版面の設計手順 >>>> 2.4.2 基本版面の設計の注意点 >>>> 2.5 基本版面の設計要素の各ページに対する適用 >>>> 2.5.1 基本版面からはみ出す例 >>>> 2.5.2 基本版面で設定した行位置の適用 >>>> 2.5.3 基本版面で設定した文字位置の適用 >>>> リフローを前提として再考を要する項目 >>>> >>>> 第4章 見出し・注・図版・表・段落の配置処理 >>>> 4.1 見出し処理(改ページ処理も含む) >>>> 4.1.1 見出しの種類 >>>> 4.1.2 別行見出しの構成 >>>> 4.1.3 見出しにアクセントを付ける >>>> 4.1.4 改丁・改ページ・改段処理 >>>> 4.1.5 改ページ等の直前ページの処理 >>>> 4.1.6 行取りの処理例 >>>> 4.1.7 行取り処理した見出しがページ末にきた場合の処理 >>>> 4.1.8 小見出しの前を1行アキにした場合の処理 >>>> 4.1.9 同行見出しの処理 >>>> 4.1.10 窓見出しの処理 >>>> 4.1.11 段抜きの見出しの処理 >>>> 4.3 図版の配置処理 >>>> 4.3.1 図版配置の指定方法 >>>> 4.3.2 図版配置の基本的な考え方 >>>> 4.3.3 縦組における図版配置の条件 >>>> 4.3.4 横組における図版配置の条件 >>>> 4.3.5 JIS X 4051における図版配置の基本的な考え方 >>>> 4.4 表の処理 >>>> 4.4.1 表の構成 >>>> 4.4.2 表の全体の組方向 >>>> 4.4.3 表を配置した例 >>>> 4.4.4 ページへの配置からみた表の種類 >>>> 4.4.5 見開きに配置する表の処理 >>>> 4.4.6 分割を可とする表の処理 >>>> 4.5 行・段落などの行送り方向の配置処理 >>>> 4.5.1 ルビなどが付いた場合の行間の処理 >>>> 4.5.2 段落間処理 >>>> 4.5.3 行送り方向の領域の調整処理 >>>> 別の観点(機能論的観点)から再定義すべき項目 >>>> >>>> 2.6 柱とノンブル >>>> 2.6.1 柱及びノンブルの位置 >>>> 2.6.2 柱及びノンブルの配置の原則 >>>> 2.6.3 柱及びノンブルの配置方式 >>>> 3.3 ルビと圏点処理 >>>> 3.3.1 ルビの使用 >>>> 3.3.2 ルビの付け方 >>>> 3.3.3 ルビの文字サイズ >>>> 3.3.4 親文字のどちら側にルビを付けるか >>>> 3.3.5 モノルビの親文字に対する配置位置 >>>> 3.3.6 グループルビの親文字に対する配置位置 >>>> 3.3.7 熟語ルビの親文字に対する配置位置 >>>> 3.3.8 ルビが親文字よりはみ出した場合の処理 >>>> 3.3.9 圏点の処理 >>>> 3.4 割注処理 >>>> 3.4.1 割注の利用 >>>> 3.4.2 割注の文字サイズと行間など >>>> 3.4.3 割注を本文の2行以上にわたって配置する処理 >>>> 4.2 注の処理 >>>> 4.2.1 注の種類 >>>> 4.2.2 注の番号 >>>> 4.2.3 合印の処理 >>>> 4.2.4 縦組又は横組の後注処理 >>>> 4.2.5 横組の脚注処理 >>>> 4.2.6 縦組の傍注処理 >>>> 4.2.7 頭注(縦組)・脚注(縦組)・傍注(横組)の処理 >>>> 機能論的観点からの補注 >>>> >>>> 直接的に文字列を読むための機能以外に、書物によって具現化される機能は複数存在する。 >>>> 異論はあろうが。。。 >>>> ・注(annotation) >>>> ルビ、脚注、傍注、頭注、割注、圏点など >>>> ・参照(link) >>>> 他のドキュメントの特定個所の排他的指示 >>>> URL+anchor >>>> レガシーブックでは、書名、発行年、版、ページ、行で実現 >>>> ・移動(navigation) >>>> 目次 >>>> 柱 >>>> ノンブル >>>> 従来の書物の版面設計(版面デザイン)は、これらの機能論的な観点から見直す必要がある(≒従来の書物の表現方法に固執する必要はない)。 >>>> 工藤智行氏(日本デイジーコンソーシアム、有限会社サイパック)によるアクセシビリティの観点からのnavigation >>>> >>>> ■ ナビゲーションとは何か >>>> ・本文を音声読み上げできればアクセシブルという大きな誤解 >>>> ・ナビゲーションは読み上げ位置の移動を中心とした操作 >>>> ・ナビゲーションは音声を中心とした読書で必須となる >>>> ・主としてリーディングシステム側の機能 >>>> ・スクリーンリーダ等の音声UIを通じて操作できなければならない >>>> ・ナビゲーション機能が不十分だと音声を中心とした読書が困難 >>>> ■ 具体的なナビゲーション操作 >>>> ・前回読み終えた場所からの再生 >>>> ・目次やインデックスから目的の場所への移動 >>>> ・しおりの場所に移動 >>>> ・前の章、次の章、前の節、次の節等への移動 >>>> ・次ページ、前ページ、指定ページへの移動 >>>> ・次段落、前段落、現在の段落の頭への移動 >>>> ・フレーズ単位での前後移動 >>>> ・5秒/10秒/30秒/一分といった時間単位での前後移動 >>>> ■ 高度なナビゲーション操作 >>>> ・表の読み上げ >>>> 縦方向、横方向、表見出しの読み上げ >>>> ・現在の読み上げ位置の音声での把握 >>>> 現在の章、節等の名前、何ページ中何ページ、全体の音声の再生時間でのパーセンテージ >>>> >>> >>> >>> -- >>> -- >>> 慶應義塾大学政策・メディア研究科特任教授 >>> 村田 真 >>> >> >> > > -- > -- > 慶應義塾大学政策・メディア研究科特任教授 > 村田 真 > > > > > > *************************************** > (株)三陽社 > メディア開発室 > http://www.sanyosha.co.jp/ > > 田嶋 淳 > tajima@sanyosha.co.jp > > ※ブログ運営中です。 > ご意見をいただければ幸いです。 > http://densyodamasii.com/ > *************************************** > > -- Regards, Makoto
Received on Tuesday, 3 August 2021 14:52:00 UTC