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

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

GlyphWiki:井戸端

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

目次

各種議論の場として用意しました。個々の細かいルールはその都度決めていくということでお願いします。議論が終結したと判断したものはGlyphWiki:井戸端-保存に移動しました。また未解決のまま時間がたってしまったものはGlyphWiki:井戸端-未解決に移動しました。新しい話題の追加は一番上にお願いします。

RTL文字グループを追加できますか?

例:NegativeHalfWidthGlyphs・NegativeGlyphs —jjanggu 2021/09/24 11:10
  • まずグリフウィキの目的は第一が漢字です。その上で強い・広いニーズがあれば対応しますが、目的に対する優先順位から言うと難しいと思います。ちなみにRTLに対応する、というのはデータベース機能ではなく、フォント生成時のみに関係するということで正しいでしょうか。そうするとRTLフォントは全く未経験なので無理だと思います。--kamichi 2021年9月25日(土) 19:15

ユーザー:liuxinquanが妨害行為の疑いがあると見なすことができますか?

標題のとおり。--fitzgerald 2021年8月26日(木) 23:45
  • PS:このユーザーは会話を見ていないのかそれとも見ていないふりをしているのか分かりません。--fitzgerald 2021年8月26日(木) 23:47
  • 次に改善しなかった場合はSPAMユーザーとして利用停止対象とします。ご指摘ありがとうございます。--kamichi 2021年8月27日(金) 17:53

「pinyin-*」について

若干当事者以外の人も含めた編集合戦になりつつあるので、是非を検討しませんか。prefixが用意されているので、登録の手段については適切だと思います。一方で非漢字なので既存の集合であるかと言われると、あるような無いようなです。また、匿名編集者(ピンイングリフの全部か一部については言及しません)を、現状でSPAM投稿者として認定しています。ですので、今後もSPAM投稿が続く(登録失敗して表面上現れなくても)ようであれば、BAN対象として、過去のピンイングリフも一括して削除対象と考えています。--kamichi 2021年7月14日(水) 19:27

  • 私としては、「kumimoji-」命名に統合するのが落とし所だと思います。--kesuuko 20:11, 14 July 2021
  • グループ:漢語拼音音節組み文字にて出典とされている「现代汉语词典」は“中中辞典”(英英辞典の中国語版)のようですが,高額のため購入して確認することは私には難しく,どのようにこれらの拼音グリフが使われているのかはわかりません。ただ,常識的に考えれば拼音はラテン文字として表現できますので,わざわざ専用の組文字グリフを用意する必要性は薄いと考えます。組文字にしてしまうと英字幅が不統一になり,かえって見にくいと考えます。--spinda-kkmr 2021年7月14日(水) 21:57
    • 「现代汉语词典」はおそらく「bán等は実在していない」証拠として使用されていて、「bān等の組文字が存在する」証拠として使用されていない。sz 2021年7月15日(木) 06:30
    • 「现代汉语词典」はただの国語(大陸中国語話者にとっての)辞書で、今回のピンイングリフの出典にはならないと思います。情報の出し方が中途半端になりましたが、私の出典はサンセール社の中国語フォント(簡単電脳)の中に、漢字の上にピンインルビが振ってあるフォントがあり、それのピンインのみ版(そのものがあったかどうかは忘れてしまいました)とみなせば典拠ありかなと思った次第です。ピンインフォントの何が便利かというと、素の中国語の文章があった場合にそれをピンインフォントに切り替えるとそのままピンインに変わるので中国語学習者にとってピンインを調べる手間が省ける、というものです。もちろん多音字などはありますので多少の編集は必要ですが。kumimojiが漢字のため、と考えると本件は特別にprefix「pinyin-」を認めても良いのかなと思います。--kamichi 2021年7月15日(木) 08:15

フォント生成の不具合について

この間、フォント生成機能を使って生成したフォントのベースラインが上に来ているという不具合が起きています。修正をお願いできますか?--jjanggu 2021.06.09

  • すみませんがこの情報だけではとても今の忙しさでは対応できません。それとこれはバグ報告だと思うので、そちらにお願いします(もしすでに書かれていて気が付いていないということであれば、それを指摘してほしいほどの忙しさです)。--kamichi 2021年6月9日(水) 19:06

グリフに登録されている「中国京语词典」(词典㗂京中国)のプレフィックスはどうやって判断するの?

最近、「中国京语词典」(词典㗂京中国)という辞書を購入したのですが、今まで何の接頭辞を使えばいいのか分からなかったのですが、他に良い意見はありますか?
--fitzgerald 2021年6月6日(日) 18:48
  • jingyucd(JINGYU CiDian)とか?お任せします。--kamichi 2021年6月9日(水) 09:02
    • え、後で考えて、プレフィックス「gintiengd」を使用することにしました(gin=京、tieng=㗂、d=dictionary=词典)。
      このプレフィックスを残しておいてください。将来的にはここにグリフを登録します。--fitzgerald 2021年6月9日(星期三) 11:01
    • 「残しておいて」というのは予約してほしいということでしょうか?それはできませんので、必要な時に必要な接頭辞を付けて作業する、バッティングしたら議論で調整し解決を図るという文化でお願いします。--kamichi 2021年6月9日(水) 19:06
    • tienggin(kinh?)がよさそうだと思います。--jjanggu2021.06.09 19:20
      • はっきり言ってないかもしれないと思います。
        でも、私は「tienggin(kinh)」という感じがしますちょっと長いように見えます。----fitzgerald 2021年6月9日(星期三) 21:53

「最近更新したページ」の仕様変更について

以前、最近更新したページのsandboxを標準で非表示にした際に合わせてやるつもりだった「ユーザー占有グリフ・ページ」の標準での非表示化を次の作業として考えています。やや影響がありそうなため、この場で賛否について確認しておきたいと思います。なお、最終的には実施しますので、反対の方はできれば妥協案のアイデア提示もお願いします。--kamichi 2021年5月27日(木) 14:46

  • 部分的にサポートされています,私は次のように改善することを提案します:指定ユーザーの名前を入力することで指定ユーザーの編集を隠すことができます。----fitzgerald 2021年5月27日(星期四) 15:22
  • ユーザー占有グリフ及びページのデフォルトでの非表示化に賛成いたします。--spinda-kkmr 2021年5月27日(木) 17:14

ご意見ありがとうございます。fitzgeraldさんのご提案「指定ユーザーの編集(だけを)を隠す」というのは、「指定ユーザーの編集だけを見る」であればすでに実装済みなのですが、それでは足りないということでしょうか。「あるユーザーの編集は参考にならないから見えなくても良いし、たくさん並んでいると嬉しくないが、別のあるユーザーの編集は参考になるから見えてほしい」ということでしょうか。

例えば(最近の更新ページのプログラムを書き直しになるので私のやる気が維持できるか微妙ですが)連続したユーザー占有グリフおよび占有ページの編集を1項目にまとめる(1項目の表示+「ほか何件」と表示)というのはいかがでしょうか。そこに「利用者:○○の履歴を見る」リンクを用意しておけば、気になったユーザーの編集について確認することができます。ちょっと複雑でしょうか?--kamichi 2021年6月2日(水) 08:41

  • え、現在のグリフウィキは (すべての) ユーザーの編集を非表示にできますが、特定のユーザーによる編集を非表示にすることはできません。 できれば「特定のユーザーに編集を隠す」という機能を付けたいのですが。
    例: ユーザー "abcd" (仮想) の編集を非表示にしたい場合、テキスト ボックスにユーザーの名前 "abcd" を入力するだけで済み、このユーザーの編集履歴は表示されません。
    添付: 「個人のグリフ (または記事) を非表示にする」を追加することもできます。
    この発言は理解できますか?
    --fitzgerald 2021年6月6日(日) 18:48
    • 文章を理解したと思います。私の疑問は、わざわざ特定の1名だけ表示しない意味(意図)がわからない、というものです。なお、特定の複数のユーザー占有グリフを表示しない、という機能は用意するつもりはありません。他の方で「特定の1名のみ表示しない」機能にニーズがあると思われたら賛意表明をお願いします。現時点では、他に意見が特に出ていないので、まずは「標準状態としてユーザー占有グリフ・ページを表示しない」こととし、「フラグを立てると、全ユーザー占有グリフ・ページも表示する」とし、「特定のユーザー1名について占有グリフ・ページを表示しない」機能を追加するかどうかは、もう少し議論が必要と思います。--kamichi 2021年6月9日(水) 09:02
      • そうですね、あなたの意見を尊重します。--fitzgerald 2021年6月9日(星期三) 11:01
  • 最近,ユーザー占有グリフおよびページが増えていて一般グリフの履歴確認が困難な場合があるので,ユーザー占有グリフ・ページのデフォルトでの非表示化を早期に実施する必要があると考えます。--spinda-kkmr 2021年7月16日(金) 17:30
  • 再度のお願いになりますが,最近,ユーザー占有グリフの増加のため一般グリフの履歴を追うことが困難になっています。ユーザー占有グリフ・ページのデフォルトでの非表示化を実施する必要があります。--spinda-kkmr 2021年7月22日(木) 12:50
    • 7月中の実施が目標です。すみません。--kamichi 2021年7月22日(木) 14:25
      • 更新しました。日本語以外のページの翻訳が日本語に戻ってしまっていますが、これから直します。--kamichi 2021年8月14日(土) 15:05

Vソースの命名について

現在のUnicodeのVソースのGlyphWikiに於ける命名は明らかに直感に反しており、また将来的に行われるVUソースとV-Fソースの統合や、WS2017とWS2021に存在するV0ソースに対応していません。そのため変更や新設が必要だと考えています。以下に現状の命名と私案を下の表にまとめました。

(注記:VUソースとV-Fソースの統合は将来的に行われることが決定しています)
Unicode Vソース現在の命名私案
V0-****(N/A)v0-****
V1-****(N/A)v1-****
V2-****(N/A)v2-****
V3-****(N/A)v3-****
V4-****v04-****v4-****
VU-*****vu-*****vn-*****
V-F****v-f****vn-f****

尚、意見のある場合は下に記述して下さい。なお、私はこの作業は手作業では行えず、botを使用する他ないと考えています。—kesuuko 2021年5月8日(土) 11:53

  • ご提案ありがとうございます。特に意見はありません。結論が出たら管理者側で処理したいと思います。--kamichi 2021年5月8日(土) 12:08

  • 今年の5月20日までに意見のない場合、私の案に基づく改名に反対意見のないものと見做します。また賛成意見が(私を除いて)3人以上から出た場合、繰り上げて改名を(kamichiさんに)依頼することとする場合があります。--kesuuko 17:25, 12 May 2021

  • 計數個の考えに同意します。--fitzgerald 2021年5月13日(星期四) 12:18
  • グループ:prefix-vを確認する限り,この改正案は適切と判断しました。kesuukoさんの提案に賛成いたします。--spinda-kkmr 2021年5月15日(土) 12:19

    • 5月20日までに反対意見がなかったため、命名を私の私案に合わせて変更することが決定しました。kamichi様はできれば今月中に既存グリフを移行してください。--kesuuko 20:23, 22 May 2021

  • 以下作業工程です。すみませんが現在週末しか作業できないので時期のお約束はできません。--kamichi 2021年5月23日(日) 12:04
    • 1)(完了)旧名に対して新名でエイリアスを貼る
    • 2)(完了)旧名が実体ありの場合、新旧のエイリアスを逆転する
    • 3)(完了)旧名は新名のエイリアスなので、すべて削除する
    • 4)齟齬がないか確認→皆様、ご協力をお願いします。

V4ソースの命名について

