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

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

GlyphWiki:井戸端

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

目次

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

T用折れの追加について

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

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

  • 今までのサンドボックスなんですが、スパム投稿の量に開いた口が塞がりませんでした。サイバー攻撃である可能性が高いと自分は思っています。自分もかなりの連続投稿をしたことがあるから何とも言えませんが、今回の件はかなりひどいので対応をしていただければと思いますが。。。ところで、感情制御ができなくてまた下品な言葉を使ってしまって本当に申し訳ございません。--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

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

接尾詞無し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


古代文字の字形の基準について

最近,Unicode第1面の古代文字が多く登録されていますが,各利用者ごとの字形の解釈の差のため,Unicode規格票と離れた字形のグリフが登録されていることがあります。
そこで,解釈のばらつきを回避するために,以下の基準を提案いたします。

1.古代文字は,原則としてUnicode規格票に倣った字形とする。
2.ただし,ある文字グループについて,別の基準(典拠がはっきりしており,かつ,Unicodeコード位置と明確に対応できるものに限る)に従って作成することについて複数(3名以上)の利用者が合意した場合は,それに従う。

上記のとおりです。意見をお願いいたします。--spinda-kkmr 2015年5月23日(土) 12:36

  • 自分が現在作っている古ペルム文字のように、規格表が非常にガタガタで判別が難しい場合には、2の案を適用させるべきだと思います。地域差、書き癖により、明らかに別の字と捉えられるもの(ロシア、ブルガリア、セルビアのキリル文字の差とか)に関しては-var-bgのように区分したらいいのではないかと思います。

データのライセンスについて

クリエイティブ・コモンズのCC0が発表されました。これをグリフウィキのグリフデータおよびドキュメントデータに適用(ライセンスの変更)することはいかがでしょうか。いままでグリフウィキのデータに関するライセンスの問い合わせを受けたことは無かったと思いますが、より明確になるかと思います。デメリットがあるかどうか、現時点で思いつきません。--kamichi 2015年5月8日(金) 08:09

  • 賛成です。今までのライセンスと実質的にできることが変わるわけではないので、独自ライセンスより望ましいと思います。--emk 2015年9月1日(火) 21:45

「非」明朝体漢字の登録制限について

グリフウィキはもともと明朝体漢字のデータベースを想定していましたが、多分にそれ以外の漢字が登録されています。個人占有グリフに登録する分には何とも思いませんが、一般グリフにどんどん異体字扱いで増えていくのはどうかと思います。次のような縛りを考えています。

  • 明朝体が見出し字となっている辞書に、非明朝体だが見出し字として掲載されている字形は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-001kamiyo_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####-###」でいきたいと思います。

補正して欲しい字に関して

教育部異体字事典の様な楷書のソースから転写しようとしたけれど上手く再現できないといった場合のための「グループ:請補正字」のようなものはあるのですか?今の自分の場合はu7fb9-itaiji-002なのですが。 --yoshiciv

  • 現状では残念ながらありません。積極的に請うという意味ではグループを作成した方がよいと思います。それと、できれば署名の際、「〜〜〜」に加えてもう一つ「〜」を入力していただけると(つまり「〜」4つ)、投稿日時も自動的に入ります。--kamichi 2014年10月17日(金) 08:36

  • 一般の「問題のあるグリフ」の様なグループもよいと思います。u2ff0-u5200-u524a(⿰刀削、IDSは字形と違います)などの為に作るのはどうですか?--umbreon126 2014年10月20日(月) 10:38
    • 賛成です。また、問題のあるグリフ以外にも「翻訳を手伝ってほしいドキュメント」「作業中」などのタグをつけて、そのタグが付いている一覧を特別ページで出せるといいかなと思います。wikipediaがどのような方式かを知らないので、調べてみます。--kamichi 2014年10月20日(月) 10:53

IDS名称ミスのグリフについて

現在,u2ff1-u52d7-u65e5@3(⿱勗日,正しくはu2ff3-u8279-u7530-u65e5)のような誤ったIDSのグリフがいくつか存在するようです。これらは残しておく必要性が低いと思うので,白紙化したほうがよいと思います。--spinda-kkmr 2014年3月22日(土) 12:54

  • ツイッターで呼ばれたので来ました。
  • ①については白紙化すべきだと思います。白紙化を避けるのは、基本的に、一つのグリフに対して正しい命名が複数ある場合なので、間違った命名は対象にならない筈です。(長期間放置された間違いなのでサイト外から参照されている可能性があるとかいう問題は、「白紙化の抑制について」の議論で私が書いたようにシステム側で対応してほしい所です。)
    ②は余力があればやりましょうか。数が多くて面倒な時とかはdo-not-useを付けるだけでもいいですよね。元々do-not-useの付加は恒久的な状態ではなく、「いつか消すべきだし、今すぐにでも消したいけど、ほかの専有グリフに部品として引用されてるのでシステム上消させてくれない」という意味で使っていたので、グループの問題が解消した時点で誰かが消せばよい、という事で。— sayunu 2014年6月21日(土) 13:05

TRONコードの命名について

現在,TRONコードの命名は“tron-#-####”となっていますが,TRONコードは現時点で第31面まで予約されており,第10,16,17,22,23面には既に文字が割り当てられているようです。したがって現在の命名ではこれらに対応できません。解決法として,次の2つが考えられますが,どちらが望ましいでしょうか。

  • (1)“tron-##-####”に変更する。
  • 例えばtron-9-8023@5tron-09-8023に変更する。わかりやすいというメリットはありますが,既に存在する“tron-#-####”のグリフを移動・白紙化しなければなりません。

  • (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)の1桁でいいのではないでしょうか。 --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

