GlyphWiki logo
navigation
help
search

toolbox
languages
articlediscussionedit this pagehistory

GlyphWiki:井戸端-保存

From GlyphWiki, the free glyph database

Contents

以下、保存用です。編集はご遠慮ください。

2009年〜2012年の分についてはGlyphWiki:井戸端-保存2012年までをご覧ください。

2013年〜2014年の分についてはGlyphWiki:井戸端-保存2014年までをご覧ください。

2015年〜2016年の分についてはGlyphWiki:井戸端-保存2016年までをご覧ください。

2017年〜2018年の分についてはGlyphWiki:井戸端-保存2018年までをご覧ください。


ユーザー専用グループでのフォント生成について

ユーザー専用のグループでフォント生成をした際、ダウンロードすると反映されていない文字がいくらかありました。これって何かの仕様ですか?それともバグですか?初心者で何もわからないので教えてください。--koko-kanji 2023年12月20日 17:37
  • Group:koko-kanji_itaiji@25のことであれば、おそらく「\n」が存在することが原因だと思います。見映えの問題については、空行(何も書かれていない行。改行を2つ続けるとできる)を設けることで改善すると思います。--kesuuko 18:05, 20 December 2023
    • 教えて頂きありがとうございました!解決頑張ります!--koko-kanji 2023年12月20日 23:07

拡张Iの質詢

拡張Iは9月13日に正式に発表されましたが、現在このことをしている人はいますか?--fitzgerald 2023年9月14日(木) 18:50

  • 「している」とは?--kamichi 2023年9月15日(金) 09:08
    • 私も詳細はよくわかりませんが、「Ext.Iの漢字の作成」のことであれば、現在そのような作業を行なっている人はいません(システム上、Ext.Iの漢字は現在作成できません)。--kesuuko 09:26, 15 September 2023
    • 「unstable-(Ext.I)」からの移設はこれから行います。参考:Group:ExtI-final

白紙化を要求sandbox@21880

このGlyphに含まれる内容は粗野で冒涜的な言葉が含まれています。--fitzgerald 2023年9月14日(木) 18:50

  • 本来はGlyphWiki:削除依頼に書きこみをお願いします。とりあえず対応しました。お知らせありがとうございました。--kamichi 2023年9月15日(金) 09:08

文字のライセンスについて

GlyphWiki:データ・記事のライセンスを閲覧した上で質問させていただきます。

このWiki上のグリフを、色の変更などの編集を施し、クレジットを明記した上でCC BY-SA 4.0を使用した他サイトにアップロードすることは可能でしょうか。--kankitsu-777 2023年7月16日(日) 14:02

  • すみませんが、お答えできません。ご自身で判断ください。あるいはご利用をお控えください。--kamichi 2023年7月16日(日) 19:10

About the naming of glyphs from 汉字海

I recently bought a dictionary named 汉字海 and I am currently thinking about registering glyphs from this dictioanry. Could I use the prefix kanjikai?

(最近我买了一本叫“汉字海”的字典。现在我想把其中的字形注册。可以使用前缀kanjikai吗?)

I plan to register glyphs named like kanjikai-xxx, where xxx is the the serial number of that character in 汉字海. For example, kanjikai-351 will be sandbox@20314.

P.S. I'm not very familliar with Glyphwiki, so be free to correct any mistakes. -mjzsl123 2022年11月26日

  • 一度言及した気がするのですが、prefixはそれで良いとして、IDの桁数が変わるとグリフ名の長さが変わるのは困るので、kanjikai-NNNNNNにしてください。--kamichi 2022年11月26日(土) 20:25

    • 汉字海 also includes an appendix, and the characters there do not have serial numbers. Is it valid to use the expression kanjikai-apdxNNNNN? --mjzsl123 2022年11月27日(日) 13:50

      • We decided not to add these characters in the appendix, because they are all included in the UCS. Characters are kept in the appendix because the authors don't know their meanings. --mjzsl123 2022年11月29日(火) 10:18

