- From: Kobayashi Toshi <binn@k.email.ne.jp>
- Date: Sat, 30 Oct 2021 18:02:49 +0900
- To: "Atsushi Shimono (W3C Team)" <atsushi@w3.org>, W3C JLReq TF <public-i18n-japanese@w3.org>
下農 様 みなさま 一部修正いたしました.【 】です.また,注記でなく,本文でもかまいません. 小林 敏 です. 別の注記を書きましょう.()内は補足説明で,ドキュメントでは削除する. モノルビの簡略化1 モノルビでは,親文字とのルビの位置関係で【主なものとして】以下のような方法がある.ここでは1を採用した.なお,ルビの文字列はベタ組である.(現在のルビは,1方式またはその変形方法が徐々に増えているが,3の方式は伝統的な出版社では採用している例は多い.ある意味3の方法は活字組版の個別処理が可能なことが前提の方法で,もうそれはやめていいんではないか,と私は思っている.) 1 親文字の中心とルビ文字列の中心をそろえる. 2 親文字の先頭とルビ文字列の先頭をそろえる 3 親文字の先頭とルビ文字列の先頭をそろえる方法を原則とするが,親文字よりルビ文字列の長さが長い場合,後ろへのはみ出しを優先する.前後の文字種によりルビと親文字との配置位置は変わる. モノルビの簡略化2 親文字からルビ文字列がはみ出した場合,前後の文字に掛けるか掛けないかでは,【主なものとして】以下のような方法がある.ここでは1を採用した.この簡略化は,グループルビ,熟語ルビの場合でも同じである.(現在は,1はそれほど多くないが徐々に増えている.簡略化の3方式と組み合わせて2が多いが,これも前後の状況でルビの位置を変える.これも行の調整を少なくする効果もあり,前述の活字組版の方法であり,もうやめていいんではないかと思っている.) 1 親文字の前後の文字には,アキのある約物を除き,掛けない. 2 親文字の前後の漢字には掛けないが,仮名や一部の約物には親文字サイズの1/2を掛ける. 3 親文字の前後の文字には,文字種を限らないで親文字サイズの1/4を掛ける. モノルビの簡略化3 親文字からルビ文字列がはみ出した場合,【主なものとして】以下のような方法がある.ここでは1を採用した.2の場合には,簡略化1で採用した配置方法を変更しないといけない.この簡略化は,グループルビ,熟語ルビの場合で同じである.(行頭・行末をそろえるか,親文字とルビとの配置位置を優先するかという問題であるが,印刷物でも1の方法は徐々に増えているので,1でいいでしょう.) 1 行頭ではルビ文字列の先頭,行頭とルビ文字列の末尾をそろえる. 2 行頭では親文字の先頭,行頭と親文字の末尾をそろえる. グループルビの簡略化 グループルビでは,ベタ組にした親文字列とルビ文字列の全長が異なる場合,【主なものとして】以下のような方法がある.ここでは1を採用した(ラテン文字の場合は除く).ルビが親文字からはみ出した場合は,モノルビの簡略化の2及び3と同じ簡略化と同じである. 1 短い方の文字列の先頭,末尾及び字間を空ける.先頭及び末尾と字間との比率は,原則として1/2にする. 2 短い方の文字列の字間だけを空け,両方の長さをそろえる. 3 親文字列とルビ文字列ともにベタ国とし,それぞれに先頭,末尾または中心をそろえる. 熟語ルビの簡略化 【熟語ルビは,モノルビ又はグループルビの処理の組み合わせである.それぞれの簡略化の方法を採用した.…すべて削除】【熟語ルビでは,主なものとして以下のような方法がある.ここでは1を採用した.2又は3の処理法は簡略であるが,熟語ルビの性質から,あるいは,ルビと親文字の対応方法を変えれば,この方法は採用できることから,採用しなかった.(現在では4の方法が伝統的な方法として採用されている例が多いが,この処理は,とても複雑であり,努力するほど読みやすさが増大するといことではないように思われる.) 1 熟語ルビを構成する各親文字に対応するルビの文字列の長さにより,各親文字に対応するルビをモノルビで処理するか,又は熟語ルビ全体をグループルビとして処理する.】 2 熟語ルビを構成する各親文字に対応するルビの組み合わせにより,それぞれをモノルビとして処理する. 3 熟語ルビ全体をグループルビとして処理する. 4 熟語内では,各親文字と対応しないルビについて,その前後の漢字に親文字サイズで1/2まで掛かってよいとする処理を行う.この方式では,親文字列からのルビのはみ出しは,モノルビで説明した2の方法による.他にも,細かいルールがある.】 > How do I know which parts are requirements vs which parts are simplifications from the more complicated specs? >C-g) C-#46-6 > 前半の何が簡略化されたんだ?という点について、章立てに関するところで >すが、いまの2.のとこ >ろから2.2だけ抜いて、2.1/2.3で背景情報の章、2.2でsimple-rubyでの前提要件の章、 >にするのはいいのか >も、と少し思いました。2.2だけ取り出して章を立てた場合、中の3と5は処理方針、1, >2,4は前提要件、と2つ >の節に分けてもいいかもです?が、ここら辺の再編、いかがでしょうか?
Received on Saturday, 30 October 2021 09:04:24 UTC