現在、UnicodeのV4ソースの命名は「v04-****」となっていますが、これをUnicodeやWS2017に合わせて「v4-****」に変更すべきだと思います。反対意見のある場合は真下に記述して下さい。なお、私は作業にはbotを使用する他ない(手動で行うにはグリフ数が多すぎる)と考えています。--kesuuko 00:40, 26 April 2021
  • この内容については「Vソースの命名について」に移動しました。—kesuuko 2021年5月8日(土) 11:53

変体仮名グリフについて

最近、インターネットで変体仮名の手書きや金属活字の資料(Twitterの変体仮名関連アカウントや変体仮名の資料データベースなど)を調べてみたところ、Unicodeの変体仮名の例示字形は癖が強かったり、もとの字と形が違ったりしていることがわかりました。変体仮名は日本の文字であり、Unicodeの例示字形より、民間の変体仮名に基づいて、グリフウィキ内の一般仮名のデザインを踏まえて新しく作字することを提議します。 それでは今後のグリフウィキ内の変体仮名グリフについてみなさんから意見を聞かせていただきたいと思います。
    • 1)varグリフかitaijiグリフとして登録
    • 2)今までのグリフウィキのものを置き換える
    • 3)反対
  • jjanggu2021.3.19(金) 11:23

  • 現状のグリフはUnicode(ISO/IEC 10646)の例示グリフですので、2)はないと思います。できれば1つグループページを作って、例示グリフと提案グリフの対比ができれば、判断できる人にとって有益な情報提供と思います。その結果、規格(標準)側で修正・変更があれば、大変意義のあることだと思います。1)についても、var(itaiji)ではなくて、仮のprefixを用意すると混乱が少ないと思います--kamichi 2021年3月19日(金) 12:32

  • >>わかりました。このままユーザー専用グリフとして作字していきます。なお、prefix字形を検討するほか、自分が例示字形と区別するよう変更した字形はリバートします。ご迷惑をおかけいたしました。--jjanggu2021.3.19(金) 12:47

  • Twitterの例のアカウントの「癖」という判断の根拠は現時点では不明。「日本国の政府の指導の下で文字を国際規格として登録する」に要する資格は「TwitterのBOTの運営」に要する資格とは段違いである。sz 2021年3月19日(金) 15:25

  • 私の意見は「弱い(3)」です。
  • Unicodeの変体仮名字形は,日本の文字規格を参照しているはずなので,ある程度の信頼性があると考えます。とりあえずはUnicode規格票に従っておくのが良いと考えます。
  • なお,私は非漢字グリフ作成があまり得意ではなく,変体仮名にも詳しくないので,詳しい方に比較用のグループページを作っていただけると大変有り難く思います。
  • 以上,--spinda-kkmr 2021年3月19日(金) 17:45

    • すいませんが、主張を180度変えました。改めてIPAグリフとUnicode規格票を確認したところ、IPAの方の変体仮名グリフはデザイン上グリフウィキの一般仮名、または花園明朝と共通点が多くみられたので、一般仮名のデザインを踏まえてUnicode規格に従うのがいいと思います。また、私のユーザー専用グループは「自分好みにデザインしたもの」とし、原則上グリフウィキ内の変体仮名グリフと区別していきます。--jjanggu 2021年3月20日(土) 14:19

新しいプレフィックスを追加したい

最近、「布依方块古文字」という新しい本を購入しました(文字通りの意味は:ブイ族の表意文字)。調べてみると、この本に含まれている文字の多くはグリフウィキに含まれておらず。したがって、新しいプレフィックスを追加することを提案します。 予備的な考え方は次のとおりです。
  • bouyei-xxxyy

その中で、「xxx」はページ番号を意味し、「yy」は文字が左から右、上から下の順序であることを意味します。

例:「bouyei-04708」は、その文字が47ページの8番目にあることを意味します。

おそらくそれだけです。

このリクエストはどうですか?--fitzgerald 2021年3月12日(星期五) 16:00

  • prefixの新設については、現状に悪影響があったり、混乱を招くようなことがない限り自由ですので、早速prefixページを作って、グリフ登録を始められると、みなさんの理解が進むと思います。よろしくお願いします。--kamichi 2021年3月19日(金) 12:34

KAGE-EDITORはスマートフォンに適応する予定はありますか?

それはほとんど不可能だと思いますが。

しかし、それが本当にスマートフォンに適応している場合、Glyphwikiのオーディエンスはより広くなり、Glyphwikiを使用するためのしきい値も低くなります。

PS: 少し前に、KAGE-EDITORの2つの無害なバグを見つけました。これらは、必要に応じて修正できます。

  • 文字検索を実行した後、[削除]ボタンが失敗することがあります。
  • ストロークの開始または終了の形状を変更した後、[削除]ボタンが失敗することがあります。
  • チェックしてください。

fitzgerald 2021年3月9日(火) 17:20

  • kage-editor の作者としてコメントします。
    • 現時点ではスマートフォンでの操作に対応する予定はありません。
    • 「[削除]ボタンが失敗する」は「キーボードのDeleteキーを押しても選択した筆画・部品が削除できない」ことを指していると思って良いでしょうか? フォーカスが検索欄のテキストボックスや形状選択のドロップダウンリストなどに当たっている時はキーボード操作が効きません。ので、一旦何もないところをクリックするなどしてフォーカスを外してからDeleteキーを押すか、代わりに画面下部の「切り取り」ボタンを使ってください。
  • 以上は twe 2021年3月10日(水) 19:39

拡张Hいくつかの質問。

少し前に、Unicodeにはすでに拡张H領域の収集データがあることがわかりました。今すぐアクションを実行する必要がありますか?--fitzgerald 2021年3月3日(水) 15:26

中国大陸からアクセスしている皆さんへ(お尋ね)

グリフウィキは、将来的に強制HTTPSへのリダイレクトを行う「常時SSL化」に移行します。現在は試行として無印(glyphwiki.org)のみ常時SSL化を実施していますが、これから{ko,en,zht}.glyphwiki.orgについても移行します。

ところでなぜzhs.glyphwiki.orgは移行しないのかというと、TLS 1.3暗号化通信が中国大陸ではブロックされると聞いているためです。ところがTLS 1.3に対応しているサイトはかなり増えています。どうして問題にならないのか(少なくとも私の周りでは困っているという話を聞いたことがありません)、不思議です。

そこで中国大陸に住んでいる皆さんに教えてほしいのですが、https://glyphwiki.org/ へのアクセスが可能かどうか、試してくれませんか。問題が無いようであれば、zhs.glyphwiki.orgも常時SSL化に移行したいと思います。特に情報がない場合は問題ないとみなすことにします。

GlyphWiki将来会迁移到“始终为SSL”,它将重定向到强制HTTPS。但是,我听说TLS 1.3加密的通信在中国大陆被阻止。因此,我想告诉居住在中国大陆的每个人,请尝试访问https://glyphwiki.org/并在下面举报。如果没有特定信息,我们将始终认为SSL并不是问题。

以上の書き込みは kamichi 2021年1月30日(土) 23:05 による

(以下は、もともとの書き込み「無印(glyphwiki.org)の先行「常時SSL化」試行について」「お知らせ」より移動)

現在、glyphwiki.orgについて、HTTPによる通信を強制的にHTTPSにリダイレクトする「常時SSL化」を試行中です。不具合等ある方はGlyphWiki:井戸端にご報告をお願いいたします。問題がなければ正式に移行します。

特に中国(大陸)はSSL化によるアクセスブロックが発生すると思われるので、zhs.glyphwiki.orgについては今後もHTTP/HTTPSをそのまま通します。{ko,en,zht}.glyphwiki.orgについてはリクエストがあれば常時SSL化に移行しますが、当面様子見とします。

rss.xmlについて、RSS内のURL記述がすべて無印(glyphwiki.org)になっているため、必然的にHTTPSにリダイレクトされます。中国大陸のユーザーにとって不便になる可能性がありますが、ニーズがどれほどあるかが不明なため、当面そのままとします。

また、事情によりHTTP通信が必要な場合に、non-ssl.glyphwiki.orgを用意しました。日本語版です。

  • 自亐大陸 用爲電信 據說TLS1.3 除去ESNI 則當無礙 已試 ESNIのないTLS1.3であれば アクセスは可能だと言われています 直接なアクセスは未だ問題ありません 大陸電信ユーザーより hupo 2021年2月9日(火) 14:40 公布
    • hupoさん、情報提供をありがとうございます。問題なさそうということで、全ドメインについて常時SSL化に移行する方向で考えます。--kamichi 2021年2月15日(月) 09:11

U+82B2の字形変更からの議論

kesuukoさんが、U+30C28と区別するために、u82b2@8の字形を、u82b2@9の字形に変更しました。でも、Unicodeの中で、そんな「半重複」の漢字は多くあります。「半重複」っては、ひとつのコードポイントで一部のソースの字形がもうひとつのコードポイントのすべての字形と重複することと指します。U+82B2のJソースとU+30C28のすべてのソースはその一例です。でも、三年半前には、わたしはU+2ACDDと区別するために、u69f1@7の字形を、u69f1@8の字形に変更しましたけど、tweさんがu69f1@9にリバートしました。原因と言えば、「uXXXXのグリフは、日本ソースがあれば日本ソースの字形を優先することになっています」としました。それは今kesuukoさんの編集と矛盾になっていますから議論が必要だと思っています。私の整理によって、Unicodeに既存する「半重複」の漢字は以下の通りの40対(79字)があります(月肉舟に関するものを除く)。

コードソースコード
5668J20F96
56CDK21155
58C4J21428
5C6EJ4DB9
5DFDJ22049
69E9GH3BA3
69F1JK2ACDD
6B04J237EC
7361TK2486F
7422J24968
7468G24A01
7589J24D01
7714J25133
7A3DK25874
7A81J2592E
7AB4K259D1
7BF9J25CBB
7C06HJK25C83
8158T266E2
81EDJ26900
8200J2695D
82B2J30C28
8412T26CC6
8481J26CEF
8641J21582
K27144
8B39J27AF4
9038J284DC
9686J28E93
9819J29460
985EJ29516
34A8G20457
3778J21B6A
418BK9F9D
43DEGJ2669C
4620T889A
48B4G9097
4C17J29C18
23CEBT23D6D
246C9G821D

また、月肉舟に関する「半重複」の漢字は、80A6 80D0 80CA 8101 8127 81A7 4443 268AB 80F6 266E9 4420 80AD 43D9 440B 6721 2667F 813C 26772 26808 26805、20対あります。(上に挙げたコードポイントは肉部、順序は対応する月/舟部の漢字のブロックまたはコードポイントによる)