グリフ作成について

「GlyphWiki:グリフを登録する」ページには、新しいグリフを登録できると記載されていますが、新しいグリフを登録する方法については説明されていません。新しいグリフを登録する手順は何ですか?具体的には、新しいユーザー占有グリフを登録する手順は何ですか?例えば、「glypc_2005」というグリフを作りたい。どうもありがとうございました!

  • よくお読みになってからご利用ください。「GlyphWiki:グリフを登録する」→「グリフ登録ページを開く」→「まったくゼロの状態からグリフを登録する」--kamichi 2022年6月29日(水) 09:05

  • どうもありがとうございました。大変申し訳ございません、この項目を見落としておりました。

KPS10721

http://cheonhyeong.com/PDF/KP1-reconstitution.pdf (2022/06/25投稿)

APIについて

初めての井戸端です。現在試行中のAPIについてすこしお聞きしたいですが、 https://glyphwiki.org/api/glyph?name=dkw-12627 で返した関連漢字はどうやらdkw-12627と違うようです。APIで返されたデータはWikiより古いものでしょうか?--toyjack 2022/2/15 21:33
  • 古くありません。グリフがエイリアスで、「related」が"U+3013"である場合、関連字に特別の指定なしということで、エイリアス先のグリフの関連字がそのまま引き継がれる、と解釈します。ですので、本件の場合エイリアス先の「u22cc6」で再度APIを叩き、「related:"U+22CC6"」を得る必要があります。--kamichi 2022年2月16日(水) 08:05
    • なるほどです!ご教示どうもありがとうございました!--toyjack 2022/2/16 20:50

赤バツについて

もう一度ほとんどのイメージは赤バツになっています。サーバーのバッグでしょうか。今は作字が全然できなくなりました。困っています。早く修復してほしいです。お願いします。--sim-ch 2022/1/23 0:26
  • 前にもお知らせしたと思いますがバグではなく(おそらく心無い人の所為による)サーバ高負荷によるサービス不能状態になっています。定期的に排除するようにしていますので、時間を置いて状況をご確認ください。これ以上の対応は特定国・地域からのアクセスをすべて拒否するなどの極端な対応しかないと思っていますし、それはできないと思います。--kamichi 2022年1月23日(日) 18:40
    • もう一度こんな状況が発生しています。本当に困っていますけど…サーバー高負荷なんて、どうしてですか。もしかすると、ロボットのせいでしょう?--sim-ch 2022/1/25 1:46
  • ご迷惑をおかけしています。ログを確認していて、一つ私の認識と違う状況になっていたので、サーバの設定を変更してみました。まだ生じるようでしたらご報告をお願いいたします。--kamichi 2022年1月25日(火) 12:52
    • またご迷惑をお掛けして来ますけど、ただ今はもう一度、赤バツだらけになっています。このバッグはいつも夜1時ごろに発生します。前回は3時ごろ直りました。上地様の認識と違う状況って、具体的にはわかりませんが、もしご都合がよければ、夜1時ごろの状況をご自分でご覧ください。お願いします。--sim-ch 2022/1/27 0:46
    • グリフウィキは外部とつながっているゲートウェイサーバと、それにつながる内部ネットワークでWebサーバが動いていて、ゲートウェイサーバがリバースプロキシとして外部からのグリフウィキへのアクセスを内部のWebサーバに渡しています。深夜2時ごろから、リバースプロキシ側でpng画像へのリクエストに対して404エラーが大量に発生するのですが、それは内部のWebサーバにはログが残っていません。ということは内部のWebサーバに到達する前にプロキシ側で処理が終わっていると理解しました。なぜそうなるのかがわかっていません。てっきりプロキシ側でリクエストを受け付けすぎて、内部Webサーバがさばけずにタイムアウトするのかと思い、内部Webサーバ側の受け口(MaxClientsなど)を広げたのですが効果が無いようです。今の状況だと深夜2時に作業をするのが難しいのですが、近々機会が得られそうなので、その時に実際の状況を見たいと思います。--kamichi 2022年1月27日(木) 09:51

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

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

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

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

  • フォント生成に用いるベースフォントを更新しました。ベースラインがおかしい問題は解決していると期待します。現象(不具合)が続くようでしたらご指摘ください。よろしくお願いします。--kamichi 2023年6月21日(水) 21:19

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

