GlyphWiki logo
navigation
help
search
toolbox
languages
user pagediscussionedit this pagehistory

User-talk:kamichi

From GlyphWiki, the free glyph database
13:42, 29 December 2012; revision @314 by kamichi (Talk)
← previous revision | latest revision | next revision →

2012を振り返る

総投稿数(グリフ+記事)

 count  
 -------
 235303

投稿者上位20(グリフ+記事。自動投稿を含む)

 count |          username          
 ------+----------------------------
 73894 | jo...
 38391 | ka...
 37344 | au...
 27027 | py...
 10282 | nk...
 10095 | sp...
  6528 | no...
  4889 | ya...
  4857 | kk...
  2796 | fx...
  2478 | tw...
  2071 | ka...
  1982 | go...
  1616 | ma...
  1400 | sa...
  1160 | ts...
  1106 | eb...
   982 | ge...
   862 | ki...
   758 | sa...

戸籍異体

Unicode IVS Add-in for Microsoft Office における花園明朝の非対応について

Windows 7上でのOffice 2010に上記アドオンを適用しても、花園明朝のIVSグリフは利用できないことを確認しています。メモ帳では問題なく表示できているので、実装に問題があるか、なにか特別な条件を設けているのか不明です。

FYI(FMI)

なぜあなたは私のプロジェクトを削除しましたか?

guocuozuoduo 04:07, 4 October 2012

  • グリフの名前の付け方に問題があり、その名前は受け入れられないからです。特に「u」で始まるグリフ名については、問題がある名前は削除しています。日本語を理解できるようなので、まずGlyphWiki:命名ガイドラインを読んでください。今回の場合、「元となる漢字のUCS番号-itaiji-###」という名前が適切です。--kamichi 2012年10月4日(木) 07:24
  • 何をなさりたいのかが不明ですが、もしかつてのシンガポールの簡体字だけでまとめて新しい名前を付けたい、ということであれば、「singapore-simplified-u####」みたいなものであれば許容できると思います。--kamichi 2012年10月4日(木) 07:25
  • Group:シンガポール特有の簡体字もぜひご覧ください。--kamichi 2012年10月4日(木) 07:24

自由命名の方向性