どう処理すればいいでしょう?--sim-ch 令和3年1月13日(水) 午前1:48(GMT+9:00)

  • 基本的な考え方は、利用者にメリットがある方法にすべきであると思います。字形が重複・半重複している2つ以上のコードポイントがある場合に、(グリフウィキの基本としている)Jの規格で最も優先するコードポイントの字形を最優先に決め、それ以外のコードポイントは、その最優先の字形と区別ができることが利用者にとってのメリットだと私は考えます。ですので、このルールが、本来のルールの上位に来るとすれば解決するのかと思います。もしかしたら論点がずれているかもしれません。他の方のコメントを待ちます。--kamichi 2021年1月13日(水) 09:51

    • でも、kamichiさんの観点によっては、U+82B2はJソースがあるので原則としてJソースの字形が優先ですが… --sim-ch 令和3年1月13日(水) 午後1:32(GMT+9:00)
      • あれ、失礼しました。確かにkesuukoさんの変更は矛盾しますね。私の意見では、u82b2は戻すべきと思います。ただu30c28側をどうするか…あえてu82b2-gにすることを提案します。--kamichi 2021年1月13日(水) 17:27
      • u82b2は花の異体字、u30c28は菕の類推簡化字という解釈ですか…。そうするとu82b2-gは不適切ですね。--kamichi 2021年1月13日(水) 17:33

    • JIS X 0213に存在する漢字(u5668u5dfdなど)は無条件でその字形にすべきだと思います。JIS X 0213になく、JIS X 0212にのみ存在する字は個別検討しても良いでしょう。--kesuuko 2021年1月13日(水) 18:11
      • あれ、kesuukoさん、本件は0213にあるものをkesuukoさんがJ字形からG字形に変更した、という認識です。では、U+82B2をJ字形に戻す部分はOKですね。--kamichi 2021年1月13日(水) 20:06
      • とりあえず全てケースバイケースとするべきだと思います。ただ、常用漢字や人名用漢字、JIS X 0213の互換漢字(u5c6eufa3cとか)あたりは無条件でJ字形にして問題無さそうです。--kesuuko 2021年1月13日(水) 20:40

花園明朝を新しいバージョンにアップグレードしていただきたいです。

