GlyphWiki logo
ナビゲーション
ヘルプ
検索
ツールボックス
他の言語
利用者ページノート編集履歴

利用者-会話:sayunu

出典: フリーグリフデータベース『グリフウィキ(GlyphWiki)』

頂いた挨拶

  • こんにちは。匿名で高水準の編集を継続される方はなかなかいないので、おそらく同一の方なんだと思っていましたが、アカウント取得ありがとうございます。 --kamichi 2009年7月19日(日) 22:26

  • こんにちは。ここ数日の匿名利用者のうち、何か一貫した作業をしているのは大体私です。継続して参加というより気が向いた時に来ると思いますが、よろしくお願いします。(管理者には IP アドレスが見えているものと思ってましたが、そうでもないんですね。)— sayunu 2009年7月19日(日) 23:01

  • 卒論お疲れ様でした。--kamichi 2010年1月13日(水) 12:12

  • 終わってよかったです。ありがとうございます。— sayunu 2010年1月15日(金) 17:03

  • 感謝の言葉を忘れていました。非漢字(特にラテン文字など)を整えてくださって本当にありがとうございます。私の非漢字のデザイン実力はまだまだなので(自分でも気に入らないことがたくさんあります)、sayunuさんの修正をいつも感謝しています。 --johotogoshinentai 2013年4月7日(日) 16:14

