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

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

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

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

2022年7月29日(金) 03:10

昔の会話の前後関係などが分かりにくくなっていたので、検討の末、「グループ-ノート:sayunu_つぶやき-####」に整理してみました。御迷惑でないといいですが。

そして、新しい呟きもこの形式で書いてみます。ほかの方法を採用しなかった理由 :

井戸端
ツイッターみたいに気軽に個人的に思いを呟きたいので、議題を持ち込んで会話する為の井戸端は合わない。
共有グループページ
占有名前空間の外に書くのは迷惑だろう。
利用者ページ
ほかの人が返信を下さる時、利用者ページ自体は本人しか編集できないので、話の内容を会話ページに転載して続きを書くなどの形になる。これは流れが分かりにくい。
占有グループページ
上に同じ。
利用者の会話ページ
度々ログを消さないと際限なく長くなってしまう。定期的に消すと過去の議論を参照しにくいし、例えば五年後に事情が変わった場合に過去ログに最新情報を注記したり出来ない。定期的に別ページに移すと、編集履歴が断絶して追いにくい。
sayunu_sandbox のノートページ
上に同じ。

…という事で、「初めから期間を特定した占有グループのノートページ」という複雑な方法に至りました。

もし誰かが返信される場合は区切り線の次に追記される想定です。


2022年7月29日(金) 03:28

2014 年ぐらいからずっとグリフウィキで活動していなかったですが、2022 年七月に少し戻って来ました。グリフウィキの漢字骨格データを、有料フォント開発の下敷きに利用したいという もくろみがあるからです。

かつて、さゆぬは趣味でグリフを弄ってるだけでしたが、最近はフォント開発アプリケーションを買って、個人開発の仮名フォントを売ったりしています。しかし漢字をゼロから揃えるのは個人には荷が重いので、いきなり完成品とは言わないけれども、手動調整の下敷きになるようなグリフが一括生成できると嬉しい。

つまり KAGE の肉付けエンジンの代わりですが、デザイナーにとって制御しやすく自由度が高い方式を取ろうとしています。例えば左ハライという部品一個に対して、縦長・横長など幾つかの形状をベジエ曲線で自由に設計し、それを線形補間するような感じです(Glyphs.app のスマートコンポーネントに近い)。

もし基本的な機能がうまく出来たら GitHub にでも置きたいなと思っています。断続的に進めているので、いつ出来るかは分かりませんが。


2022年8月2日(火) 05:35

「GlyphWiki:」から始まる全てのページを グループ:sayunu_sandbox@22 で分類・整理しましたが、これらのページを見ていて思った事の一部を呟きます。主な観点 :

  • 利用者と貢献者を分けて考え、利用だけに焦点を当てた案内があるといい
  • 全ての作業指針を纏めるポータルがあるといい

(1) 外字データを登録したい人はそんなにいない

「グリフウィキに既に登録されているデータの利用」という所だけに焦点を当てた説明文書を整えた方がいいと思う。そこにはデータの編集という行為は基本的に関わらない。利用しやすい形に蓄積されたデータを提供する事がウィキの目指す所であって、その状態に近付けば近付くほど、編集の必要は縮小する。無論「完成」はしないけど。

データを登録する行為は「グリフウィキの利用」なのか「グリフウィキへの貢献」なのかというと、後者であるという立場に統一した方がいいと思う。そして利用者と貢献者をキッチリ区切って、それぞれの為の説明を整備したい。現在のチュートリアル「どうやって使うのか」は「グリフウィキに実装されている機能の利用」という意味合いで書かれていて、実は利用と貢献が混ざっている。今ある項目のうち、「GlyphWiki:グリフを検索する」「GlyphWiki:グリフを利用する」「GlyphWiki:高度な活用方法」はデータ利用だ。「GlyphWiki:グリフを登録する」「GlyphWiki:グリフを編集する」はデータ貢献だ。「GlyphWiki:グループページを使う」は…混在してる。

現在のグリフウィキはグリフ不足に喘いでいるわけではない。既に百万以上のグリフが登録されているし、Unicode の漢字は基本的に埋まってるわけだし。この状況で、訪問者に「何かグリフを登録したくないかい ?」と問うても大抵は何も出ないだろう。ここは訣分からん人も来るような開かれたインターネットだし、匿名利用者に不規則なデータを登録されても困るわけで、「是非登録しよう」みたいな勢いは前面に出さなくていいと思う。新たなグリフを登録したい人は、グリフウィキを訪れた人のうち百人に一人ぐらいぢゃないですか。貢献したい人への案内は勿論それはそれで用意する(次の節に繋がる)。貢献したい人には色んな注意事項があり、それを読めて意思疎通できる人である必要がある。