忙しいであろう鯖管さんにはいつもお世話になっております。前にも同じようなことを言った記憶があって重ね重ね失礼いたしますが、最近いくつか台語の字が追加された影響で一部表示できない文字があって困っている人がいるようです。(例:https://kian-tiong.medium.com/台語文字的字型發展現況-下-2574f0961a85 ) そこで、花園明朝の新しいバージョンにアップグレードしていただきたいです。 —yoshiciv 2021年1月7日(木) 01:20
  • ご意見ありがとうございます。更新の作業を近々再開したいと思っています。方針を大きく変える可能性がありますが、3月までには公開予定です。--kamichi 2021年1月7日(木) 08:49
  • TH-Fonts を使ってもよろしいでしょうか。すべてのUnicode漢字が支援できます。花園明朝風のブランチフォントTH-Mingもあります。またTH-TshynではUnicode13.0のすべての文字が支援できます。ご覧くださいね。--sim-ch 令和3年1月7日 午後3:18(GMT+9:00)
    • 管理人のkamichi様の言う方針転換とはグループ-ノート:花園フォントにて議論された「古代文字(西夏文字・契丹文字等)の分離」と認識してよいのでしょうか。--spinda-kkmr 2021年1月9日(土) 15:33
      • まだ悩んでいますが、もっと根本的に、①ASCIIや基本集合以外の非漢字を捨て、漢字(系)のみに限定し、細かい作業を省く(議論では漢字のみを別フォント名でフォークすると書きましたが、逆に花園は漢字のみにする)②何も考えずにUCSコードポイントとしてGlyphWikiに登録されているものはすべて拾う、のいずれかを考えています。--kamichi 2021年1月9日(土) 15:50
    • 個人的意見としては②が良いと思います。花園明朝Aの大幅なグレードダウン(IVS使用不可や第0面の記号の割愛など)は,GlyphWikiを知らない花園明朝Aのみの利用者には混乱の元となるので避けるほうが良いと考えます。なお,私が先述した「古代文字の割愛」は大きなグレードダウンにはならないと思われます。
    • 個人的には花園明朝Aで現状使える「IVS」「第0面の記号」「第1面の英数字と絵文字」は今後も花園明朝Aでサポートした方が混乱が少なくなって好ましいと考えます。
    • 以上,--spinda-kkmr 2021年1月10日(日) 11:55
    • なお「第1面の英数字」とはグループ:CodeChart-MathematicalAlphanumericSymbols等のことを意味します。--spinda-kkmr 2021年1月10日(日) 13:02

編集操作ができません

タイトルにあるように、直接編集はできませんが、VPNを使用して編集することはできます。

私が妨害工作員として禁止されたかどうか尋ねてもいいですか?私は絶対に妨害工作員ではないことを保証できます。

(PS:上記のコンテンツは、VPNを使用してのみ送信できます。)--fitzgerald 2021年1月6日(水) 17:32

    • 上地さんでは先日、「それで理由は簡単で、SPAM対策に引っかかっています。この2か月ほど、中国本土IPアドレスからのSPAMがひどいため、かなり広範囲のIPアドレスをブロックしています。解除はできないので、近日中に対応策を用意します。ちょっとお待ちください。」と述べたことがあります。ご了承ください。--sim-ch 令和3年1月6日(水) 午後6:24(GMT+9:00)

      • このような状況が長続きしないことを願っています。結局のところ、このような状況ではあまりにも厄介です。--fitzgerald 2021年1月6日(水) 19:49

      • ネットワークを切換えてみればこの状況はよくなりましょうか。いま使っているアカウントといってはキャンパスネットワークを接続するとき編集ができないがスマホのホットスポットを接続するとき編集ができるようになります。--sim-ch 令和3年1月6日(水) 午後8:8(GMT+9:00)

      • 条件が限られているので試しませんでした。--fitzgerald 2021年1月6日(水) 20:31

  • ご迷惑をおかけしております。事象はsim-chさんが説明してくださった通りです。それで根本的な対策をする余裕が今ないので、fitzgeraldさんについては手動対応いたしました。しばらくは個別対応としますので、投稿に問題がある場合は、お手数をおかけしますが、管理者まで直接ご連絡ください。--kamichi 2021年1月7日(木) 08:49

    • ここであなたにとても感謝していますが、それでも直接編集することはできません。--fitzgerald 2021年1月7日(星期四) 20:21
      • あれ、まだダメでしょうか?ダメな場合、投稿時間を管理者(kamichi )までお知らせください。--kamichi 2021年1月13日(水) 09:54
      • そんな感じです。
        ご覧のとおり、現在のすべての編集はまだVPNの助けを必要としています。
        1月6日にこの質問をしたときから今まで、私の編集はすべてVPNの助けを借りて行われてきました。--fitzgerald 2021年1月13日(星期三) 21:33
    • うまくいかないケースのチェックができないと修正できないので、VPNを使わずに投稿して、その日時をメールしていただけないでしょうか。--kamichi 2021年1月14日(木) 09:33
      • いいえ、プロンプトは表示されず、何も起こりません。--fitzgerald 2021年1月14日(星期四) 15:27
      • 私はあなたにメールを送ろうとしました、チェックしてください。--fitzgerald 2021年1月14日(星期四) 15:36

ドメイン名にhttpsを使用することに関する質問

私の知る限り、glyphwikiは日本語版のインターフェースでhttpsドメイン名のみを使用しますが、他の言語のページについてはどのような決定を下しますか?--fitzgerald 2020年11月23日(月) 00:28
  • 特に要望等出てこないので決定の優先度を下げていますが、次の段階としては{ko, zht, en}をHTTPSに移行予定です。ほかに希望があれば意思表明をお願いします。--kamichi 2020年11月24日(火) 08:03

新しいグリフの作成の下に「KAGE-Editor」ボタンを追加する必要があります

私の知る限り、多くのブラウザでflashが徐々に無効になり始めています。これを行わない場合、存在しないグリフを作成する場合は、glyphEditorで一度保存する必要があります。--fitzgerald 2020年11月23日(月) 00:25
  • ありがとうございます。この件について、すでに別の方からもご指摘いただいていたのですが、対応を忘れていました。今「入れ替え」しました。特に問題がない限りSWF(Flash版)はこのまま廃止とします。--kamichi 2020年11月24日(火) 07:59

var・itaijiの「空き番」の処理について

  • var・itaijiの番号について,「白紙化により発生した欠番」については廃止して再利用してはいけないというルールが存在しますが(GlyphWiki:グリフを登録する参照),「過去に一度も登録されていないのに,より大きい番号のvarが先に登録されてしまって空番になってしまった場合」はどのように処理すべきでしょうか。
  • 例としてはu79bb-02-var-002が過去に一度も登録されていないのにu79bb-02-var-003u79bb-02-var-004が登録されてしまっています(ノート:u79bb-02-var-003も参照)。
  • このような例を白紙化欠番と区別して「空き番」と呼ぶことにした場合,空き番に気づいた場合は埋めるように登録すべきでしょうか(この例ではu79bb-02-var-002を先に登録し,更に必要な場合は既に埋まっている003と004は飛ばしてu79bb-02-var-005を登録する)。
  • 私の意見は「白紙化欠番は同名のグリフが異なる字形で存在することを防ぐルールなので,過去に未使用の空き番は埋めても良い」です。
  • 以上,--spinda-kkmr 2020年11月21日(土) 12:22
    • spinda-kkmrさんの意見に賛成です。もし空き番を埋めてはならないとすると、「u8273-var-101が存在するためu8273-var-002からu8273-var-100は欠番(u8273-var-001は登録済み)」「u27725-itaiji-101が存在するため、u27725-itaiji-001からu27725-itaiji-100は欠番」など、明らかに合理性を欠くほど大きな番号での命名を余儀なくされるパターンが発生するためです。--kesuuko 2020年11月21日(土) 17:06
    • 賛成です。―twe 2020年11月22日(日) 11:41
    • 賛成です。私も空き番は使えるという認識です。もう少し厳密にいうと番号の大小に意味を持たせないというポリシーです。--kamichi 2020年11月22日(日) 14:53
      • では「空き番」については使用可能という方針が決まったと確認いたします。--spinda-kkmr 2020年11月22日(日) 18:09

T用折れの追加について

    • u5340-tの履歴では、Tソースの標準字形(細明體)を再現しようとしたバージョンがボツになっていたのですが、Tソースのために、u5340-t@2のような折れをエディタに追加することができますでしょうか?--jjanggu2020/10/23 17:20
  • そもそものKAGEエンジンの目的が、デザインを抽象化して座標の集合だけで漢字字形を記述するものなので、今回の場合はエディタではなくてKAGEエンジンへの機能追加が本来の筋なのですが、その形状はあくまでもデザインであって字体ではないと思っていて、優先順位としては低いものとした結果、エンジンに追加されていない、ということになります。また漢字グリフをbopomofoや「かな」のように重ね合わせで登録することは機械可読性に問題がありデータの再利用が難しくなるので禁止と考えます。以上によって八方ふさがりになっていると認識しています。--kamichi 2020年10月23日(金) 18:09

    • u5e7a-gみたいに複曲線で曲線をもっと中国風らしくするのはどうでしょうか。
      私の意見は、点と点が繋がっていないため(sandbox@10711)、そして、「抽象化」ではなくデザインの領域であるため、同じく反対。--sz 2020年11月21日(土) 02:35

    • 部品をそれほど伸ばすことはめったにないので、個人的に問題ないと思ってるんですが...-jjanggu

今までのサンドボックスについて

  • 今までのサンドボックスなんですが、スパム投稿の量に開いた口が塞がりませんでした。サイバー攻撃である可能性が高いと自分は思っています。自分もかなりの連続投稿をしたことがあるから何とも言えませんが、今回の件はかなりひどいので対応をしていただければと思いますが。。。ところで、感情制御ができなくてまた下品な言葉を使ってしまって本当に申し訳ございません。--jjanggu
  • あえて逆向きの対応ですが、最近更新したページからsandboxを隠してみました。実際には自動更新やボット登録の方が頻度は上なので、システムへの影響はあまり問題視していません。ところで、SPAM的な投稿と以前認定しましたので情報を公開しますが、最近ウンか月のこの大量のsandbox投稿は中国大陸管理のIPアドレスからのものです。また、この1か月以内に急に増えた別のsandbox投稿は、乗っ取られているとか、open proxyが立っているとは考えにくい米国大手企業の管理IPアドレスです。とりあえずこれ以上の反応はしないこととします。--kamichi 2020年10月19日(月) 17:14
    • おちついたら、自分以外の占有ユーザーグリフについても最近の更新から隠す予定です--kamichi 2020年10月19日(月) 17:15
    • 過去に提案した、匿名利用者からのsandboxへの1日の投稿数に限度を設ける件は先行して実装します。--kamichi 2020年10月19日(月) 18:01

最近の投稿について(長文。方針の変更について提議します)

  • 書くべきか非常に悩んだのですが、最近のグリフウィキの投稿は「(私の主観でいう)学術的な利用」と「表現としての利用」に極端に2分されていると感じます。昔、香港・ベトナムでグリフウィキの発表をしたときに中国圏の方からいただいたコメントとして「何のためにあるのか」という意見が多く、私なりの意義を説明したところ「たぶん創作字にしか使われないだろう」と言われて、意外に思ったのですが、その指摘は正しかったのかもしれません。「表現としての利用」は目的外利用であると思っています。ただ、その文字が定着したり、あるいは時間がたった時に社会性を持ったものとして資料的な価値を見出す可能性があるとしてあえて許容してきたのですが、そろそろ判断を切り替えるときかなと思っています。私としてはグリフウィキが広く発展することよりも、学術的価値を見出してもらうニッチなニーズを重視しています。この方針の変更についてご意見ありましたらお願いします。なお、繰り返しますが根底にあるのは「学術としての価値を追求する」です。具体的には創作漢字を受け付けず、表現の場とすることを否定します。グリフウィキに登録できるのは引用できるグリフ(どこかに掲載されたもの、Webを含む)のみとすることを考えています。またsandboxは「登録の練習」の場とし、(残念ですが)時候の挨拶も含めた表現、交流の場としては認めない方針です。グリフウィキの当初の目的として「交流」もある程度期待することはあったのですが、断念することにします。ただ、おそらくですが、日本の漢字文化と中国の漢字文化はやはり違い、文字を表現手段として活用する、という側面は日本ではあまり見られない(せいぜいCMやデザイン)ので非常に興味深いです。これを否定するつもりはありません。ただグリフウィキをその場とすることは受け入れられないと思っています。--kamichi 2020年10月8日(木) 11:18
    • 大変難しい問題だと考えます。(私自身の感覚では)グリフウィキが学術目的のデータベースであることは登録利用者の間では合意ができていると考えています。しかし,優れた漢字デザインエンジンを用いて明朝体の創作漢字を作ってみたいという人も一定数いると考えます。
    • そこで,
      • (責任を明確にするため)登録利用者に限る
      • 著作権を主張できなくなる(グリフウィキの方針に基づく)
      • ユーザー占有グリフにて登録する
    • という制限を理解してもらった上で,学術目的の妨害をしない範囲で許可するという方針にするのはどうでしょうか。具体的制限についてですが,1人につき「1日1個まで」かつ「30日間に10個まで」程度が適切だと考えます。制限回避目的の複数アカウント取得はスパムと見做すものとします。
    • ここでいう創作漢字とは,利用者自身が思いついた創作漢字に限り,ネット上や街中・書籍上に存在するもの(利用者以外が考えたもの)は含まないものとします。また,書き間違いや作字ミスによる異体字も含まないものとします。これらはデータベースとして収集する価値のあるものと考えられるためです。但し出典は必須とします。
    • なお,交流の場としての利用を禁止することについては賛成いたします。漢字や文字コードに関わる人同士の交流であっても,Twitterなどの然るべき交流の場がある以上,わざわざデータベースを交流の場にする必要は無いと考えるためです。
    • 以上,--spinda-kkmr 2020年10月8日(木) 17:46
    • 追記。別件になるかも知れませんが,sandboxに投稿練習目的で投稿する場合であっても,匿名利用者の投稿回数には制限をかける方が良いと思います。大量の投稿履歴のせいで他の履歴が見づらくなるためです。--spinda-kkmr 2020年10月8日(木) 17:51
    • 私自身の意見では、Glyphwikiで編集する場合は、アカウントを登録する必要があります。そうしないと、sandboxも例外ではなく、編集できなくなります。これにより、これを効果的に防ぐことができるようです。
      なお、中国大陸のユーザーはtwitterを使えません。--fitzgerald 2020年10月10日(星期六) 00:09

  • グリフウィキ13周年の直前にサービス不能となってしまい、若干ショックだったのですが、少し考えてみました。それで前々からも申し上げていますが、表面に見えていない迷惑投稿も踏まえると、やはり匿名ユーザーを排除するのは難しいです(迷惑投稿者が登録ユーザーに移ると面倒なので)。そこで一つ再提案ですが、sandboxの投稿を1IPアドレスおよび1ユーザーごとに一日10グリフまで、とすると、意外と解決するのではないかと思ったのですがいかがでしょうか。もう少し減らしてもいいですが、まずは10個で。--kamichi 2020年10月15日(木) 11:29
  • Fizgeraldさんの意見を支持します。なお、編集回数制限については、10回以上編集したい場合、ユーザーから管理人に自ら申し出て許可を求めることがよさそうだと思います。なぜかというと、私も特定目的で10回以上編集したことがあったからです。(sandbox@8164sandbox@8182jjanggu 2020.10.15
    • あなたは私の名前を間違って入力したようです。--fitzgerald 2020年10月15日(星期四) 23:50

  • すみません、意見を180度変えました(この表現は日本語以外でも通用するでしょうか?)。まず、プログラムを確認したところ、バージョンが5桁になっても問題は起きないことがわかりました。1か所桁あふれの制限があるところがあるのですが、現時点ですでに5桁まで対応する設定になっていました。全く勘違いしていました。それから、最近更新したページ(Special:RecentChanges)からsandboxを外す(自動投稿などと同じようにフラグでON/OFFを切り替える)だけでよく、練習用ページに制限を課す必要はないのではないかと思うに至りました。いかがでしょうか?--kamichi 2020年10月15日(木) 19:32

  • 創作漢字の制限について議論が止まってしまっていますが,
    • 責任を明確にするため登録利用者に限る
    • 著作権を主張できなくなる
    • ユーザー占有グリフにて登録する
  • の3つに加えて
    • 自作の創作漢字であることをメタ情報に明記する
  • という制限を付けて,取り敢えずは「学術目的を妨害しない範囲」という緩めの規制をかけることにし,より明確な規制が必要になったらその時に定める,という事でどうでしょうか。なお,制限対象は利用者が思いついた創作漢字に限り,ネット上や書籍上にある,ユーザー考案でない創作漢字は制限対象外とします。
  • 以上,--spinda-kkmr 2021年3月3日(水) 17:28
  • 上記の補足説明です。「緩めの規制」とは特に具体的なグリフ数制限等をかけないという意味です。仮に一般の方々(漢字や文字コードに関する深い知識の無い人)にグリフウィキが爆発的に知れ渡って創作漢字グリフで溢れかえるようになったら具体的なグリフ数制限が必要になるでしょうが,現状ではそのような心配は無いだろうという意味です。--spinda-kkmr 2021年3月16日(火) 23:22
    • もう1つ補足です。(私の提案で)制限対象外のネット上・書籍上・街中等の「ユーザー考案ではない創作漢字」については,
      • 命名は“sosaku-#####…”(後ろはヘボン式ローマ字)とする
      • メタ情報に出典とIDSを明記する。出典がウェブ上の場合はInternetArchiveやウェブ魚拓を取得して,出典が失われないようにする
    • この2つをルールとして提案いたします。なお,過去に“sousaku-#####…”で命名されているグリフは遡って修正はしませんが,今後新たに作成された場合は命名ルール違反として“sosaku-#####…”に移動するものとします。
    • 以上,--spinda-kkmr 2021年3月24日(水) 17:37
    • 中国(香港、台湾などを含む)ソースの創作漢字の命名は拼音でよろしいでしょうか?--jjanggu2021.3.24(水) 17:45
    • それで良いと考えます。要は「その言語をラテン文字で表記する場合のルール」です。日本語はローマ字のルールが複数あるのでヘボン式と指定しました。なお,英語等の外来語を含む場合は元の綴り優先が妥当と考えます。--spinda-kkmr 2021年3月24日(水) 17:50
  • ユーザー考案の自作の創作漢字の命名について,1つ提案いたします。GlyphWiki側が機械的に創作漢字であることが分かるように,“ユーザー名_sosaku-#####…”での命名をルールとするのはどうでしょうか(ユーザー占有グリフであることには変わりません)。既存不適格命名はユーザーの責任で移行することとします。--spinda-kkmr 2021年3月26日(金) 17:03

  • 提案が錯綜してきたので表形式でまとめます。現時点ではあくまでも私の提案です
ユーザー考案の創作漢字ユーザー考案ではない創作漢字
命名ユーザー名_sosaku-#####…
ユーザー名_#####…
sosaku-#####…
グリフ数制限当面は具体的には定めない
学術目的を妨害しない範囲
出典がある限りは制限無し
その他のルール登録利用者に限る
著作権を主張できなくなる
自作の創作漢字であることをメタ情報に明記する
メタ情報に出典とIDSを明記する
出典がウェブ上の場合はArchiveを取得する
  • いずれの場合も命名の後ろ部分は日本語はヘボン式ローマ字,中国語は拼音とする。英語等の外来語は元の綴りを優先する。また,IDSも許容する(混用は不可)。
  • 以上,--spinda-kkmr 2021年3月26日(金) 17:36

  • spinda-kkmrさん、まとめてくださってありがとうございます。基本的に全賛成です。少しコメントすると、若干ルールが複雑かなという気はします。それとユーザー占有グリフにもsosakuを強制することについて、実質的にルール違反への対応はできないので、状況が改善しなければアカウントBANで対応することになるのかと思います。--kamichi 2021年3月26日(金) 23:58
    • では,ユーザー考案の創作漢字については命名は各自の管理に任せるということでどうでしょうか。メタ情報への創作漢字である旨の表示は,ライトユーザーや検索で偶々GlyphWikiに巡りついた人が実在漢字と誤認しないように必要であると考えます。--spinda-kkmr 2021年3月27日(土) 12:41
    • ユーザー占有グリフは当該ユーザーが覚えやすいことを前提としているので、ユーザー占有グリフで作字する場合、センシティブな字句が使用されていない限り、それぞれ自分の命名ルールと表記に従っていいと思います。--jjanggu 2021年3月27日(土) 13:04

sandboxについて

  • グリフのバージョンですが、設計時に4桁までしか想定しなかったので、10000を超えるとどうなるか不明です。現在sandboxだけが頻繁に更新され、バージョン7000を超えました。これだけのためにシステムをいじるのは面倒なので、9000に到達したあたりで、sandboxのみ保護ページに切り替え、sandbox2を代わりに使うこととします。--kamichi 2020年9月24日(木) 19:02

sandboxのエイリアス指定の禁止について

  • つい最近まで、既存のグリフをそのまま編集せずサンドボックスに入れてそのエイリアスにするような投稿が数回あったのですが、そうするとサンドボックスの意味がないので、こういう行為を禁止することができますでしょうか? --jjanggu

  • エイリアスの意味の確認という意味では、禁止まではできないかと思います。数量の制限で解決できると考えています。--kamichi 2020年10月15日(木) 11:24

ハングル集合について

  • sim-chさんが、今度は明朝体相当のハングルグリフセットを作成してくださいました。必要ならデータを提供してくださるとのことで、kesuukoさんなどの意見が欲しいとのことでした。例えば、以下の対応が考えられます。
    • A)今のハングルセットを置き換える
    • B)別名で明朝ハングルセットを置く。花園明朝に(そもそも外す可能性も考えていますが)どちらを入れるかは別議論とする
    • C)既存のハングルグリフセットで満足しているので不要
    • D)その他
  • 皆様のご意見をお願いします。--kamichi 2020年9月13日(日) 22:48
    • 私はB案に賛成し、グリフ名は「uXXXX-var-XXX」とすべきだと思います。--kesuuko 2020年9月13日(日) 23:11

    • C。完全に明朝体(漢字風)のハングルはほとんどの場合でデザインフォントとして認識されており、一般的な場合でのハングルの表示には適さないので、現在のハングルで十分です。--jjanggu 2020.9.13
    • C。jjangguさんのおっしゃる通りと思います。sz 2020年9月18日(金) 10:47
      • 又、伝統と離れた妙な字形が多くあり(𠤎=ㄷ、⿱一八=ㅠ等)、普段用の書体(display font に非ざる物)として扱うのには同意できません。sz 2020年9月18日(金) 13:03
      • 匕はㄷじゃないですよ。ㄷは「匸」です。「匕」は「訓民正音圖解」に現れる혓바닥소리すなわち[ʈ]のような音です。まだUnicodeに含んでいないハングルです。--sim-ch 단기4353년9월19일(토) 오후12:00
      • WindowsのGulimというハングルフォントではㅠは左の丨が丿になりました。今のところ筆劃避讓のため、對稱性を考えて一部のㅠの右の丨を丶になるのはどうして妙でしょう?--sim-ch 단기4353년9월19일(토) 오후12:08
    • でも、北朝鮮の「광명체」(光明体)は多くの場合で使用していますけど…Soonwha(すなわち最近わたしが新しく作ったその明朝体のハングルフォント)は光明体と似ていますが…--sim-ch 단기4353년9월18일(금) 오전11:01
    • また、韓国もそんな風のフォントがあります。HanYangがデサインした「순명조」というフォントです。--sim-ch 단기4353년9월18일(금) 오전11:07
    • Bが好ましいと考えます。花園明朝には既存のハングル文字セットを入れ,明朝ハングルセットはグリフウィキ登録漢字のうちハングル文字圏の主要文字コードの漢字を収録したものとし,韓国語に詳しい人向けのフォントにしてはどうでしょうか(UROに限っては完全収録とし「仮想K字形」の文字も入れる)。名称については別途議論すればよいと思います。--spinda-kkmr 2020年9月19日(土) 21:07
  • まず、sim-chさんにお願いです。署名の年表記は西暦にしてください。各文化圏で自前の年表記を使われると混乱します。いろいろあって楽しいですが。さて、Cの意見も多いですが、Bの意見もありますので、Bでいかがでしょうか。ただ、「-var-」だと後ろの番号が統一できない可能性があること、仮に「-var-001」で統一できたとしても、従来のUCSの「var」の数字の非関連性を考えると混乱しそうなことを踏まえ、「接頭辞」を1つ作って「****-uHHHH」とするのはいかがでしょうか。「****」をどうするかについてはsim-chさん、アイデアをください。--kamichi 2020年9月19日(土) 13:04
    • 「****」を「soon」になるのはどうでしょう?SoonwhaとSoonbonの「soon」(순)です。ところで、一部の部品を組合せたら筆画は細かくなりました。例えばsimch-hangul_u116e-3simch-hangul_u11c0-1を。そんなものは不自然だと思っていますけど…どうやって解決できるかをお教えください、そのうえで字形データを用意してあなたに送ってあげます。--sim-ch 2020/09/19 午後02:49
    • 回復お願いいたしますけど… --sim-ch 2020/09/27 午後10:40
  • 仕事が通常期に入ってしまったので、反応が悪くてすみません。それで、筆画が細くなるのは自動調整機能によるものなのですが、具体的に細くなってしまう例を出していただけないでしょうか。それで、KAGEデータを手で書いて自分で細くすることはできるのですが、細くしない(自動調整させない)ことはできなかったと思います。ですので、解決は難しいかもしれません。--kamichi 2020年9月29日(火) 15:32

