Re: フォント分科会 3/30

田嶋さん、

詳しい情報をありがとうございます。Kindle 一人勝ちかと思っていたのですが、楽天 Kobo などのシェアがそれなりにあるんですね。

webkit を使っているものでも結果が、それも日本語に重要なところで、それぞれ微妙に違いそうで怖いですね。

木田

> 2021/03/31 9:39、田嶋　淳 <tajima@sanyosha.co.jp>のメール:
> 
> 木田さま
> みなさま
> 
>  EPUBリーダで重要なものについてですが、シェア的には楽天Koboなどもそれなりに大きいはずですがあそこはエンジンはWebkitベースのはずで挙動がほとんどApple Booksと変わらないはずです。Book☆WalkerもWebkitですね。もちろん各社そのまま採用はしていないはずで、ACCESSやBPSなど数社Webkitベースのエンジンを手がけている会社と提携しているはずですが、今現在どういう状況なのかはわかりません。結構そこは外には出ない情報と思います。
> 
> 　Webkit以外のエンジンを採用しているRSとしては、インフォシティがエンジンを開発している紀伊國屋書店Kinoppy、少なくとも過去にはモリサワがEPUBのエンジンを手がけていたDNPのhontoがあります。
> 　Kinoppyはフォント処理はかなり綺麗で、font-style:italicを指定するとちゃんとフォントの内包しているイタリック体で表示してくれたりします。
> 　hontoはドットブック、XMDF、EPUBのエンジンを全て内包していたハイブリッドビューアだったのですが、どうやら内部的にEPUBへの切り替えを進めているらしく過去に買ってその時にはドットブック形式だった本が最近開くと変わっていたりしました。EPUBのエンジンももしかしたらもう切り替えているかも知れませんが（モリサワMCBookのロゴが過去には出ていたが出なくなっている）、これも出てこない内部情報なのでちょっとわかりません。フォント的には（なにせモリサワが絡んでいるので）モリサワ書体の指定ができたりもするはずですが、あまり一般に売られているもので実例は見たことがありません。なおhontoは文字詰め、文字空け処理を勝手にやるビューアです。和欧間のアキも自動で入ります。
> 
> 　凸版のBookLiveもシェア的には重要で一時はシャープのエンジンを採用していたはずですが、デバイスごとに細かくカスタマイズしているようでちょっと把握できていません。ここは外部データのサイドロードに対応していないのでテストもできない感じです。
> 
> 　なお、そのあたりの状況は出版社の検収担当者や電子取次の技術部門の方が詳しいのではないかなと思います。制作現場にまでなかなか話が伝わってこないのが悩ましいです。honto、Kinoppyのビューア開発側の人には繋がりがありますので、話を聞くことはできるかと思います。
> 
>> 2021/03/30 19:10、木田泰夫 <kida@me.com <mailto:kida@me.com>>のメール:
>> 
>> JLReq TF の皆様、
>> 
>> 今日のミーティングの記録をまとめました。修正点、足りない点などあれば教えてください。
>> 
>> 
>> 村田さん（二つ目は田嶋さんにも）に二点質問：
>> • プレゼンの P13 で、U であるべきなのに Tu なのは中国考慮、と書いてあるところがありますが、どのようなことなのか教えていただけますか？
>> • P3 オープンな環境、について。オープンとは言っても程度問題で、重要なケースから稀な組み合わせまで、広いスペクトラムがあると思います。例えば OS などに付属のみんな知っているフォント × よく使われるブラウザ（Safari, Chrome, Firefoxの三つ?）、OS 付属の EPUB リーダ、そして Amazon Kindle は最重要かと想像します。ここに挙げた、私に容易に想像のつく組み合わせ以外に、どのようなフォント and/or リーダーが重要ですか？
>> 
>> 石井さんに質問（別スレッドで既に聞きましたが）：
>> • レイアウトエンジン、例えばウェブブラウザから、特定の文字に対して GSUB/verX があって、つまり横転するに違いない、ということを知ることは簡単ですか？ もしそれができれば、正立横転の「判断」をフォントに任せずに、ウェブブラウザから完全にコントロールできますか？
>> 
>> 
>> ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
>> 今日のゴール：フォントとレイアウトエンジンとの間の問題点を明確化する
>> 
>> 村田さんのプレゼン
>> https://1drv.ms/p/s!An5Z79wj5AZBgrp06H7M3ZUfkyQ4AA?e=T6rdZB <https://1drv.ms/p/s!An5Z79wj5AZBgrp06H7M3ZUfkyQ4AA?e=T6rdZB>
>> 
>> 箱庭からオープンな環境へ
>> 従来はコンテンツに対してフォントとアプリが決まったセットであった。印刷さえできれば良い。デジタルデータであっても、フォントとアプリが決まった組み合わせ
>> 今のオープンな環境：どのブラウザ、どのフォント、どのEPUBリーダが使われるかわからない
>> 問題
>> 縦書きにおいて、記号の一部、矢印などの正立回転の挙動が不統一
>> 角川などは一文字づつ調査。危ないものはビットマップに置き換える。文字処理技術の敗北。アクセシビリティ問題
>> 同じような問題は、他の言語でも起こっている。アラビア語の伸ばし処理、韓国語の約物、ヘブライ語、デヴァナガリなど
>> CSS working group からフォントとの問題点がリエゾンステートメントとして SC29 に送られた（薛さんの2/14のメール）
>> 原因
>> EPUB リーダの実装に問題がある
>> 特に amazon の実装で問題が多い
>> AJ1, CSS Writing mode (Browser), UAX50 がそれぞれ整合していない
>> MS のメイリオとMS明朝で異なる。
>> AJ1 フォントは AJ1 テンプレートで揃っている。源ノ角は UAX50。TrueType はバラバラ
>> また議論の中から、記号の誤用、または文字コードの定義がそもそも曖昧であるケースも見られた
>> 問題となる文字の例
>> U+2016 Double Vertical Line
>> U+3030 Wavy Dash
>> （あれ、悪いのは MS 明朝だけでは？）
>> 
>> 結論
>> Adobe-Japan1 のテンプレート通りにフォントを作ると UAX50 に適合しない
>> UAX50 に適合しても、CSS Writing Mode で横転してくれない文字がある（どれ？）
>> フォントを直すと過去の資産が壊れる
>> 問題解決にはまず現状分析が重要
>> –––––––
>> 議論
>> 調査範囲を増やす必要がある（todo: 村田さん @ 文字情報なんたら委員会）
>> フォントベンダーは問題についてあまり理解していないように見える（村田）
>> Ken はずれがあるのは知っていて、AJ1 のテンプレートを無視すべき、と言っている
>> Adobe からは UAX50 を変えるべきというフィードバック（Nat）
>> AJ1 → UAX で一旦互換性を無視すべきという意見（石井）
>> CSS 専用 vert ?　日本語用 UAX50?
>> AJ1x, CSS Writing mode, UAX50 の違いの網羅的なリストはあるか？ Nat が社内向けに持っている（todo: Nat が文書をシェアする）
>> それぞれの約物、記号の意味、用法、縦横の挙動を整理し直すべきではないか？（木田）
>> 
>> 次回のフォント分科会は 4/20
>> 今回約物の半角ツメの問題について話す時間がなかったのでまずその話題から。それ以外に問題点はあるか？ メーリングリストで進められるものは進める。
>> ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
>> 
> 
> 
> 
> ***************************************
> （株）三陽社
> 　メディア開発室
> 　http://www.sanyosha.co.jp/ <http://www.sanyosha.co.jp/>
>  
>  田嶋 淳
>  tajima@sanyosha.co.jp <mailto:tajima@sanyosha.co.jp>
>  
>  ※ブログ運営中です。
> 　　ご意見をいただければ幸いです。
> 　　http://densyodamasii.com/ <http://densyodamasii.com/>
> ***************************************
>