思うことや分からないこと 1: 字形の統一

  • 利用者ページより転載:
  • (1) 規格票の例示字形みたいなものに、例示以上の意味を持たせるのは悪だと思います。例えば、JIS X 0213 の例示字形にただぴったり合わせたフォントを作っておいて「新 JIS に準拠」とか言うのは、包摂規準という「解釈のしかたの指示」に従っていないわけで、態度の点で JIS 非準拠です。(毎年改定して、全ての例示字形を微妙に変えてやればいいのに。包摂の範囲内で。)
  • (2) グリフウィキの符号位置ごとの代表字形も、単純に例示をなぞるのではなく、統一的なデザイン方針が必要でしょう。各国の原規格における包摂規準まで見に行くべきかもしれない。

  • 現実問題として、「例示」が「規範」的要素を持ってしまうのは仕方がないと個人的に考えます。「例示」の意味を理解した上であえて「規範」とする、これが精一杯かと。さらに通常のフォントのように1人または特定の数名がポリシーを決めて作業するのと違い、グリフウィキは不特定多数(実質的には特定多数に近いですが)となるので、主観をできるだけ排除できる規範が求められ、それが「例示字形」になるのは自然な成り行きと思います。たとえばグリフウィキの場合、「-itaiji」を使って独自の字形で漢字集合をそろえてしまう、ということも理論的には可能です。
  • これは(さゆぬ注: (2) は)頭が痛いです。たとえば明確にGソースの文字を日本デザインにするか否か、ゴンベンの1画目が点でいいのか、Gソース風でいいのか、現状では揺れています。 --kamichi 2009年8月14日(金) 13:18

  • [ sayunu 2009年8月23日(日) 19:28 ]
  • 冒頭は特にグリフウィキの話というより、JIS の改訂の度に世間のフォントが包摂範囲内の微細な例示変更に追随するとしたら無駄だなあという事でした。制定する側にも迷惑な話だし。グリフウィキの符号位置 代表字形も、次の JIS で字形が変わったら追従するんでしょうか。
  • 多人数でやるからこそ、「この位置・この部品はこの形で統一する」などという一貫した明文の方針が必要なのでは。と言うのは、おっしゃるようにソースごとの違いをどこまで反映するかの件なんですが。
  • 例示をなぞるにしたって「どこまで似てれば同じなのか」恣意的ではないですか。CID とか戸籍統一文字とかいうものの粒度が念頭にあったりするんでしょうか? 例えば、利用者登録前に「縁」@5 の右上の縦画をちょっと傾けたら「規格票に合わせる」ってまっすぐにされましたが、そこも区別するんでしょうか。するとここが傾いてるヒラギノは「非準拠」? 逆に、平成明朝体では(私が持ってるフォントを見ると)「興」の右側の縦画が傾いてるようですが、垂直になっていると「非準拠」?
  • 縁(u7e01@5)
  • 興(u8208)

  • mashabowです。とりあえず、規格票字形追従の是非はさておき……
  • JIS X 0213:2004 の漢字については、花園明朝2008年10月12日版の公開準備のときに一度すべて規格票字形と突き合わせました(kamichiさんやuakiraさん、mashabowなどが作業にあたりました)。どこまで規格票字形に合わせれば「規格票字形」なのかという点については特に明示的な合意はありませんでしたが、私は以下のような差異は無視し、これらについては規格票字形に無理には合わせませんでした。
    • 「臼」などの縦画が傾いているか否か
    • 横画の下にある縦画・左払いなどの頭形状が接続か開放か
    • 横画の下にある縦画・左払いなどの頭が接触するか否か
    • 「華」「畢」などの下部の横画について、相対的な長さの違い
    • などなど
  • 他の方も、当時はおおよそこのような基準で作業していたと思います。 --mashabow 2009年8月24日(月) 01:26

  • y-iijimaです。こんにちは。字形については難問ですが、sayunuさんはいろいろとこだわりをお持ちのようなので、ご自身の理想をまずは私案として明文化されてみてはいかがでしょうか?
  • 具体例については、u7e01@10u8208@3もISO/IEC10646規格票のJ欄とよく一致しているので、私には問題ないと思えます。逆にu7e01@5はISOのJ欄と一致せず(もちろんG欄・T欄とも一致せず)大げさに言えば規格外の異体字に見えます。規格票の字形よりu7e01@5を優先したいということであれば、なぜ規格票と異なる字形が優先になるのかを多くの人に納得させる努力も必要かと思います。--y-iijima 2009年8月24日(月) 08:50

  • [ sayunu 2009年8月24日(月) 12:49 ]
  • mashabow さん、いいですねそういうの。そういう明文化が望ましいです。縦画の傾斜の有無は同じものと見なし、一々合わせなかった、ということですね。
  • まづ私案を書いてみるっていうのは確かにそれが一番なんですが、それをやるとなると凄い時間を食いそうなので「合議で出来ませんかね」という感じなんです…。前回の返信だって ほかにやること有るのに時間掛け過ぎていて、最近何時間にも渡ってグリフ弄ってるのも、止まらなくなってるだけです。
  • それで規格外ということですが、規格に適合するか否かというのは「大げさに言えば、言わなければ」という連続的な話ではなく、間に断絶が有ると思います。例示に無い字形だと言っても、10646 の個々の文字は、背後に横たわる包摂規則に基いた包摂範囲を持っているわけで、その範囲内には字形の優先順位も有りません。「縁」の縦画が傾斜した字形は U+7E01 の範囲に含まれると考えますし、実在しない嘘字というわけでもありません(ヒラギノ明朝などの例)。これが包摂されないとすると、「縦画が傾斜する縁」を U+7E01 とは別に統合漢字に収録する必要が出ます。
  • でも確かに、規格票と違うということを認識しつつそう作る場合は、デザイン意図をノートに書いておく方がほかの方にも分かりやすいし、必要なら議論を提起しやすいですね。u7e01@5 については、今見ると我ながらヘボデザインなのでアレですが、その方が重心を取りやすいかなと思ってのことでした。(規格票は見ずにやりました。)
  • 例示に合わせておけばよかろうという事なかれ主義は、フォントを製造して販売する商業的な立場で、省力の意味で行うのは分からなくないし、グリフウィキでも未作成の文字をどんどん作って行くという場面で一々悩まないで例示に合わせておくのも分かりますが、グリフウィキが最終的に目指す所ではないと思います。その悩みを軽減しつつなるべく統一を取るために、分かりやすく明文化した方針が有ると便利。
  • それとは別の話で、グリフウィキの字形としては、あまり例の無い少数派のデザインよりは「よくあるデザイン」にした方がよいというのも分かります。「縁」の例で縦画が傾くのが「珍しいデザイン」なのかは、広い調査をしてないので知りませんけど。規格票例示字形は「よくある方のデザイン」であるとは期待できますが、例示字形がその意味で最善のデザインとは限らないだろうと思います。乱文失礼、今回も時間を掛け過ぎました。
  • あ、あと、規格票 PDF 見てて思ったんですが、J 欄・K 欄の文字って線がふにゃふにゃしてて、凄くグリッドの粗いベクター画像に変換してあるって感じですね。これではそもそも微妙な傾斜なんて表現できず、垂直・水平線に化けちゃうんぢゃないかなあ。

  • 規格表に似せた癖の無いバージョンと重心を整え錯覚を抑えたデザイン重視のバージョンの両方を作るのが理想かと。また、後者は本文向けや見出し向け(黒み調整)など細分化できますし。
  • 全ての漢字の手動でのデザインの調整は手間がかかるので、完全でなくても良いのである程度自動化を目指すべきです。そのために、以前も言ったようにデザインのよさとは何かをABテストなどで客観的にはかり具体化することが重要だと思います。--匿名利用者 2009年8月24日(月) 14:41

  • y-iijimaです。ちょっと誤解を招いたかもしれないので補足します。「大げさに言えば異体字」と書いたのは「包摂されない」という意味ではありません。包摂基準を野球にたとえたら、あるバッターのストライクゾーンです。外角のスライダーだろうが内角低めのフォークだろうが、縦画が傾斜していようが、ストライクはストライクで、どれもu7e01に含まれます。ただ、そのすべてに「u7e01」という「ど真ん中」のグリフ名を与えることはできません。どれか1つを「u7e01」にしたら、他のやつは「u7e01-itaiji-00X」にしなきゃいけない。となると、やはり「u7e01」はど真ん中の直球でなければならず、少し外れた変化球だったらitaijiにする、ということになろうかと思います。そういう感覚で「大げさに言えば異体字」と書いたのであって、あくまでもストライクゾーンの中での話ですので悪しからず。--y-iijima 2009年8月24日(月) 15:40

  • [ sayunu 2009年8月25日(火) 14:22 ]
  • y-iijima さん、そういう意味なんですね。分かりました。その喩えで言えば、どの字体がストライクゾーンの真ん中なのか判断できないのが問題ですね。もし JIS の規格票に u901f-ue0100 が例示された場合の包摂範囲と、u901f-ue0101 が例示された場合の範囲は全く一致するので、「その包摂範囲を代表する字体」としてはどちらも同じだけ資格が有ります。JIS は字体を規定してないわけで、真ん中を選ぶ基準は、字体を規定してる常用漢字表・表外漢字字体表なんかでしょうか。それが即ち「よくあるデザイン」だし。(勿論「拂うか止めるか」というデザインは規定してないので別だけど。)
  • 匿名の人、代表字形の一個ばかりに固執せず、異体として色々な字形を作って行くのがいいとはそう思います。その中に「JIS 何年版の例示字形」も全て有ると。既存の字形を大きく変える時は、itaiji に逃がしておくのがいいです。「速」のハライ版とトメ版は両方有るといいな。
  • でも、錯視調整や本文・見出し用といった所まで分けるのはどうか、と言うか KAGE の生データでそこまでこだわれるのかという感じがします。それはレンダリングする側が処理したらいいのでは…。AB テストとかはよく知らないから実際にどうやるのか想像できないけど、一応綺麗に完成している二つの字形について、ある程度の人数がここに来ていれば「ねえこれどっちがいい?」って出来るのかな? 具体化というのは「これこれの場合はここがこうなるようにデザインせよ」といった言葉で? みんなでそれぞれデザインノウハウを書いて総合するっていうのもいいですね。
  • 符号位置は字体の包摂範囲に対応し、特定の字形には対応してないということを思うと、現在のグリフウィキの、ある符号位置に無印で特定の字形が記述された状態は追々不便になる気がします。符号位置はグリフページではなくグリフ一覧ページとし、その符号位置の下位に含まれる字形が列挙され、そのうち一つを便宜上の代表として採用するというインターフェイスがいいな。