自由命名を廃止し、以下の3本に収斂させる案

  • 登録した前頭語を用いるもの(命名ガイドライン相当)
  • ユーザー占有グリフ(制約なし)
  • IDS表記(-var-###によるブランチを許容)

GlyphWiki:グリフの整理にて作業

個人的備忘

グリフのバージョンは現状では数字5ケタまで対応。これは以前利用可能であった時間指定によるグリフのバージョン指定で日付指定が数字6ケタであったため

(お知らせページより移動)無印UCSグリフの漸次廃止について

このところ無印UCSグリフについて、地域デザインの編集合戦に相当する状況が発生しています。その労力が大変もったいないので、無印UCSグリフの廃止の実施を早めます。具体的には以下のように移行します。

  • 無印UCSの更新停止。無印UCSのグリフページは各ソースへのリンクを表示し、編集不可とする
  • 偏化変形、異体字2種については当面現状維持
  • 今後無印UCS全グリフを時間をかけてソース付与グリフに移行し削除(各ソースへのリンクを表示するガイドページ化)

無印UCS廃止作業

  • グリフ名の「無印」→「-jv」変換
  • グリフデータ内の引用部分の変換
  • ドキュメント:放置か?
  • 無印の画像リクエストに何を返すか:全ソースを並べたもの?更新が煩雑?使いにくい?ソース優先度をつけて1つ選ぶか(負荷高い?)?
    • 無印の画像ファイルのリネームor全再生成
  • kkユーザーへの告知
  • 正しいソースへの移動作業の簡素化、作業者確保
  • 仮想Jソースのガイドラインの検討

検討事項

UCS未定義字のIDSによるグリフ名記述について

正直なところ、IDSをUCSコードで記述しても、字のイメージが全く見えず、グリフ名も長くなるという問題もあります。内部データはそのままにしても、ページ生成時にIDS記述がある場合は文字に直したものも自動的に併記するような機能があるといいかもしれません。

  • u2ff0-u9b5a-u91dd という記述は u2ff0-u9b5a-u91dd(⿰魚針) みたいに表示される

コメント

漢字構成記述文字選択→漢字構成記述文字選択or漢字入力の繰り返しで簡単にurlが生成できるようなページがあると良いと思います。 ついでに自動的に字形生成までできると良いと思います。--匿名利用者 2009年3月13日(金) 10:24

ご意見ありがとうございます。urlの生成とありますが、これはどういう意味でしょうか。⿰、魚、針 と入力していくと u2ff0、u2ff0-u9b5a、u2ff0-u9b5a-u91dd と書き換わっていくのか、それとも u2ff0-u9b5a-u91dd を編集するページ(この場合 http://glyphwiki.org/wiki/u2ff0-u9b5a-u91dd?action=edit )が表示されるという意味でしょうか?ちなみに、ちょっと近いことは http://fonts.jp./kage/demo.html でやっています。「⿰虫永」と入力されているボックスにIDSを記述して右の「Conv」ボタンをクリックすると、それをKAGE/cgiの生成URLに変換したものがその下に表示されます。こちらは文字の区切りを「.」にしているので、そのままは使えません。なお、このデモページのKAGEエンジンは古いものなので、なるべく早い機会にグリフウィキの部品データや分析データを使ったものに置き換えたいと思っています。--kamichi 2009年3月13日(金) 22:38

後者を考えていました。

>なるべく早い機会にグリフウィキの部品データや分析データを使ったものに置き換えたい

期待しています。--匿名利用者 2009年3月13日(金) 22:47

部品エディタ

グリフエディタについて、現在Adobe Flashで実装していますが、これ以上の更新は行わないこととします。将来的にHTML5のCanvasベースに書き直すことを目標とします。

現在の検索内容

  • 直接漢字が指定された場合
    • 漢字そのもの、引用している部品
    • 関連字グリフ、その字で引用している部品
    • 関連字を同じくする字、その字で引用している部品
    • UCSの派生グリフ(部分一致するもの:偏化変形、他ソース、異体字)
    • 指定漢字のIDS、部品字の関連字、引用部品
    • 指定漢字の異体字DBの関連字(詳細未整理)
  • そうでない場合
    • 漢字そのもの、引用している部品
    • 関連字を同じくする字、その字で引用している部品
    • UCSの派生グリフなら代表字・引用部品・代表字関連字共通字・引用部品
    • グリフ名部分一致
  • グループ名と一致する場合、そこで記述されたもの(他グループ引用は無視)
  • 利用者名と一致する場合、そこで記述されたもの(他グループ引用は無視)

現状では部分一致も検索しますが、検索キーワードそのものがwiki名に沿っていないと検索されません。wiki名は先頭英小文字で5字以上です。

  • 現在の部品エディタの検索
    • 1文字は符号位置に直して検索
    • 2文字はエラー
    • 3,4文字はエラーは出ないが検索結果はなしとなる
    • 5文字以上で検索キーワードと一致するグリフおよび先頭一致検索を行う
      • 検索キーワードがグリフ名規則(5字以上)に沿わないと検索しないというプログラムミス
  • 3,4文字もエラーとするか、部分一致の条件を緩めるか
  • 2字でもサロゲート(JSの仕様)ならOKとする

memo.

グリフエンジンの改良

  • sayunu_u5165
  • 7ストロークの曲線の制御点が直線の延長上に無いときに欠ける現象の修正
  • 屋根つき右ハライ u4e41
  • 左払い上はね u4e44
  • カカト(下部他筆画:完了、ボディ下端:未了)
  • カカト調整で曲線の制御点を使わない
  • ウロコ(自身長さ:完了、またぎ長さ:完了、他並行横棒接近:未了)
    • 2?7をはずす、ハネの考慮、278は?
  • ハネの大きさ、仮想的な全体に対する大きさの割合の考慮
  • 開放筆画の末端座標と実際のストロークの末端を合わせるとゴシック体との共有が難しい、肉付けをしないで仮想ボディを計算するのが面倒
  • 部品同士を近づけた時に、開放ストロークが一定以上重なるようであれば引っ込める
  • 99部品について、接着フラグを立てると下端などの開放形状が接続形状になる機能

User:sayunuより引用

[ 19. 2010年3月21日(日) 21:27 ] 賢い肉付けエンジンなら、曲線の始点と終点を与えるだけで、平均的な位置に中間制御点を補ってくれると思う。自動ではうまく行かない様なグリフでのみ中間制御点を手動で指定するという形だと便利だし、デザインが統一されるんだけど。あと〈亡〉みたいな直角に曲がる線って、中間点まるで要らないよね。縦拂いも三個目までの点が一直線に並ぶなら、その分の情報は蛇足だよね。

TTFファイルの限界について

  • TTFファイルの限界が65535グリフなら、HanaMin-Extを制作してU+10000以上の文字はそのフォントに収録するのはどうですか。(つまり、HanaMinにはBMPの文字のみ収録して、HanaMin-ExtにはU+10000以上の文字のみを収録するのです。) --johotogoshinentai 2010年11月15日(月) 09:13

  • ご意見ありがとうございます。いくつか方法があると思いますがjohotogoshientaiさんのご意見も候補の1つです。日本の一般的なユーザーの場合、JIS X 0208,0212,0213の文字はすでに利用できる場合が多いので、その集合(A)とそれ以外の集合(B)で分割することをベースとして考えています。つまりBのフォントをインストールすればUCSが全部使える、というニーズを想定しています。
  • 花園明朝としては1つ方針を決めたいと思いますが、派生花園フォントとして、いろいろな集合を組み合わせたバリエーションも配布したいと思います。--以上はkamichi 2010年11月15日(月) 09:34

    • ですが、JIS X 0213には拡張Bの文字もあるので、JISを基準で分離するのは難しいかもしれないと思います。 --johotogoshinentai 2010年11月15日(月) 10:22

    • ご意見ありがとうございます。分離というのは、全く分離するわけではなく、AにもBにも含まれる符号位置はあり得る、ということで解決すると考えています。具体的にはBにはExt.Bをすべて含めることを想定しています。--kamichi 2010年11月15日(月) 10:28

    • 仮想J字形で埋めた「(URO+EXT-A~D)-MS明朝ver5.0」フォントを提案します。また「The Unicode Standard の字形」(EXT-C以降は???)フォントや「住基フォントコンパチ」フォントなどもあったらよいと思います。 --tsuruki 2010年11月15日(月) 21:02

記号とその他文字

あと、HanaMinに記号とその他文字をもっと収録するのもいいと思います。今、HanaMinには記号とその他文字が少なそうです。ASCIIとLatin-1、全角半角、Group:johotogoshinentai_非漢字(まだ未完成ですが)にある文字も収録するのはどうですか。 --johotogoshinentai 2010年11月15日(月) 10:22

  • ありがとうございます。収録するかどうか悩むのですが(理由は下記「もう一つ提案」と同じ)、もともと集合がそろってからまとめて収録という方針にしていました。--kamichi 2010年11月15日(月) 10:41

もう1つ提案

半角文字を作れる方法はありませんか。半角文字も作れればいいのに、と思います。 --johotogoshinentai 2010年11月15日(月) 10:25

  • うーん、まだ非漢字の扱いが決まっていないのです。もともとは「漢字グリフ」のWikiでしたので…。KAGEエンジンで扱う範疇外という意味での非漢字グリフをこのまま強引にKAGEエンジンによるデータで収集していっていいのか、悩みます。--kamichi 2010年11月15日(月) 10:28

  • 思ったのですが、latin系文字の扱いはここでは考えないこととして、U+FF61~U+FF9Fの符号位置グリフだけ横幅を半分にする、ということだけでいいのでしょうか?どちらかというと真ん中ではなく左に寄せた方がいいのかなと思いますが。--kamichi 2010年11月15日(月) 11:02

    • できればネットにつながっていない状態でフォントの生成ができる方がいいです。その意味では特定のページを参照しないと判断できないというのはウーンという気がします。ページではなく、あらかじめグリフウィキでコードポイントごとに半角か全角かの初期値を決めておいて(その議論をグリフウィキのページで行うことは賛成です)、それをファイルとして保持しておく、というのが望ましいと思います。--kamichi 2012年12月19日(水) 21:45

無印UCS廃止について

「編集合戦」と言いましたが、編集合戦ではないと思います。もし私と匿名利用者のことなら、その匿名利用者が根拠のない編集を行って、それを私がリバートしただけです。(なお、UnicodeやISOのファイルが正しいと言えないと言いましたが、それたちを信じられなければ、どんな標準を信じればいいのですか。)

とにかく、というわけで無印UCS廃止はいらないと思います。あと、私のせいで無印UCS廃止するなら申し訳ありません。 --johotogoshinentai 2010年11月19日(金) 22:52

  • コメントありがとうございます。「編集合戦」は私も言いすぎと感じていますが、それに近い状態と考えます。なお「根拠のない(デザインへの)編集」と断言されていますが、もともと無印UCSグリフは「仮想J字形」を想定したもので、匿名氏の考える「旧字体」に近いものです。ですので少なくとも私にとっては匿名氏による旧字体への変更は理解できるものです。
  • johotogoshinentaiさんだけでなく他の方も表明されたことのある「漢字は日本人だけのものではない」というご意見ですが、もともと当初の私の考えは「私は日本向けにグリフウィキを運営して、主ターゲットは日本デザインのユーザーである。それ以外の地域デザインはそれぞれの地域の人がグリフウィキを別で運用してくれればよい」というものでした。さすがに現在はその考えを改めましたが、想定する主たる利用者は日本デザイン利用者であることは変わっておりません。
  • ですので、UCS符号位置は抽象的な概念であること、および仮想J字形をきちんと定義できていないこと、この2つが現況の原因であることは明確ですので主観の異なる立場のグリフを共存させるためには無印UCSの廃止は妥当と思います。
  • 当初の予定では「無印UCS」を「仮想J字形」と断言し、johotogoshinentaiさんが登録されるGソースは「-g」を付けるべきだ、というのがもともとの方針でしたが、これを改めます。
  • また本件とは全く別の観点で、CHISEプロジェクトとの連携・統合を長い間模索してきましたが、その大きな障害はこの無印UCSです。ですので無印UCSの廃止は全く唐突な話ではないことを補足いたします。
  • 無印UCSがなくなるとやや煩雑になるので、私も心苦しいのですが、ご理解を賜りたいと存じます。--以上はkamichi 2010年11月19日(金) 23:25

  • 以下補足です。johotogoshinentaiさんは強力なGソース推進派だと私は思っています。今回の無印UCS廃止に全く影響がなかったかと聞かれれば、あったと思います。それを悪いことだとは思っていません。時期が早まっただけです。
  • 本音を言うならば、johotogoshinentaiさんのグリフ登録スピードはとても速く、Ext.Bがどんどん埋まっていくことは私はたいへんありがたいことだと思っていますし、毎日楽しみにしています。ですので、johotogoshinentaiさんにどんどんグリフを投稿していただくために、無印UCS廃止はしばらく先延ばしするつもりでした。しかし、時々匿名氏による旧字体への変更があり、これはたいへんもったいないことです。やはり早く「-g」と「-jv」を分けなければならない、と考えました。これが真相です。繰り返し述べますが、johotogoshinentaiさんにはたいへん感謝しています。--以上はkamichi 2010年11月19日(金) 23:25

    • ご感謝、ありがとうございます。kamichiさんのご意見、よくわかりました。
    • 正確にいえば、私は別にGソース派ではなく、「ソースがある形を従って、なるべく仮想字形を作らない。ソースが2つ以上の場合には日本の字形に似ているソースを選ぶ。」主義です。このように思うようになった理由は、韓国のハンコムバタン(한컴바탕)というユニコード・フォントのためです。ハンコムバタンの漢字は、基本的に韓国のデザインに基づいているけど、韓国の文字コードに入っていない漢字については日本や中国のデザインを従っています。なので私は「字形は状況、出所、実際の使いなどによって変わるもの」と思ったし、「仮想J字形」や「仮想J字形に基づいた旧字体」みたいなアイディアが理解しにくかったのです。 --johotogoshinentai 2010年11月20日(土) 00:16

ホットキーの提案

glyphwikiを使って編集を行うとき、編集およびプレビューや文字の投稿をする場合、マウスをいちいち押すのが時間がかかることになります。文字を編集するときにShift+Eのようなキーの組合でホットキーを使う方がもっと便利になることだと思いますので、アイディアの1つとして書き込みます。--ldx0 2010年12月7日(火) 16:19

  • ご意見ありがとうございます。できれば井戸端会議がいいかなと思いますが、せっかくですのでここで。Webページでのホットキーはなじみがないのですが、<a>タグにaccessskeyを指定するタイプを想定されているでしょうか?--kamichi 2010年12月8日(水) 00:07

  • 1年たってしまいましたが、やっとホットキーについて知る機会がありました。慣れれば早くなりますが、あまりなじみがないかなとも思います。他の方で活用されている人がいらっしゃるでしょうか?--kamichi 2012年2月29日(水) 23:43