IVDグリフにおけるエイリアス・被エイリアスの優先について

  • IVDとAJ1文字集合、戸籍統一文字などの関係において、どちらが主(実体グリフ)となるべきでしょうか。過去に言及された方はいますか?一見後者の方が字形の安定性がありますが、IVDは理論的には全く同じ字形になるので、前者を主としても構わないと思いますし、グリフウィキではUCSをベースに位置づけているのでより適切かと考えます。--kamichi 2013年2月23日(土) 15:30
    • IVSグリフについては、私は現状に反して、IVSを実体とすべきではないのかなと思っていました。公共性も安定性もIVSだと思います。UCS優先なら尚更です。問題はソースがやや不明瞭(?)であることでしょうか?戸籍統一文字やCJK統合漢字のCode Chartsより汚いと思います。--kirikaxfan 2013年3月11日(月) 22:45
    • 私もIVSグリフについて,IVSグリフ“u(2)####-ue01##”を実体とすることには基本的には賛成です。ただし例外として,JIS X 0208:1997字形“j90-####”(以降,旧JISとします)が含まれる場合は,例外としてそちらを優先するのがよいと思います。現在の日本語の情報機器の環境は,WindowsPCの多くはJIS X 0213:2004字形(以降,新JISとします)ですが,携帯電話などのモバイル機器では今でも旧JISがほとんどです。また,印刷物では旧JISと新JISが混在している状況です。ですので,旧JIS・新JISに関わる“j90-####”のうちグループ:JIS2004で例示字形が変更された文字に含まれるものについては,こちらを優先して“j90-####”を実体にするのがよいと思います。--spinda-kkmr 2013年3月27日(水) 19:34
    • 追記。Jソースが存在するUnicodeのコード位置については,Jソース字形の無印UCSグリフを優先して実体とすべきと思います。--spinda-kkmr 2013年3月27日(水) 20:21
    • 追記。前言とは意見が少し変わることになりますが,実体になると分かりにくいのは戸籍統一文字“koseki-#####0”や住基ネット統一文字“juki-####”などなので,「その字形が汎用電子にのみ存在する場合はIVSを優先するが,AJ1に存在する字形,またはJISのバージョン間で字形が異なる場合は,無理にIVSを優先しない」でどうでしょうか。「溢」等は,j78-306ej90-306ejx1-2004-306eのようにJISのバージョンによって字形が異なるため,このようなグリフはJISを優先して実体化するほうが望ましいと思います。--spinda-kkmr 2013年4月20日(土) 10:48
    • 追記。ufa5bufa5fのようにCJK互換漢字に存在する字形の場合は,CJK互換漢字コード位置のグリフを優先して実体にすべきと考えます。IVSに比べれば互換漢字のほうが利用できる環境が多いのでより重要と考えるためです。--spinda-kkmr 2013年4月20日(土) 11:01
  • 前言を撤回することになりますが,私はIVSを実体にすることには反対です。IVSのコード位置には規則性が無く,「再」ではu518d-ue0100u518d-ue0101のように旧字体に若いコード位置が割り当てられているのに,「辻」ではu8fbb-ue0100u8fbb-ue0101のように新字体に若いコード位置が割り当てられています。これでは混乱の原因となります。varを用いて命名する方がよいと思います。--spinda-kkmr 2013年8月18日(日) 10:08
  • 別の議論(漢字データベースで提唱している、すべてをvar,itaijiで表現してフォントに取り込む)はここでは考えないという前提としたときに、純粋にIVD(IVS)グリフ名とその実態(現状では全てに別の名前を振る事が可能)のどちらが実体に良いかというときに、AJ1や戸籍統一文字については安定したグリフと考えられるので実態名(AJ1など)を優先してもいいと思っています。ただ住基は「若干」、登記は「割と」、認知度が低いと考えると無尽蔵に実態名に寄せるのも、とは思います。ただし、ルールとして決めた、という合意がとれるのであれば、特にこれ、という意見はありません。--kamichi 2013年8月19日(月) 22:45

  • 古い議論を掘り返すことになりますが,IVD(u(#)####-ue01##)と戸籍統一文字(koseki-#####0)やMJ(jmj-######)等の間にどちらを実体にするかの優先順位が決められていないため,ユーザーによってどちらかに寄せようとする方針が異なると編集合戦になる可能性があります。エイリアス入れ替え実装により実体を寄せることは6年半前よりも容易になっています。GlyphWikiとしての方針(目安程度の緩い規則でもよい)を決めるべきと思います。
  • 私の現在の意見は,
    • AJ1とそのIVDでは優先順序無し(GlyphWiki:prefixに基づく)
    • Hanyo-DenshiコレクションとMoji_JohoコレクションはIVD優先
  • です。GlyphWikiはUnicodeベースのデータベースなのでUnicode由来の命名を優先した方がいいという理由からIVD優先が好ましいと思います。私が過去にIVDに反対してvarを使うべきとしたのはIVD(IVS)を使える環境が少ないためですが,Word等の主要なソフトウェアがIVSに対応しているため,IVD(IVS)を排除する理由が薄れてきたためです。
  • 以上,--spinda-kkmr 2020年4月4日(土) 19:05
  • 追記。既にvarが実体になっている場合は,無理にIVD(IVS)を実体に寄せる必要は無いと考えます。--spinda-kkmr 2020年4月4日(土) 19:13
  • ユーザーごとの方針の違いによるエイリアス入れ替え合戦が起こる可能性が高いので,早急な議論が必要です。議論を深めるため,この項目を先頭にいたします。意見のある方はお願いいたします。--spinda-kkmr 2020年4月29日(水) 18:18
    • 上記に「Hanyo-DenshiコレクションとMoji_JohoコレクションはIVD優先」とありますが,AJ1やUnicodeのJソース,JIS等の命名がある場合はそちらが優先となります。要は「戸籍や住基,登記統一文字はなるべく実体にしない」ということです。--spinda-kkmr 2020年4月29日(水) 18:21
    • なお,参考に私の意見を書いておきますと,「Unicode(J/JV)>JIS90(JIS2000)>AJ1≓JIS83≓JIS78>Unicode(GHTK等の日本以外ソース)>UnicodeIVD(汎用電子・文字情報)>MJ(jmj-######)>戸籍>住基>登記」です。--spinda-kkmr 2020年4月29日(水) 18:42

  • spinda-kkmrさんの最後のご提案を基本ルールとし、編集合戦が起きた場合の解決の根拠にするということでお願いします。ただ、このルール化をもって既存のエイリアスをすべてを整理する、ということではなくまずは問題解決の際に用いるということでお願いします。--kamichi 2020年10月15日(木) 11:22

KAGE engineのリファクタリングについて

何度か言及しながらあまり具体的な成果がありませんでしたが、この度大幅なKAGE engineの内部実装の整理をしてみたので、エンジンのほうに興味のある方、特に作者のkamichiさんにご意見を伺いたいです。量が多くなってしまったのと、今後も頻繁に更新すると思うので、詳細は利用者-会話:turgenevに記載しました。--turgenev 2020年3月26日(木) 00:33

「𣇋」的-jv字形

此字是「晚」的異體字,「𠂊」-->「丷」,右邊應該保留從「兑」而不用「兌」。 hkcs 2020年1月10日(金) 01:45

変体仮名の関連字について

変体仮名の関連字について方針が現在ありませんので,GlyphWiki全体としての方針を決めた方がいいと思います。私は「元になっている漢字を関連字にする。関連字無し(〓)にはしない」が好ましいと考えます。GlyphWikiは本来漢字のデータベースなので,漢字を基準にするのが好ましいと思うからです。--spinda-kkmr 2019年12月27日(金) 20:45
  • 私は賛成です。そのようにした方が探しやすいと思われます。通常の仮名文字(u3042u30a2など)も同様にすべきかは別件で議論を行うべきだと思います。--kesuuko 2019年12月27日(金) 20:50
  • 他の同音仮名はメタ情報で見れるわけですし、それで良いと思います。yoshiciv 2019年12月29日(日) 18:51

削除の方針について

GlyphWiki:削除の方針に「他の利用者(登録ユーザー・管理人)に対する誹謗中傷・挑発その他の嫌がらせ,及び他の利用者に迷惑のかかる一切の投稿」を追加することを提案いたします。--spinda-kkmr 2019年8月26日(月) 17:49
  • こちらについては管理上の問題として、議論はせずにそのまま取り入れさせていただきます。ご提案ありがとうございます。--kamichi 2019年8月26日(月) 23:41

喫緊の課題として「デリケートな政治的メッセージを投稿すること」を削除の方針として追加することを提案いたします。--spinda-kkmr 2020年10月10日(土) 16:09

  • 内容を若干更新しました。--kamichi 2020年10月15日(木) 11:33

KAGE/engineの改良について

以前投稿した曲線の近似などを含め、KAGE/engineを改良できればと思っています。機能追加のほかに、いわゆるリファクタリングとして ・関数への切り分け、重複の削除 ・変数・メソッド名の修正 ・コメントの充実 ・誤字の修正 等々も考えていますが、いかがでしょうか。Gitはこれから慣れていく予定です。 --turgenev 2019年8月3日(土) 19:57
    • 誤字の修正はともかく、ストロークの種類を表す数字(4:乙曲線、99:他グリフの引用 など)を数字のまま書かず列挙体(enum)にするなどの変更については、ソースを読み慣れた人にとってはあまりメリットがない(もちろん初めて読む人にはメリットがある)割にコードの量は(少しですが)増えるので考え方次第かとは思います。また、プログラミングの知識のある利用者も一定程度いると期待してこの場に書き込みましたが、もしふさわしくないようであれば場所を(Gitなどに?あるいは会話ページ?)変えます。--turgenev 2019年8月3日(土) 21:04
    • あとは、現在のKAGEエンジンによる曲線部分の太さなどのデザイン・感覚的要素をどれほど重視・維持する必要があるのか(あるいは変更結果についての意見をどこで募るか)についても伺いたいです。ただ単に直線を近似した曲線に変える、というだけの変更ではうまく行かない気がしています。現在の「とめ」「はらい」(というより、書き始めから書き終わりにかけて線の太さが変化するストローク全般)の細くなっている側の処理は、ややアドホックな印象があり、素直に近似するにはおそらく適しません。また、「とめ」の最後は半円ではなく五角形になっています。これを円にするというだけでも字のバランスへの影響はある程度発生すると思います。--turgenev 2019年8月3日(土) 22:03
    • 将来的には、ゴシックへの対応も含め、エンジン(肉付けの方式)が複数あってそれぞれに対応したデザインがGlyphwiki上で編集できるという状態になることも考えられるので、一旦思いついたデザインは捨ててしまわないほうが良いかもしれないですね。--turgenev 2019年8月3日(土) 22:47
    • すみません、夏休みに時間が取れたら検討したいと思いつつ、もうすぐ終わってしまいますね。ご提案ありがとうございます。一つ気になっているのはエンジンを変更すると既存の非漢字データへの影響が大きいと思われることです。ですが、前向きに考えたいです。ただ、KAGEデータのフォーマットはあまりいじらなくてもいいかなと思いつつあります。--kamichi 2019年8月26日(月) 23:44
    • KAGEエンジンやGlyphWikiの今後について、時間を取って議論できたら(あるいは人がいなければ私の頭の中で検討できたら)良いなと思っています。地理的時間的に無理であれば会合ではなく、オンライン討議で構わないと思います。これはどこかページを変えてやりましょうか。コアなユーザーの方を含め、ご相談に乗っていただける余裕は皆様ございますでしょうか?--kamichi 2019年8月26日(月) 23:48
    • データフォーマットではなく内部処理の変更です。紛らわしくてすみません。とりあえずデザイン(というより全体の挙動)を変更しない範囲でもソースコードの改善はできそうなので只今作業中です。曲線部分の処理については、現在のデザインの「変更」よりは「(字体の)追加」というような形でマージできたらと思っています(パラメータを一つ変えれば、変更済のデザインで字形が生成される)。
    • 非漢字についても、一つの符号位置に対して、それぞれのフォント(ゴシック、明朝、変更後の明朝、etc.)に対応した複数のグリフを関連付けることができるようになれば、既存の体系を破壊せずに済むと思います。もちろんこれはすぐにできる変更ではないと思いますが、Glyphwikiの共有・編集・他グリフ引用等々のシステムをたった一つの明朝体デザインだけに使うのは勿体無いのではないかと個人的には思っているところです。議論の活発化を私からも期待します。--turgenev 2019年8月29日(木) 16:38
    • ただいまコードの整理中なのですが、adjust系関数の適用の順序は結果に影響するでしょうか。箇所はkage.jsの11行目の
    • this.adjustKirikuchi(this.adjustUroko2(this.adjustUroko(this.adjustKakato(this.adjustTate(this.adjustMage(this.adjustHane(this.getEachStrokes(data)))))))); です。(私の実力不足でもありますが)解読に苦労しております。できれば、ソースコードにコメントなど増やしていただけるとありがたいです。あとは、動作テスト用に、ソースコードのできるだけ多くの場所を通るようなKAGEデータのセットのようなものがあると今後役に立つと思います。それと、KAGEエンジンに関するページを設けたほうがいいような気もします。(通常はGitHub上でやるのでしょうが、KAGE engineはGlyphwikiの利用者のコミュニティと切り離せるものではないと思うので。)turgenev 2020年3月13日(金) 12:27
    • 特にテストデータのあてがないのであればこちらでやってみます。コメントなども含め、今までの開発中に何かしら役に立ったもの、あるいは構造を明らかにしたものが既にあるのであれば、提供いただけたほうが手間が省けると思った次第です。turgenev 2020年3月13日(金) 12:37
      • ありがとうございます。kage.jsの11行目の関数の呼び出し順序はすべてではないのですが一部この順番が必要なはずです。具体的にはkageデータの1,2,3番目、とくに1番目の筆画種別について、100の位1000の位などに筆画の細さなどの情報が付与されるので、順番が変わるとうまく処理されなくなることが考えられます。それとテストデータセットについては特に想定していませんでした。取り急ぎ回答いたします。--kamichi 2020年3月13日(金) 15:12
      • 早速のお返事ありがとうございます。個人的には、adjust系の関数は一気に適用するのではなく必要に応じて(それぞれの画の描画時に、画の種類に対応して)呼び出されるほうが望ましいと考えていますし、情報を数値として付与するのも見通しが悪い気がします。また、cdDrawCurveやcdDrawLineの処理も、もっと細かく、画の種類ごとに分割したほうがいいと思っています。(機能は変わらないものの)内部実装としてはかなり大きな修正にはなると思いますが、今後も考えるとその方向で作業を進めたいと思っていますがどうでしょうか?turgenev 2020年3月14日(土) 00:08
      • 回転機能については、このページの下のほうにある通り、引用時に回転角度を指定できるようにしたほうが良いと思うのですが、機能的にそうしない理由などは何かありますでしょうか。turgenev 2020年3月21日(土) 22:53

VNPF命名の廃止について

VNPF - Vietnamese Nôm Preservation Foundation(會保存遺産喃) にて配布されているフォントの外字が大きく変更されていて、元データが参照できない為、vnpf-6XXXX命名を廃止すべきではないでしょうか。(なお、現在の外字はグループ:prefix-vにてv-fXXXXと命名されることになっています。)--kesuuko 2018年11月25日(日) 17:59
  • “vnpf-6####”の新規作成は停止とし既存分は当面の間存置する,で良いと思います。ちなみに過去分のフォントについては一応InternetArchiveに残っている ようです。--spinda-kkmr 2019年3月20日(水) 17:15

KAGE/engineの曲線の近似について

現在のKAGE/engineでは(kUseCurveをtrueにした時の)曲線部分のベジェ曲線の計算方法は利用者-会話:y-iijimaのようになっているかと思いますが、"bezier curve fitting"などのキーワードでいろいろと調べてみたところhttp://www.realtimerendering.com/resources/GraphicsGems/gems/FitCurves.c や、そのjavascript実装であるhttps://github.com/soswow/fit-curve を見つけました。だから何だという感じではありますが参考までに。turgenev 2018年11月10日(土) 01:43
  • 話題提供をありがとうございました。大変興味深いです。やることがたまりすぎていますが、これもキューに入れます。--kamichi 2018年11月11日(日) 14:47
  • 近似したい点の列と両端点での傾きを指定する内部仕様になっているようです。点の列だけを指定すると両端点それぞれの隣(一つ内側)の点から傾きを算出し、近似が悪くて分割する際の分割点での傾きは、その点の両隣の2点間での傾きを使用しているようです。KAGE/engineで使う場合は各点での傾きが予め決まっていますが、分割時にもそれを使用するように改変することは容易だと思います。turgenev 2018年11月17日(土) 22:51

u2060u2064などの字形について

u2060u2064ufeffといった無幅空白のグリフは制御文字としての字形(例:u200d@2)と空白としての字形(例:ufeff@3)のどちらがよろしいでしょうか。--kesuuko 2018年9月5日(水) 20:54

u200dの字形

u200dの字形はu200d@1u200d@2のどちらが良いでしょうか。私はu200d@1が良いと思います。--kesuuko 2018年7月15日(日) 22:29

部品の廃止について

部品は多くのグリフで引用されているので,廃止されると大きな影響が出ます。そこで,部品廃止は廃止したい部品グリフのノートページに提案したうえで他のユーザーの同意を得たうえで廃止することを原則とし,以下の場合のみ1ユーザーの判断で廃止可能,とすべきだと考えます。

  • (1) -07部品(位置指定の無い部品)のうち他のグリフの配置を変えただけのもの。
  • (2) -07部品(位置指定の無い部品)のうち純然たる部品ではなく,異体字として成立するもの。この場合グリフはvarまたはitaijiとして存続する。

以上,--spinda-kkmr 2018年6月16日(土) 10:09

kesuuko様よりノート:u20089-03に追加の提案がありました(斜体部分が引用)。

  • (3) 明らかな命名ミスがある場合(-01なのに旁や冠、IDSミス、包摂されるのに-itaiji等)
    • この場合,グリフは適切な命名のグリフの移動のうえで存続となります。

以上,--spinda-kkmr 2018年6月21日(木) 19:34

  • 同意します。また、従来から「位置や大きさを変えただけの部品を敢えて用意すること」への疑義もたびたび出ていますが、「その部品を利用することによるデザイン統一性への良い影響」を根拠に「問題なし」という意見であることもあたらめて表明します。--kamichi 2018年8月27日(月) 12:13

回転機能に関して

↓以下、GlyphWiki:バグ報告-保存@19ゟ引用

  • 「u22a0b」のようなグリフは珍しいそうですが、ストロークの方向を逆にすると、ウロコなどが変になります

現在登録されたグリフ:u22a0b  バグ例:sandbox@115

これはテストだけですが、直線の場合には:「 http://jeroenhoek.nl/research/gwdftool.png 」こういう風書かれるといいかもしれません。jeroen 2009年1月16日(金) 13:12

KAGEエンジンの理念として、実用的な範囲でなるべく単純化する、というポリシーがあります。それでExt.B集合も含めると、現状のKAGEエンジンで表現できないグリフのタイプが(1)ミラーリング(2)篆刻体の等幅、の2つあります。当初これらは「明朝体の範疇外」として無視するつもり(そのため変になる)でしたが、皆さんが無理やりデザインしてくださっていた(もちろん、ありがたく思っています)のを、そのままにしている、というのが現状です。--kamichi 2009年1月16日(金) 15:32

それで、ミラーリングについては、無理に逆さ字形も対応するのではなく、単純にポリゴンを行列変換で回転させる手法をとるのが理想的と思っています。ですので引用「99」の次に「0」は回転なし、「1」は時計回りに90度、「2」は180度、「3」は270度、という機能を加えることにしたいと思います。対応時期については、まだ優先度が低いです。--kamichi 2009年1月16日(金) 15:32

回転機能について、それは優雅なアプローチだと思います。jeroen 2009年1月16日(金) 20:01

ちょっと手が回らないので今後の予定とします。--kamichi 2009年6月15日(月) 22:51

↑引用終わり

  • このようにkamichiさんは9年前に回転機能の追加を予定していましたが、9年程経った今も実装されていません。回転機能の追加をお願いします。--kesuuko 2018年6月3日(日) 01:02

    • ご提案ありがとうございます。KAGEエンジンの現在の作り方に依存して、以下の条件であれば、実装できそうなのですが、いかにもとってつけたような感じでスマートではないのですが、いかがでしょうか。--kamichi 2018年6月3日(日) 09:56

 KAGEデータに「0:999:角度:矩形左上X:Y:矩形右下X:Y」を追加し、その時点までに
 生成したポリゴンの任意の矩形を任意の角度回転させる。矩形が筆画の一部分に
 かかっている場合の影響は考慮しない。エディタでは編集不可のため、最後に
 手作業で付与する。

  • 回転(反転?)にはどのようなバリエーションが考えうるでしょうか。任意の角度としましたが、90,180,270度回転と上下反転、左右反転、などでしょうか。90,270度回転は縦と横の大きさが一致しないとアスペクトが変わりますが、それでもいいですよね。--kamichi 2018年6月3日(日) 10:19
    • それでよいと思います。私は回転は90,180,270度の3種類のみを想定しておりました。回転と反転を組み合わせれば大抵のグリフは作れると思います。現状では例えばobuso-1633-jv@1がかなり不恰好です。Unicode範囲内の漢字でこのように不恰好になっている例はあるのでしょうか? 非漢字グリフの作成まで考えるならば,任意角度の回転もできた方がよりよいことは確かですが… --spinda-kkmr 2018年6月3日(日) 10:37

 0:99:{1|2|3}:矩形左上X:Y:矩形右下X:Y ...回転(1:90度,2:180度,3:270度)
 0:98:0:矩形左上X:Y:矩形右下X:Y ...左右反転
 0:97:0:矩形左上X:Y:矩形右下X:Y ...上下反転

ご意見ありがとうございます。この3つで行きましょうか。--kamichi 2018年6月3日(日) 11:29

  • 第2,3パラメータが3桁になるのは影響が不明なため2桁に変更しました。--kamichi 2018年6月3日(日) 17:47
    • ということで、実装できました。プレビュー用エンジンのみ反映しているため、グリフエディタでは反映されません。近い将来グリフエディタをSWFからJS+Canvasに直しますので、その時まで保留とします。--kamichi 2018年6月3日(日) 19:03
    • なお、バッドノウハウになりますが、矩形が他の筆画と重なってしまう場合は、書き順を無視して回転・反転対象を先に書き、先に処理するやり方で回避できます。--kamichi 2018年6月3日(日) 19:04
    • ああ、部品内で97,98,99を使った場合、その座標が引き継がれないので影響が大きすぎますね。おっとっと…--kamichi 2018年6月3日(日) 19:06
      • そうではなくて回転対象矩形に他の筆画が混じったのでした。先ほどのバッドノウハウで回避はできますが、影響が出そうなので、改良します。--kamichi 2018年6月3日(日) 19:14
      • 回転反転対象の矩形に他筆画が入った場合にポリゴンがすべて入らない場合は回さないように修正しました。ただし、縦筆画の筆初めの右につく三角形のように小さな装飾ポリゴンが矩形に完全に入ってしまって一緒に処理されるのは防げません。--kamichi 2018年6月3日(日) 19:24
  • 45度単位の回転の追加をお願いいたします。45度単位の回転はirg2017-01989の作成の為に必要です(https://hc.jsecs.org/irg/ws2017/app/?find=T13-3378 )。--kesuuko 2019年12月9日(月) 14:22
    • 私も45度単位回転の実装をお願いいたします。u2bccを45度回転させてu2bcdを作成できるなど,非漢字グリフの作成に有用です。--spinda-kkmr 2020年3月13日(金) 18:40

文字幅等を定義するグループ

  • 文字幅等を定義するグループのフォント生成対応は、現在三グループに対応していますが、次のようにするべきだと思っています。--kesuuko 2018年3月26日(月) 15:05
グループ名 左端右端対応状況備考
(いずれにも入っていない)0200対応済み
グループ:HalfwidthGlyphs0100対応済みUCSグリフ等のみ
グループ:HalfwidthGlyphs-nonUCS0100未対応UCSグリフ等以外
グループ:One-thirdwidthGlyphs067未対応
グループ:One-quarterwidthGlyphs050未対応
グループ:One-sixthwidthGlyphs033未対応
グループ:DoublewidthGlyphs0400未対応
グループ:TriplewidthGlyphs0600未対応
グループ:NonSpacingGlyphs00未対応制御文字
グループ:NonSpacingGlyphs-Halfwidth-1000対応済み半角の文字に対して合成
グループ:NonSpacingGlyphs-Fullwidth-2000対応済み全角の文字に対して合成
    • 皆様のご意見をお待ちしております。

  • 喫緊で必要なものは追加に賛成ですが、どれでしょうか?--kamichi 2018年4月17日(火) 09:05
    • 最も必要度が高いのはグループ:HalfwidthGlyphs-nonUCSです。このままでは非Unicodeの半角文字が利用できません。
    • 次に必要度が高いのはグループ:NonSpacingGlyphsです。このグループに登録しておけば自動的にフォント生成対象から除外するようにすれば,制御文字が制御文字の字形そのままで登録されていても(例:u2d7f)いちいち気にせずにフォント生成できるので便利です。
    • 以上,--spinda-kkmr 2018年4月17日(火) 17:50
    • グループ:NonSpacingGlyphsに関して、私は反対です。私はグループ:NonSpacingGlyphsの文字はufeffのように幅無しの空白をフォントに入れることを意図して提案したので、私は賛成できません。私は、グループ:フォントに含まれるべきでない符号位置として、白紙化された符号位置(u1f620など)も含めてページ化すべきだと思います。グループ:HalfwidthGlyphs-nonUCSに関しては、極めて緊急性が高いので、私も賛成します。--kesuuko 2018年4月17日(火) 22:55
    • グループ:HalfwidthGlyphsが容量オーバーになりかかっているようです。上記対応と同時にこのグループを分割し,グループ:HalfwidthGlyphs-BMPグループ:HalfwidthGlyphs-SMPの2つに分けるのがよいと思います。もちろん半角対応をしたうえでです。
    • あるいは,グループ:HalfwidthGlyphsの配下にあるグループはすべて半角グリフになるというシステムに変更し,そのうえでBMP,SMP,nonUCSの3グループをそこに登録するというシステムでもよいと思います。
    • また,グループ-ノート:HalfwidthGlyphsにあるように,ユーザー占有の半角グリフを作成したいという需要もあるようです。もし対応するのであれば,nonUCSの末尾に追加してもよいというルールにするか,あるいはuser-exclusiveという4つ目のグループを作るかのいずれかとなると思います。ただ,ユーザー占有の半角グリフを許すかどうかはルール化されていないので,議論が必要と思います。
    • 以上,--spinda-kkmr 2018年6月3日(日) 10:54

  • 取り急ぎグループ:HalfwidthGlyphsグループ:HalfwidthGlyphs-BMPグループ:HalfwidthGlyphs-SMPに分け、この2つのページをフォント生成時に参照することの作業のみ着手します。--kamichi 2018年6月3日(日) 11:34
    • 分離しました。それで、non-UCSについてですが、現状のグリフウィキのフォント生成は、UCSコードに対するグリフ記述によって収録グリフを指定するので、non-UCSのページを反映させることができません。つまり、「aj1-xxxxx」というグリフがあって、それを「U+00xx」に割り当てる形でフォントを生成しようとした場合、BMPページにある[ [u00xx] ]という記述に基づいてそのグリフが半角扱いとなります。ということで、non-UCSのグリフをどのようにフォント生成に反映させるかについて、イメージをお知らせください。--kamichi 2018年6月3日(日) 15:28
      • 私は、 uf0021(aj1-00033) uf0018(sawn-f0018) とグループページに記述された場合、そのフォントのU+F0021やU+F0018が半角になると考えています。--kesuuko 2018年6月3日(日) 15:37
      • 私もそう考えておりました。非UCSのグリフについてはグリフ単位で半角化されると考えています。なお,UCSグリフについても,例えばu203cはグリフウィキではデフォルトで全角ですが,これを u203c(u203c-halfwidth) とすれば半角化できると考えております。--spinda-kkmr 2018年6月3日(日) 15:47
      • ちょっと混乱してきました。以下の表の半角・全角の認識が一致するかどうか、および(1)と(2)はどちらでしょう?--kamichi 2018年6月3日(日) 19:40

[[ucs(半角記述あり)] ]半角
[[ucs(半角記述なし)] ]全角
[[ucs(半角記述あり) グリフ(記述あり)]]半角
[[ucs(半角記述なし) グリフ(記述あり)]]???(1)
[[ucs(半角記述あり) グリフ(記述なし)]]???(2)
[[ucs(半角記述なし) グリフ(記述なし)]]全角

  • 私の認識では(1)は半角,(2)は全角です。
  • つまり,UCS本来(グリフウィキでのデフォルト)の全角半角をグリフで書き換えられる,という意味です。これが使えないと「これはグリフウィキでは半角規定だが,全角にしたい」(またはその逆)といった利用法ができません。住基文字“juki-####”の非漢字グリフではUCSで半角の文字も大部分が全角になっているので,これができないとかなり困ります。
  • 以上,--spinda-kkmr 2018年6月3日(日) 19:53
  • グループ:spinda-kkmr_test0@42でテストしたところ,上記の2つの例は私の想定通りになっていました。 ue000(aj1-00632) だけが全角のままでした。現状では「UCSの半角全角の指定に関わらず,グリフの半角全角の指定を優先する」ようになっているようです。ですのでグループ:HalfwidthGlyphs-nonUCSに収録されるグリフも,フォント生成時に指定されるUnicodeコード位置に関わらず半角にする,でよいと思います。
  • 以上,--spinda-kkmr 2018年6月7日(木) 18:02
  • グループ:HalfwidthGlyphs-nonUCSが機能していないようです。このままですとAJ1等に含まれる半角グリフが利用できませんので,なるべく早くの対応をお願いいたします。現状ではグリフを半角指定するとコード位置に関わらず半角グリフになる仕様のようですので,それで良いと思います。--spinda-kkmr 2019年3月6日(水) 19:21

  • 議論が長期間停止してしまっていますが,グループ:spinda-kkmr_test0@46で再テストしたところ,やはりグループ:HalfwidthGlyphs-nonUCSは機能していないです。このグループにはAJ1に収録されている「半角ひらがな」や「半角濁点付きカタカナ」などの有用グリフがありますが現状では正常に利用できません。
  • 現状ではGlyphWikiでのデフォルトにかかわらずグリフがHalfwidthGlyphsに収録されていれば半角,無ければ全角になる仕様のようなので,単純にグループ:HalfwidthGlyphs-nonUCSのグリフ幅を半角にするようにすれば特に問題ないと思われます。早急なご対応をお願いいたします。
  • 以上,--spinda-kkmr 2019年11月4日(月) 13:13

  • グループ:HalfwidthGlyphs-nonUCSの対応を早期にお願いいたします。繰り返しとなりますが,ここには「半角ひらがな」や「半角濁点付きカタカナ」などの有用グリフがあります。--spinda-kkmr 2020年3月13日(金) 18:40
    • 再度のお願いとなりますが,「半角ひらがな」「半角濁点付きカタカナ」等を利用したいので,早期にグループ:HalfwidthGlyphs-nonUCSへのご対応をお願いいたします。
    • また,これを機にユーザー占有グリフの半角を許すかどうか,許すのであればどのグループに記述するのか(nonUCSに含めるのか,第4のグループを設定するか)も決めるべきと考えます。--spinda-kkmr 2021年3月3日(水) 17:33

接尾詞無しCJK統合漢字のグリフページのガイドページ化について

接尾詞無しのCJK統合漢字のガイドページ化の提案があります。

私は、このように考えております。

まず最初にu****(*)のグリフを5種類に分けます。

  • 1.非漢字及び互換漢字
  • 2.Jソースの存在する漢字
  • 3.Jソースの存在しない漢字
  • 4.簡体字特有の字形が含まれ、Gソースが存在する漢字
  • 5.簡体字特有の字形が含まれ、Gソースが存在しない漢字

その後、種類ごとに処理を行います。

種類処理
非漢字及び互換漢字何も行いません。
Jソースの存在する漢字u****(*)のデータをu****(*)-jにコピーして、u****(*)をu****(*)-jのエイリアスにします。
Jソースの存在しない漢字u****(*)のデータをu****(*)-jvにコピーして、u****(*)をu****(*)-jvのエイリアスにします。
簡体字特有の字形が含まれ、Gソースが存在する漢字u****(*)のデータをu****(*)-gにコピーして、u****(*)をu****(*)-gのエイリアスにします。
簡体字特有の字形が含まれ、Gソースが存在しない漢字u****(*)のデータをu****(*)-jvにコピーして、u****(*)をu****(*)-jvのエイリアスにします。

その後、次のような順番でシステムの改修などを行います。

1u****(*)からu****(*)-j、u****(*)-jv、u****(*)-gに部品の一括更新をする。
2接尾詞無しのCJK統合漢字をガイドページになるようにする
3接尾詞無しのCJK統合漢字を白紙化して実際にガイドページにする。
4接尾詞無しのCJK統合漢字を編集できないようにする。

以上です。--kesuuko 2018年2月10日(土) 19:05

  • ご提案ありがとうございます。最終的にはガイドページ化が想定されていて、時期尚早ということで見送られてきた経緯があります。提案に対しては(1)「簡体字特有」の字形とは何か、あるいはそれが含まれているからGソースとみなしていいのか(字形衝突、あるいは簡体字的字形の他地域での受容は考えないのか)(2)無印グリフ(ページではなくpngの直接参照)を参照すると何が表示されるか、それは妥当か、という2点が懸念されます。少し広く意見を欲しいところです。--kamichi 2018年2月12日(月) 15:03

    • 御回答ありがとうございます。(1)に関しては、字形衝突が起きないようにすれば問題ないと思います。(例えば、u22016は簡体字特有の字形だが、u5723は簡体字特有の字形ではない。)また(2)に関しては、Gソースの有無を確認するため問題ないと考えております。--kesuuko 2018年2月17日(土) 11:51

    • 「簡体字特有の字形」という言葉はGlyphWiki:仮想J字形のガイドラインに出てきますが、現状「簡体字特有の字形を含まない漢字の無印グリフは(仮想)J字形にして、そうでない(=簡体字特有の字形を含む)漢字の無印グリフはそのソースの字形(大概はGソース)にする」というルールで運用されているので、統合漢字の無印グリフu(X)XXXXは上の表にしたがって実質的にu(X)XXXX-j/jv/gと読み替えられる状況になりつつあると思います。そういうわけでu(X)XXXXをガイドページにするとき、現在u(X)XXXXにあるデータの行き場としてu(X)XXXX-j/jv/gを上の表にしたがって選ぶのは妥当と思います。―twe 2018年2月22日(木) 17:16
    • (2)については「花園明朝にどのグリフを収録するのか」としても同じ問題があると思いますが、現状の無印グリフの優先順位(JIS X 0213:2004 > JIS X 0212 > J欄字形 > AJ1 > 仮想J字形 > 簡体字 でしょうか?)で決定するのが字形が変わらなくて無難と思いますが、複雑過ぎますかね。―twe 2018年2月22日(木) 17:16
      • 花園明朝についてはこれを機にSource Han Sans/Serifのように地域ごとに別のフォントにするというのもアリかもしれません。(話が飛んでしまいました)―twe 2018年2月22日(木) 17:16
      • Noto フォントでもそうですが、GSUB loclフィーチャを使えば複数国語の書体を同一フォントに入れることは可能です。 golconda 2018年3月6日(火) 22:59
  • 賛成です。考えるとすれば次のような感じでしょうか。--kesuuko 2018年2月25日(日) 01:31
※他にもUソースが存在しますが、ここでは省略します。
フォント名内容
1花園明朝JA現在の花園明朝Aと同じ
2花園明朝JB現在の花園明朝Bと同じ
3花園明朝GA花園明朝JAのグリフをG字形+仮想G字形に置き換えたもの
4花園明朝GB花園明朝JBのグリフをG字形+仮想G字形に置き換えたもの
5花園明朝KA花園明朝JAのグリフをK字形+仮想K字形に置き換えたもの
6花園明朝KB花園明朝JBのグリフをK字形+仮想K字形に置き換えたもの
7花園明朝VA花園明朝JAのグリフをV字形+仮想V字形に置き換えたもの
8花園明朝VB花園明朝JBのグリフをV字形+仮想V字形に置き換えたもの
9花園明朝TA花園明朝JAのグリフをT字形+仮想T字形に置き換えたもの
10花園明朝TB花園明朝JBのグリフをT字形+仮想T字形に置き換えたもの
11花園明朝HA花園明朝JAのグリフをH字形+仮想H字形に置き換えたもの
12花園明朝HB花園明朝JBのグリフをH字形+仮想H字形に置き換えたもの
13花園明朝MA花園明朝JAのグリフをM字形+仮想M字形に置き換えたもの
14花園明朝MB花園明朝JBのグリフをM字形+仮想M字形に置き換えたもの
15花園明朝KPA花園明朝JAのグリフをKP字形+仮想KP字形に置き換えたもの
16花園明朝KPB花園明朝JBのグリフをKP字形+仮想KP字形に置き換えたもの

  • (1)については,とりあえず「簡体字特有」を「“Gソースのみ”または“GソースとHソースのみ”」(Jソースは存在しない前提で)と解釈していったん機械的に処理し,その後で面倒ですが1つ1つ目視点検して調整するしかないと思います。
  • (2)については,tweさんの意見に賛成です。CHISEでどの文字集合に存在するのかがUnicodeコード位置から検索できるので,処理は比較的容易だと思います。
  • kesuukoさんの花園明朝ソース分割についてですが,Jソース版のフォント名は変更すると混乱するので現状維持がよいと思います。ソースごとのフォントは作成作業に相当時間がかかると思いますがアイデアとしては良いと思うので,まずはGソース版とKソース版を優先して作れると良いと思います。Kソース版は2点之繞や旧字体の食偏などを異体字セレクタに頼らずに表示できるようになるので,日本人にも利用価値が高いと思われます。
  • 以上,--spinda-kkmr 2018年2月25日(日) 10:52

  • では、spinda-kkmrさんの意見の通りに実行することとしてよろしいでしょうか。--kesuuko 2018年3月4日(日) 16:40
    • ここ数週間、議論が進展していません。皆様に最終確認を行います。spinda-kkmrさんの意見の通りに実行することとしてよろしいでしょうか。--kesuuko 2018年3月26日(月) 15:05

  • 時間がないのでspinda-kkmrさんのご意見に絞って部分的に書きます。(2)についてKソースは反対です。なぜなら「Kソース」の字形を韓国の人は少なくとも一般的と思っていない事例があるからです。我々にとって「伝統字体」が使えて便利というのであればそれは「K」ではなく「伝統字体」というラベルで切り出すべきと思います。Gソースは問題ないと思います。とくに(1)については決定しても着手できるのかという大きな問題があります。積み上がり過ぎている諸問題に優先順位をつけて取り組みたいと思います。--kamichi 2018年3月29日(木) 21:49

  • 別の話題でGoogle FontsにようやくHanaMinが取り込まれるという話題があります。個人的にはまだ時間がかかるのではないかと思っているのですが、そうであるなら今後各規格票字形フォントを一般のHanaMinと切り離した形で個別実装しても良いと思います。HanaもMinも日本語なので、もう少しユニバーサルな名称で独立させるとかいかがでしょうか。ただしそうなると必然的に話が大きくなってしまうので、それとは別に当初の議題である無印UCSの扱いについては別途詰めないといけません。問題がゼロとは言いませんが、無理やり分離して、ぼちぼち直していく形で着手しましょうか。--kamichi 2018年4月17日(火) 09:10

簡体字のUソース

簡体字にはUソースとGソースが存在しますが、UソースとGソースでu9485のように、一部異なる字形が存在します。このような文字の場合、どのような字形を仮想J字形とするのが望ましいでしょうか。--kesuuko 2018年1月5日(金) 17:57
  • 簡体字のUソースというのはどれのことでしょうか。ちょっと混乱しています。--kamichi 2018年2月2日(金) 12:54
    • 簡体字のUソースとは、ここではUソースの文字のうち、簡体字特有の字形を含むものをいいます。--kesuuko 2018年2月6日(火) 20:35

JV source shaping for ancient Chinese characters

One case is the left hand and right hand. The character is 𠬞 (or 廾 / 大 when as component in modern words, such as 樊、與), which means to push up. The original character is composed of left hand and right hand. (The flipped character, composed of right hand and left hand, is 𠬜.)
The left hand component in the Unicode sources are shaped inconsistently. Left hand is usually written as 𠂇 in modern text, such as 左. In the Extension B, sometimes it is written as 𠂈, with second stroke sometimes protruding third stroke. Sometimes it is written as 丩, with protrusion and without. However, 𠂈 and 丩 and 𠂇 are of completely different origin, so it would be better to differentiate and be consistent.
For left foot and right foot, the characters are currently 𡕒 and 夊. it just so happens that the if we remove the first stroke, we get 丩 with left protrusion. I think it is better to unify it that way? chanhenryfaihang 19:36, 23 May 2015

どなたか,上記英文を日本語に翻訳してください。--spinda-kkmr 2015年5月24日(日) 10:06

Propose unify characters containing u20b1e@5 (left hand 𠂇 + right hand 又). Inconsistencies in the left hand component:

By etymology, left hand (𠂇) =/= u20088 (殄) =/= u4e29 (丩) Therefore, propose using u20087-01-itaiji-001: u20b1e-03, u20b1e-04

above -- hkcs 2016年9月30日(金) 20:39