Re: Meeting notes 2020·12·01

Nat さん曰く：
> 調べてみればU+2010はSJIS 0x815Dから来ていて、和文フォントであれば全角扱いにしたようです（Adobeジャパンからの仕様）。アキ量はCIDで決める設定になっていれば（このバグの）横組み用字形であれば４分空きは入るようです。

SJIS の亡霊ですね。ま SJIS ではなくて Unicode のマッピングが悪いんでしょうけれど。

田嶋さん、バージョンは /Library/Fonts などにあるフォントファイルを選んで Command-I すれば出てきまする。

> なので当面EPUB的には「縦組みではU+2010使うのは怖いからU+002Dに置換しておいた方が安全」みたいな話にはなりそうですね。

いやいや、普通の人はモリサワパスポートや源ノなんて入れてませんし、入れていても EPUB リーダが使いませんから ^^;  そんな特殊ケースは無視無視（できません？）

ただ、ヒラギノの古いバージョンで正立のままになるとしたら、OS のどのバージョンから標準でそれが期待したようになっているかは重要な情報ですね。Pro と ProN の違いだとしたら平和なんですが。

木田

> 2020/12/03 13:17、田嶋　淳 <tajima@sanyosha.co.jp>のメール:
> 
> ナットさま
> 木田さま
> みなさま
> 
> ちょっとフォントバージョンはどこを見ればいいやらなのですが、モリサワパスポート経由で入れたものだと思われます。また、追加で見てみたところ、N付きフォントに関してはヒラギノも横転する傾向がありました。ただ全部ではなかったので制作時期によるんでしょうかね。それと源ノ明朝／源ノゴシックも正立します。つまりアドビも。なので当面EPUB的には「縦組みではU+2010使うのは怖いからU+002Dに置換しておいた方が安全」みたいな話にはなりそうですね。
> 
> <スクリーンショット 2020-12-03 13.11.15.png>
> 
> 
>> 2020/12/03 13:09、Nat McCully <nmccully@adobe.com>のメール:
>> 
>> 調べてみればU+2010はSJIS 0x815Dから来ていて、和文フォントであれば全角扱いにしたようです（Adobeジャパンからの仕様）。アキ量はCIDで決める設定になっていれば（このバグの）横組み用字形であれば４分空きは入るようです。
>>  
>> ナット
>>  
>> From: 木田泰夫 <kida@mac.com>
>> Date: Wednesday, December 2, 2020 at 7:55 PM
>> To: 田嶋　淳 <tajima@sanyosha.co.jp>
>> Cc: JLREQメーリングリスト <public-jlreq-admin@w3.org>
>> Subject: Re: Meeting notes 2020·12·01
>> 
>> うぉ。問題のあるのは U+2010 横転のヒラギノProN だけですかね？　大日本スクリーンの人に問題を認識しているか聞いてみます。バージョンはわかりますか？
>>  
>> 木田
>> 
>> 
>> 2020/12/03 12:33、田嶋　淳 <tajima@sanyosha.co.jp>のメール:
>> 
>> 
>> みなさま
>>  
>> InDesign日本語版デフォルト設定、縦組みでテキストを流した時にダーシ・ハイフン等に使われる記号類のフォント別の挙動がどうなるかをちょっとテストしてみました。U+2014などではDNPやタイプバンクは中央に来るように設定をいじってますね。あと別枠ですがハイフンが横転してしまうヒラギノ怖いです（笑）。
>>  
>> <縦組みでダーシ・ハイフン等が中央に来るかテスト.pdf>
>> 
>> 
>> 2020/12/03 9:00、Kobayashi Toshi <binn@k.email.ne.jp>のメール:
>>  
>> 小林龍生　様
>> 木田泰夫　様
>> みなさま
>> 
>> 　小林　敏　です．
>> 
>>  小林龍生　さんwrote
>> 
>> 
>> ところが、今回、敏さん・木田さんテーブルとJISとの対応付けを試みてみて、抑えき
>> れない妄想が湧き上がってきたのですね。
>> すなわち、（いまでも引きずっている）シフトJIS的環境（もしくは指に染みついた慣
>> 習）による非漢字の運用と、JIS
>> X0213の非漢字全体を対象とした非漢字の運用との間に、何とも表現しがたい深淵が潜
>> んでいるのではないか、という。
>> 前回のミーティングで、ぼくが提起した問題を、ぼくなりに敷衍すると、以上のよう
>> なことになります。
>> 
>> 私も，今回の議論をしていて，いままでの考え方を基本的に変えないといけない
>> な，という感じでいます．それをうまく表現できないのですが，文字クラスを
>> Unicodeに対応したものに変えるということは，これまでの活版的な考え方，電
>> 算植字的な考え方，あるいはDTP的な考え方でとは違った考え方をしないといけ
>> ないかと思っています．もちろん，こうした過去の技術で考えてきたことには，
>> ある種の合理性があり，それを学ぶ必要はもちろんあろいうことは前提です．
>> 
>> 別にいえば，小林さんのいうシフト“JIS的環境……”での運用ではいけないと
>> 思うようになっています．いくつか例を挙げます．
>> 
>> 1　連数字問題
>> 　これはJIS的環境ではなく，電算植字的環境の問題．Unicodeには，そんなもの
>> は存在しない．一般のアラビア数字として扱っている．これは単純に連数字の文
>> 字クラスを削除すればよい．
>> 
>> 2 欧⽂⽤⽂字（cl-27）という言い方
>> 　これはまさにJIS的環境を前提にしている．下農さんがいう“アジアの諸言語
>> とかアラビア語とかも混植になることはあると思う”を考えれば，文字クラス名
>> を変えないといけない．今，私の考えているのは“ラテン文字”といえば，とい
>> うこと．それ以外のものの扱いは，必要なら，別の文字クラスを考えればよいし，
>> とりあえず，ベタ組にして，2行にわたる分割はUnicodeを参照すればすむことと
>> 思います．
>> 
>> 3　非漢字
>> 　これがもっとも問題が多い．そこで，以下のように分けて，その対応を考えて
>> いけばよいのではと思っています．その先には，前置省略記号（cl-12）と後置
>> 省略記号（cl-13）だけでなく，ハイフン類（cl-03）や分離禁⽌⽂字（cl-08）
>> の文字クラスの削除，あるいは分類を考え直す必要があるように思っています．
>> 
>> 　この問題は，英文などの影響から，英文の非漢字が和文でも使用されるように
>> なっている．しかし，その定着度が異なり，以下の分類でいえば，aとbは和文ま
>> たは英文のルールでよいが,cとdが問題．dは，和文での使用が定着し，和文の
>> ルールが必要である．これに対し，cは，使用例も少なく，ルールも，ある意味
>> であいまいであるし，いろんな配置方法がとられている（最も詳しく，こうした
>> 非漢字の配置法を記述したものに“校正技術”（日本エディタースクール出版
>> 部）という本があり，これでは明確に示しているが）．
>> 
>> a　和文としか用いない
>> 　例　※，【】，〈〉など
>> 
>> b　ラテン文字などでしか扱わない
>> 　例　アポストロフィ
>> 
>> c　ラテン文字で主に使うが，わずかに和文でも例がある
>> 　ハイフン，二分ダーシ
>> 
>> d　ラテン文字が由来であるが，和文で定着している
>> 　パーレン，アステリスク，疑問符，％など
>> 
>> これとはすこし違いが，縦組と横組の問題がある．縦組では和文的な全角のラテ
>> ン文字アラビア数字があり，横組で，これらの使用を避けた方がよいという考え
>> 方があり，その意味では，縦組はより和文的，横組はより英文組版的ともいえる
>> ので，それをどう考えるか，という点もでてくる．
>> 
>>  
>> ***************************************
>> （株）三陽社
>> 　メディア開発室
>> 　http://www.sanyosha.co.jp/
>>  
>>  田嶋 淳
>>  tajima@sanyosha.co.jp
>>  
>> 　※ブログ運営中です。
>> 　　ご意見をいただければ幸いです。
>> 　　http://densyodamasii.com/

>> ***************************************
> 
> ***************************************
> （株）三陽社
>  メディア開発室
>  http://www.sanyosha.co.jp/

>  
>  田嶋 淳
>  tajima@sanyosha.co.jp
>  
> 　※ブログ運営中です。
> 　　ご意見をいただければ幸いです。
>   http://densyodamasii.com/

> ***************************************