最近、「中国京语词典」(词典㗂京中国)という辞書を購入したのですが、今まで何の接頭辞を使えばいいのか分からなかったのですが、他に良い意見はありますか?
--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
  • Group: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

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

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

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

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

おそらくそれだけです。

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

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

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
  • 我在上海,目前可以正常访问glyphwiki.org。--solidblock 2021年12月20日(星期一) 23:32

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

忙しいであろう鯖管さんにはいつもお世話になっております。前にも同じようなことを言った記憶があって重ね重ね失礼いたしますが、最近いくつか台語の字が追加された影響で一部表示できない文字があって困っている人がいるようです。(例: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様の言う方針転換とはGroup-talk:花園フォントにて議論された「古代文字(西夏文字・契丹文字等)の分離」と認識してよいのでしょうか。--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面の英数字」とはGroup: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が登録されてしまっています(Talk: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

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

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

sandboxについて

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

グリフウィキで共有したい漢字(文字)とは何か

  • もともとグリフウィキはPCで扱えない漢字をインターネット上で共有することを目的としていて具体的には学術性のある文字(文字そのものに、ではなく、扱う分野が)をイメージしていました。過去の字典や文献に出現する漢字、あるいは異体字がターゲットになります。このところ創作漢字やかなり近現代(第二次大戦以降)の用例字が登録されていて、後者は目的としては問題ないと思うのですが、どうしてもサイト維持の点で考えると、登録される文字が思想・主張や字義以上の意味を持っているとどうしても軋轢が生じてしまいます。今グリフウィキで使わせてもらっている固定IPアドレスは所属先から借りているもので、かつ他の用途にも使われています。このため、今後トラブルが起きた際にいろいろな迷惑がかかることを考えると「登録グリフの方針を変更する」あるいは「非力な外部サーバに移設する」などの選択肢を考える必要があると思っています。言論の自由も大事なのですが、もともとの目的は学術のニーズを満たす、ということがベースですので、それを維持することが優先だと思っています。皆様のご意見を頂戴したいと思います。--kamichi 2020年5月10日(日) 11:58

(なお、私が全く理解できない言語を自分の発言として載せることはできないので、申し訳ありませんがハングルへの翻訳はしませんでした)

  • (This is a machine translation. Welcome modifications)
    • What are the kanji we want to share on GlyphWiki
      • Originally, GlyphWiki was aimed at sharing Kanji that could not be handled on a PC on the Internet, and specifically envisioned academic characters (not the characters themselves to be academic, but the field to be handled). The target is the kanji or variant characters that have appeared in past books and literature. Recently, I think that the original Kanji (創作漢字 sosaku-kanji) and the characters used in modern times (since World War II) have been registered, and the latter does not pose a problem for the purpose. If there is more meaning than ideology / assertion or literal meaning, there will be conflict. The fixed IP address that I am currently using at GlyphWiki is borrowed from my office and is also used for other purposes. For this reason, considering that various troubles will occur when trouble occurs in the future, I think that it is necessary to consider options such as "change the registration glyph policy" or "remove to a weak external server". Freedom of speech is also important, but since the original purpose is to meet academic needs, I think maintaining that is a priority. We would like to hear from you.

  • (这是机器翻译。欢迎修改)
    • 我们想在GlyphWiki上分享什么汉字
      • 最初,GlyphWiki旨在共享无法在Internet上的PC上处理的汉字,并且特别设想了学术字符(不是字符本身,而是要处理的领域)。目标是过去书籍和文学中出现的汉字或变体字符。最近,已经注册了艺术汉字(創作漢字 sosaku-kanji)和近代(第二次世界大战之后)的实例,我认为后者并不是目的,但是就维护站点而言,将要注册的字符是不可避免的。如果含义比意识形态/主张或字面意义更多,那就会有冲突。我目前在GlyphWiki上使用的固定IP地址是从我的分支机构借来的,也可用于其他目的。因此,考虑到将来发生故障时会发生各种故障,我认为有必要考虑诸如“更改注册标志符号策略”或“删除到弱外部服务器”之类的选项。 言论自由也很重要,但是由于最初的目的是为了满足学术需要,所以我认为保持言论自由是当务之急。我们希望收到您的来信。

(ここからご意見をお書きください)

  • 今のところの私の意見ですが、少なくとも、現代の政治的な事項であっても造字され、流通した漢字は大事な資産と思いますので、サイトを一般のVPSサーバに移設することを考えています。予算の都合で仮想6コア、メモリ8GB、ですがストレージがSSDですし、ネットワークも今より良い環境になると思います。--kamichi 2020年5月11日(月) 14:01

  • 私見ですが、問題のもとになりそうな一部の(政治的な)字を除けば基本的に放置で良いのではないでしょうか。(いつぞやの草書風字がこれに入るかは知りませんが。)結局、上記の選択肢をとっても荒らしが湧かなくなるわけではないですし、問題のもとになるものが具体的に予想されているわけでもありません。 
 それと、話が変わって申し訳ないのですが、Unicodeのアプデで小書きの仮名も追加されましたし、そろそろ花園フォントの更新をお願いします。    
yoshiciv 2020年7月20日(月) 11:38

  • yoshicivさんありがとうございます。同意です。閉じます。--kamichi 2020年7月22日(水) 09:07

サービスの一部不具合について

  • GlyphWiki:お知らせの「サービスの一時不具合について」ですが,1回目のメンテナンス直後にFirefoxでアクセスできない(httpsで接続できないためと思われる)現象が発生しましたが,すぐに復旧しました。現在でも正常です。--spinda-kkmr 2020年3月25日(水) 18:11

Ext.Gの自動登録について

  • Unicode13は(おそらく)既に安定しています(こちらの資料 によると、既にベータレビューは終了しています)。そのため、可能な限り早くExt.Gを自動登録すべきだと思います。但し、実際には次に挙げるような問題があります。
1Group:ExtG-finalと実際のExt.G の一致。私はBabelStone Hanフォント との矛盾がないことは確認しました。
2UKソースの命名。-uとするか-ukとするか。
3エイリアス関連の処理。Ext.Fのようにu3XXXXのグリフがirg2015-0XXXXのエイリアスになってしまうことは避けたい。

以上。--kesuuko 2020年1月22日(水) 14:16

    • 議論が進展しないので、ひとまず次のように決定してもよろしいでしょうか。
1sim-chさんによって作成されたデータをもとにGroup:ExtG-finalを修正した為、一致しているものとみなす。
2-ukとする。
3「irg2015-*****のデータをu3****-jvに移す→u3****をu3****-jvのエイリアスとして作成する→irg2015-*****又はそのエイリアス元をu3****-jvのエイリアスにする」を作業内容とする。

以上。--kesuuko 2020年2月21日(金) 19:16

  • 良いと思います。2番は具体的な作業は発生するのでしょうか?--kamichi 2020年2月22日(土) 11:25
    • 追加です。sim-chさん、ありがとうございます。--kamichi 2020年2月22日(土) 11:33
    • 3番の、Ext.Fで起きている問題点を教えていただけないでしょうか。一括で治せるものなら一緒に直してしまいたいです。--kamichi 2020年2月22日(土) 11:33
    • 2番については、特に自動登録に関わる作業は発生しません。但し、「-u」とすると拡張Hの登録時に問題が発生します(https://hc.jsecs.org/irg/ws2017/app/index.php?id=04282 )。また、3番については、現在extf-*****の関連字が〓になってしまっている問題があります。--kesuuko 2020年2月22日(土) 18:56

  • では2番は「-uk」に改めて賛成です。3番ですが、多くの「extf-*****」はExt.F領域グリフのエイリアスなので、関連字は関係ない(エイリアス先に依存)と思うのですが、エイリアス先に依存せず対応するExt.Fの文字を当てるべきというご意見なのか、それとも別に残っている「extf-*****」の関連字に問題があるのかどちらでしょうか?あるいは、そもそもの記述にある「extf-*****」が大本(Ext.F符号位置グリフのエイリアス参照先)になることが問題とお考えの派生でしょうか。こちらについては他の方の意見も欲しいのですが、もし同様にお考えの方が多ければ機械的に直したいと思います。--kamichi 2020年2月23日(日) 10:08
    • 私は、u2****がextf-*****のエイリアスになっていることが問題(Ext.Eまでの慣行に反する)だと考えています。--kesuuko 2020年2月23日(日) 10:17

      • すみません、これは2018年にすでにどなたから提起された際に、私の当時の認識では自動修正はできないという結論でした。それで、今Ext.F領域のグリフデータを確認したところ、462グリフが独自にデザインされて登録されたグリフ、5,116グリフが「extf-*****」以外のエイリアス、1,895グリフが「extf-*****」のエイリアスでした。この最後の1,895グリフについて向きを逆にすればよいという認識で正しいでしょうか?--kamichi 2020年2月23日(日) 10:43
  • (インデント戻る)私の試案を表にします。
独自にデザインされたグリフ(u2****が実体)現状維持
「extf-*****」以外のエイリアス個別検討(u2****-j/jv/gなどのエイリアスは問題ないが、IDSグリフやsawnグリフのエイリアスは修正すべき)
「extf-*****」のエイリアス最低でもエイリアスの入れ替えは行うべき

以上。--kesuuko 2020年2月23日(日) 11:04

  • 現在、「extf-*****」について入れ替え中です。それ以外についてですが、「u2****-j/jv/gなどのエイリアス」を除くと649グリフです。私のノートページにデータを置きますので、ご覧ください。--kamichi 2020年2月23日(日) 11:51
    • 基本的にはエイリアスの入れ替えを行うべきだと思いますが、ユーザー占有グリフのエイリアスになっているものに関しては手作業で修正を行うべきだと思います。--kesuuko 2020年2月25日(火) 10:12

  • 今、irg2015のグリフのデータそのままをu3****-jvに登録しました。次に-jvを無印にエイリアスを貼ろうとしたのですが、たとえばu30020のような関係の場合に、どのグリフがベースで、どれがエイリアスかに悩みます。ひとまず止まっています。--kamichi 2020年2月24日(月) 14:04
    • 一旦そのままエイリアスを貼るべきだと思います。--kesuuko 2020年2月25日(火) 10:12
      • 承知しました。また作業を再開します。--kamichi 2020年3月13日(金) 15:13

  • 今、Ext.Gのすべてのグリフについて自動登録が終わりました。U+30000-U+301EFについては一部矛盾グリフがあるので、適宜直していきます。それで今後irgグリフやIDSグリフについて、整理削除する過程で一括処理ができるものについては言ってください。--kamichi 2020年3月14日(土) 14:05
    • 矛盾(存在するのにサムネイルがない)を解消しました。自動登録は完了です。--kamichi 2020年3月14日(土) 14:24

明朝体以外の花園フォントについて

花園フォントでは、ゴシック体も用意すると聞いたのですが本当ですか? もしそうなら、ゴシック体以外の字体の「花園行書」などを作る予定があるのですか?--yoshiciv 2019年12月29日(日) 19:28

  • 構想段階では、花園フォントはあくまでもニッチなニーズに応えることが目的で、既存のフォント(特に商用)とバッティングしないことを意識していました。このため、最低水準のラインナップとして明朝体、その次はゴシック体、と思っていました。すでに10年以上たちましたが、目論見通りニッチなフォントとしての位置づけとなり、既存フォントとバッティングする心配はなさそうです。ですので、特に書体を制限することは現状では考えていません。同時に、ゴシック体ですら実装に取り掛かる余裕もないのが現状です。明朝体のデータが蓄積されていますので、これを何かしらの変換で他書体にすることもいずれはできるのではないかと思っていますし、みなさまの試作を歓迎します。ゴシック体、やりたいですね…。--kamichi 2020年2月22日(土) 11:31

命名の文字数制限について

グリフ名が60文字を超えた場合意図的に登録できないようですが、100文字ほどに増強は出来ないでしょうか。 IDSの命名において60文字を超えてしまうことが多々あり、そうした場合占有グリフとして登録するしか道がなく不便に感じます。(例として、u2ff1-u2ffb-u2ffa-u5ef4-u2026-u2ffa-u2010e-u56de-u6b6a-u2ff3-cdp-8b62-u4e5d-u516dが登録できないため、n-gtwinppx_keidukaejitomoyasuとして仮登録、u2ff8-u5382-u2ff3-u2ff2-u6709-u6709-u6709-u2ff2-u6709-u6709-u6709-u2ff2-u6709-u6709-u6709が登録できないため、n-gtwinppx_amanohashidateとして仮登録。グリフの典拠は要約にあります。)--n-gtwinppx 2019年12月23日(月) 16:51
  • 私は反対です(少なくとも積極的には賛成できません)。Talk:biangpublicにあるとおり,60文字制限は管理人のkamichiさんがCD-Rに保存する時の制約(Joliet規格)を考えて決めたものです。
  • 60文字を超えるIDSと言うのは滅多にない物なので,そのような場合はGroup:prefix-miscにある“misc-####…”命名を用い,IDSをメタ情報に記入するというのはどうでしょうか。misc-biangを参考にしてください。
  • 今回の場合,前者はmisc-keizukaejitomoyasu,後者はmisc-amanohashidate-itaiji-001(misc-amanohashidateは使用済み)が望ましいと考えます。
  • 以上,--spinda-kkmr 2019年12月23日(月) 17:41
    • 迅速なご意見ありがとうごさいます。spinda-kkmrさんのご意見通りに"misc-####..."の命名で行きたいと思います。さらに、60文字以内でなければならない理由までつぶさに教えてくださり感謝いたします。--n-gtwinppx 2019年12月23日(月) 19:00

削除の方針について

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

「単」の字について

「单」の字を含む地域ソースのない漢字グリフが「単」に変更されています。 例:u5a75, u6b9a, u89ef, u28859 Jソースのある文字に限り「単」の字形を採用すべきだと思いますがどのように考えていますか。
    • prometziu 2019年8月1日(木) 10:53
    • 私は強く反対です。prometziuさんの言っていることはu2c739の艹を四画にしたりu2ce51の左半分を黄にしたりするようなものです。--kesuuko 2019年8月1日(木) 13:52

SATソースの命名について

CJK統合漢字拡張Gでは、u302f6のようにUKソースとSATソースの両方を持つ符号位置が存在します。そのため、SATソースの命名の変更を提案します。
  • 案1:SATソースを-s命名に変更する。
  • 案2:SATソースを-z命名に変更する。
  • 以下にそれぞれの命名の例を挙げます。
現在案1案2説明
u2e014-uu2e014-uu2e014-uUTC、UK、UCIソースのグリフは-uのまま変更しません。
u2ceb7-uu2ceb7-su2ceb7-zSATソースのグリフは命名が変更されます。

以上。--kesuuko 2019年7月26日(金) 14:59

  • 本来、接尾ソース記号は規格票のGTJKVなどのソース欄の例示字形を指すものでした。拡張領域でソースを欄で区別するのではなく、ソースを列挙する形に変わりましたので、意味が変わってきていると思います。このためSATソースに1文字を割り当てるのは変(今後アルファベットが足りなくなって崩壊する)と思います。代案としてUソースのみ「-usat」「-utc」「-uci」に分解するというのはいかがでしょうか。混乱しますかね?--kamichi 2019年7月31日(水) 19:07
    • こちらの資料 ではSATソースはUソースではなくなるようです。いずれにせよ「-usat」は不適切だと思います。--kesuuko 2019年7月31日(水) 19:13
    • ご指摘ありがとうございます。ただ…「-s」「-z」は反対です。誤解を生みかねないので。影響が大きすぎるのでできませんが、拡張領域の1字ソース自体が現状にそぐわないとすら思っています。もう少し議論しませんか。--kamichi 2019年7月31日(水) 21:10
      • こちらの資料 では、SATソースの正式な略称(TやV、Jなど)はSとなるようです。その為私はSATソースの接尾詞は「-s」が良いと思います。--kesuuko 2019年9月10日(火) 22:12
      • 現状では、こちら に挙げた漢字など、UTC/UKソースとSATソースを同時に持つ漢字の命名が困難です。早急に命名を規定することが必要です。私の私案は次の通りです。
ソース名現在私案1私案2
UTCソース-u-u-u
UKソース(-u)-u-uk
UCIソース-u廃止*廃止*
SATソース-u-s-s

 *UCIソースについては、Unicode13.0以降のソースに使わない方針のようです。

以上。--kesuuko 2019年12月21日(土) 10:22

  • 追認という形でよいと思うのですが、まずはSATソースが「-s」ということですね。--kamichi 2019年12月23日(月) 13:29

諸橋大漢和(など)の字書の古い版固有のグリフについて

旧版で存在し、新版で削除・更新されているグリフについて、記録としてグリフ登録できるとよいと思います。接尾辞「-old」あるいは版番号付きの派生などが考えられます。--kamichi 2019年5月22日(水) 14:48

  • よいと思います。このページ によると各版の間で差異があるようなので,接尾辞“-old-AAB”を提案いたします。AAは版番号(初版は00)でBは初版と縮写版を区別するための枝番です。

命名(spinda-kkmr案)
初版(1955年~1960年)dkw-NNNNN-old-001
縮写版(1966年~1968年)dkw-NNNNN-old-002
修訂1版(1984年~1986年)dkw-NNNNN-old-011
修訂2版(1989年~1990年)dkw-NNNNN

  • この命名であればかなり機械的に判定ができるのでよいと考えます。
  • 以上,--spinda-kkmr 2019年6月9日(日) 18:41

ExtGの自動登録について

ExtGの自動登録の際は、irg2015-0****のデータをu3****-jvにコピーして、u3****及びirg2015-0****をu3****-jvのエイリアスにするのが良いのではないでしょうか。なお簡体字特有の字体に関しては利用者が目視で確認します。

その理由としては、

  • 1.ExtGの漢字にJソースを持つ字が存在しないこと
  • 2.現在、UCSグリフの実体を-jvにすることが私を含む複数の利用者によって行われていること
  • 3.未だにExtFのグリフが実体になっていないケースが非常に多いこと
  • などがあります。--kesuuko 2019年4月26日(金) 15:06

右側に付ける合成用文字について

u102cu17c8のように基底文字の右側に付ける合成文字についてですが、1文字分の幅を必要とするため、u0e32のように合成文字ではない扱いにした方が良いのではないでしょうか。--prometziu 2019年4月10日(水) 01:08
  • 賛成です。その方がフォントにした時見映えがいいと思います。--kesuuko 2019年4月22日(月) 22:17

フォント生成について

少し気になったので質問です。ログを見た所、一文字目に「一」が入るのは仕様でしょうか?