思うことや分からないこと 2: 包摂規準とか

  • 利用者ページより転載:
  • JIS と Unicode って包摂の範囲が違うから、対応が定められていると言っても実は別の文字ですよね。でも Unicode の包摂規準ってどんなのかよく分からない。

  • 厳密にはグリフウィキはUnicodeではなくISO/IEC 10646をベースとして考えています。それで、ISO規格の包摂基準というのは、あえて言えばAnnex Sですが、これは参考的なものであって完全ではありません。golconda氏の調査された http://kanji-database.sourceforge.net/ucv/index.html などは一つの情報ではあります。 --kamichi 2009年8月14日(金) 13:18

  • sayunu 2009年8月23日(日) 19:28
  • URL を頂きありがとうございます。そのページ Safari だと動作がおかしいけど…。
  • ISO/IEC 10646 を「ベース」とするのはよいですが、原規格分離(飲飮)とか包摂のバグ(桟栈)まで全て呑むことはないと思います。各代表字の名称以下に包摂される範囲はシステム全体で一定している方がいいです。

思うことや分からないこと 3: 部品の設計

  • 利用者ページより転載:
  • グリフウィキの部品は、使う時に(左右結合なら)上端を 0、下端を 200 の座標に合わせておけば大抵ぴったりになるように設計したい。(上下結合なら左右の端。)

  • 本来はそのはずなんですが…、異なるものを潰していくしかないですね。 --kamichi 2009年8月14日(金) 13:18

  • sayunu 2009年8月23日(日) 19:28
  • そのはずだったんですか? どこかに書いてありましたっけ。折角 0/200 で引用していても、現状の一括更新では微妙にずれてしまうのが残念です。

