以下、保存用です。編集はご遠慮ください。
2013年から2014年までの分を保存しています。それ以降についてはGlyphWiki:井戸端-保存をご覧ください。
香港標準字形のための接頭辞
香港が香港の標準字形をIVDに登録する準備をしています。
http://www.iso10646hk.net/ivd/1/ 
この香港標準字形コレクションのグリフをhka-####で作成してもよろしいでしょうか？
- 新参者の私が言うのも何ですが，常識的な提案であれば，命名規則を定義してグリフを作成し始めても構わないようです。グリフを定義するグループ:prefix-hkaを作ってみました。 --ziyang 2014年12月28日(日) 18:23
- 韓国ソースの“ka-kc#####”もガイドラインにはありませんが登録されているので，典拠がはっきりしていれば大丈夫だと思います。--spinda-kkmr 2014年12月28日(日) 19:00
「非」明朝体漢字の登録制限について
グリフウィキはもともと明朝体漢字のデータベースを想定していましたが、多分にそれ以外の漢字が登録されています。個人占有グリフに登録する分には何とも思いませんが、一般グリフにどんどん異体字扱いで増えていくのはどうかと思います。次のような縛りを考えています。
- 明朝体が見出し字となっている辞書に、非明朝体だが見出し字として掲載されている字形はOKとする
- 翻刻された非明朝体字形の明朝体化字形は論文などとして公開されているもの（自分でこれから公開するなどを含む）
- 他の公的な明朝体文字集合に含まれるもの
以上ご意見をお願いします。--kamichi 2014年12月3日(水) 15:20
- 草書の明朝体化字形が“-itaiji-”を用いて登録されているのには私も違和感があります。上記の条件を満たせば可，それ以外は不可(ユーザー占有で登録する)でよいと思います。--spinda-kkmr 2014年12月28日(日) 19:05
- 賛成です --pyrite 2014年12月28日(日) 20:06
少し考え方を軟化させたというか、明朝体化してある分に関しては、別の接尾辞で独立するならば制限しなくてもいいかなと思うようになりました。接尾辞をどうするか悩みますが。--kamichi 2014年12月28日(日) 20:29
- 前段の非明朝体異体字扱いの件賛成です。また草書などの崩し字系は、別の接尾辞があるといいと思います。
※出典元がハッキリしていればOKとの条件を付与し、「u####-sosho-###」「u####-##-sosho-###」(sosho=草書)
もしくは、「u####-fude-###」「u####-##-fude-###」(fude=筆書き。「-fude-」なら行楷書もOK？)などの接尾辞を新設。
以前、大字典𡨸喃(字形は基本楷書、一部草書または草書楷書交じり)の字形登録(
daitudien-013119)で悩んだ末、
個人占有グリフ
kamiyo_creas-u975e-itaiji-001
kamiyo_creas-u8863-itaiji-001で設定したと言う事がありました。
※無理やりIDS表記しても、直ぐに64文字越えしてしまいますので…--kamiyo 2014年12月29日(月) 00:50
匿名利用者によって大量に白紙化されましたが、まだ結論を出していなかったのに作業されてしまったという意味で抗議したいと思います。ですが、上記の試案に従って、復活はしないという方針でお願いします。再登録はprefixとして「sosho-u####(-var-###)」という命名を想定しています。--kamichi 2015年2月23日(月) 16:53
その種の字体を大量に登録していたものですが、単にUSER名付きグリフを激増させたくないという理由でitaijiにしていただけなので、他に接尾詞を作るなら白紙化OKです。なので残りも気にせず消して下さい。--yoshiciv 2015年2月23日(月) 18:58
- 「sosho-」は複数の解釈が想定されるので「sosho-u####(-var-###)」ではなくyoshicivさんが作られたように「sosho-u####-###」でいきたいと思います。
CDP外字の「古」「新」の命名について
CDP外字はグリフウィキでは「旧」版のもの(http://fonts.jp/glyphwiki/cdp3vers.pdf の中央のもの)をベースに作成されていますが，「古」「新」のグリフを作成したいという需要もあるようです(ノート:cdp-9daf参照)。以下に，案を示します。
| 古 | 旧 | 新 | 利点 | 欠点 |
| 案1(現状) | cdp-####-ko | cdp-#### | cdp-####-shin | 直感的に
わかりやすい | 検索がしにくい※ |
案2
(spinda-kkmr提案) | cdpo-#### | cdp-#### | cdpn-#### | 検索がしやすい | 直感的に
わかりにくい |
案3
(pyriteさん提案) | cdp-####-old | cdp-#### | cdp-####-new | | |
※検索がしにくいとは，例えば「古」版のCDP外字だけを検索したくても難しい，ということです。また，先頭一致検索で“cdp-”を検索すると3つのバージョンのCDP外字が交ざってしまいます。
個人的には案2が望ましいと思いますが，皆様のご意見をお願いいたします。
以上，--spinda-kkmr 2014年11月29日(土) 10:37
- CDP外字はこれ以上バージョンが増える可能性はありませんか？（shinshinとか出る羽目になったらイヤなだなぁ）
ないのなら上記のような感じでいいと思うのですが、個人的にはko/無印/shinよりはold/無印/newがよいです。
あと検索は正規表現使えないんでしたっけ。使えるなら便利なのですが。--pyrite 2014年11月29日(土) 11:54
- 表にpyriteさんの案を追加しました。私は案2を支持する理由としては，CDP外字は「古」「旧」「新」では全く字形が違う場合があるので，基本的に同一の文字がベースであるUnicodeのソースを表す“-g”“-k”のように接尾語で表現するのは好ましくないと考えるからです。--spinda-kkmr 2014年11月29日(土) 12:04
- 「古」版と「旧」版で字形が異なる例としては，「古」版のcdp-8b7d
sandbox@2062に対し，「旧」版の
cdp-8b7dなどがあります。--spinda-kkmr 2014年11月29日(土) 12:17
- ワイルドカード[_][%]が使えるようです。また、デフォルトの検索にはキーの末尾に[%]を付与して検索しているようです。[cdp%-8555]で検索すると
cdp-8555
cdpo-8555
cdp-8555-koがヒットします。好みとしては接尾語をつけるスタイルのほうがいいのですが、特にこだわりはありません。 --tsuruki 2014年11月29日(土) 14:19
- 私は最初、案3の「cdp-####-old」「cdp-####-new」(私も同じ事を考えていました)がいいかな、と思いましたが新旧で字形が全く異なる観点、かつ直感的に解りやすいと言う事を考えると、「cdp-old-####」「cdp-####」「cdp-new-####」が良いかと思います。
あとバージョンが増える事を考えた場合であれば、「cdp-v1-####」「cdp-v2-####」「cdp-v3-####」として無印「cdp-####」をいずれかのバージョンにエイリアス化するのも有りかと思います。--kamiyo 2014年12月29日(月) 10:12
- ずいぶん昔の話になってしまいますが、また、どれが旧でどれが新かという議論もありますが、案2でいきたいと思います。理由は上記にあるように、3バージョンでまったく異なる字形が入っているケースがあり、「別集合」を強調するためです。--kamichi 2015年5月6日(水) 21:29
Ext F2グループの生成
Ext F2が追加される予定であることを案じて、ExtF2仮というグループ(グループ:ExtF2仮)を作っておきました。それに伴い、まだ追加していない漢字を補えば幸いだと思います。--ldx0 2014年10月22日(水) 10:19
外国語の記事の見分けについて、およびグリフウィキの多言語UIについて
今のグリフウィキのなかで外国語への翻訳が進んでおり、それを見分けやすくためにグループを作る必要がございます。それにつれ、まず韓国語からなる記事を含むグループ(
グループ:韓国語対応ページ)を作っておきました。外国語の記事を同定しやすくためな提案なので、皆様からのご意見をお伺いしたいです。--
ldx0 2014年10月15日(水) 11:35
- （一番上に持ってきました）ありがとうございます。韓国語のUIはすでにデータをいただいていること、および中国語のUI、韓国語のページについて、翻訳を協力していただけるという申し出を受けていること、もありますので、早急に翻訳についての作業場を整備しなければなりません。--kamichi 2014年10月15日(水) 12:39
- 翻訳プロジェクトの件について、メールを送りました。ご確認お願いいたします。--ldx0 2014年10月15日(水) 13:00
- 確認しました。ご協力ありがとうございます。--kamichi 2014年10月17日(金) 08:43
見出しを勝手に分岐してしまいますが、現在日本語と英語の2言語が用意されているグリフウィキのUIについて、韓国語と簡体字中国語を増やしたいと思います。これは純粋に利用者（登録および活用のいずれも）を増やしたいという意図もありますが、将来的に科研費などの研究費を申請するにあたってのアピールの側面もあります。現在韓国語が５０％程度、簡体字中国語は始めたばかりです。これら2言語について、ある程度完成してから実運用に入ろうと考えていましたが、逆に運用を始めてしまい、「翻訳が足りないな」と思ってもらう方がいいのかと思うようになりました。どちらがよいと考えますでしょうか。なお、当然ですがUI言語を増やすことにより、今までの価値観でいうノイズは増えると思いますが、これは受け入れざるを得ないと考えます。--kamichi 2014年10月17日(金) 08:43
- 別件のいたずらのこともあり、日本語以外のUIはROM（閲覧）のみの機能にするということもちょっと考えています。やや極端すぎるでしょうか。--kamichi 2015年1月7日(水) 23:40
新しい接頭辞の決定について
（すでにこの意見は出されているかもしれませんが）緩やかな運用の方法として、今後、新しい接頭辞を使いたいという場合に、「グループ:接頭辞」というページを作り、そこにその出典情報やグリフ名の命名法を書く形で明示するという運用はいかがでしょうか。たとえばすでにガイドラインに入っている「koseki-######」については「グループ:koseki」のページを作るという方法です。うまく統一できれば機械的に「koseki-######」のページに「グループ:koseki」へのリンクを張る形にしても良いと思います。一部の文字コード(CNS 11643)についてはページが乱立してしまいますが。--kamichi 2014年9月30日(火) 14:01
- 微修正します。単に接頭辞の名前のページだとバッティングする可能性があるので「グループ:prefix-(接頭辞)」にしようかと思います。長いでしょうか？--kamichi 2014年10月8日(水) 08:39
- 賛成です。「グループ:」の後ろに「prefix-」のように何らかの接頭辞のグリフか、その他のグループか判りやすいと思います。ちなみに名称の長さは、グループ名ですので気にならない範囲だと思います。--kamiyo 2014年10月13日(月) 19:43
- 異論が出ていないようですので，試みに香港のIVD提案のためのグループ:prefix-hkaを作りました。kamiyoさんの作成されたページを真似ています。共通して必要な情報があれば，テンプレートを定義していただくと，グループの作成者が助かると思います。 --ziyang 2014年12月28日(日) 18:23
GTコード(GT書体)の字形について
下記の「GやTやVソースの字形を忠実に再現することに関して」でも言及しましたが，GTコード(GT書体)は画数を明確にするために故意に不自然な字形を作成していることがあります。
私はこれを厳密に再現する必要はないと考えます。その理由としては，
- (1)CHISE-wikiでは，GTコードと他の文字コードをGT書体独特の字形を考慮せずに対応付けている。
- (2)厳密に再現しようとすると女偏や人偏，行人偏のグリフを既存のグリフとは別に作らなければならず，結果として“gt-#####”グリフの登録の妨げになる。
の2つです。試案として，以下の2つを提案いたします。
1.以下の字形を許容する。
※行人偏には行構えの左側を含む
2.画数を明確にするための不自然な字形(例:
gt-00700@2の中央下の折れなど)を厳密には再現しなくてよい。
以上，--spinda-kkmr 2014年9月15日(月) 17:45
- 上記許容に賛成です。
あまりGT書体は確認しておりませんでしたが、結構癖のある字形が多いですね。(ExtFのz-sat#####もGT書体由来？)
上記2.と重複している可能性がある気もしますが、現状判明している分を念の為以下表を追加致します。
- 反対です。
グリフ名の対象となる字形が明確な物（対象がフォントや大きな画像情報）の文字に対してはなるべくオリジナルと同じようにするべきだと思います。 --tsuruki 2014年9月21日(日) 11:23
- （口（や糸の「厶」）は
こんな(umbreon126_sandbox@31) 字形でしょう。）私は今反対も賛成もない。でも、私の意見では、要項は筆画の字形ではなくて漢字の字形（？？）です。例：厶の鱗の有無は重要ではない、口はどうでも良い（Gソースのような字形はどうでしょう？GT書体は中国の字形を基にするようです）、人偏は（中華字海と同様に）u4ebb-01-var-001とする--umbreon126 2014年9月21日(日) 12:02
- この問題は結論が出にくいと思います。GT書体は抽象字形ではなくフォントなので、忠実に再現するべきという意見に私も同意しますが、では忠実とは何か、という部分では人によって字形差の認識に差が出ると思います。台湾の「口」もそうですが、GTの「口」を忠実に再現すべきかと聞かれれば個人的意見としては同意しにくいです。ですので、面倒ではありますがやはりガイドラインというか個々の特徴的部品について、○×で意見をまとめるしかないのではないでしょうか。--kamichi 2014年9月21日(日) 19:39
- GTコードの実装はGT書体だけではありません。Tフォントの3書体もGTコードを実装していますが、これらの字形は(Tゴシック、T楷書はもちろんのことT明朝も)必ずしも上記のような字形を再現していません。ですからGT書体のデザインを忠実に再現する理由はないと思います。むしろT明朝を参照したほうがいいのでは。--emk 2014年9月21日(日) 21:15
- なるほど、それもおっしゃる通りですね。ただ、おそらく当初はグリフウィキにおける「gt-」はGT書体を想定していたと私は思います。GT書体とGTコードを別に考えるとしてグリフ名も分けて考える必要がありそうです。これはデータの登録者・利用者の意向が優先されると思いますが、実際問題としてGTフォントとT明朝、いまはどちらのシェアが高いでしょうか。私の周りではやはりまだGTフォントを使っている人がちらほらで、T明朝利用者は聞いた事がありません。--kamichi 2014年9月21日(日) 22:53
- T明朝のほうがいいでのはないかと思ったのは、より一般的な明朝体のデザインに近いので、より仮想J字形と整合性のとれたデザインになる可能性が高いと思ったからです。GT書体のグリフそのものがほしければGT書体をそのまま使えばいいのではないでしょうかと思いましたが、ライセンス上の理由(商用利用不可)から自由でGT書体のデザインに忠実なグリフへの需要があるのでしょうか。--emk 2015年1月2日(金) 16:17
- 議論が止まってしまっていますが，あくまでも「許容」であって仮想J字形のような「強制」ではないので，これで運用してもかまわないと思います。“忠実に再現したい場合にそれを禁止するものではない”というやや緩めのガイドラインで運用すればよいと思います。--spinda-kkmr 2015年12月27日(日) 11:52
- とりあえず，上記のガイドラインで試運用してはどうでしょうか。--spinda-kkmr 2015年12月27日(日) 12:17
- 試運用に賛成です。というのは、グリフウィキは字体差と書体差の線引きがあくまでもユーザーの主観によるので、結論は出せないと思います。区別したい人に禁止を強制できない、という形になると思います。--kamichi 2015年12月29日(火) 14:38
- グループ-ノート:GTコードに上記ガイドラインを追加しました。--spinda-kkmr 2015年12月31日(木) 12:56
手書き検索について
出やすい文字と出にくい文字の差が激しいと感じていましたが、どうやら書き順が重要なようです。ちょっと困りますね。--kamichi 2014年8月13日(水) 15:21
TRONコードの命名について
現在，TRONコードの命名は“tron-#-####”となっていますが，TRONコードは現時点で第31面まで予約されており，第10,16,17,22,23面には既に文字が割り当てられているようです。したがって現在の命名ではこれらに対応できません。解決法として，次の2つが考えられますが，どちらが望ましいでしょうか。
- (2)第10面以降を英字で表現する。
- つまり第10面は“tron-a-####”，第11面は“tron-b-####”とし，第31面を“tron-v-####”とする。第10,16,17,22,23面はそれぞれa,g,h,m,nとなる。既に存在するグリフ名を変更しなくてよいというメリットはありますが，第10面以降が直感的にわかりにくくなります。
私は(1)が望ましいと考えますが，皆様の意見をお願いいたします。
参考ですが，2014年1月1日時点の“tron-#-####”のグリフ数は383です。
以上，--spinda-kkmr 2014年1月25日(土) 11:11
現状 CNS 11643 が36進(10+アルファベット）になっているので、(2)の１桁でいいのではないでしょうか。 --tsuruki 2014年1月25日(土) 14:17
- 私も(2)の名称はCNSの「TA-####(10面) TB-####(11面) TC-####(12面) ...」を連想しました。
またTRON自体31面を超える事が無さそうですし、現状の名称を崩す事をせずにすみますので、(2)で良いかと思います。---kamiyo 2014年3月1日(土) 10:26
- すみません、意思表明していませんでした。大変申し訳ないのですが、私は(1)案を支持します。移行グリフ数もそれほど多くなく、脳内での読み替えが不要になるためです。移行は機械的にやっても構いません。--kamichi 2014年3月1日(土) 17:06
- 私は(1)案支持です。今後TRONコード(TRON文字収録センター)の活動が再度活発化すれば第32面以降に拡張される可能性もありますし，グループのほうは比較的楽に修正できるので，グリフの置き換えを行っていただければありがたいです。--spinda-kkmr 2014年3月1日(土) 18:31
- 移行が正式に決まるまでは，“tron-#-####”グリフの新規作成は控えさせていただきます。--spinda-kkmr 2014年3月2日(日) 11:11
- 余談となりますが，TRONコードの第11面から第15面まではかつて〓〓〓〓〓が使用していたので，“tron-11-####”～“tron-15-####”はライセンス上作成できないと命名ガイドラインに明記しておかなければいけませんね。--spinda-kkmr 2014年3月2日(日) 13:41
- 半年前で議論が止まってしまっていますが，個人的にはTRONコードを利用したいので，なるべく早くグリフ名の移行を行っていただければありがたいです。グループは利用者側で比較的楽に修正できると思います。--spinda-kkmr 2014年9月21日(日) 11:28
- 議論が長期間止まってしまっているために，TRONコードのグリフの新規登録が事実上できない状況が続いています。グループ:TRONコード序数記号に収録されている記号など，TRONコードでしか表現できないものもあります。できる範囲内で，早期のグリフ名移行をお願いいたします。グループは利用者側で修正できると思います。--spinda-kkmr 2015年1月30日(金) 17:18
- 催促するようで申し訳ありませんが，時間のある時でよいので，なるべく早くグリフ名の移行をお願いいたします。グループ側は各利用者で修正できると思います。現状ではbotの利用はkamichiさんに限られていますし，私はプログラミングができませんのでbotの作成ができません。自力では何百もあるグリフを手動で移動しなければなりません。--spinda-kkmr 2015年3月28日(土) 19:10
- 催促ありがとうございます。今から開始します。以下の手順を想定しています。--kamichi 2015年3月28日(土) 21:15
新グリフ名を旧グリフ名のエイリアスとする完了エイリアスの向きを逆転完了- 1日置いて、旧グリフを白紙化
- 大変遅くなりました。作業が完了し、「tron-?-」グリフは0個になりました。--kamichi 2017年12月17日(日) 14:29
質問
すいません。Exta日本提案字って何ですか？こんな質問ですみません。
- 質問の意図が分かりませんが、1つの意味はExt.A集合の審議の際、日本代表から提出された追加希望集合のことです。各国・地域からそれぞれ提出のあった集合について審議し、1つにまとめていきます。--kamichi 2013年12月3日(火) 08:23
- ちなみにその集合はUCSでは「Unified Japanese IT Vendors Contemporary Ideographs」（略称JA）と呼んでいますので、この名称で検索するといろいろでてくると思います。--kamichi 2013年12月3日(火) 08:27
MJ文字図形名“jmj-######”の命名ガイドライン追加について
“jmj-######”を命名ガイドラインに追加することを提案いたします。現在，Ext-FにおけるJソースとしてこの命名が出現し，グリフが作成されていますが，
という理由から，命名ガイドラインに追加するに足るものと考えます。ご意見をお願いいたします。--spinda-kkmr 2013年7月5日(金) 20:56
- “jmj-######”ですが、命名ガイドラインに追加賛成です。mjの文字収録数が6万字近く存在する上、現在提示されているExtF(v1.0)に存在する“jmj-######”も1800字超存在しますので追加すべきと思います。--kamiyo 2013年7月5日(金) 22:47
- 賛成です。簡単ですが取り急ぎ。--kamichi 2013年7月6日(土) 09:55
- “jmj-######”を命名ガイドラインに追加しました。--spinda-kkmr 2013年7月6日(土) 11:50
Jソースが存在するExt-Fの字形について
extf-07257(
jmj-058846)のように，Jソースが存在するExt-Fの字形については，
GlyphWiki:仮想J字形のガイドラインを適用せず，1点之繞などの新字体的な字形もそのまま作成する，ということでよいでしょうか。--
spinda-kkmr 2013年5月25日(土) 19:27
- その方針でよいと思います。GlyphWiki:仮想J字形のガイドラインの「仮想J字形が適用されるグリフ」の節に、そのようなグリフを除外する旨を書き足すべきと考えます。―twe 2013年5月25日(土) 20:15
- 提案ありがとうございます。賛成です。若干気になっているのは、昔Ext.Cの資料で平成明朝ではない日本提出のグリフが最終的に若干変化した記憶があります。Ext-FのJソースというのは字体として固まっている物なのでしょうか。--kamichi 2013年5月26日(日) 08:47
- 現在のExt-Fの資料では，Jソースはほとんど(全て?)が“jmj-0#####”となっており，これは文字情報基盤文字情報一覧表 のMJ文字図形名と一致します。ですので，字形としては安定していると思われます。--spinda-kkmr 2013年5月26日(日) 10:01
- 遅くなりましたが，GlyphWiki:仮想J字形のガイドラインにExt-Fのグリフに関する記述を追加しました。--spinda-kkmr 2014年2月9日(日) 18:27
合成用(non-spacing)グリフについて
GlyphWikiで作られたフォントで合成ができるかどうかをチェックするため、
グループ:johotogoshinentai_サンドボックス@16でフォントを生成し、「q̉」、「鿌⃝」をMS Wordなどで入力し、そのグループで生成されたフォントを適用してみました。合成には問題がありませんでした。
現在、GlyphWikiには、
u20ddや
u20de、
u3099、
u309aのように、いくつかの合成用グリフが作成されています。これらが現状ではspacingグリフとして実装されますが、合成用文字が合成できないのは望ましくないと思われます。ということで、このようなグリフをグループ:NonSpacingGlyphsに集めました。そのグループに記述されているグリフの幅を0にセットするように変更するのが良いと思います。 --johotogoshinentai 2013年3月31日(日) 19:10
グリフの幅を0にするだけでは（前ではなく）後の文字に重なってしまいそうなんですが、その辺はどうなんでしょう。 --hanubeki 2013年4月1日(月) 16:21
- グループ:johotogoshinentai_サンドボックス@16の合字用グリフでは0:0:200:200より左側の範囲に配置されているようですね。しかし、これではGlyphWiki上での表示が真っ白になってしまいます。 --hanubeki 2013年4月1日(月) 16:27
- その問題には、2つの対策があります。一般のグリフは横の始点が0、終点が200だとしたら、
- 1) 合成用グリフは始点も終点も0にする：u0020-u####やu3000-u####に0:0:200:200内のグリフを作成します。そして、u####にはu0020-u####やu3000-u####を引用し、それを左に100pxや200pxシフトします。こうするとu####は真っ白でも、u0020-u####やu3000-u####を見ると元のグリフを見ることができます。
- 2) 合成用グリフは始点も終点も200にする：こうするとu####が真っ白にならないので、u0020-u####やu3000-u####を作成する必要がありません。ただし、半角文字の上に重なる合成用グリフは右寄せにする必要があります。 --johotogoshinentai 2013年4月1日(月) 16:52
- 3) 2+グループ:HalfwidthGlyphsとグループ:NonSpacingGlyphsの両方に定義されているグリフは始点も終点も100にする、というのも考えてみましたが、処理が複雑になりそうですね。 --hanubeki 2013年4月1日(月) 17:54
- HalfwidthGlyphsとNonSpacingGlyphsの両方に定義されているグリフは存在しないので、それは実現できないと思います。半角でありながら合成用であるグリフは存在できません。 --johotogoshinentai 2013年4月1日(月) 17:57
ちょっと考えてみて、まとめてみました。始点・終点の位置により、次のようになります。
始点も終点も100のほうがほかの場合よりはマシだと思われますが、いかがでしょうか。 --johotogoshinentai 2014年1月22日(水) 19:42
反転グリフも作れるようになりましたし、合成グリフも作れるようにするのもどうでしょうか？グループ:HalfwidthGlyphsに属しているグリフは始点0、終点100に設定されているように、グループ:NonSpacingGlyphs-Halfwidthに属しているグリフは始点も終点も100、グループ:NonSpacingGlyphs-Fullwidthに属しているグリフは始点も終点も200にすれば良いでしょう。 --johotogoshinentai 2014年10月14日(火) 10:31
- 私も合成用グリフの早期実現に賛成です。多くのフォントにて実装されているので，花園明朝も対応するほうがよいと思います。--spinda-kkmr 2014年11月1日(土) 12:10
- 合成用グリフと合成済みグリフと頭の中でごっちゃになっています。合成用グリフの方はspacingなど（？）のメタ情報をいじるだけでできるという理解でいいでしょうか。--kamichi 2014年11月1日(土) 12:58
- あるグリフにメタ情報が入っているかどうかをチェックするためにはグリフをいちいちチェックするしかありませんが、合成用グリフもHalfwidthGlyphsのようにグループで管理すると、どのグリフがグループに入っていてどのグリフが抜けているかをチェックするのが便利です。というわけで、私は合成用グリフもHalfwidthGlyphsのようにグループで管理するほうが良いと思います。 --johotogoshinentai 2014年11月1日(土) 13:14
- ziyangさんありがとうございます。まさにおっしゃる通りの意味でした。ですが、まだよく理解できていないかもしれません。合成用グリフを用意するならばおそらくhmtxテーブルを操作するものと思います。合成済みグリフを用意するならばおそらくgposテーブルを用意するものと思います。どっちでしょうか？hmtxテーブルをいじってみたのですがosxとwindowsでずれ方が違うので合わせて混乱しています。--kamichi 2014年11月2日(日) 14:09
- 合成用グリフの経験がないので，頭の中でadvanceWidthを0にしてOKと思っていました。OS XとWindowsでずれ方は違うのは，何か深い闇があるのでしょうか。私の手に余るので，より詳しい方のご意見があれば有難いです。--ziyang 2014年11月2日(日) 15:22
- 合成済みグリフの実装は合成用グリフの実装より難しいようなので、とりあえず合成用グリフだけを実装しましょう、と言ったのです。合成用グリフは始点と終点を調整するだけで済むと思いますが、合成済みグリフの実装はそれより複雑な処理が必要なようなので。 --johotogoshinentai 2014年11月2日(日) 19:19
- とりあえず重ね打ちによる合成だけでも早期に対応してほしいです。そうすればグループ:JISX0213合成文字の25文字のうち23文字は表現可能になります。
- この議論は井戸端にコピーしてよいでしょうか? これはグリフウィキ全体に関することなので，利用者全員の目に届きやすいところにあるほうがよいと思います。
- 以上，--spinda-kkmr 2015年5月23日(土) 12:48
上記，利用者-会話:kamichiよりコピーしました。--spinda-kkmr 2015年6月4日(木) 18:32
合成用グリフの実装は、(普通のグリフの始点が0、終点が200なら)
もし始点を0以外にするのが不可能であれば、半角グリフのように終点だけを変える方法で決定してください。つまり、グループ:NonSpacingGlyphsにあるグリフはすべて始点も終点も0で実装されるようにしてください。(GlyphWiki上では真っ白に見えますが、それは仕方ありません。) --johotogoshinentai 2016年6月28日(火) 09:16
iOS11でグループ:kesuuko_sandbox@3で生成されたフォントで実験をして確認したところ、正常に合成されました。--kesuuko 2017年10月8日(日) 23:03
- このことから、私は合成用文字も通常の文字のようにデータを登録すべきだと思います。(例えば、
u0300は
u0060のエイリアスとする。)--kesuuko 2017年10月9日(月) 00:11
- 後手後手ですみません。今までの書き込みではtweさんのおっしゃる、グリフを負の位置に置いて文字移動幅0にする方法と、johotogoshinentaiさんのおっしゃる、始点と終点（といってもこれがグリフデータ上どれを指すのかわからないのですが）を真ん中にすればいい、という2つがあり、まだ混乱しています。それとkesuukoさんの方法はグリフウィキとしては合成用文字として特に処理されず、OSレベルでU+0300グリフがnon-spacingグリフとして扱われているものと思います。ですので、まだ私の中ではどうすれば合成用グリフが生成されるのかが見えていません。そこで、既存のフォントの挙動を参考に作りたいと思います。合成用グリフがきちんと利用できるフォントの代表と言ったら何でしょうか？Arial Unicode MSは大きいので、普通のラテン用フォントでご教示いただきたく思います。--kamichi 2017年10月9日(月) 09:16
- 当時きちんと読んでいなかったのがよくないのですが一番初めの「2013年3月31日(日) 19:10」の書き込みを読んで理解したのは、KAGEデータで99の部品引用で負の位置に配置すれば合成ができる、ただし文字幅が0でないので2文字分になる、文字幅を修正すれば合成用グリフの実装ができる、ただしグリフウィキ上文字が見えないのが問題、そこでグリフウィキで指定したグリフ集合について、普通の場所に置いたグリフを負の位置に配置して文字幅0に設定する特別処理を用意すれば合成用グリフが生成できる、ということでいいでしょうか。今はグループ:HalfwidthGlyphsにあるものはFontForge上で「SetWidth(512)」という指定をしているだけです（通常は1024）。これを0にするというのがtweさんのおっしゃっている内容と思い、私もこれで行けるのではないかと思っています。--kamichi 2017年10月9日(月) 09:26
JIS規格になくAdobe-Japan1だけに存在する漢字について
1年前、
ノート:u26c9eに書きましたが、返事がなくて井戸端で議論したいと思います。
𦲞(u26c9e) のように、JIS規格になくAdobe-Japan1だけに存在し、AJ1の字形がUnicode/ISOと異なると、AJ1の字形を優先するのはいかがでしょうか。AJ1は日本語表記に使われている文字を集めている集合なので、準JISみたいなものだと思われます。ちなみに、メイリオもそんな実装をしているようです。 --johotogoshinentai 2013年3月26日(火) 10:48
- ちょっと考えてみましたが、Jソース(JA、JHソースなど)とAJ1の字形異なると、JソースとAJ1のどっちを優先するほうが良いでしょうか。 --johotogoshinentai 2013年3月31日(日) 00:34
- JA,JHの場合悩ましいですが、原則論は国内規格字形優先が妥当かと思います。--kamichi 2013年6月3日(月) 12:04
メタ情報の削除について
- 荒らしによってノート:aj1-20072に書き込まれたメタ情報を削除しようとしてもできません。これは仕様でしょうか? --spinda-kkmr 2013年2月28日(木) 19:01
- あれ？普通に白紙化できましたが、どのような状況でしょうか。（私はJavaScriptを切っているのでそれでOKだったのかもしれませんが…）--kamichi 2013年3月1日(金) 07:46
- 先ほど，匿名の状態でsandboxにメタ情報を書き込み，その後ログインして編集を試みたところ，正常に削除できました。ノート:aj1-20072の時はメタ情報が存在するにもかかわらずノートページにメタ情報が表示されませんでした。原因は不明です。--spinda-kkmr 2013年3月1日(金) 18:24
KAGEエンジンの新しい改造内容について（2/12更新）
sandbox@1130のように、99で引用した部品について、ストレッチ機能を追加しました。中心(100,100)から第2項目をX座標、第3項目をY座標（ただし中心からの差分）で表現される座標に向けてリニアに変形させます。たとえば「99:-20:0」とすると左に圧縮します。「99:0:-20」とすると上に圧縮します。圧縮の端は0,0や200,200の外枠ではなく、その部品の最端座標になります。
大変申し訳ないのですが、現在のグリフエディタにこの機能を追加することができません（あまりに煩雑すぎて断念しました）。ですのでしばらく手作業になります。（根性でなんとかグリフエディタでも反映できるようにしました。99部品を選択すると真ん中につまみが表示されるので、それを0,0-200,200の範囲内（目安）で動かしてください。
- 現在試行中とし、しばらくしてこの機能がメリットがあるかないかを判断し、ないということでしたら廃止します。--kamichi 2013年2月1日(金) 22:09
- やはり中心から、というのは無理があるかもしれません。任意の点から任意の点への変形でしょうか。また、１つではなく２つ、という要望も出そうですが、そうすると現状のKAGEでは座標が足りなくなってしまいます。たとえば全面引用（0,0-200,200）のみ変形を認めるなどの限定が必要と思います。--kamichi 2013年2月2日(土) 00:29
2/2の変更
大変ご迷惑をおかけしました。99番による部品引用時のストレッチ機能に2種類用意しました。
- Aモード：中心点(100,100)から任意の1点に向けてのストレッチ
- Bモード：任意の点から任意の点に向けてのストレッチ
後者は例えば左右２部品の左右のバランスを変更するなど、いろいろ応用ができます。
使い方ですが、まず９９部品を選択すると灰色のつまみが中央に現れます。これを操作するとAモードの調整となります。つまみを右（X座標でいう２００以上）に持っていくとつまみが左にワープし、同時に中央に黄色のつまみが現れます。これがBモードです。黄いつまみが元の基準となる点を表し（黄つまみを動かすと灰色つまみも同じ位置に動きます）、灰色つまみがストレット先を表します。まず黄つまみで部品内で分割する位置を指定し、いったんマウスクリックを離し、再度クリックすると灰色つまりを動かせますので変形します（２つのつまみは全体（200ドット四方）に対するものなので、部品を100%の大きさにしてからでないとイメージがつかめずうまく調整できないと思われます）。
BモードからAモードに戻すには、灰色つまみを左（０以下）に動かします。
- 問題点として、上級者以外の人にとっては、変形機能よりも変形され終わった部品が用意されている方が便利、と思うことでしょうか。--kamichi 2013年2月2日(土) 18:07
- ちょっと自由度が高すぎますね。グリフウィキの理念とは若干ずれてしまっている気がします。パラメータ１つぐらいで調整できる範囲が望ましいかと考えます。--kamichi 2013年2月3日(日) 17:16
- 私もそう思います。構えや繞を調整するためならば，ストレッチ機能はAモードだけでもよいと思います。そうなると今までにBモードで調整されたグリフを再調整する必要がありますが… --spinda-kkmr 2013年2月3日(日) 19:06
- ありがとうございます。昔KAGEシステムが自動合成を主としていたときに、はめ込み用の枠（四角）、というものを設定できました。他の部品と組み合わせるとその部分にいれる、というものです。逆に言うとその枠を拡大縮小するような仕組みでいいのかとも思います。個々の筆画に影響を与える変形は上級者すぎるかなと思います。--kamichi 2013年2月3日(日) 21:39
いったん使用停止でお願いします
まだ議論は途中と思いますが、いったんストレッチ機能は新規の使用は停止して、再検討したいと思います。今考えているのは、グリフに新しい線分を設定できるようにします。この線分は始点と終点の２点で構成されます。視覚上はなにも表示されません。変形の度合いが０％〜１００％に相当します。つまり変形Bタイプの黄色の点が始点に相当し、灰色の点が終点に相当します。そして９９部品として利用するときにスライダで０％〜１００％の範囲で変形度合いを調節する、というものです。線分上をスライダでそうさするか、X軸とY軸に分けてスライドできるようにするか悩んでいます。--kamichi 2013年2月3日(日) 23:16
- 自由度が相当高いから、かなりデザインの得意な人が慎重に使わないと、グリフ同士の統一性が損なわれる恐れが有るなあなどと思っていました。それで私が考えていたのも、部品側に基準点と変形方向の情報を予め持たせるという案で、多分 kamichi さんが考えていらっしゃるのと似た話だと思います。
あるいは、変形度合いの異なる二つの部品グリフを参照して、マルチプルマスターみたいに補間する機能が有ったら、応用性と、簡便さと、デザインの統一性を満たせるかも知れません。ちょっと複雑ですけど。（ニンベンの右側には「去」と「去-02」の平均を使うとかいう事も…。）— sayunu 2013年2月4日(月) 00:02
- 仮にそうやるとしたら、二つの分離したグリフを参照するのではなくて、一つの部品グリフ内に二つのマスターを纏めて持っておくというシステムの方が良さそうですが、大きな改修になりますかね。— sayunu 2013年2月4日(月) 00:31
- いや、マルチプルマスターはまた別の話にした方がよさそうですね。単純な変形機能に関して言えば、変形方向に「斜め」って必要でしょうか ? モンガマエ・トラガシラ・シンニョウみたいな大抵の場合は垂直か水平だけでまかなえると思いますが、問題はヤマイダレとかでしょうか。タレの類はかつて「どれぐらいのバリエーションを用意すればいいか検討しないといけないなあ」と思いながら放置してしまったので、まだ自信を持って言えないのですが、ヤマイダレって実は縦の調整はそんなに要らないのではないかという印象が有ります。斜めが可能で困る事も無いでしょうけど。縦横別々に調整できる必要は無さそうに思います。
調整スライダーは、0〜100 の 101 段階という事でしたら、細か過ぎるのではないかと思います。0〜10 の 11 段階で足りるでしょうし、0〜5 の 6 段階ぐらいでもいい気がします。
部品を作る上では、もしかしたら「始点から終点まで」よりは「基準点からプラス方向とマイナス方向へ」変形できるしくみの方が扱い易いかも知れません。普通は中庸な大きさで部品をデザインしますし…。線分の中心点を基準にするとか ? いや、でもあまり自信は無いです。— sayunu 2013年2月4日(月) 06:18
- ご意見ありがとうございます。正負両方、荒めに調整、同意します。それで、XとYの分離が必要かどうか、ですが、よくわかりません。たとえば「まだれ」や「しんにょう」などの２方向囲いなどで必要か？と考えました。といっても囲うものはだいたい矩形ですので１軸でいいのかな？まず１軸で実装し、足りないと言うことであれば分離を検討、とも思います。--kamichi 2013年2月4日(月) 08:46
例:
ufa66 -> 65,100(L) LだけなのでX軸のみ。Y座標は無視される。X座標65から左端(12)の方向にストレッチ
2/12の変更（第３世代）
- 手を入れました。KAGEエンジン自体の変更はなく、あくまでグリフエディタにおいて今までのような詳細な変形をできなくしました。
- まずグリフのメタ情報に「ストレッチ境界」という属姓名で境界となる座標(x,y)とそこからのストレッチの方向（UDLRで上下左右。２つ指定すると四隅を指定）を指定します。
- その情報があるグリフについてはエディタで99部品として選択したときにストレッチの段階を-10〜10で変更できます。なお、すでに第2世代までで値を設定していた場合、今後メタ情報をセットして部品エディタで選択すると値が壊れますので、再度-10〜10で調節してください。
- まだ試行とします。各ユーザーの試用をお願い致します。--kamichi 2013年2月12日(火) 01:42
- メタ情報のセットが面倒なので、あまり使われていませんが、まずは大きな問題無しということで、このやり方での運用を行いたいと思います。メタ情報のセットのし易さについて機能追加を検討したいと思います。--kamichi 2013年2月15日(金) 08:23
キャッチフレーズのこと
新しいロゴを kamiyo さんが作ったそうでお疲れ様です。悪くないと思います。（仮名が旧版なのが残念ですけど…。）それで、この「漢字グリフ登録管理サイト」というフレーズはこれが最も良いんですかね ? 初見の人にもこのサイトの目的が端的に伝わるといいなあと思うんですが、「登録・管理」よりは「共有」を前に出したらどうでしょうか ? 例えば「フリー漢字グリフ共有サイト」みたいに…。このシステムの売りは「登録できる、ヤッター」でもなく「管理できる、ヤッター」でもなくて、最終的に「共有できる、ヤッター」でしょうし。— sayunu 2013年1月14日(月) 17:52
- ご意見ありがとうございます。これ、人によって若干違うでしょうね。私は「自由」という文言を是非入れたかったのですが、どう入れるか悩み、やめました。文言の決定は私の責任だったので、私の考え不足ということになります。もしもっと良い文言がありましたら、kamiyoさんにお願いして文字だけ差し替えていただこうかと思っています。--kamichi 2013年1月14日(月) 17:59
- ええ、自由（フリー）という表現は是非欲しいです。少なくとも私が考える限り、自分の作るデータを権利放棄してまでこのウィキに預ける事は、本人にとって利益にならない慈善行為ぢゃないですか。このサイトに載っているデータをどこの誰でも手軽に自由に無料で使える様にという目的の為に「登録」も「管理」もやっているんですよね ? データを登録する人よりも、データの恩恵を受ける人の方が多くなってくれないとしょうがない訣で…。
…あ、いや、そうか、このシステム上で独自の漢字字形データを「管理」できるのが売りの一つなんでしょうか。その意図は気付かなかったです、すいません。— sayunu 2013年1月14日(月) 18:48
- ロゴを確定して、１００万レコード、３０万グリフ達成記念にロゴを印刷したマグカップを作ろうと考えています。ということで、このキャッチフレーズを詰めなければいけないのですが（笑）、「漢字字形自由共有サイト」「漢字字形自由共有網頁」「漢字字形自由共有ウェブ」「漢字字形自由共有Web」「漢字自由共有網頁」「文字自由共有網頁」では意味不明ですかね… --kamichi 2013年1月22日(火) 17:14
- うーん、その中で選ぶとしたら、一番奇異な感じがしないのは「漢字字形自由共有サイト」でしょうかねえ。「網頁」を使うとしたら、「サイト」ってルビでも振りましょうか。— sayunu 2013年2月2日(土) 18:24
- ありがとうございます。特に他にコメントもないので「漢字字形自由共有サイト」にしたいと思います。--kamichi 2013年2月10日(日) 21:47
- ロゴを更新しました。kamiyo様、ありがとうございます。--kamichi 2013年2月11日(月) 16:04
KS X 1001規格票例示字形(k0-####)のコード位置番号表記について
現在，KS X 1001規格票例示字形“k0-####”のコード位置番号は，区点番号で表記されています。
しかし，CHISE character descriptionやchise_linkmap，およびUnicodeの規格票では，KS X 1001のコード位置はGL領域の番号で表記されているようです。“k0-####”も，“j78-####”や“j90-####”のように，GL領域の番号で表現したほうがよいのではないでしょうか。
以上，--spinda-kkmr 2012年7月27日(金) 19:34
- ちょっと話が飛んでいるかもしれませんが、私は、k0-####は必要ないと思います。韓国の規格は文字が重なる場合がないからです。u####-kで十分だと思います。
- できるだけ重複グリフを避けたほうが良いと思っています。--johotogoshinentai 2012年7月29日(日) 12:05
- 2つの議論を分けて考えたとして、個人的には「k0-####」が「u####-k」で完全に代替できるなら、韓国ソースについては「u####-k」に一本化するということで構わないと考えます。現時点で、「完全」には代替できない、という情報をお持ちの方はいらっしゃいますでしょうか？また、重複グリフについては意見が分かれそうなので、ここでは取り上げないものとしてみます。--kamichi 2012年8月19日(日) 12:51
- 以前，johotogoshinentaiさんが指摘したことですが，KS X 1001の規格票の草冠は3画草冠
u8279-03なのに，ISO/IEC 10646のKソースは草冠がほぼ全て4画草冠
ufa5e-03になっています。したがって，KS X 1001の字形とISO/IEC 10646のKソースは異なると思います。--spinda-kkmr 2012年8月21日(火) 19:22
- もとの話題に戻しますが、区点表記とGL表記とどちらがいいでしょうか。統一するということでGL表記に移行することに賛成です。ある程度たくさんあるので機械的に移行することになると思います。--kamichi 2012年12月4日(火) 08:49
- この件ですが、GL表記に移行します。機械的に行う（autoglyph-botによる、新規登録と白紙化）予定です。--kamichi 2013年1月1日(火) 16:21
- 移行が完了しました。--kamichi 2013年2月11日(月) 11:59
u597dに対し
sandbox@996 (gt-07641) (女偏の形が違う)，「行」
u884cに対し
u884c-g (gt-45899) (左側の行人偏の縦棒の頭が接続)など。
u4ebb-01-var-001
u4ebb-01
u5f73-g01
u5f73-01
u5973-01-var-002
u5973-01
u7cf8-01-var-002
u7cf8-01
u53b6-g
u53b6
sandbox@1962
u53e3
tron-9-8023@5は
tron-09-8023に変更する。わかりやすいというメリットはありますが，既に存在する“tron-#-####”のグリフを移動・白紙化しなければなりません。
sandbox@1756
sandbox@1754
͡(u0361) 
sandbox@1757
u2040
sandbox@1755
sandbox@1758
sandbox@1759
square
u02e9-u02e5と˥˩
u02e5-u02e9は単に˩
u02e9と˥
u02e5を重ねるだけでは表現できません。JIS X 0213を全て収録するには，少なくともこの2文字だけは合成済みグリフとして搭載する必要があります。ちなみに，
u8fb6-g10
u8fb6-10-var-001、
u3ac3-05-var-001
u3ac3-10、
u9580-05
u9580-10
u9580-10-var-001などの部品は、それぞれストレッチ機能を使用し完全統合しても良い様な気もします。
sandbox@1131
sandbox@1132(Bモード)と
sandbox@1133(Aモード)。１画目の位置などに注目
RSS