Unicodeにない戸籍統一文字等のIDS表現について

  • Unicodeに存在しない戸籍統一文字(koseki-#####0),住基ネット統一文字(juki-####),登記統一文字(toki-0######0),GTコード(gt-#####)について(以下,「戸籍統一文字等」とします),私はIDS表現によるグリフを実体とし,これらUnicodeに存在しない戸籍統一文字等のグリフをそのエイリアスとするのが望ましい(例:u2ffa-u8fb6-u9ce5を実体とし,gt-52573をそのエイリアスとする)と考えますが,どうでしょうか。
  • 私がIDSを優先すべきと考えるのは,IDSを用いればUnicodeに無い文字をUnicodeで疑似的に表現できるので望ましいと考えるからです。
  • 以上,--spinda-kkmr 2013年4月19日(金) 18:29

    • 亀レスで恐縮です。いまIDSグリフが大量に登録されていますが、そこで懸念しているのがUCSコードが抽象字形を指しているため、そのうちG風とJ風でバッティングしてしまうのではないかと思っています。この場合「IDS-var-###」になると思いますが、そう考えると挙げられた「戸籍統一文字等」の方が字形が安定しているのではないかと考えます。いかがでしょうか。--kamichi 2013年6月3日(月) 12:01
    • 私はJ字形を基本にIDS表現していたので,例えばu8fb6は2点之繞,ufa66は1点之繞というようにしていましたが,確かに他のソースのことを考えると(u8fb6-gは1点之繞)字形の衝突が起こりえますね… 最近大量に登録されているG風のIDSグリフについては私はよくわかりませんが,戸籍統一文字は文字情報基盤文字情報を経由してUnicodeに登録される可能性が高いので,無理にIDS表現にこだわる必要も無いかもしれませんね。--spinda-kkmr 2013年6月3日(月) 20:02

    • 私もIDSを実体とし、koseki-######などをエイリアス化する方向に賛成です。
    • IDSの無印を仮想J字形(または左下GTなどを使用しないJ字形に近い形状)にした上で、仮想J字形以外の字形と偏化変形を全て「IDS-var-###」に字形を割り当てるのも有りなのかとも思います。
      当方も中華字海、台湾教育部異体字字典、會保存遺産喃の字喃など、G,T,V字形に該当する物を多数作成しておりますが、文字によって字形に差異のあるものが多々見受けられます。
    • また、現状関連字はCJK統合漢字1字を割り当てることが可能ですが、関連字にIDS(3字以上)が使用できれば、さらに見やすくなる気もします。
    • 例えば、仮想J字形にu2ff1-u8002-u2ffa-u200ca-u53ea(壽・寿の異体字の一つ)を作成し、(現在の関連字:寿) u2ff1-u8002-u2ffa-u200ca-u53ea-var-001(zihai-117106) (zihai-...をエイリアスとする)、(現在の関連字:壽) u2ff1-u8002-u2ffa-u200ca-u53ea-var-002(twedu-a00836-069) (twedu-...をエイリアスとする)をそれぞれ関連字に「⿱耂⿺𠃊只」を割り当てて、異体字関連グリフに「壽(台湾教育)」「寿(中華字海)」を割り当てる。--kamiyo 2013年6月10日(月) 15:34

CJK互換漢字の字形の扱いについて

CJK互換漢字の無印グリフ(ないし、無印廃止後に花園フォントにおいて採用されるグリフ)の字形の扱いはどうなっているのですか?

互換漢字は統合されないにも拘らず一つのコードポイントに複数のソースが与えられています。無印グリフにjv字形を適用しないとしたら、いずれのソースを典拠にするのかを決めなければなりません。そもそも、互換漢字の無印グリフはそれがどこのソースに基づくものかすらグリフページからは分からないわけですから、いずれにしても現時点で統合漢字より、地域ソースグリフ作成の必要性が高いと思います。

現状の互換漢字は、無印グリフが無秩序な状況になっていると思います。たとえばu2f88bはjvでもUCSソース(tとkp)でもない中途半端な字形です。またこの字について、UCSソースにあたる字形を持つグリフは現在存在していません。あるいはu2f9bcは、TソースとHソースがある中でTソースが“恣意的に”採用されている状態です(Hソースは「ヨ」の中の棒が飛び出ません)。それともこれにはHソースではなくTソースを選ぶ特別の理由があるのでしょうか。

互換漢字の字形はどのようなものにするのかを決めてガイドラインに示すこと、そして全互換漢字について地域ソースグリフを作成していくことが必要だと思いますが、どうでしょうか。--kirikaxfan 2013年3月23日(土) 13:13

  • ちょっと説明(解明?)します。互換漢字は、「その互換漢字がどんな字形の違いを目的としてエンコードされたか」をde factoの原則(?)としてきました。たとえばu2f88bは、u5eb0-tとは「并」と「幷」の違いでエンコードされているものです。ですので、「并」と「幷」の違いを反映し、それ以外の違い(この字の場合、u5e7f-05u5e7f-t05の違い)は反映しません(u5e7f-t05を使うと、ほかのグリフとのデザインが一貫性がなくなることもあります)。
  • u2f9bcにTソースの字形が反映されているのは、もともと「CJK互換漢字補助」領域の文字は、複数欄ではなく、Tソースの字形しかなかったからです。ですのでTソースの字形に合わせられています。
  • 互換漢字について地域ソースグリフを作成していくのは全く問題ないと思います。 --johotogoshinentai 2013年3月23日(土) 14:00

    • まず、ここで使われている「エンコード」という言葉の意味が分かりません。「符号化」=「コードポイントを与える」という意味ですか?
    • であれば、之繞はどうです?KS X 1001用互換漢字は、統合先との間に字形の差を与えないものです。しかしその一つであるuf99aは、u9023に統合される互換漢字であるにも拘らず、統合先とは異なり二点之繞になっています。これはどういう理窟ですか。
    • またu2f9bcについては、理由は分かりましたが、私が言いたいのはそういうことではなく、では現時点にあって、それでいいのですか?ということです。「理由」ではなく「根拠」の問題として、歴史的にではなく論理的に、今TソースとHソースが対等の立場なのであれば、今Tソースが選ばれていることは“恣意的な状態”ではないですか、ということです。もし今、このグリフをTソースにしたい人とHソースにしたい人が現れて編集合戦を繰り広げたとしたら、どちらに決着させるのですか、ということです。もし現時点でそれに答えがないのだとすれば、これは普遍的な問題ですから、新たにルールを定めて解決する必要があるはずです。
    • どうでしょうか。--kirikaxfan 2013年3月23日(土) 15:01

      • 「符号化」のことです。
      • 字形の差について、ちょっと補充します。「その互換漢字がどんな字形の違いを目的として符号化されたか。(仮想)J字形で使われているデザインなら、その差も反映する。使われていないと、その差は反映しない。」つまり、「なるべく元の字形を反映し、(仮想)J字形と合わない差は反映しない」ということです。2点之繞はJ字形でも使われているので、問題ないと思います。実際、メイリオなどもuf99aは2点之繞にしています。
      • それについてはちょっと考える必要がありますね。 --johotogoshinentai 2013年3月23日(土) 15:59

  • (インデント戻る)だからそもそもuf99au9023には「差」がないんでしょう!韓国ではu9023も二点之繞でしょう。K0-5627は確かに二点之繞になってますよ。GlyphWikiにグリフもありますよ(u9023-k)。このグリフはuf99aと互いにエイリアスですよ!そりゃそうですよ“読み方”が違うだけなんですから。意図された字形の差なんてあるはずがない。差がないのに、「差として反映される」って、一体どういう理窟なのですか。johotogoshinentaiさんは韓国の方でしたよね。韓国のフォントではそうなっていないのですか?
  • すみませんが、私はこの辺りでひとまずこの議論を離脱します。好んで編集合戦をする気はありませんが、当面この一連の問題について独断的にリバートを通告されても関知しませんので、編集内容に問題があるとお考えならば皆さんで議論して結論を出し、ガイドラインに成文化してください。私の編集のやり方はその段階で考えます。これがGlyphWikiに相応しくないと判断されるならばBANしてもらっても結構です。
  • ノート:ufa5eにおける議論も収束はしていませんが、まとめてここで離脱を宣言します。ただ最後に最低限はっきりさせておくべきことは、互換漢字をエイリアス実体とすること、特に“排他的に”そのようにすることには私は複数のレベルで違和感を持っているということです。議論に集中していて曖昧なままになっていたのでここに記しました。以上です。--kirikaxfan 2013年3月24日(日) 19:45

    • ご指摘ありがとうございます。私の中途半端な説明で気分が悪くなりましたら本当に申し訳ありません… 私は慣習や慣用などを規則として定立しようとすると、見落としが発見されることが多いので…
    • 離脱を宣言しましたが、いったん改定案(?)を書いておきます。
    • 意図した字形に違いがあると:「その互換漢字がどんな字形の違いを目的として符号化されたかを重点にする。(仮想)J字形で使われているデザインなら、その差も反映する。使われていないと、その差は反映しない。」
    • 意図した字形に違いがないと(主にKS X 1001の重複漢字):「できるだけ元の字形を反映する。ただし、(仮想)J字形で使われているデザインだけを反映する。」
    • これで良いでしょうか。 --johotogoshinentai 2013年3月25日(月) 01:34

      • 私が前段に書いた内容論の表現はレトリックです。口語的な表現の方が焦点の置き方が分かりやすいというのが根幹にありまして。許容範囲内とは思っていますが、攻撃的に見えたかもしれないので、その点お詫びしておきます。失礼しました。
      • 提案がなされていますが、この問題はかなり大きな問題、根本的な問題を含んで一筋縄にはいかないように思うので、私としては引き続き意見の表明を控えさせていただきます。申し訳ありません。--kirikaxfan 2013年3月27日(水) 09:21

UCSの地域+偏化変形グリフについて

vnpf-60838u7fdf-v02ufa1e-v03という引用をvnpf-60838u7fdf-02-var-002ufa1e-03-var-003と変更しました。これは、「-jv」の設置により「地域ソースは規格表で規定されているものに限る」という方針を偏化変形にも適用したためです。u7fdfufa1eにはVソースはないので「地域+偏化変形」グリフは登録できないと思います。しかし皆さんは今までは仮想地域字形として使われてきたかもしれません。

本来「偏化変形+地域」グリフの場合、規格表でその字形が規定されていません。また地域字形にあたるものを地域指定ではなく「-var-###」に持ってくると、「-var-###」が日本では使わないものが並んで濁ってしまうことも考えられます。仮想地域字形を規定するのは面倒ですし、どちらの方針にするか悩みます。

以上ご意見ありますでしょうか?--kamichi 2013年1月20日(日) 16:25

  • 部品グリフの例示ソース指定って、その欄で見受けられる部品の形状ではなくて、親字の特徴を引き継いだ部品を表すんですね。ソース指定と地域指定を別に用意するとしたら…しかし V 欄がベトナム字形の代表として妥当とも限らないし、或る字形を「ベトナムで通用している字形である」と認定するのは我々には中々難しいですね。
  • 連番で var をガンガン作っていくとしたら、ガンガン作ってもゴッチャにならないユーザーインターフェイスが欲しいものです。— sayunu 2013年2月2日(土) 19:06

白紙化の抑制について

異論も多いと思いますが、実運用で気になったので、明確にできればと思います。重複しているグリフの白紙化をどうするか、という問題はこれまでにも出てきました。これまでは意味のある重複は白紙化せず、「-itaiji-###, -var-###」に多く見られるただの重複については、白紙化を否定せず、ということでした。グリフウィキ上ではこの方針で構わないと思うのですが、実際にWebでグリフ画像を引用している場合に白紙化されてしまうと非常に面倒です。ですので、今後は「間違い等ではない限り、重複グリフを白紙化しない」という方針に転換したいと思います。同時進行で命名ガイドラインから命名ルールへの移行も想定しているため、それほど混乱は起きないと思います(結局「itaiji, var」あたりで番号を自由につけられる関係上、重複が発生しやすい。そのうち無法地帯になる可能性もある。他の命名を行ったグリフについては「itaiji, var」を作成しない、というルールも必要か)。コメントありましたらお願いします。--kamichi 2013年1月1日(火) 15:43

  • とりあえず、それでよいと思います。— sayunu 2013年1月12日(土) 01:33
  • 異体字グリフ「-itaiji-###」「-var-###」についての白紙化しない件、了解しました。
  • ちなみに、過去に白紙化されてしまったものに関しては、如何致しましょうか。もし、白紙化を今後行わないと言う方針に決定した場合、過去に白紙化されたものに関しましても異体字連番の欠落状態を解消する為、白紙化異体字グリフを復活させた方がいいのでは…と思いました。
    特に異体字作成の際、表示されている異体字番号の次の番号でグリフ作成しようとしたら、以前に白紙化されていた(例えば「uxxxx-itaiji-001」「uxxxx-itaiji-002」が表示されており、「uxxxx-itaiji-003」を作成しようとしたら、実は「-003」は以前に白紙化されていた)と言う事に幾度か遭遇しましたので、少々気になっておりました。--kamiyo 2013年1月12日(土) 11:05
  • 「間違い」には,varとitaijiの使い分けミスも含まれるのでしょうか? やはりUnicodeで包摂されるかどうかはきちんと運用されるほうがよいと思うので… なお,私はitaijiで表現されているグリフをIDS表現に直すことがありますが,その場合でも元のitaijiはエイリアスとして残すようにしています。--spinda-kkmr 2013年1月12日(土) 11:08
    • 難しいところです。個人的には「間違いによる白紙化の是非」は「間違いの種類」ではなく「間違ってから戻すまでの時間」によると思います。つまり、気がつかずに放置してしまった間違いを長い時間が経ってから白紙化するのは望ましくない、という意味です。システム上「削除」を「0:0:0:0」で判定しているので難しいのですが、白紙化するのではなくu342c-02@3のようなやり方もあるかなとは思います。ということで登録時に間違えて、というものはすぐに直せるので白紙化許容とし、時間が経ってしまったものはまずはノートで議論、ある程度問題となるケースの種類がしぼられてきたら再度ルール検討、でいかがでしょうか。あと、白紙化したものを連番で間違えて復活してしまう件はシステム的に補助できないものかと考えます。--kamichi 2013年1月22日(火) 17:21
  • 改めて考えましたが、画像が外部から参照された場合については白紙化直前のバージョンを返すという事は出来ないんでしょうか。ウエブ上で参照できる個別のリソースとしては URL が変らないのが望ましいですけど、データベース全体としては常に最も整理された最新の状態であってほしいですよね。
  • これまでの私の暗黙の方針では、「-02」「-07」などの部品グリフは自立グリフと違って部品専用だから、外部から参照される事などは考えずに、内部的な部品としての使い易さだけを重視して整理・改名していました。どうなんでしょう。— sayunu 2013年2月2日(土) 18:17
    • sayunuさんの意見に賛成です。本来varを使うべきものにitaijiが使われている例が存在するので,そのようなグリフはきちんとvarに移動したうえで白紙化するのが望ましいと考えております。白紙化されたグリフは白紙化直前のバージョンを出すようにすれば,データベースとしての正しさとグリフの安定性を両立させることができます。あるいは,「管理者または他の利用者の判断により白紙化されることがあります。確実にグリフを指定したい場合はバージョンを指定してください。」と注意書きを載せれば,とりあえずは大丈夫だとは思います。--spinda-kkmr 2013年2月2日(土) 18:54

「白紙化の抑制」はこの議論にて事実上の規定事項になったと考えられますが,最近は「作成時点ではUnicodeに無かったが,現在はあるIDSグリフ」がUnicode命名を実体グリフにしたうえで(IDSを)白紙化されています。Unicodeグリフを実体にするのは当然としても,白紙化抑制の考えからすればIDSグリフはエイリアスグリフとして残しておくのが順当と考えられますが,皆様のご意見をお願いいたします。--spinda-kkmr 2019年2月16日(土) 10:44

  • 上記意見を書き込んだにも関わらず,IDSグリフの白紙化が進んでいるようです。確認と意見の書き込みをお願いします。特に管理人のkamichi様にはなるべく早期の意見表明をお願いいたします。--spinda-kkmr 2019年2月17日(日) 10:31
  • 反対です。そもそもIDS表記は文字コードに存在しない文字を表現するためのものなのでUnicodeに存在する文字をIDS表記にすることは望ましくないと思われます。(もっとも、互換漢字をIDS表記に使うことも望ましくないのですが。)--kesuuko 2019年2月18日(月) 21:21

  • 意見表明が遅くなり申し訳ありません。この件については、2つの対立する考え方があると思います。それで、白紙化抑制の方針を考えたときの一番の目的は、グリフウィキ上の登録グリフが整理されていない状態よりも、外部Web上でグリフを利用(引用)しているユーザーおよびページ閲覧者に対して、白紙化でグリフが真っ白になってしまう混乱を避けること、でした。現在、グリフウィキは大量のグリフが登録されていて、できれば無秩序状態を整理したいというのはコアユーザーの1つの意見だと思います。またIDSグリフは最も字形揺れが大きい(各UCSパーツごとに字形差が存在する)ので、もしそれが既存UCSグリフ等にマッピングできるのであれば積極的に移動させたいと思うことも理解できます。それで、以前sayunuさんの提案にあった、白紙化しても最終グリフが画像引用の場合表示される案を参考に「白紙化したグリフはページとしては白紙化される。画像を要求した場合は、グレーアウトした最終版グリフ画像が得られる」としてはどうかと思います。この場合、グリフを見たいというとりあえずの要求は維持できると思います。内部処理で1つ問題があるので、少し時間をかけて実現できるか検討したいと思いますが、よって今後は「グリフ白紙化を抑制しない」という方針変更も併せて提案いたします。以上いかがでしょうか。割と大きな方針変更なので少し広く意見を求めます。--kamichi 2019年2月21日(木) 12:00
    • 「Unicodeに収録されたIDSについては白紙化対象としてもよい」が現在のGlyphWikiの方針であるということで認識しました。今後はそれに従います。
    • なお,白紙化グリフについて外部から画像の要求があった場合は白紙で無い最も新しい版が得られる機能については,なるべく早くの実装をお願いいたします。現時点では「確実に字形を指定したい場合はバージョン指定をする」ことを周知すればよいと思います。
    • 以上,--spinda-kkmr 2019年2月22日(金) 21:28

古琴減字譜(GEOG-QIN)の命名規則について

古琴減字譜「geog-qin」のグリフと、減字譜を先日から少々調べていたのですが、現状追加出来ていないグリフが有るものの、現在のグリフ名の付け方の場合ですと、追加が困難であり、改番をした方が良さそうに見受けられました。
そこで「geog-qin-#####」から「qin-#####」へ移行する際、グループ:kamiyo_temp@2の様なグリフ命名規則に変更すると、追加が容易になるかと思われますので、命名変更の提案をさせて頂きたいと思います。如何でしょうか?--kamiyo 2012年12月16日(日) 01:24

  • 賛成です。ですが、もともとの作成者の方がこのドキュメントを見ているかどうかが気になります(仕方ないですね)。あと、現状のグリフについている関連字というのは妥当なのでしょうか?--kamichi 2012年12月29日(土) 23:47

  • 関連字についてですが、現状は呼称が漢字1字の記号は、
  • (「蠲:geog-qin-0160」→関連字「蠲」、「剔:geog-qin-0030」→関連字「剔」 など)、
    その呼称を関連字として割り当てられており、呼称が漢字2字以上の記号は
    (「撥剌:geog-qin-2016」→関連字「撥」、「滾拂:geog-qin-0580→関連字「滾」、「挑四弦:geog-qin-0014」→関連字「挑」、「大指当十二:geog-qin-1112」→関連字「大」 など)
    呼称1文字目を関連字として割り当てられおり、「関連字」としては妥当かと思います。但し問題は、記号によって(特に「大」「中」「名」など)80個近くが同じ関連字に割り当てられており、(減字譜以外)他の漢字(国字、字喃等含む)異体字グリフを探す事が少々困難になっておりますで、減字譜(geog-qin)に関しては関連字を外して、グループ:古琴減字譜(又はこのグループの派生グループ)にグリフを貼付する事で、これ等を解消すると言うのも良いかと思われます。--kamiyo 2012年12月30日(日) 13:40

  • 次はこのグリフ群の新命名への移行に着手したいと思います。--kamichi 2013年2月11日(月) 13:42
    • (done)新命名での旧命名へのエイリアスをはる(グループ:kamiyo_tempに沿って。一部新たに追加されたグリフも対象)
    • (done)エイリアスの向きを逆転
    • 引用部品名の更新
    • 白紙化(geog_にコピーするか要検討。いらないのでは?)

  • 関連字についてはメタ情報に記述し、関連字自体を削除したいと考えます。2、3個の記述で良いと思います。呼称、組み合わせの文字群、などでしょうか。--kamichi 2013年2月11日(月) 14:11

  • Hello! Sorry that I'm not familiar with Japanese and not certain if this is the correct way to join in the discussion. I was tied up and have put down the creation of qin tablature for a while. Thank you very much for Kamiyo's suggestion. I have to admit that my project is a evolving one and could have a better rule. I would like to join in this discussion with a view to creating a set of open source qin tablature characters. --Daniel(利用者:geog) 2013.3.11-0357GMT+8

GやTやVソースの字形を忠実に再現することに関して(再考か否か)

現在、以下のデザインはデザイン差としてグリフウィキでは認めないとしています。個人的に見つけ次第強めに排除しているつもりです。

  • 折れのカーブ
    • 不可:u533b-t@1
    • ガイドライン:普通に「折れ」を使う(u4ea1)

  • Tデザインの口右下
    • 不可:横棒が飛び出る
    • ガイドライン:普通に右下角を使う

  • Gデザイン「入」の入り
    • ガイドライン:「細入」を使う(c1-442b)※将来的に改善対象

ですが、戸籍統一文字や登記文字を見ていて、迷っています。この方針に関して意見のある方は教えてください。なお、私が拒絶する理由はたとえばTデザインの口を許容すると、あらゆる「口」を含む漢字が単純2倍になってしまう、と感じるからです。--kamichi 2012年3月29日(木) 21:19

  • 私の案としては以下のとおりです。
    • Gソース,Tソース等の字形は,上記のガイドライン通り一定のルールのもとで再現する。
    • 戸籍統一文字,住基ネット統一文字,登記統一文字(以降,行政系文字コードとする)は可能な限り忠実に再現する。ただし,戸籍統一文字は必ずしもデザインが整ってはいないので,見た目を良くする程度の差異は許容する。
  • 行政系文字コードを正確に再現すべきと考える理由としては,行政系文字コードには包摂・統合の概念が無く1つのコードに対しただ1つの字形が存在するためです。
  • また,大規模文字セットであるGTコードについても,GT書体は若干クセのある字形ですので,グリフウィキでどう扱うかを考えるべきだと思います。たとえば,GTコードでの「好」の字(gt-07641)はsandbox@996のようになっており,u597dとは女偏の形が異なっております。しかしGT書体は画数を明確にするために恣意的に通常の明朝体とは字形を変えてある場合もあり,必ずしも厳密に再現すべきかどうか判断に迷うところです。gt-12636u5f71のように,接触・非接触の違いの場合は再現すべきと考えますが,女偏のように部首全体の字形が異なる場合は,デザイン差としても構わないと思います。ただし,GTコード自体には包摂の概念はありません。
  • なお,GT書体の一覧は,こちらのサイト で公開されています。
  • 以上,--spinda-kkmr 2012年3月31日(土) 12:36
  • 追記。GTコード系のフォントではJIS第1・第2水準の文字に対しUnicodeの配置通りのフォントが作成されています(他の文字はシフトJIS領域に対し別の字を割り当てている)が,たとえばsandbox@996(gt-07641)はu597dに割り当てられています。--spinda-kkmr 2012年3月31日(土) 12:44
  • GT書体の字形について分かりやすくまとめますと,「部首全体の字形が異なる場合はデザイン差とみなす」,「その他の字形の違いはなるべく再現する」ということです。--spinda-kkmr 2012年4月7日(土) 19:24
    • GT書体は確かに難しいですね。ですが、住基や戸籍などの例も踏まえると忠実に再現したいという要求に対しては否定できないかと考えます。ある程度共通理解が取れるようであれば「デザイン差」のルール化で対処するということでいかがでしょうか。

  • 話が飛んで恐縮ですが、Tソースの「口」の形状を許容する方向で考えています。ただし、KAGEシステムの思想として右下角の縦棒と横棒の末端がデータ上接続していないというのは許容できませんので、T型右下という形状を追加してから、と考えています。--kamichi 2012年4月24日(火) 08:35
    • 3年間止まっていますが,いまchanhenryfaihangさんがTソースの「口」の形状を作成して,umbreon126さんに白紙化されるというやりとりをしています。いまも方向性が同じなら,T型右下の早期実現が望ましいです。他にもGlyphWiki:ソフトウェアへの要望に要望が出ています。 --ziyang 2015年4月8日(水) 22:02

  • had a try to imitate G source 捺 stroke with visible beginning: u5165-var-001 u516b-var-002. 細入り conforms neither of them, also these two are different. one might be named 半細入り(for G 入, 內, etc) and the other might be 開放半細入り(for G 八, 公, 分, etc). furthermore, observing existing japanese fonts, 捺 strokes other than 乀乁, for example J source u516c u5206, looks like 半細入り, not 細入り which is only for 點. hope that these will be added into KAGE. farter 2015年8月18日(火) 16:50

仮想J字形が戸籍統一文字のエイリアスとして作成されている件について

匿名利用者の方が“u####-jv”“u2####-jv”のグリフを“koseki-#####0”のエイリアスとして作成してしまっています。私はこれは望ましくない(“koseki-#####0”と“u####-jv”が同じグリフなら,後者を実体にすべき)と考えますが,意見をお願いいたします。--spinda-kkmr 2012年1月23日(月) 20:57

追記。上記の結果,同じコード位置の“u####”と“u####-jv”が別のグリフとして存在してしまっているものがあります。私はこれも望ましいことではないと考えます。意見をお願いします。--spinda-kkmr 2012年1月23日(月) 21:01

  • 理想的には、「エイリアスと被エイリアスは上下関係なし」であり、でも「UCS符号位置がベースの方がしっくり」きます。あと、字形が安定している方がベースの方が管理しやすい(そういう意味ではkoseki-の方が安定しているか?)と思います。本来はエイリアスと被エイリアスを入れ替える機能を早く作るべきなのですが、手間取っています。建前上、矛盾する上記2つの理想が、ルールと考えることに同意いただけるようでしたら明文化してもいいと思います。--kamichi 2012年1月23日(月) 21:35

  • UCSとJVの件についても、JV計画が宙ぶらりんになっていて申し訳ありません。早く無印UCSの編集をストップしてJVに移行したいのですが…--kamichi 2012年1月23日(月) 21:35

    • グリフウィキではUCSのコード位置で関連字や異体字を管理しているので,“u####-jv”や“u####-var-###”“u####-itaiji-###”が実体で“koseki-#####0”や“juki-####”がエイリアスのほうが分かりやすいというのが私が上記の意見を書いた主な理由です。特に住基ネット統一文字(juki-####)は一般人は容易に閲覧できないので実体になっていると部品として利用するときに分かりにくくなります。

    • なお,エイリアスと実体の入れ替え機能は,是非とも早期に実現していただきたいです。

KAGE の肉付けについて(特に縦画起筆)

  • ここで話すべきか分かりませんが、ほかの場所も無いので…。以前から気になっているのですが、縦画起筆(開放形状)の右側に飛び出るウロコはもっと大きくしてはどうでしょうか。二倍か三倍ぐらいに。私の持っている主な明朝体を比べた画像を用意しました。
  • 明朝体エレメント比較
  • 字形デザインの差異も興味深いですが、個々のエレメントに注目して見比べてみると色々と思う所が有るでしょう。特に花園明朝は縦画起筆のウロコが非常に弱々しい事が分ります。遠目には存在に気付かないくらい。これを大きくした方がいいと考える理由は次の通りです。
    • ほかの明朝体で組まれた文章中で、足りない字だけ花園明朝を使う様な場合、エレメントが似ていた方が溶け込み易い。
    • 縦画の接続・開放まで作り分けているグリフウィキにおいて、その違いが縮小した画像でも見分け易い。
    • ウロコを付ける以上、ちゃんとした大きさの方がカッコいい。
    • グリフの編集中、「拡大しているのだ」という事を思い出し易い(実寸の積もりでデザインしてしまわない)。
    • 肉付け処理の改変が恐らく比較的容易。
    • 大した副作用が予想されない。
  • 御検討願います。— sayunu 2011年6月10日(金) 14:37

  • ありがとうございます。検討します。もともとは、これ以上縦画起筆ウロコを大きくすることは直線ポリゴンでは変だ、ということで躊躇していました。試行して調整したいと思います。--kamichi 2011年6月21日(火) 09:04

命名するときのローマ字表記について

グリフウィキでは、普通にはヘボン式ローマ字を使っていますけど、たまに訓令式や日本式ローマ字も見えます。

なので、命名ガイドラインに、「グリフに名前を付けるときには、特別な場合ではなければ、必ずヘボン式ローマ字を使うべきだ」という事項を追加すればいいと思います。この人はヘボン式を使ったり、あの人は訓令式を使ったりして混乱が生えればダメだと思います。

訓令式や日本式は発音にも合わず、事実上よく使われていません。(誰が「ti」を「チ」と読みますか。tiが「チ」なら、「ティ」は?) 訓令式や日本式は日本語の文法や音韻を教えるときにはいいかもしれませんけど、グリフウィキはそんな場所ではないので、訓令式や日本式を使う理由は全然ないと思います。--johotogoshinentai 2010年12月30日(木) 02:27

  • いくつかコメントがありますが、結論から言うと、複数の方々の共通の認識が確立される前に「削除」や「移動」するのはちょっと問題があります。
    • まず、今回johotogoshinentaiさんが更新されたkikko関係のグリフは正式なグリフとして管理をしているものではありません。1つの参考として「命名ガイドライン」に載っていないものは私的なグリフと考えてください。つまり、その命名で使いたい人がいる、ということで、その命名を尊重してください。
    • 2つめに、確かにヘボン式ローマ字が事実上の標準ですが、一部の方々や組織ではヘボン式以外のローマ字を使っています。これは一種の文化ですので、尊重する必要があります。
      • 日本語は良い意味でも悪い意味でも正書法が定義されていない言語だと私は認識しています。
    • 3つめ、あまり関係ないですが、私は文字を打つ時は「ち」を「ti」で打ちます。「てぃ」は「thi」です。これはIMEに私が合わせていることになりますが、このことによりそれほど違和感は感じません。もちろん「ち」をローマ字で書くときは「chi」です。

ということで今回の件、移動してしまったグリフについては、もともとの作成者のご意向に委ねたいと思います。基本的にグリフウィキは「登録した人のニーズに合わせる」ポリシーですので他の方が強制的に変更するというのは望ましくありません。ご理解をよろしくお願いします。(下に続く)--以上はkamichi 2010年12月30日(木) 12:21

4つめ

本来はこの話とは切り離して考えるべきですが、このように私的なグリフの命名を勝手気ままに認めると、ユーザーが増えた時に混乱すると思います。その意味でjohotogoshinentaiさんのご指摘は正しいと思います。グリフウィキの設計をするときはとにかく「自由」を前面に考えていたのでこのような「ルール無し」となりました。現状では命名ガイドラインに沿っていないグリフは少ないので、ルールを変更するのであれば今がチャンスかなとは思います。私が考えているルールは次のようなものです。

  • 命名ガイドラインに載っていない命名は認めない
    • ユーザー占有グリフ(kamichi_****)として作る分はルール無し
  • まとまった集合については、命名ガイドラインへの追加申請を認める。申請時にはその集合の概要を説明する必要がある--以上kamichi 2010年12月30日(木) 12:22

    • 自由な命名ができなくなってしまうとtokyo23city-04-shinjukufukuoka-ward-02-hakataが使えなくなるので困ります。私は今後も少しずつ組み文字を作成しようと思っているのですが,組み文字を“kumimoji-u####-u####-u####”のまま扱うのは非常に厄介なのでエイリアス名を付けています。占有グリフにしないのは,他の方が利用できるようにと考えてのことです。もし自由命名が禁止された場合,組み文字の管理が厄介になりそうですね。組み文字はグリフウィキの本来の目的ではないので,やむを得ないのかもしれませんが… --spinda-kkmr 2010年12月30日(木) 18:54
    • 追記。もし自由命名が禁止された場合,ouichizaのように,どの文字コードでもコード化されていない文字はどのように扱うのでしょうか? --spinda-kkmr 2010年12月30日(木) 19:10

  • ご意見ありがとうございます。おそらく、「グリフ」の自由命名に制限ができる代わりに、集合を冠した自由命名(定義)で対処することになると思います。できれば接頭辞に限定したいところではありますが、たとえば「tokyo23city-」は東京23区向けの命名、といった感じです。大きな制限をかけるというよりも、必ず何かの集合の一部にしてもらうというやり方を考えています。ouichizaはいろいろ考えられますが「画数の多い漢字」など考えられると思います。これらの集合は命名ガイドラインというよりも「集合リスト」というグループページに記述していく感じです。以上いかがでしょうか。--kamichi 2010年12月30日(木) 19:55

    • つまり,「無秩序に命名することは禁止するが,各自で一定の接頭辞を作ってそれを使う事は許容する」ということでしょうか? --spinda-kkmr 2010年12月30日(木) 20:31

    • はい、「無秩序に命名することは禁止する」、「各自で一定の接頭辞を作り、その意味を記述する。問題があれば事後審議」というのが大枠です。--kamichi 2010年12月30日(木) 21:47

    • ただし、今先にやるべきことがいろいろあるので、すぐに試行(施行)というわけではありません。3月末までの間にこれも含めて進めたいと考えます。この制限自体の是非も含めてご意見お願いします。--kamichi 2010年12月30日(木) 21:47

  • 少し議題とずれますが、僕が前から気に成つてた事に、「先に命名したもん勝ち」と言ふものが有ります。此僕の所謂命名の先取性と自由命名性との組合せから考へられる主な弊害は、例へば、tokyo23city-04-shinjukuと云ふ符号は、既に「新宿」が左、右の順に並んでゐるので、

    • 【一】「新宿」を縦に並べたい人がゐても、別の命名を考へねばならない。

    • 【二】「新」の字形をu65b0-var-001にしたい人がゐても、別の命名を考へねばならない。

    • 【三】tokyo23city-04-shinjukuで「文京」を組んだり、sandbox@537taitoと命名したりする事も出来るし、誰かに然うされた場合、誰も其符号は嬲られないので、変であると思つても直されず、残続ける。

  • と云ふ者が有るかと思ひますが、此の点に就て皆さんは何う考へて御出ででせうか。――lizard 2010年12月30日(木) 23:11

  • ある意味「厚かましさ」に依存しますが、グリフウィキは「先取」とは言い切れないと思います。つまり後から登録しなおしたもの勝ち、ということです。また、バージョン番号を併記することで共存も可能と考えます。結局本件は突き詰めると問題の対象が「グリフ名」から「接尾語」に移るだけではあります。ただ、ある種の集合に属する、というメタ情報的な要素が1つ増えるだけでも運用しやすいのではないかと思います。みなさんいかがお考えでしょうか。--kamichi 2010年12月30日(木) 23:37

  • まづローマ字について、私は日本式に似た規則を普段使っていて、チは「ti」です。(ちなみにティは「tĕi」です。)ローマ字は「表音記号」ではないし、johotogoshinentai さんはラテン文字の言語を英語しか知らないんぢゃないですか ? 言語学の論文などでは日本式の様な表記(音韻表記)を取る事が多いですから、それに近接した学術的文脈に在るグリフウィキでそれを用いるのも無理は無いです。
  • 全く自由な命名は私も問題が有ると思っていました。実際、ガイドラインに沿わない命名のグリフが匿名利用者によって一個や二個作られても、意図が不明というのも有って削除されていたし。定義された接頭辞が必ず付いて、名前空間が限られる様になると扱い易いでしょう。
  • 接頭辞を定義する際に或る程度は慎重さが必要だろうと思います。その下位の命名規則も決めるべきでしょう。「tokyo23city-」だったら、縦書きも横書きもこの下位に置けると定義した上で、例えば縦書きは「tokyo23city-04-shinjuku-ttb」とするとか。(「ttb」は「top to bottom」の略で、「ltr」や「rtl」と共に CSS なんかで使われる表現です。)
  • そもそもその地名の組文字を何に使う為に作ってるのか不明なのであまり踏み込めませんが、地名の組文字を表す上位の接頭辞を定義したらどうです ? ついでながら、東京 23 区なら「city」より「ward」では ? — sayunu 2010年12月31日(金) 17:51
    • tokyo23city-04-shinjukufukuoka-ward-02-hakata等を作成した本人からの提案ですが,自治体名・区名の組み文字のエイリアス名を“autonomy-#####-xxx…”とするのはどうでしょうか(実体グリフは必ず“kumimoji-…”を用いる)。#####にはJIS X 0402で定められる5桁の市町村コード,xxx…には自治体名・区名をローマ字で入れる,というのはどうでしょうか? 例えば“autonomy-13104-shinjuku”,“autonomy-40132-hakata”などとなります。これで複数の接頭辞を1つにまとめられると思います。縦書き・横書きについては,横書きをデフォルトとし,縦書きは末尾に“-vert”を付ける,などが考えられます。
    • また,極端な意見かもしれませんが,組み文字は面倒でも“kumimoji-…”を使った名称でのみ管理する,という方法もあるかもしれません。組み文字はグリフウィキの本来の目的ではないと私も考えているので,これも1つの案として検討する必要があるかもしれません。
    • なお,私が東京特別区に“ward”ではなく“city”を用いたのは,東京特別区自身が「区」の訳語として“city”を用いているためです。
    • 組み文字とは関係ありませんが,自由命名はouichiza等の,文字コードを割り当てられていない文字に限る,というのはどうでしょうか。
    • 以上,--spinda-kkmr 2010年12月31日(金) 19:13
  • 取り消し線で抹消した部分の提案を撤回いたします。申し訳ありません。
  • 私が作成したグリフのせいで皆様に迷惑をかけているようなので,“tokyo23city-…”をはじめとする区名組み文字のエイリアス名は,2011年2月末をメドにすべて削除(白紙化)します。今後は“kumimoji-…”を直接扱います。
  • 以上,--spinda-kkmr 2011年1月1日(土) 19:16

  • 政令組文字グリフについてですが、全く迷惑でありませんので白紙化については再考をお願いします。この件はやや私が性急に過ぎた感がありますので、もう少しじっくり考える、また、あまり縛りをかけずに少しずつルールを決めていくという感じで進めたいと思います。--kamichi 2011年1月1日(土) 20:01
  • これまでの議論に出たように、縦に並べるか横に並べるか、それ以外か、などの情報はあるといいと思います。おそらくフォントの文化からして基本的には横なので、縦の場合にvertに相当する情報を名前に入れるのが妥当と思います。横は冗長なので情報なしでいいのではないでしょうか。あと長くなるので組文字のIDS化は私は好ましくないと思っています。--kamichi 2011年1月1日(土) 20:01
    • 了解しました。白紙化については再考いたします。もう少し議論が深まるのを待とうと思います。--spinda-kkmr 2011年1月1日(土) 20:12

既存グリフの字体の変更について(匿名ユーザー・登録ユーザー)

  • 今般、既存グリフの字体の変更が多々行われ、字体に関する議論および移行が進んでいない中で、もったいない状況にあると思います。登録ユーザーの場合は利用者-会話ページで呼びかけることができますが、匿名の場合、リバートした際のサマリーに書くのがせいぜいです。(つづく)
  • かといってシステム側で制限するのは本意ではありません。しかしいくらか制限を設けるべきなのかもしれません。この議論はすでに提議されていて、私は「トラブルドリブン」と書きました。今がその段階のような気がします。(つづく)
  • 原因となるUCS符号位置の抽象性を排除する作業を急ぐという考え方もあると思います。再度のお願いになりますが、皆様のご意見をいただきたく思います。(つづく)
  • たとえば「匿名ユーザー、登録ユーザーに対する機能制限(機能削除)を設けるべきか」「UCS符号位置グリフの抽象性の排除に関して、すぐに実行できそうな対処法」あたりについてコメントがあればお書きください。--kamichi 2010年10月24日(日) 10:10
    • エイリアスグリフのエイリアス対象のデータ更新時の扱いも議論すべきかもしれません。--kamichi 2010年10月24日(日) 10:20
  • 「勿体無い」と云ふのは、小生も同感です。エイリアスの実体となつてゐるグリフを更新した際に、「以下のグリフで参照先となつてゐますが、同時に更新しますか」の様な文言と選択肢が出て、「○×は更新」「一括更新」をチェックすると選択した者が更新、「更新しない」を選択するとエイリアスは旧版を参照し続ける(或いは旧版の自動的な実体化が成される)と云ふのが有ると当面は便利であると存じます。或いは投稿前の画面に「字形を変更」と云ふチェックボックスを設け、エイリアス実体グリフの編輯を投稿する際に此にチェックすると、自動的にエイリアス先の更新はしない(或いは実体更新前版の自動実体化が成される)と云ふ機能が当面は便利であると存じます。―lizard 2010年10月24日(日) 13:25
  • 匿名利用者に既存のグリフを大量に書き換えられてしまうのは違和感を感じます。UCS符号位置の字形の方針が固まるまでは,「部品グリフを別のグリフに置き換える」機能の匿名利用者に対する利用制限を設けることもやむを得ないと考えます。この機能は大量のグリフを一括で変更してしまうので,影響が大き過ぎます。--spinda-kkmr 2010年10月26日(火) 19:07

「縦払い」ストロークで3つの点が並ぶ現状について

縦払いストロークは、初めの3つの点が1直線に並ばないとポリゴンが切れる不具合があります。この解決方法として

(1)常に1直線になるように固定する(2点目のX座標は無視する) (2)直線部分と曲線部分が切れないようにする(直線部分の末端に丸ポリゴンを置く)

の2つがあると思いますが、デザイン上(1)の1直線に「ならない」ケースは存在するでしょうか?するのであれば(2)にすべきですし、存在しないなら(1)にしたいと思います。--kamichi 2010年8月9日(月) 22:39