GlyphWiki logo
ナビゲーション
ヘルプ
検索
ツールボックス
他の言語
グリフノート編集履歴

ノート:sayunu_sandbox

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

考える場所

  • [ 13. 2010年1月9日(土) 22:16 ] 揃えなきゃ。縦方向と横方向に変形するから難しい。
u5382@4u5382-05@5
u5e7f@2u5e7f-05@3
u7592@5u7592-10@1u7592-10-var-001@1
u9e7f-05@3u9e7f-10@4
u9ebb-05@2
u9ebb-k05@1u9ebb-k10@1
u6236-05@2u6236-10@1
u6237-05@4
u6238-05@4←誰も使ってない
u864d-05-var-001@1u864d-05@6u864d-10@3
cdp-88bc@3
などなど

  • [ 14. 2010年1月11日(月) 01:26 ] 戸の垂れ。横幅は揃えられたけど、縦は個々にぴったりの幅が違って使い回しにくい。一画目が「ノ」の奴とも揃えたいが、一画目が「一」の場合と横最大幅が異なるから困る。単純に二画目以降を揃えても大丈夫かな。
  • 無論、部品化しにくい物を無理に部品化する必要は一切無い。
  • 「扉」の中の「非」は、独立の「非」よりも間隔が狭い方がいい気がする。
  • 下に寄ってるなあ。特に「扈」。上端の横画は縦座標 29。
  • u623b@3 u623f@2 u6249@3 u96c7@2 u6248@2

  • [ 15. 2010年2月17日(水) 01:14 ] ウ冠の一画目はもっと短くした方が良かったなー。今度直すか。影響が大きいんだよな。それだったら、ワ冠の二画目の始点が、一画目を僅かに貫通しちゃってる所から直したい。

  • [ 16. 2010年2月21日(日) 02:31 ] もっとみんな饒舌になろうね。グリフを編集する時、どんな意図なのか書こうね。特に、微細で分かりにくい編集の場合。「新規」みたいな明らかな事は別に要らない。これは自戒でもある。

  • [ 17. 2010年3月8日(月) 14:40 ] 最初は、何も見ずに頑張って作る。一点一画の始点・終点・中間制御点、全て自分で考えられる限り最善の調節をする。次に、お手本と比べる。マトモな明朝体を幾つか持っていればいい。近付いたり離れたりして舐める様に見る事。まあまあ、同じぐらい美しければ投稿。ああ、自分のグリフは下手だなと思ったら、盗もう。大丈夫、なぞるのではなく、幾つかの明朝体に共通のデザインを真似るんだったら、著作権の侵害にはならないと思う。そうやって鍛える。(MS 明朝はかなり癖が強いので、お手本としてはちょっと…。平成明朝でも良いし、IPA 明朝は無料だから入れといて損は無いのでは。あと私はヒラギノ明朝。)

  • [ 18. 2010年3月21日(日) 21:27 ] 〈sandbox〉とは「砂場」の事で、つまり色んな物を作ったり壊したりしてみる場所という意味なので、何か特定のグリフの恒久的な名前として使うのはおかしいと思う…。まあ占有グリフの命名は自由ですけど。(←直接言え。)

  • [ 19. 2010年3月21日(日) 21:27 ] 賢い肉付けエンジンなら、曲線の始点と終点を与えるだけで、平均的な位置に中間制御点を補ってくれると思う。自動ではうまく行かない様なグリフでのみ中間制御点を手動で指定するという形だと便利だし、デザインが統一されるんだけど。あと〈亡〉みたいな直角に曲がる線って、中間点まるで要らないよね。縦拂いも三個目までの点が一直線に並ぶなら、その分の情報は蛇足だよね。

  • [ 20. 2010年6月5日(土) 12:23 ] どうして〈千〉みたいに左拂いの途中から縦画が伸びる字形って、「初期データ」では接続になってないんだろう。平成明朝などでは接続してるのに。それと左拂いがやけに長かったりするし、その頃の肉付けは現在と違ったのかなあ。

  • [ 21. 2010年7月19日(月) 11:10 ] かつて私が作った仮名は、本当に漢字と混植されるとは思わなかったから、かなり大きく作ってあるけど、全部小さめに直した方がいいかも知れません。どうやら(曲がりなりにも)一通り出来たみたいなので、並べて組んだ時に揃って見える様にしたいですね。
  • 特定一種類の書体だけを手本にして作ると、その書体の癖まで引き継いでしまうので避けたい所。
    • はっきり言ってしまえば、一部の仮名が MS 明朝臭いのが嫌です。17 で書いたけど、参考にするなら複数の書体を見てほしい。— sayunu 2010年8月5日(木) 19:40

  • 縦方向の中央揃えについて考えたい。例えば「二」の字。単純に考えたら、枠の上端からの距離と下端からの距離を等しくすればよい。すなわち、一画目と二画目の縦方向の座標値の和が 200 になる様にするのが基本。
  • ただ、実際に肉付けをすると上にウロコが付くので、全体を多少下にずらした方がいいかも知れない。まあしなくてもいいんだけど、するならするで統一したい所。下へ 1 px、これでどうか。「三」「工」「王」などが該当する。和は 202 になる。
  • 一方、「口」などはどうするか。やはり基本的には骨格の位置で、上と下の和を 200 にする。しかしこっちは下にゲタが出るので、少し上にずらしたい所。上へ 1 px。和は 198。
  • 開放形状の縦画は上端の限度が 14、下端の限度が 186。そんなに突っ張る必要が無ければ 17〜183 とかにしてもいい。まあ合計 200 になってればいいんぢゃないですか。
  • どれぐらいの縦幅にすればいいかというのが難しい。いつも感覚的に決めてるけど、客観的な基準を立てるとなると…。取り敢えず、当然ながら、画が込み合うほど大きくなる。つまり「日」より「目」の方が背が高い。「自」の下端が「目」の下端より上になる事は有り得ない。そうやって似た字と比べて決める事は可能。
  • それと言うまでもないけど、どんなに込み合ってるからと言って、下端の横画を 187 とかにベッタリ置いてはいけない。でか過ぎ。極限まで物凄く混雑した字でも 180 って所か。そしたら「下へ 1 px ずらす」というのに整合させると上端は 22 になるけど、ウロコがはみ出ちゃうなあ。大概の字は 25〜177 ぐらいに収まってほしい。— sayunu 2010年11月26日(金) 01:45

  • 理論上、部品の理想的な配置はグリフごとに違う。それなのに敢えて 0〜200 に揃えているのは、第一に簡単さの為。一々のグリフを作る度に悩むより、一定の基準が有った方が楽だ。第二に、グリフ同士の統一性の為。同じ部品は同じ位置に在った方が、字形を比較する上で都合がいい。
  • そしてその大前提として、0〜200 に機械的に揃えてしまっても殆どのグリフで問題が起こらないという事実が有る。理想的な配置と言ってもそこから微妙にずれるだけで、それは毎回作るたびに変わる、作る人ごとに違うという誤差範囲に大抵収まる。勿論、0〜200 に揃えては美しくならないというグリフも有るから、それは個別に対応しよう。ただし「美しくならない」というのが思い込みである場合も有るので注意。
  • そんな訳で、基本的に部品は 0〜200 に揃えて使うし、そんな風に揃えて使い易い様に部品を設計する。— sayunu 2010年12月27日(月) 03:36

  • 今の KAGE の肉付けだと、右拂いの終端は縮小するほど相対的に大きくなっちゃうんですよね。拡縮して部品とするにはその辺が不便だと思ってるんですが。— sayunu 2011年4月26日(火) 21:28

  • 「編集内容の要約」は毎度毎度おんなじ定型句を貼り付けてないで、個々の字について真摯に書いてほしい。
  • 字形について「要約」なんて変な話で(Wikipedia からの丸写しのせい)、「説明」とか言ってはどうかと思うんですけど。— sayunu 2011年4月27日(水) 22:33

  • 「袁」の下の部分(が糸みたいになったの)を部品にしようとすると、微妙に違うのが多くて困る。
  • まづ、下が撥ねるか撥ねないか、最後の画を拂うか止めるか。恐らく「撥ねない・拂う」の組み合わせは(ゴシック体でなければ)稀なので、「撥ねる・拂う」「撥ねる・止める」「撥ねない・止める」の三種類が欲しい。これは糸みたいになってないのを部品化する上でも同様。
  • sayunu_sandbox@318 sayunu_sandbox@322 sayunu_sandbox@323
  • 一画目の転折の表現にも何種類か有る。折れた後を右上拂いにするの(G 欄式)と点にするの(J 欄式)の二つでいいならいいけど、更に右上拂いでは頭を突き出さない場合(G)と突き出す場合(仮想 J)を用意する事も考えられる。そうすると三種類。上と合わせて九種類。
  • sayunu_sandbox@317 sayunu_sandbox@318
  • 綺麗なグリフを作るには、これを一個づつ用意するだけでは足りない。特にこういう斜めの画を含む部品は、縦長や横長に使う時に(45 度を目安に)それぞれ調整を要する。この部品の場合、上に重い部品が来る時は最初の画を左下へ押し込み、上に余裕が有る時は引っ張り出してやる事になる。まあ「取り敢えず使える」だけでいいならいいけどさ…。
  • sayunu_sandbox@319 sayunu_sandbox@320 sayunu_sandbox@321 sayunu_sandbox@324
  • 細かい所だけど、三画目の縦画の頭を接続(押さえ無し)にするか開放(押さえ有り)にするかという違いも有る。
  • 縦画を撥ねない場合、中央に揃えるデザインと、左に寄ったままにするデザインが書体に依って見られる。
  • 最終画を止める場合、細入りを繋ぐか離すかというバリエーションがまた出て来る(シタミヅの悪夢(ノート:u6c3a)、sayunu_sandbox@62〜73)。
  • あと、園なんかでは周りが囲われるから、あちこちの突き出しを引っ込めた方が纏まりがいいんだけど、これぐらいは別の部品を作るより肉付けで対応できたらいいんだよなー。— sayunu 2011年5月4日(水) 18:14

  • グリフウィキが無防備である為に起こる荒らしについて、私は復旧に(殆ど)協力しません。綺麗なグリフを作るのが好きなだけなので。
  • 著作権を譲渡しちゃってるので拘束力は無いけど、作ったグリフが壊される恐れって やる気を削ぐよね。— sayunu 2011年5月20日(金) 00:24

  • u961d-02 の一括更新をしていたが、うんざりしたので已めた。占有グリフが大量に有って更新を阻む。占有グリフは「旧部品引用グリフ」としても永遠に残るし、引用してる部品を白紙化できないし、扱いをどうにかする必要が有る。「管理者権限で個別に更新」とかぢゃなくて。
  • それに、複数のタブで複数の絶対位置指定をして、切り替えながら選ぶという裏技っぽい方法は、こだわればこだわるほど効率が悪い。欲を言えば、こういう機能が実装されたらいいんだけど。
  • どうして相対指定にしないかと言うと、このグリフは曲げ撥ねの中間制御点が右に飛び出てるせいで外接矩形がずれていて、配置が崩れ易い為。
  • そしてこんな事に時間を費やしている場合ではない。学振の申請書を書かなきゃいけないのに。— sayunu 2011年5月25日(水) 22:33

  • 一括更新の占有グリフの件について思い付いた。「旧部品の一括更新」ではなく「部品の一括更新」にはページ送り(「これ以降の対象グリフを見る」)が有るから、これに同一の部品名を指定して、占有グリフに占有された一ページ目を飛ばして二ページ目で作業すれば何とかなる。
  • あれは「部品の一括更新」と言うより「部品の一括置換」ではないかと思いますがね。「部品グリフを別のグリフに置き換える」とも言ってるし。
  • 更新完了の画面から「部品引用グリフ一覧へ戻る」時、ページを憶えててくれれば効率的なんだけど。— sayunu 2011年5月27日(金) 11:51

  • u961d-02@10、右側の余白を取り過ぎた気がして来た…。— sayunu 2011年5月27日(金) 12:25

  • 非漢字って何の目的で収録してるのか分からない。仮名は全体的にひどい出来なので、花園明朝に入ってるのが正直恥づかしい。— sayunu 2011年5月29日(日) 14:37

  • 以前(五月四日)、「袁」などの下部について「縦画を撥ねず、最終画を拂う字形は明朝体では稀だろう」と書きましたが、普通に存在しますね。— sayunu 2011年8月4日(木) 22:58

  • グリフデザインのコツみたいな記事を纏めたいけど、無償でやれるほど暇ではなくなったし、私の活動が歓迎されてない気がするし、やらない。— sayunu 2011年8月4日(木) 22:58
    • え、そうですか?私としてはそうは思っていませんが…。すみません、私もここ1年(以上)集中して時間が取れていません…--kamichi 2011年8月6日(土) 00:18
    • 「気がする」という程度でして、客観的にそうおっしゃって頂けるなら、気のせいでしょう。ありがとうございます。やっぱりお一人での開発・運営だと滞りがちですね。— sayunu 2011年8月7日(日) 00:17

  • 「字形同定基準」が欲しい。どこまでソースを再現すれば、再現した事になるか。要するに包摂規準か。
  • 勿論、その基準よりも細かい作り分けを禁ずる訳ではなく、「取り敢えずどこまで細かくやっておけばよし」というのが共有できるといいなーと。Unicode 規格票についてはこれぐらい、戸籍統一文字ではこれぐらい、とソース毎に分けるべき部分が有るかも知れない。分けないで行けるなら分けない方がいいと思う。
  • 例えば、細入りの接触・非接触は区別しなくていいとか、隣接しない(別の要素を挟む)二本の横画は長短を区別しなくていいとか、空間の相対的な大小は区別しなくていいとか、そんな感じの。ここで挙げた例が受け入れられるかは知らない。— sayunu 2011年9月29日(木) 21:49

  • 私がどうして var と itaiji の区別にこだわったか、意図を書き出しておきます。
  • そもそも、u#### か u2#### で始まる名前のグリフはほぼ全て、対応する Unicode 符号位置に統合(包摂)される事が保証されている。u4e00-g にしても、u4e00-02 にしても、U+4E00 として可能な字形の一例であって、全て uni4E00 としてフォントに収録され得る。で、現行の定義なら u4e00-var-### もその仲間に入る訣だ。(現に偏化変形として登録されてるグリフが全て統合範囲内かはちょっと自信無い。)
  • そうすると、統合されない u4e00-itaiji-### は特異な例外。だから混ぜないでおきたかった。
  • 私のイメージの中では、u4e00-g とか u4e00-02 とか u4e00-var-001 は全て u4e00 という名前空間の中で並列している一方、u4e00 と u4e00-itaiji-001 とは別々の空間を形成する。u4e00 という名前を借りてはいるけど、u4e00 の外に在る。かつて itaiji-u4e00-001 とかいう接頭辞化にちらっと触れたのも、そういう前提での話です。
  • なので、u4e00-itaiji-001-02 とか u4e00-itaiji-001-var-001 とか有っていいと思うの。例えば u8209-itaiji-001@1u8209 に統合されないけど、u8209-itaiji-002@1u8209-itaiji-003@1u8209-itaiji-001@1 と統合されるので、u8209-itaiji-001-var-001 や u8209-itaiji-001-var-002 と命名すれば筋が通る。— sayunu 2011年9月29日(木) 22:37

  • 私の好みでは、u4e00-v001 とか、u4e00-var001 とか、ハイフンが無い方ががすっきりしていいなーと思うのですが。
  • 言ってはみたけど、itaiji-u4e00-001 もあんまりカッコ良くないよなー。ui4e00.001 とか。— sayunu 2011年9月29日(木) 22:52

  • 長短の差異は(別字でない限り)統合されると Annex S に書いてあった筈だけど、吉と𠮷はどうして区別されるんだろう。— sayunu 2011年9月29日(木) 22:52
    • http://togetter.com/li/191225 を眺めていたら、U+20BB7(𠮷)は「事故で入った」との事ですね。一度入っちゃったので、U+5409(吉)にツチ吉の IVS を振れないと。「間違えた符号位置は廃止ね」とは行かないものか…。— sayunu 2011年9月30日(金) 18:50

  • お久しぶりです。花園明朝の仮名が恥づかしいと言っても、フォントに収録されちゃってる状態は変らないので、最低限整えておこうと思いました。取り敢えず「あ〜こ、すせそ」を実際に当方で組んでみて、大きさや位置を大体揃えたりしました。でもまだまだたくさん有って挫けそう。続きは気が向いた時にやります。濁点は大きめが好きなので、出来るだけ縮小しないで使っています。それと、濁点の為に「か」と「が」で位置をずらすのも避けています。片仮名は面倒なのでやる積もり無いです。— sayunu 2012年12月20日(木) 03:01
    • ありがとうございます。私は日常で花園明朝を使っているので仮名を見る機会が多いのですが、少し慣れてしまいました。とはいえ、漢字とのバランス、仮名同士のバランスが気になることが多いです。これは難しいですね。--kamichi 2012年12月20日(木) 08:18
  • わあ、本文の表示に使ってらっしゃるんですか。そしたら仮名の品質は見た目の印象を大きく左右しますね。取り敢えず「どう見てもガタガタ」な状態には見えない様にしたいです。— sayunu 2012年12月21日(金) 03:25
  • 「まみむめもらりるれろ」と、出現頻度が高くて気になった「のをとん」の大きさなどを整えました。でも前の作業を改めて見ると、「そ」とか もう少し小さい方がいいかも知れません。— sayunu 2012年12月21日(金) 03:25
  • 「さしたちつてなにぬね」を整えました。未着手は「はひふへほやゆよわゐゑ」。高頻度の平仮名の大半が一応整列したので、本文を組んだ印象は大分良くなったと思います。— sayunu 2012年12月22日(土) 18:37
  • と言うか、「ち」は現段階でそのままにしました。— sayunu 2012年12月22日(土) 18:39
  • 「はほやゆよ」を整えました。それに、小書きの「あいうえおつやゆよ」も更新しました。残りは「ひふへわゐゑ」。— sayunu 2012年12月22日(土) 23:32
    • ありがとうございます。さて花園フォントを更新しないといけませんね… --kamichi 2012年12月22日(土) 23:34
  • はい、これが収録されれば以前よりはマシになると思います。片仮名が心残りですけど…。— sayunu 2012年12月24日(月) 03:22
  • 「ひふへわゐゑ」と繰り返し記号(ゝ)、長音記号(ー)を整えて、小書き「わ」を更新し、全体をザッともう一巡しました。濁点付き平仮名は全部、半濁点付きは「うかきくけこはひふへほゝ」のみ更新しました。完璧に揃ったとは思いませんが、前よりは良くなりました。あとは片仮名、せめて位置だけでもどなたか揃えて下さればよいのですが。— sayunu 2012年12月24日(月) 03:22
  • フォント生成してみたら、「ゆ」が壊れてるみたい。小さい「ゆ」は大丈夫。— sayunu 2012年12月24日(月) 04:07
  • どうしても気になってしまうので、片仮名もガーッと揃えました。平仮名より雑なのでまだ色々と問題が有ります。こんな事より年賀状を作らないといけないのに…。— sayunu 2012年12月28日(金) 23:01
  • 結局片仮名も全部やってしまいました…。半端で放置できないのが困ります。濁点付きは「カキクケコサシスセソタチツテトハヒフヘホワヰウヱヲヽ」、半濁点付きは「カキクケコハヒフヘホセツトヽ」、小書きは「アイウエオツヤユヨワヰヱヲカケクシストヌハヒフヘホムラリルレロ」と「プ」を更新しました。それにノマ(々)、より(ゟ)、コト(ヿ)も揃えました。(挙げ忘れは無いかな ?)年賀状はこれから作ります。— sayunu 2013年1月1日(火) 21:13

  • ページの横幅は可変にならないんですかね。以前からの懸案らしいですね。こういう場合、左枠(div.left_pane)は float でいいですが、右枠(div.right_pane)は float させないで、単に左マージンを与えればいいです。マージン部分に左枠が収まります。具体的には、左枠の横幅が 150 ピクセルなので、右枠は「margin-left: 160px」ぐらいにする。あとは body 要素などの不要な width を消す。これで横幅可変になる筈です。— sayunu 2013年1月6日(日) 14:28
    • 恥ずかしながらグリフウィキの作成時は時間との戦いでもあったので、とにかく組み立てる、ことが主眼で、そのため複雑怪奇なcssになっていると思います。簡単に直せるようであればやってみます。ご助言いただきありがとうございます。--kamichi 2013年1月6日(日) 14:41
  • (※ この話の続きは利用者-会話:kamichiに有ります。サクッと実装されました。— sayunu 2013年1月12日(土) 01:48)

  • 前から思ってるんですけど、グリフページ最上部の題名は「u5fc3」などとグリフ名だけをそのまま載せるより、(少なくとも UCS グリフについては)例えば「UCS/Unicode 統合漢字 U+5FC3「心」(u5fc3)」ぐらい分り易く表示してほしいなあ。個々のウエブページを見に来る人はこのウィキのシステムを把握しているとは限らないので(どっちかと言うと理解してない人の方が多いだろうので)、なるべく多くの人にピンと来る descriptive な言語表現でありたい。「u5fc3」という名称は、命名規則を知っていれば問題なく理解できるコンパクトでクリーンな表現ではあるけど、知らない人に提示して理解できる物ではない。現状では下記 URL の様な誤解が起こるのも不思議ではないし、新しいグリフを登録しようとして既存のグリフを上書きしてしまう間違いも少しは抑制できそうだし…(インターフェース全体の問題だけど、ページの題名もその一端として)。
    • http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1251367717
    • 「この漢字は誰かがデザインした図形で、実際に昔からある漢字ではないのではないでしょうか」
    • 「そのサイトは、漢字のようなデザイン文字をみんなで作って登録するサイトですから、字ではなく絵だと思ってください」
  • 更に言えば、「koseki-116250」なども「法務省 戸籍統一文字 116250(koseki-116250)」ぐらい書いてほしい。一番上に。— sayunu 2013年1月12日(土) 02:20
  • 前提知識が無い人でも何となく把握できる様に…「国際符号化文字集合・ユニコード統合漢字 5FC3「心」(u5fc3@5)」とかどうかな…。— sayunu 2013年1月12日(土) 03:03

    • 前頭辞についてはあまり細かくしすぎて長くなることは反対なので、おっしゃる通り前頭辞に対する説明を別に用意して、その前頭辞を用いるグリフについては説明が合わせて表示されるような仕組みが望ましいと思いました。それと、前々から思っていましたが質問サイトというのは回答が締め切られるとそれ以上書けないので間違った情報が固定されてしまうというのがどうにかならないものかと思います。--kamichi 2013年1月13日(日) 17:02
    • 個人的にモチベーションが高かったので(あと雪で家に閉じ込められたので)実装してみました。若干セキュリティ漏れが懸念されますが運用でカバーしたいと思います。長くなってしまうので若干表現も再検討したいですが、とりあえずできました。--kamichi 2013年1月14日(月) 22:21
  • わ、こんなに早く実装されるとは思わなかったです。対応ありがとうございます。確かにかなり長大になってますね。それに、現状だと、互換漢字や非漢字にも「統合漢字」って表示されて…。— sayunu 2013年1月14日(月) 22:33
    • はい、あまりデータを複雑に書くと可読性が落ちるので領域ごとに分けて行きたいと思います。--kamichi 2013年1月14日(月) 22:37

  • うーむ、やっぱり「国際符号化文字集合・ユニコード」って並列すると長いなあ。一般人に通り易いのは「ユニコード」かなと思ったけど、どっちか省いた方がいいかも知れないなあ。— sayunu 2013年1月14日(月) 23:10

  • ダイアクリティックについて、 逆さブリーブ(u0020-u0311) 下ドット(u0020-u0323) フック(u0020-u0309) 下マクロン(u0020-u0331) 下チルダ(u02f7) 下サーカムフレックス(u02c6-04) 下ダイエレシス(u00a8-04) 下カンマ(u0020-u0326) も更新しました。もうダイアクリティック関係には対応したくないです。サーカムフレックスとかは少し小さくしてもいいかも知れません。
  • ASCII 辺りの記号類も少し弄りました。
  • ラテン文字は半角を実体として作ったけど、本当は全角グリフを引用した方がいいと思うんですよね。特に〈M〉なんか自然な幅で作りたいし、枠の中心に在る方が引用時に座標が扱い易いし。でも今回は、半角で組んだ時の見た目を手っ取り早く直したかったので、半角優先で作業しました。これを踏まえてまた全角と半角の引用関係を逆にしてもいいかも知れません。
  • フォント生成時のグリフ破損(「白抜け」?)に関しては、先述の通り、〈ゆ〉と〈O〉を発見しました。あと、半角片仮名は〈ア〉など少なからぬグリフが壊れています。直し方は知りません。— sayunu 2013年1月19日(土) 16:41
    • ありがとうございました。それで白抜けについては神(fontforge)のみぞ知る、というか、ポリゴン自体は問題がないので計算上の問題と思います。ですので解決法は適当に1ドットずらして試す、しかありません… --kamichi 2013年1月19日(土) 19:21

  • 全角を実体として半角へ引用する場合の問題としては、全角形として作るべき UCS 文字などが限られているのも有りますね。「-fullwidth」とかいう接尾辞を付ける ? — sayunu 2013年1月19日(土) 17:33
    • はい、それで良いと思います。--kamichi 2013年1月19日(土) 19:21
  • にしても、どれを全角で、どれを半角で作るべきかよく分らないんですよね。いっそ無印記号グリフは全部全角にするとか、逆に全部半角にするとか決めてしまいましょうか…。— sayunu 2013年1月22日(火) 22:11

  • メモ。これまでに私が編集したラテン文字などのグリフは、ベースラインの縦座標が 170、ミーンラインが 82、アセンダーラインが 28、キャップラインが 31 となっています。つまり〈o〉などの小文字の真ん中は 126、縦幅は 88。〈H〉などの大文字の真ん中は 100.5、縦幅は 139。〈+〉などの演算子は真ん中が 120(小文字よりちょっと上)になる様に揃えてあります。
  • 大文字の基準位置は古い版のグリフに従いました。ミーンラインは古い版では不揃いだったので、少し大きくして揃えました。この数値は大まかに決めてしまった物で、変更の余地は有ります。半角の大文字がかなりひょろ長いので、少しだけ小さくしたらいいかも知れません。ベースラインを 3 px 上へ、キャップラインを 2 px 下へ、とか。
    そう言えば、フォントデータとしてのベースラインがデザイン上のベースラインにぴったり合うといいですねえ。— sayunu 2013年1月22日(火) 22:30

  • あと、半角グリフって本当に左寄せで作るのが良いんでしょうか。中央の方がデザイン上は色々と楽なんですけど…。部品としての使い易さとか。全角グリフのエイリアスで済む場合も多いし。— sayunu 2013年1月22日(火) 22:38
    • 左寄せの場合、1)フォントとしてグリフを呼び出すときに全角と同じで位置調整不要、2)デザイン時の「半分の大きさ」の認識について、少なくとも左側はわかりやすい、という2つのメリットでしょうか。方針さえ決まれば真ん中寄せでもいいのですが。--kamichi 2013年2月11日(月) 18:39

  • そもそも、初めてこのサイトに来た人は、「最近更新したページ」を見ればほかの参加者の動向が分るという事すら知らされていないのだった。ただ「誰も居ない」グリフページが見えているだけ。要約欄に「いたづらは已めて下さい」と書いたって十中八九読まれないし。— sayunu 2013年1月25日(金) 00:44
    • たとえばWikipediaなどはどうなんでしょう?確かに私もグリフウィキを使うようになってから、とても暇なときにWikipediaの「最近の更新」を見ることを覚えました。わりとメニューのリンクは少なくしてあるので、気がついてほしいところです。--kamichi 2013年2月11日(月) 18:39

  • 私は既存のグリフを美的に改良するという活動を何年も前からじわじわやっているけど、やはり慣れるにつれてうまくなったという自覚が有る。初期に弄ったグリフは今見ると直したかったりする。それぢゃあ、どうやって慣れたかと言ったら、既存のグリフをああでもないこうでもないと悩みながら弄り回しているうちに考え方が洗練された訣で、弄り回す事が出来たから上達できたと言える。
  • 昔のグリフウィキは、そういう点で、今よりも練習しやすかった。当時の既存グリフにはあまり洗練されていない物も多かったので、あまり慣れていない状態でも、ちゃんと考えれば「前よりマシ」なバージョンを作るのはさほど難しくなかったから。今は、私も含めて色んな人が既に改良を加えてしまったグリフが多いので、新しく来た人が「どんな字形をどんな考え方でデザインすればいいか」実践を通じて自分で学ぶのが難しくなった様に感じる。
    勿論、自分の占有グリフのサンドボックスとかを作って練習する事は出来る。私も今でもよく「改良版を作ってはみたけど、旧版より優れているかどうか自信が無い」「時間を置いてまた考えたい」という様な場合によく利用する。けど、サンドボックスだけ弄ってても貢献にならない、成果を感じないんですよね。最初期の私の活動を思い返すと「ちょっと手を出してみたら、出来た」という手軽な物で、「サンドボックスでみっちり練習するぞ」とかいう気合いを持って来る人は普通は居ないし。
    だからどうしようという訣でもないですけど。実践で学べないなら、やっぱり読んで学べるドキュメントが有るといいんだけどね。書くのも面倒でね。— sayunu 2013年2月11日(月) 18:28
    • つい先日他の方が指摘されていましたが、人の手の加わっていないグリフも結構あるようです。「練習用」と言い切ってしまうと語弊がありますが、そういうグリフを適当に一覧できるといいのかもしれませんね。--kamichi 2013年2月11日(月) 18:39

  • どうして cm(u339d) とか、プロポーショナルにしてあったのに等幅に変えてしまったんでしょうか。「c」はでかいし「m」は小さい。まあ全角の単位記号なんか どーだっていい代物だけど、収録するからにはね…。もう何でもいいや…。— sayunu 2013年2月24日(日) 18:59

  • 平仮名とかラテン文字とか弄ったけど、あれは何やらフォントに収録される方向で行っちゃったからしょうがなく直したんであって、「コード表に空きが有るから取り敢えず埋めようぜ」みたいな態度は厳に慎むべきっていうか、漢字ウィキなのに直す物が増えて面倒臭いっていうか、放棄するっていうか、登録したら何の為になると思うんだ ?
  • 漢字にしたって例示字形の微妙な癖を思考停止で模写するなら全ッ然 意義感じないし(うまく模写できてないし)(細部を論ずるなら元の画像を引用すりゃあいい)、作業として面白くないし、KAGE の肉付けはカッコ良くないし。どこまで区別するのか未だに不明確なのがいけない。明朝体のデザイン差って本当にくっだらないと思うよ。ぶつぶつ。— sayunu 2013年2月24日(日) 19:19

