GlyphWiki logo
ナビゲーション
ヘルプ
検索

ツールボックス
他の言語
グループノート編集履歴

グループ-ノート:sayunu_つぶやき-2013

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

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

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

非漢字グリフの今後について悩んでいます。せっかく皆さんがいろいろそろえてくださっているのですが、根本的に間違っているような…。細線のようなバッド(?)ノウハウもいろいろ蓄積されてきていますし。それで、これから曲線の密集時の細線化自動調整機能を検討する際に、非漢字に多大な影響が出ます。そこで、非漢字については漢字とは別系統の線種に分離するのが良いと思います。まずは単純に今存在する線種のコピー(別番号)になりますが、最終的には複数の非漢字用線種の実現になると思います。この春休みの間にエイヤでやってしまいたいと思います。しかし、あるいは非漢字は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

2013年1月6日(日) 14:28

ページの横幅は可変にならないんですかね。以前からの懸案らしいですね。こういう場合、左枠(div.left_pane)は float でいいですが、右枠(div.right_pane)は float させないで、単に左マージンを与えればいいです。マージン部分に左枠が収まります。具体的には、左枠の横幅が 150 ピクセルなので、右枠は「margin-left: 160px」ぐらいにする。あとは body 要素などの不要な width を消す。これで横幅可変になる筈です。


    • 恥ずかしながらグリフウィキの作成時は時間との戦いでもあったので、とにかく組み立てる、ことが主眼で、そのため複雑怪奇なcssになっていると思います。簡単に直せるようであればやってみます。ご助言いただきありがとうございます。--kamichi 2013年1月6日(日) 14:41
  • (※ この話の続きは利用者-会話:kamichiに有ります。サクッと実装されました。— sayunu 2013年1月12日(土) 01:48)

2013年1月12日(土) 02:20

前から思ってるんですけど、グリフページ最上部の題名は「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)」ぐらい書いてほしい。一番上に。

前提知識が無い人でも何となく把握できる様に…「国際符号化文字集合・ユニコード統合漢字 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

2013年1月14日(月) 23:10

うーむ、やっぱり「国際符号化文字集合・ユニコード」って並列すると長いなあ。一般人に通り易いのは「ユニコード」かなと思ったけど、どっちか省いた方がいいかも知れないなあ。


2013年1月16日(水) 01:09

グループ-ノート:sayunu_sandbox@2 で会話してから、ザッとラテン文字のエックスハイト(小文字の大きさ)を変更して回りました。前より大きくなっています。また、従来は全角グリフが半角グリフに引用されていましたが、半角がメインという事で、これを逆にしました。ほかに 疑問符(u003f) 感嘆符(u0021) アンパサンド(u0026) を更新しました。ギリシャ文字やキリル文字は弄りません。

ダイアクリティックに関しては、 アキュート(u00b4) グレーブ(u0060) サーカムフレックス(u02c6) ハーチェク(u02c7) マクロン(u00af) ダイエレシス(u00a8) チルダ(u02dc) ブリーブ(u02d8) 上ドット(u02d9) 上リング(u02da) ダブルアキュート(u02dd) ダブルグレーブ(u02f5-03) オゴネク(u02db) セディーユ(u00b8) を更新し、これが付いた文字も大体更新しました。但し、上に二個以上ダイアクリティックが付いているグリフや、下に付いているグリフは、時間が掛るので放置しました。やれやれ。

フォントを生成すると〈O〉が壊れてる様です。


2013年1月19日(土) 16:41

ダイアクリティックについて、 逆さブリーブ(u0020-u0311) 下ドット(u0020-u0323) フック(u0020-u0309) 下マクロン(u0020-u0331) 下チルダ(u02f7) 下サーカムフレックス(u02c6-04) 下ダイエレシス(u00a8-04) 下カンマ(u0020-u0326) も更新しました。もうダイアクリティック関係には対応したくないです。サーカムフレックスとかは少し小さくしてもいいかも知れません。

ASCII 辺りの記号類も少し弄りました。

ラテン文字は半角を実体として作ったけど、本当は全角グリフを引用した方がいいと思うんですよね。特に〈M〉なんか自然な幅で作りたいし、枠の中心に在る方が引用時に座標が扱い易いし。でも今回は、半角で組んだ時の見た目を手っ取り早く直したかったので、半角優先で作業しました。これを踏まえてまた全角と半角の引用関係を逆にしてもいいかも知れません。

フォント生成時のグリフ破損(「白抜け」?)に関しては、先述の通り、〈ゆ〉と〈O〉を発見しました。あと、半角片仮名は〈ア〉など少なからぬグリフが壊れています。直し方は知りません。


    • ありがとうございました。それで白抜けについては神(fontforge)のみぞ知る、というか、ポリゴン自体は問題がないので計算上の問題と思います。ですので解決法は適当に1ドットずらして試す、しかありません… --kamichi 2013年1月19日(土) 19:21

2013年1月19日(土) 17:33

  • 全角を実体として半角へ引用する場合の問題としては、全角形として作るべき UCS 文字などが限られているのも有りますね。「-fullwidth」とかいう接尾辞を付ける ?


    • はい、それで良いと思います。--kamichi 2013年1月19日(土) 19:21
  • にしても、どれを全角で、どれを半角で作るべきかよく分らないんですよね。いっそ無印記号グリフは全部全角にするとか、逆に全部半角にするとか決めてしまいましょうか…。— sayunu 2013年1月22日(火) 22:11

