アカウント名:
パスワード:
プリンタドライバに情報埋めこみ機能を持たせるのでは? エッジ部分に、 原画像との和が一定の規則性を持つようにスペックルノイズを埋めこむ ような仕掛けを含ませているのでしょう。おそらく、他の プリンタやドライバでは出力できないと思います。通常アプリケーション の電子データ (例えば PDF とか) として配布できるような性質の 物なら面白いんですが。
なぜ、プリンタドライバ汎用にできないかというと…。 今時のプリンタの多くはデータ解像度よりも印字解像度のほうが 高い(「○○dpi『相当』」というやつ)ので、周辺のドットから補完 して印字する機能を持っています。フォント制作者からすれば 「シャープさを失ってしまう [nifty.ne.jp]」原因となり、嫌がられる機能 なのですが、逆変換を求めるのは原理的に限界がありますし、この あたりの調整は各社独自の技術で囲い込まれているので、全部に対応 するというのは非常に難しいでしょう。
配布できてアプリケーションに依存しないような情報埋めこみの手段としては、フォントというのはかなり有効です(どのアプリでも使うから)。この手法は文字を含む文書に限られる欠点がありますが、フォントの形が違うのを検出するのは簡単です。
この方法については以前考えたのですが、細部をいじる方法では再現性を確保するのが 難しいと思います。例えば Type1 フォントのヒント情報が どのように処理されるかは文書化されていませんし、TrueType でもヒント情報が処理される場合とされない場合があり、さらには FreeType の自動ヒンティング機能を考えると、ドット単位の 細部のラスタライズ結果を保証するのはまず不可能だでしょう。
細部をいじるのではなく、偏と旁の大きさのバランスのような 字形に大域的影響を与えるパラメータをいじるなら、グレイスケール で印刷されたような場合でもある程度の情報を読み取ることができる かもしれません。和田研フォントキット [u-tokyo.ac.jp]という素晴らしい ツールがあるので、これを使えば3分ハッキングネタですね。
試してないけどアイディアだけ。TrueType/OpenType の GSUB/GPOS の chaining context substitution を使えば、フォントをいちいち生成しないでも済みそうですね。 行内に出力された一連の文字の組み合わせによって一意に定まるような variant をフォント内の字形バリエーションの中から選んで表示するわけです。実用的にしようと思うとラスタライザの実装上の限界を超えるかもしれませんが、フォントだけで実装できるというのはいい感じ。 # これくらいのアイディアなら特許ネタになりそうだから、ここに # 書いておくことに公知例としての意味があるかも。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
疑問 (スコア:0)
Re:疑問 (スコア:2, 興味深い)
モノにも依ると思いますが、印刷品質なんて一定な訳がありませんし、同じ機械からの出力でも容易く変わってしまうし、だいたい、全ての文字をビットマップとしてプリンタに送りつけるのかい、と。
で、せっかく埋め込んだ情報があったとして、コピー
-+- 想像力を超え｢創造力｣をも凌駕する、それが『妄想力』!! -+-
Re:疑問 (スコア:2, 参考になる)
プリンタドライバに情報埋めこみ機能を持たせるのでは? エッジ部分に、 原画像との和が一定の規則性を持つようにスペックルノイズを埋めこむ ような仕掛けを含ませているのでしょう。おそらく、他の プリンタやドライバでは出力できないと思います。通常アプリケーション の電子データ (例えば PDF とか) として配布できるような性質の 物なら面白いんですが。
なぜ、プリンタドライバ汎用にできないかというと…。
今時のプリンタの多くはデータ解像度よりも印字解像度のほうが 高い(「○○dpi『相当』」というやつ)ので、周辺のドットから補完 して印字する機能を持っています。フォント制作者からすれば 「シャープさを失ってしまう [nifty.ne.jp]」原因となり、嫌がられる機能 なのですが、逆変換を求めるのは原理的に限界がありますし、この あたりの調整は各社独自の技術で囲い込まれているので、全部に対応 するというのは非常に難しいでしょう。
配布できてアプリケーションに依存しないような情報埋めこみの手段としては、フォントというのはかなり有効です(どのアプリでも使うから)。この手法は文字を含む文書に限られる欠点がありますが、フォントの形が違うのを検出するのは簡単です。
この方法については以前考えたのですが、細部をいじる方法では再現性を確保するのが 難しいと思います。例えば Type1 フォントのヒント情報が どのように処理されるかは文書化されていませんし、TrueType でもヒント情報が処理される場合とされない場合があり、さらには FreeType の自動ヒンティング機能を考えると、ドット単位の 細部のラスタライズ結果を保証するのはまず不可能だでしょう。
細部をいじるのではなく、偏と旁の大きさのバランスのような 字形に大域的影響を与えるパラメータをいじるなら、グレイスケール で印刷されたような場合でもある程度の情報を読み取ることができる かもしれません。和田研フォントキット [u-tokyo.ac.jp]という素晴らしい ツールがあるので、これを使えば3分ハッキングネタですね。
試してないけどアイディアだけ。TrueType/OpenType の GSUB/GPOS の chaining context substitution を使えば、フォントをいちいち生成しないでも済みそうですね。 行内に出力された一連の文字の組み合わせによって一意に定まるような variant をフォント内の字形バリエーションの中から選んで表示するわけです。実用的にしようと思うとラスタライザの実装上の限界を超えるかもしれませんが、フォントだけで実装できるというのはいい感じ。
# これくらいのアイディアなら特許ネタになりそうだから、ここに
# 書いておくことに公知例としての意味があるかも。