思うことや分からないこと 4: var と itaiji

  • 利用者ページより転載:
  • var と itaiji ってどう違うのかな。異体字って英語で variant ですよね。字体差とデザイン差の区別だったりする? どちらも var とか v とかに統合してはダメ?

  • 明示していませんが、たぶん「itaiji」よりも「var」はデザイン差に近い(だから異体字という表現をしたくない)というニュアンスが含まれています。当初、英語的要素はなるべく排除しようと思い、「itaiji」としましたが、逆にグリフ名は多言語化してもそのまま利用するので「var」の方が良かったと思うようになってしまいました。現状では意味に差が発生しているようなので、お手上げ状態です。 --kamichi 2009年8月14日(金) 13:18

  • [ sayunu 2009年8月23日(日) 19:28 ]
  • 確かに、ハライの長さだけ微妙に調整したのと、点の向きがハからソに変わってるのは、命名上区別したいです。撥ねる撥ねないがデザイン差なのかとか、よく把握してませんけど。でもそうすると var と itaiji という名前は変です。一括改名って出来ないんですかね。
  • とは言っても、明らかに字形が異なる部品グリフを var としている例もあります。単に「無印は itaiji、部品は var」みたいになってしまっている所があると思います。(というか私がそんな感じでした。)
  • u96da, u96da-02-var-001
  • u5f56-02, u5f56-02-var-001
  • なお、部品グリフで itaiji と命名しているのは次の例で多分全てです。代表グリフで var を付けている例はありません。
  • u826f-02, u826f-itaiji-001-02
  • u241fe-03, u241fe-itaiji-001-03
  • u2696f-03, u2696f-itaiji-001-03
  • u4e91-04, u4e91-04-itaiji-002

  • mashabow です。とりあえず私が作った u826f-itaiji-001-02 については、u826f-02-var-001 に移動しました。
  • 経緯としては、「var を使う」と方針が示されたのが2009年7月5日(ノート:u9801-03@6)、命名ガイドラインに明記されたのが8月4日(GlyphWiki:命名ガイドライン@47)なので、そこまで var が周知されていない、というのもあるかもしれません。
  • itaiji ではなく var(iation) を提案した(ノート:u4e59-01)意図としては、次のようなものがあります(すみません、これも明示的には書いていなかったんですが…)。
    • 「異体字」というほどでもない、「デザイン差」程度のグリフの命名にも使いたいため。
    • 部品のバリエーションを uXXXX-01-itaiji-001 のように命名すると、uXXXX-itaiji-001 と直接関係しているように(すなわち「uXXXX-itaiji-001 の字形・デザインをそのまま部品化したのが uXXXX-01-itaiji-001 である」というように)受け取られかねない。
    • もちろん「uXXXX-itaiji-001 の字形・デザインをそのまま部品化したのが uXXXX-01-itaiji-001 である」をルールにしてしまうという手もあるが、この場合 uXXXX-itaiji-001 と uXXXX-01-itaiji-001 との整合性を維持するのが面倒。そもそもすべての異体字が itaiji で命名されているわけでもないし、その他の点でもメリットが思い浮かばない。
  • という感じです。
  • 個人的な意見としては、itaiji と var を統一する必要はなく、単に「無印は itaiji、部品は var」で問題はないと思います(kamichiさんのおっしゃるように、多言語化まで考えると微妙なところですが…)。統一するとした場合、上に書いたような uXXXX-var-001 と uXXXX-01-var-001 との関係についても考えなければなりません。--mashabow 2009年8月31日(月) 20:02

  • [ sayunu 2009年9月3日(木) 21:30 ]
  • 見解を共有させて頂いてありがとうございます。初期の var の意図は次の二点だったんですね。
    • (1) 異体字という程でもない字形差も表現するため
    • (2) 無印を -itaiji-001 とし、部品を -var-001 とすることで、同じ接尾番号を持つグリフ同士に関係が見出されることを避けるため
  • そして現在の結論は「(3) 無印は itaiji、部品は var という方針でよい」と。
  • (3) は (2) と同じ方向ですが、(1) は別の話ですね。(1) について言えば、無印にもデザイン差グリフはあるわけですから、そういう物は itaiji でなく var で命名することにしないと一貫性が無いのでは? でも結論が (3) ということは、最初は (1) も考えたけどやっぱナシということでしょうか。つまり、異体字という程に大きな字形差が有っても部品ならば var とし、逆に無印ならばデザイン差であっても itaiji とすると?
  • (3) の方針で行くと、u26c29-01@3 の字形と u26c29-01-var-001@1 の字形は部品用だから var で命名するけど、u26c29@4 の字形と u26c29-var-001@2 の字形は部品用ではないので itaiji で命名するという形になりますが、そういうことですか?
  • (2) については、その目的で var と itaiji を分けることはあまり効果的ではないと思います。無印と部品との間の問題はそれで回避できますが、部品グリフ同士の間にも同じ問題が有ります。つまり -01-var-001 と -04-var-001 の関係です。これは var と itaiji の使い分けで回避するのではなく、方針として「同じ接尾番号でも関係が有るとは限りません」というのを立てるべきです。(あるいは「同じ接尾番号では一貫性を維持する」という方針でもいいですが、別の話。)
  • ちょっと考えたんですが、var は「包摂範囲内の字形差」、itaiji は「包摂範囲を超える字形差」を表すことにしてはどうでしょうか。具体的に var・itaiji と命名するかは置いておいて。つまり u96da-02-var-001 の字形は UCS に収録されていない(いかなる符号位置の包摂範囲にも入らない)ので、u96da 以下に itaiji として命名する。包摂範囲内の字形差は、無印グリフであれ、部品グリフであれ、var を使う。

思うことや分からないこと 20.

  • 確認はしていませんが、おそらくということでご参考まで:初期デザインの際に参考にする字形は過去の明朝体活字を指定しました。おそらくそのデザインで引っ張られているものと思います。平成明朝体は初期デザインとしては参考にしていませんが、その後のデザインにて優先的に参考とする方針に暗黙的に移行したものと認識しています。--kamichi 2010年6月7日(月) 12:39
    • なるほど、元々は平成明朝を参照してなかったんですね。— sayunu 2010年6月11日(金) 13:29