既にあるデータの利用という観点では、「読むだけ」という立派な利用形態についての案内が抜けている。主に、グリフページはどういう物なのかが統合的に説明されていない。まあ、グリフページの表示自体があんまり分かりやすくないという、ドキュメンテーション以前の問題があるけど…。見る人の大半は見るだけの人なんだし、そこを丁寧にやった方がいいと思うなあ。見て分かるようなグリフページになっていたら、チュートリアルに「色んなグリフを見て回りましょう、面白いよ」と書けるんだけど。

(2) さて貢献したい人は、何をしたら役に立てるのか

データの登録が「グリフウィキへの貢献」であるなら、それはグリフウィキにとって嬉しい形でなければならない。当初グリフウィキは命名規則から何からユルユルだったけど、秩序をもたらす規則は存在すべきだし、ルールを立てていく今の方向性は妥当だと思う。

で、「井戸端で決まった事」はそれだけでは決定のうちに入らないと思います。その場の作業者の間では了解するだろうけど、私がいなかった九年間の会話を全部読んでから参加するつもりはないです。「こうする事になりました、今後はこうします」という情報だけを集約して記述すべきです。それが暫定であっても、試行であっても。(決定に至った議論ページへのリンクは添えたらいいと思う。)

例えば「u#### の無印グリフを -j などに移行したい」みたいな、個々のグリフ集合(prefix と呼んでいるらしい物)における残課題があるんだったら、実施すべき具体的な作業項目に落とし込んで明確に記述してあれば、貢献したい人は「これをこうしてほしいんだな」と思えるわけで、まだ見ぬ新たな貢献者も、私も、気が向けば協力できるわけです。

その為に「GlyphWiki:作業指針」みたいなページを作って、全般的な作業の留意点とか、お役立ち情報とか、個々のグリフ集合における残作業一覧とかを集約したらいいんぢゃないかなあ。現チュートリアルのうちデータ編集に関わる説明も、そこからリンクするのが適切だと思う。


2022年8月7日(日) 09:48

「prefix」と呼ばれている概念に別の名前を付けたい。正確には、「prefix」が前提にしている概念に名前を与えたい。「prefix」というのはグリフの命名に注目した言い方だが、その背後にある概念がグリフウィキにおけるグリフ体系の基礎だと思う。私なら〈典拠別グリフ集合〉とかにするかな…。

典拠別グリフ集合は、単にグリフ名を決める為の便宜ではない。一連のグリフを整備する作業の最も重要な軸だし、閲覧者に対する「このグリフはこういう素性〔すじょう〕のグリフです」という説明を記述すべき単位だし、典拠に見られる字形をどのような KAGE‐データに対応付けるかという作業方針の単位だ。データを利用する人から見れば、どんなデータがグリフウィキで available になっているかについて期待すべき水準でもある。例えば、国際符号化文字集合の例示字形に対応付けたグリフは、隣り合う横画の相対的な長さを区別するけど、左ハライがどんな感じでどれぐらい曲がっているかは区別しない(という暗黙的な方針がある)。しかし別の典拠別グリフ集合においては異なる「包摂方針」あるいは「厳密さ」でグリフを再現する事にするのもあり得る。

Wikipedia には「ウィキプロジェクト」というシ組みがあり、単体の記事ではなく一分野の全体を見渡した視野で記事群を纏める方針決定に役立っている。グリフウィキにこそ、そうしたシ組みが必要だ。グリフウィキの単体グリフというのは Wikipedia の単体記事よりもずっと単位が細かく、単体のグリフについて議論する事はあまりない(というか単体のグリフについて散発的な議論をするだけだと全体に通底する方針を共有しにくい)。データ整備についての方針決定は典拠別グリフ集合の単位で行うべきだ。そういう事を一つ前の呟きでも意識していた。


  • あと、命名に注目した用語としては、日本語文脈で突然「prefix」と言われると面食らうし、〈グリフ名接頭辞〉とかがいいんぢゃないかな…。 — sayunu 2022年8月7日(日) 17:03

2022年8月7日(日) 18:34

全てのグリフ名に名前空間の接頭辞を付けるという今の方針を初めから前提とするなら、UCS のグリフも u-4e00 か ucs-4e00 か uni-4e00 といった形式になっていれば統一感があったなあ。もし uface とか ubadec といった接頭辞を追加したくなっても出来ないですね。まあ実際に問題になる確率は低いし、うまく迂回した名前を選ぶ事になるだろうけど。


  • その方向で行くなら uni-4e00-j よりは unij-4e00 かも。 — sayunu 2022年8月7日(日) 19:44
  • いや、それは別にデータの体系化に有利ではないし、uni-4e00-j でいいな。 — sayunu 2022年8月7日(日) 21:27