Re: フォント関係のお話

木田さま

ちょっと思い当たらないです。すみません。

> 2020/04/21 17:55、木田泰夫 <kida@mac.com>のメール:
> 
> 田嶋さん、
> 
> ありがとうございます。この medium が欲しいというのはどこかに要望として上がっていたりします? もしそうならそれをポイントして、ほら、と言いやすいんですが。
> 
> 一度 JLReq TF で要望をまとめるのも一案ですね。如何思われます? > みなさん
> 
> 木田
> 
>> 2020/04/21 17:50、田嶋淳 <tajima@sanyosha.co.jp>のメール:
>> 
>> 
>> 木田さま
>> 
>>  割と上品な書籍だと見出し等にはBoldではなく、Mediumに相当するフォントを使っているケースが多いです。また、見出しにBoldが使われていた場合、本文内の一部の文字の強調にはMediumのフォントを使うことになるかと思います。現状EPUB制作ではこれらがいっしょくたにBoldになってしまうのが難しいところです。
>> 
>>  等幅欧文はどちらかというとデバイス側の内蔵フォントの問題のような気はします。例えばKindleであれば問題なくMonospaceで行けますね。
>> 
>>> 2020/04/21 17:44、木田泰夫 <kida@mac.com <mailto:kida@mac.com>>のメール:
>>> 
>>> ミディアム、確かに指定方法がありませんね。書籍だと典型的にどのような場所で使われるんですか?
>>> 
>>> 等幅欧文は generic font family で monospace とか、もしくはどこのプラットフォームにも(たぶん?)ある courier とか指定すれば良いのでは?
>>> 
>>> 木田
>>> 
>>>> 2020/04/21 14:49、田嶋淳 <tajima@sanyosha.co.jp <mailto:tajima@sanyosha.co.jp>>のメール:
>>>> 
>>>> みなさま
>>>> 
>>>> ちょっとズレるかもしれませんが、EPUB制作側として今後欲しいなと思っているフォント指定について述べておきます。
>>>> 
>>>> まず、現状商用EPUBでは並字(normal)と太字(bold)の2段階でしかウェイトの指定ができません。紙のデータで中間のウェイト(medium)が使われていることは多々あるので、これが使えるようになって欲しいなとはずっと思っています。
>>>> 
>>>> また、丸ゴシックも使えるようになるなら当然嬉しいです。DTPでの使用頻度は高いので。
>>>> 
>>>> それ以外の日本語フォントに関してはむしろフォント自体の埋め込み対応に期待と言ったところですが、これは技術というよりはライセンスの問題が大きそうです。
>>>> 
>>>> 日本語以外では、コンピュータ技術書でのプログラミングコード部分に使う等幅欧文フォントのニーズがあります。これは過去に(フルセットですが)EPUB内への埋め込みで対応したりもしています。
>>>> 
>>>>> 2020/04/21 14:31、木田泰夫 <kida@mac.com <mailto:kida@mac.com>>のメール:
>>>>> 
>>>>> 
>>>>> 
>>>>>> 2020/04/21 12:19、Koji Ishii <kojii@chromium.org <mailto:kojii@chromium.org>>のメール:
>>>>>> 
>>>>>> 「Rounded」は提案で上がっています。
>>>>>> https://github.com/w3c/csswg-drafts/issues/4605 <https://github.com/w3c/csswg-drafts/issues/4605>
>>>>> 
>>>>> 賛成!👍
>>>>> 
>>>>>> 教科書体は Windows 10 にもあるので、条件を満たしているように思えます。
>>>>> 教科書体を加えるとしたら、スクリプト独特な generic font family を許すか、どう使うかを議論すべきかと思います。例えば日本語の教科書体として期待される英字は、例えば米国の教科書に使われる書体(教科書の書体という概念があるかどうか知りませんがあると仮定して)と異なるかもしれません。
>>>>> 
>>>>> スクリプト独特なものを許すなら、教科書体、楷書体、などが追加候補ですね。
>>>>> 
>>>>> macOS / iOS には、明朝体、ゴシック体、丸ゴシック体、教科書体、ペン字体、の各書体がありますが(残念ながら楷書体はありません)、Windows / Office だとどんな感じですか?
>>>>> 
>>>>> ––––
>>>>> ところで、書体には serif, sans-serif といった分類とは異なる分類軸、もしくは細分類と言ったほうが適当かもしれませんが、がありますよね。それらは用途や、細かいデザインスタイルを表しています。例えば、本文書体、タイトル用(ディスプレー)書体、オールドスタイル、など。例えばこの見出しは単に汎用ボールドではなくて、タイトル用書体をちゃんと使って、sans-serif + display と指定したい。ちょっと重みを持たせたいので、serif + old style を使う、など。特に書籍などを考えるとその需要は十分あるように思います。この手の議論はあります?
>>>>> 
>>>>> 木田
>>>>> 
>>>>>> 2020年4月18日(土) 17:15 木田泰夫 <kida@mac.com <mailto:kida@mac.com>>:
>>>>>> Fuqiao さん、
>>>>>> 
>>>>>> cursive が楷書にマップされるのは賛成できません。とは言っても欧文の cursive にスタイルや雰囲気がぴったりな書体となると難しいです。cursive はペンで書かれた字体ですね。和文書体にもペン字体という比較的確立された書体カテゴリーがあります。先にも述べたようにペンという道具は共通しているのですが、欧文の cursive とはスタイルがちょっと異なります。
>>>>>> https://fontworks.co.jp/fontsearch/kleepro-m/ <https://fontworks.co.jp/fontsearch/kleepro-m/>
>>>>>> http://www.akibatec.net/wabunfont/library/dynafont/df-pen.gif <http://www.akibatec.net/wabunfont/library/dynafont/df-pen.gif>
>>>>>> 
>>>>>> どうも、generic font family には既に特定のスクリプトに依存する概念が入ってしまっているようです。cursive を i18n な環境で使うとしたら、どのような雰囲気の書体が出てくるか、目的とする言語をあらかじめ知っておく必要があるという意味です。
>>>>>> 
>>>>>> 
>>>>>>> ところで、日本語の丸ゴシックと中国語の圆体は同じ書体だと思って、このgeneric font familyはどう名付けたらかりやすいかまだわかりません。
>>>>>> 
>>>>>> 同じようですね。丸ゴシックは sans-serif の角が丸いもので、欧文書体でも存在します。
>>>>>> https://filtergrade.com/top-clean-rounded-fonts/ <https://filtergrade.com/top-clean-rounded-fonts/>
>>>>>> https://www.fontshop.com/people/stephen-coles/fontlists/soft-slash-rounded-sans <https://www.fontshop.com/people/stephen-coles/fontlists/soft-slash-rounded-sans>
>>>>>> https://fonts.adobe.com/fonts/urbane-rounded <https://fonts.adobe.com/fonts/urbane-rounded>
>>>>>> https://fonts.adobe.com/fonts/houschka-rounded <https://fonts.adobe.com/fonts/houschka-rounded>
>>>>>> etc.
>>>>>> 
>>>>>> 一般的に “rounded” という名前がついているので、名前をつけるとしたらそれが分かりやすいのかなと思います。ただ、特にこだわりはありません。
>>>>>> 
>>>>>> 木田
>>>>>> 
>>>>>>> 2020/04/18 13:38、Fuqiao Xue <xfq@w3.org <mailto:xfq@w3.org>>のメール:
>>>>>>> 
>>>>>>> 木田さん、
>>>>>>> 
>>>>>>> コメントありがとうございます。
>>>>>>> 
>>>>>>>> On Apr 17, 2020, at 4:31 PM, 木田泰夫 <kida@mac.com <mailto:kida@mac.com>> wrote:
>>>>>>>> 
>>>>>>>> Fuqiao さん、
>>>>>>>> 
>>>>>>>> ありがとうございます。状況がよく分かりました。
>>>>>>>> 
>>>>>>>> フォントフォールバックについて:
>>>>>>>>> 私は個人は状況(書体)次第だと思います。たとえば、ある楷書体のフォントには欧字がありますので、そのフォントで欧字を表示します。フォントには欧字がない場合は、font-familyは指定されていない場合と同じです。
>>>>>>>> 
>>>>>>>> 多くの non-western なフォントには latin alphabet 部分がありますので、欧文や数字はそのまま使えば良いですね。それ以外のスクリプトについては挙げていただいた issue にその議論がありますね。
>>>>>>>> 
>>>>>>>> https://www.w3.org/TR/css-fonts-4/#generic-font-families <https://www.w3.org/TR/css-fonts-4/#generic-font-families>
>>>>>>>> 
>>>>>>>> 
>>>>>>>> それで気がついたのですが、現在楷書は cursive からマップされるのですか? それはあまり良いアイディアとは言えないように思います。筆とペンは全く異なる雰囲気を持っていますから。
>>>>>>> 
>>>>>>> はい、現在楷書はcursiveからマップされるのです。私もこれが不思議だと思いました。そこで、ここで議論しました:
>>>>>>> 
>>>>>>>  https://www.w3.org/2020/03/05-clreq-minutes.html#t01 <https://www.w3.org/2020/03/05-clreq-minutes.html#t01>
>>>>>>> 
>>>>>>> 議論の結果は、以下の通りまとめます:
>>>>>>> 
>>>>>>> cursiveを楷書にマッピングすることは完璧ではありません。問題は、楷書とほとんどの欧文のcursiveフォントは全く異なる雰囲気を持っています。
>>>>>>> 
>>>>>>> ただし、clreqの編集者たちは、現在のマッピングが有益な妥協案だと思います。[1] 楷書は、中国でよく使用されている書体ですから、serifのようなfallbackできることが望まれます。
>>>>>>> 
>>>>>>> 将来、CSSWGが新しいgeneric font familyを受け入れる時、楷書を新しいgeneric font familyとして提案するも役立つと思います。
>>>>>>> 
>>>>>>>> 
>>>>>>>> また、日本語から加えたい generic font family もあります。日本語書体の分類で、分類が安定していて、頻度、重要度の高いものを挙げると:
>>>>>>>> 	• 明朝体* → serif
>>>>>>>> 	• ゴシック体* → sans-serif
>>>>>>>> 		• 厳密にいうと、serif のあるゴシック体もあります、というかそちらの方が多いのですが、とりあえずゴシック = sans-serif と考えましょう
>>>>>>>> 	• 丸ゴシック体* → new?
>>>>>>>> 	• 教科書体* → new?
>>>>>>>> 	• ペン字体* → new? (ペンで書くスタイルのため、cursive によりふさわしい)
>>>>>>>> 	• 楷書体 → new?
>>>>>>>>  • デザイン書体(POPなど)→ fantasy
>>>>>>>> * をつけた書体は macOS に標準であるものです。
>>>>>>>> 
>>>>>>>> 他に、行書や草書、江戸文字、などがありますが、用途が比較的限られます。
>>>>>>>> 
>>>>>>>> この辺りの議論は行われていますか?
>>>>>>>> 
>>>>>>> 
>>>>>>> 上のまとめありがとうございます、これはCSSWGとclreqに役に立ちます。
>>>>>>> 
>>>>>>> CSSWGでは、何のgeneric font family追加するかについての議論はまだ行われません。今までの討論は追加する方法と基準のようです。
>>>>>>> 
>>>>>>> ところで、日本語の丸ゴシックと中国語の圆体は同じ書体だと思って、このgeneric font familyはどう名付けたらかりやすいかまだわかりません。
>>>>>>> 
>>>>>>> Fuqiao
>>>>>>> 
>>>>>>> [1] その上、ほとんどのブラウザが実装されています:https://xfq.github.io/testing/i18n-personal-tests/generic-font-families.html <https://xfq.github.io/testing/i18n-personal-tests/generic-font-families.html> (ただし、私のMacBookでは、同じブラウザの同じバージョンを使っている場合でも、このページのcursiveが楷書のフォントを使用するとは限りません。原因はわかりませんけれども。)
>>>>>>> 
>>>>>>>> 木田
>>>>>>>> 
>>>>>>>>> 2020/04/16 13:20、Fuqiao Xue <xfq@w3.org <mailto:xfq@w3.org>>のメール:
>>>>>>>>> 
>>>>>>>>> 木田さん、
>>>>>>>>> 
>>>>>>>>>> On Apr 16, 2020, at 8:00 AM, 木田泰夫 <kida@mac.com <mailto:kida@mac.com>> wrote:
>>>>>>>>>> 
>>>>>>>>>> Fuqiao さんおはようございます、
>>>>>>>>>> 
>>>>>>>>>> この generic font family の議論はどのように anti-fingerprinting の議論と関係していますか? 想像するに、generic font family を改良することで、フォントの名前を知らなくても望むスタイルを指定できるように、でしょうか?
>>>>>>>>> 
>>>>>>>>> このgeneric font familyの議論は、anti-fingerprintingの議論と直接関係がないと思います。しかし、i18n WGのAddisonがおっしゃるように[1]、すべてのOSがすべての言語のフォントがあるわけではありません。特にマイナー言語の場合、既定フォント以外のフォントが必要になることもあります。
>>>>>>>>> 
>>>>>>>>> それゆえ、generic font family の議論について、新しいgeneric font familyは、Mylesの提案[2] の2番目のポイントを満たさない場合があります。anti-fingerprinting について言えば、一部のフォントはシステムフォントとしもWebFontとしてもありません。もし他のブラウザがSafariのように既定フォント以外のフォント読めなければ、これらのフォントを使用する文字は表示できないと思います。
>>>>>>>>> 
>>>>>>>>> font fingerprintingのメカニズム[3]は、ある文字をレイアウトして、測定して[4]、フォントを変更して、再測定です。これらの措置を100〜10000回繰り返して取れば、インストールされているフォントに関する有用な情報を得ます。したがって、これを予防するには、一部の(またはすうべての)既定フォント以外のフォントの読みを禁止する必要があります。
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> とすると、Fuqiao さんが触れられた、kai のように、言語に依存した書体の区分けも有用になりますね。
>>>>>>>>>> 
>>>>>>>>>> フォントフォールバックの議論はありますか? 例えば kai が指定された時に、英字や、アラビア語はどの書体を選択すべき?とか。
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> あります。例えば:https://github.com/w3c/csswg-drafts/issues/4425 <https://github.com/w3c/csswg-drafts/issues/4425> (他のissueもあります)
>>>>>>>>> 
>>>>>>>>> 私は個人は状況(書体)次第だと思います。たとえば、ある楷書体のフォントには欧字がありますので、そのフォントで欧字を表示します。フォントには欧字がない場合は、font-familyは指定されていない場合と同じです。
>>>>>>>>> 
>>>>>>>>>> 木田
>>>>>>>>>> 
>>>>>>>>>> (ところで、娘が秋から中国の大学にゆくことになっている(どうなることやら)ので、私も最近中国語を学び始めました。それでやっと fuqiao をどう発音するのかわかりました。日本語のローマ字や、英語の知識では発音できませんものね :)
>>>>>>>>> 
>>>>>>>>> それはよかったです :)
>>>>>>>>> 
>>>>>>>>> Fuqiao
>>>>>>>>> 
>>>>>>>>> [1] https://github.com/w3c/csswg-drafts/issues/4910#issuecomment-607409677 <https://github.com/w3c/csswg-drafts/issues/4910#issuecomment-607409677>
>>>>>>>>> [2] https://github.com/w3c/csswg-drafts/issues/4910#issue-590599625 <https://github.com/w3c/csswg-drafts/issues/4910#issue-590599625>
>>>>>>>>> [3] https://github.com/w3c/csswg-drafts/issues/4497#issuecomment-593452824 <https://github.com/w3c/csswg-drafts/issues/4497#issuecomment-593452824>
>>>>>>>>> [4] 例えば、英語の場合は、アセンダーやディセンダーなどのfont metrics
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> 2020/04/16 1:26、Fuqiao Xue <xfq@w3.org <mailto:xfq@w3.org>>のメール:
>>>>>>>>>>> 
>>>>>>>>>>> 木田さん、
>>>>>>>>>>> 
>>>>>>>>>>> 急に登場し恐縮でございますが、W3CのFuqiaoです。
>>>>>>>>>>> 
>>>>>>>>>>> 私もこれらのissueをフォローしてきたので、以下の通りコメントさせていただきます。
>>>>>>>>>>> 
>>>>>>>>>>>>> On Apr 15, 2020, at 11:32 AM, 木田泰夫 <kida@mac.com <mailto:kida@mac.com>> wrote:
>>>>>>>>>>>> 下農さん、
>>>>>>>>>>>> 問題提起ありがとうございまーす。
>>>>>>>>>>>> フォントを使っての fingerprinting なんてやるんですね。と言ってもほぼ大多数の人はデフォルトのままなのでは、との疑問もありつつ。
>>>>>>>>>>> 
>>>>>>>>>>> 大多数の人はデフォルトのままなので、すなわち、大多数の人はデフォルトでプライバシー保護を得ます。[1]システムでインストールされる既定フォント以外のフォントを読むことは、大多数の人にとって必要ではないはずです。確かに必要な場合は、多分ウェブサイトにブラウザの設定を変更する方法が追加することができます。
>>>>>>>>>>> 
>>>>>>>>>>>>> generic font familyはどう定義されるべきか(すべての言語にわたって包摂的な分類はできるわけがない、ある言語でしか存在しないfont familyについてほかの言語にあった場合はどうfall backするのかなど)についての議論が急務であるところですので、あまりJLReqとして直結する急務な議論ではないとは思いますが、
>>>>>>>>>>>> 議論が急務なら、JLReq TF としても何か貢献できるといいですね。
>>>>>>>>>>>> とは言っても、現在決まっているもの以上に何かできるかというと簡単ではないように思います。現実には書体のカテゴリは各スクリプトでかなり異なります。それをまるっと無視すると、serif と sans-serif くらいしか抽出できないのではとも思います。高度に抽象化された現代的な書体に当てはまるこれらのカテゴリなら、文化的なバックグラウンドが少なくて、スタイルの統一に役に立ちます。
>>>>>>>>>>>> しかしそこから広げると、同じカテゴリに入るように見えても用途や雰囲気がかなり違う。例えば、バースデーカードをエレガントっぽく仕上げたくて cursive を選んでも、それを日本語にすると、例えば行書が出てくる? ぶち壊しです。(スタイルの italic も同様な問題がありますね)
>>>>>>>>>>>> そんな難しさがスタートポイントかと思います。
>>>>>>>>>>> 
>>>>>>>>>>> 私もそう思います。下農さんがおっしゃるように、日本語や中国語の書体は、英語(欧文)のcursiveなどのgeneric font familyに完全に対応できない場合があります。しかし、これが新しいgeneric font family(例えば、楷書体にfont-family: kaiとか)が必要な理由かもしれません。新しいgeneric font familyがあれば、フォント(書体 / generic font family)を細かく選択することができます。(例えば、楷書の記事では、font-family: kaiを使えば、突然英語のcursiveが現れません。)
>>>>>>>>>>> 
>>>>>>>>>>> よろしくお願いいたします。
>>>>>>>>>>> 
>>>>>>>>>>> Fuqiao
>>>>>>>>>>> 
>>>>>>>>>>> [1] https://github.com/w3cping/font-anti-fingerprinting <https://github.com/w3cping/font-anti-fingerprinting> と https://github.com/w3cping/font-fp-protection-browser-hinting <https://github.com/w3cping/font-fp-protection-browser-hinting> による
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> 木田
>>>>>>>>>>>>> 2020/04/15 11:13、Atsushi Shimono (W3C Team) <atsushi@w3.org <mailto:atsushi@w3.org>>のメール:
>>>>>>>>>>>>>  shimonoです
>>>>>>>>>>>>>  先週中にはメールを投げねばと思いつつずいぶん伸びてしまったのですが、、ブラウザ上でのフォント関
>>>>>>>>>>>>> 係についての話です。
>>>>>>>>>>>>>  いろいろすでにお聞きかとは思いますが、最近の大きな流れとして
>>>>>>>>>>>>> ・プライバシー問題上、システムでインストールされる既定フォント以外はブラウザで読まなくする
>>>>>>>>>>>>>   既定フォント = たとえば、日本語Windowsをクリーンインストールした時に入っているフォント、と思ってください
>>>>>>>>>>>>>   プライバシー観点からの詳細: https://github.com/w3cping/font-anti-fingerprinting <https://github.com/w3cping/font-anti-fingerprinting>
>>>>>>>>>>>>>   CSSのissue: https://github.com/w3c/csswg-drafts/issues/4497 <https://github.com/w3c/csswg-drafts/issues/4497>
>>>>>>>>>>>>>   safariはすでにこの措置が実装され、適用されています
>>>>>>>>>>>>> ・CSSのfont familyは現状のeuropian centricなカテゴリでいいのか、そしてgeneric font familyはどうあるべきかの議論
>>>>>>>>>>>>>   日本語だと現状で入ってないけれども多用されているのは丸ゴシック?
>>>>>>>>>>>>>    e.g. https://github.com/w3c/jlreq/issues/160 <https://github.com/w3c/jlreq/issues/160>, https://www.w3.org/2020/03/05-clreq-minutes.html#t01 <https://www.w3.org/2020/03/05-clreq-minutes.html#t01>
>>>>>>>>>>>>>   generic font familyについてのissue: https://github.com/w3c/csswg-drafts/issues/4910 <https://github.com/w3c/csswg-drafts/issues/4910>
>>>>>>>>>>>>> があります。
>>>>>>>>>>>>>  i18nとしてはOSにシステムフォントとしてバンドルされないような諸言語(ある種のマイナー言語的なカテ
>>>>>>>>>>>>> ゴリ)についての扱いの側面と、generic font familyはどう定義されるべきか(すべての言語にわたって包摂
>>>>>>>>>>>>> 的な分類はできるわけがない、ある言語でしか存在しないfont familyについてほかの言語にあった場合はど
>>>>>>>>>>>>> うfall backするのかなど)についての議論が急務であるところですので、あまりJLReqとして直結する急務な
>>>>>>>>>>>>> 議論ではないとは思いますが、丸ゴについてなど、いくつかの議論点があるかと思うところですので、コメ
>>>>>>>>>>>>> ントありましたらいただけますと幸いです。
>>>>>>>>>>>>>  よろしくお願いいたします
>>>>>> 
>>>> 
>> 

Received on Tuesday, 21 April 2020 08:57:01 UTC