2013年1月22日(火) 22:30

メモ。これまでに私が編集したラテン文字などのグリフは、ベースラインの縦座標が 170、ミーンラインが 82、アセンダーラインが 28、キャップラインが 31 となっています。つまり〈o〉などの小文字の真ん中は 126、縦幅は 88。〈H〉などの大文字の真ん中は 100.5、縦幅は 139。〈+〉などの演算子は真ん中が 120(小文字よりちょっと上)になる様に揃えてあります。

大文字の基準位置は古い版のグリフに従いました。ミーンラインは古い版では不揃いだったので、少し大きくして揃えました。この数値は大まかに決めてしまった物で、変更の余地は有ります。半角の大文字がかなりひょろ長いので、少しだけ小さくしたらいいかも知れません。ベースラインを 3 px 上へ、キャップラインを 2 px 下へ、とか。

そう言えば、フォントデータとしてのベースラインがデザイン上のベースラインにぴったり合うといいですねえ。


2013年1月22日(火) 22:38

あと、半角グリフって本当に左寄せで作るのが良いんでしょうか。中央の方がデザイン上は色々と楽なんですけど…。部品としての使い易さとか。全角グリフのエイリアスで済む場合も多いし。


    • 左寄せの場合、1)フォントとしてグリフを呼び出すときに全角と同じで位置調整不要、2)デザイン時の「半分の大きさ」の認識について、少なくとも左側はわかりやすい、という2つのメリットでしょうか。方針さえ決まれば真ん中寄せでもいいのですが。--kamichi 2013年2月11日(月) 18:39

2013年1月25日(金) 00:44

そもそも、初めてこのサイトに来た人は、「最近更新したページ」を見ればほかの参加者の動向が分るという事すら知らされていないのだった。ただ「誰も居ない」グリフページが見えているだけ。要約欄に「いたづらは已めて下さい」と書いたって十中八九読まれないし。


    • たとえばWikipediaなどはどうなんでしょう?確かに私もグリフウィキを使うようになってから、とても暇なときにWikipediaの「最近の更新」を見ることを覚えました。わりとメニューのリンクは少なくしてあるので、気がついてほしいところです。--kamichi 2013年2月11日(月) 18:39

2013年2月11日(月) 18:28

私は既存のグリフを美的に改良するという活動を何年も前からじわじわやっているけど、やはり慣れるにつれてうまくなったという自覚が有る。初期に弄ったグリフは今見ると直したかったりする。それぢゃあ、どうやって慣れたかと言ったら、既存のグリフをああでもないこうでもないと悩みながら弄り回しているうちに考え方が洗練された訣で、弄り回す事が出来たから上達できたと言える。

昔のグリフウィキは、そういう点で、今よりも練習しやすかった。当時の既存グリフにはあまり洗練されていない物も多かったので、あまり慣れていない状態でも、ちゃんと考えれば「前よりマシ」なバージョンを作るのはさほど難しくなかったから。今は、私も含めて色んな人が既に改良を加えてしまったグリフが多いので、新しく来た人が「どんな字形をどんな考え方でデザインすればいいか」実践を通じて自分で学ぶのが難しくなった様に感じる。

勿論、自分の占有グリフのサンドボックスとかを作って練習する事は出来る。私も今でもよく「改良版を作ってはみたけど、旧版より優れているかどうか自信が無い」「時間を置いてまた考えたい」という様な場合によく利用する。けど、サンドボックスだけ弄ってても貢献にならない、成果を感じないんですよね。最初期の私の活動を思い返すと「ちょっと手を出してみたら、出来た」という手軽な物で、「サンドボックスでみっちり練習するぞ」とかいう気合いを持って来る人は普通は居ないし。

だからどうしようという訣でもないですけど。実践で学べないなら、やっぱり読んで学べるドキュメントが有るといいんだけどね。書くのも面倒でね。


    • つい先日他の方が指摘されていましたが、人の手の加わっていないグリフも結構あるようです。「練習用」と言い切ってしまうと語弊がありますが、そういうグリフを適当に一覧できるといいのかもしれませんね。--kamichi 2013年2月11日(月) 18:39

2013年2月24日(日) 18:59

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


2013年2月24日(日) 19:19

平仮名とかラテン文字とか弄ったけど、あれは何やらフォントに収録される方向で行っちゃったからしょうがなく直したんであって、「コード表に空きが有るから取り敢えず埋めようぜ」みたいな態度は厳に慎むべきっていうか、漢字ウィキなのに直す物が増えて面倒臭いっていうか、放棄するっていうか、登録したら何の為になると思うんだ ?

漢字にしたって例示字形の微妙な癖を思考停止で模写するなら全ッ然 意義感じないし(うまく模写できてないし)(細部を論ずるなら元の画像を引用すりゃあいい)、作業として面白くないし、KAGE の肉付けはカッコ良くないし。どこまで区別するのか未だに不明確なのがいけない。明朝体のデザイン差って本当にくっだらないと思うよ。ぶつぶつ。