お邪魔します:非漢字グリフについて

非漢字グリフの今後について悩んでいます。せっかく皆さんがいろいろそろえてくださっているのですが、根本的に間違っているような…。細線のようなバッド(?)ノウハウもいろいろ蓄積されてきていますし。それで、これから曲線の密集時の細線化自動調整機能を検討する際に、非漢字に多大な影響が出ます。そこで、非漢字については漢字とは別系統の線種に分離するのが良いと思います。まずは単純に今存在する線種のコピー(別番号)になりますが、最終的には複数の非漢字用線種の実現になると思います。この春休みの間にエイヤでやってしまいたいと思います。しかし、あるいは非漢字はSVG登録を認め、通常のアウトラインデータで登録する方がいいのかもしれません。--kamichi 2013年1月3日(木) 23:40

  • はい、漢字用の筆画で非漢字を描くのは本当にムチャクチャな話だと思います。なるほど、取り敢えず単純なコピー線種として退避させれば、肉付けエンジンの改良でグリフが壊れる事は無くなりますね。
  • 輪郭データ(SVG)もよいですが、漢字の補助としてならやはり骨格表現の方が望ましい様に思います。漠然と考えると…
    • 線の種類は「直線」と「曲線」
    • 太さは「太い」「中くらい」「細い」の間で滑らかに変化
    • 終端形状は「平らな切り落とし」と「半円」
  • …と、それとは別に…
    • 「楕円」「長方形」「自由な多角形」の「白抜き」と「塗り潰し」
  • …が使える程度で充分の様な気がします。非漢字だけでなく、ウニャウニャした筆画を含む漢字(グループ:tomomo_変な字)とかを表現する時に必要ですね。最終的にどんなしくみになるべきかは何とも申せませんが…。
  • そもそも非漢字をグリフウィキに登録する意義を私は感じないです。(仮名に関しては、あのせいで花園明朝の第一印象を悪くしているのが悲しいので直しましたが。)仮に、グリフデータベースではなくてフォントが欲しいという需要だったら、漢字しか含まない従来の花園明朝のほかに、よそから貰った非漢字グリフを収録したフォントも提供する(但しライセンスの制限が加わる)とかいう方法も有るでしょうか。
  • 漢字の方のシステムの開発に注力して頂きたいので、非漢字への対応に時間を取られる様になってはいけないと思います。このウィキやグリフエディターは今のところ漢字の為に作られていて、漢字向きの機能しか持っていない。例えばラテン文字のアクセント記号は、合成基準点さえ与えれば自動合成で済むのに、手動で一個一個作るなんて時間の無駄としか言えません。枠も全角で、ベースラインだのディセンダー・アセンダーだの表示されないし、はみ出せないし。半角は何やら対応する様ですけど、プロポーショナルな文字に対応するとしたら大変な労力でしょう。
  • sayunu 2013年1月4日(金) 01:57
  • 重ね描きや継ぎ足しをせずに一筆書きで骨格で表現しようとすると、やっぱり、各制御点に太さを持たせられる様にした B‐スプライン曲線みたいな物が欲しいですね。以前井戸端で似た様な事を書きましたけど。— sayunu 2013年1月6日(日) 14:08
  • KAGEの仕様としてオプションに相当するパラメータが2つ、ということで、制御点で任意の太さ、というのは難しいかもしれません。たとえば、払いの先のような細入、から、デフォルトの太さの2倍ぐらいまでの間を9段階ぐらいにして、159(曲線)とか1479(複曲線)とするなら簡単かもしれません。--kamichi 2013年1月6日(日) 14:41
  • 平仮名などを作る限りは、最細から縦画デフォルト幅までの五段階に、それより一段階太い六段階目が有ればいいなあという感じなので、ほかに色々作れる様にと考えると、おっしゃったくらいが程良いかも知れません。あとは、滑らかに連続するベジエ曲線をエディターで作り易い様になっていたらいいですね。KAGE のデータとしてはバラバラの筆画扱いでいいですが、編集画面では繋がったまま連動して変形できる様に…。— sayunu 2013年1月12日(土) 01:41