hirax.net::Keywords::「Adobe」のブログ

■CleType自主学習（仮）　

ちょっと真面目にClearType（仮）

1. 楽しそうな「iMac」＆「電子ブック」風ノートPC用スタンド　-はじまり -　(2002.08.26)
2. 一本道か、分かれ道か　- ドキュメントの縦横比について- (2002.08.29)
3. 水平思考と垂直思考 - 文字の縦横解像度 -　(2002.08.29)
4. 細かくすると楽（粗く）になる？ - ClearTypeの一番の秘密-　(2002.09.09)

楽しそうな「iMac」＆「電子ブック」風ノートPC用スタンド　-はじまり -　(2002.08.26)

　Lapvantageという楽しそうな会社を初めて知った。ノートPCをiMac風にするLapvantageDomeやPCを縦置きで使うためのLapvantagePortraitという、とても実用的でいて、それでいて明和電機のような面白い製品を作っている会社である。明和電機は兄弟が運営しているが、こちらのLapvantageの方はビアボーム親子がやっているらしい。iMac風スタンドの方は角度が振れないようのが（特にノートPCを立てられない）残念だが、Lapvantageの方はもう少しデザインがスマートであるならば今すぐにでも欲しくなる。
 

Lapvantage Products

Lapvantage Dome

Lapvantage Portrait

　複数の作業を切り替えながら作業をしたり、あるいはツールバーが多数出てくるようなソフトウェアを使って作業をする時には、左右に広いディスプレイが便利で使いやすい。しかし、単純に一つのドキュメントを読んだり、一つのドキュメントを書いたりする場合には上下に長いディスプレイを使うと、見通しがきいて考えをまとめやすくなる。気のせいか、頭の中の見通しがとても良くなるように感じたりする。だから、以前から横長の画面のノートPC(ToshibaPortege 320)を愛用していたりした私はノートPCの画面を横にして使ったり、縦にして使ったりと、画面を切り替えて使ってみたいと感じていた。AdobeAcrobat Readerであれば、画面を回転させて文章を読む機能があるので、これまでノートPCを回転させて電子ブックのようにして文章を読んだりすることもあった。　

　Lapvantage PortraitはPivotProのソフトウェア付きなので、Windowsの画面を自由自在に回転させることができる。だから、ノートPCを普通に横置きに使ってみたり、スタンドに載せて縦置きに切り替えて使ってみたり、と好きなように切り替えることができる。「これはなかなか便利そうだ」と思い、私も私も30日有効のPivotProのデモ版をインストールして使ってみることにした。

　そして、このソフトのインストールをきっかけにして

• ファイト！縦文字文化　-縦と横の解像度を考えよう - (2001.04.29)

• デバイスドライバーは仮免-ClearTypeの秘密 - (1999.09.26)

一本道か、分かれ道か　- ドキュメントの縦横比について- (2002.08.29)

　前回書いたように、複数のことを考えるなら「左右に長いディスプレイ」が良くて、一つのドキュメントを読むなら「上下に長いディスプレイ」が良い。その理由を端的に言えば、「目が左右についているから」だと思う。

　まず、「目が左右に付いているので、あまりに大きい左右への目の動きは、目にとってとても非対称な作業であるから不自然」だ。だから、左右を眺めるときには自然と頭を左右に振ることになる。その頭を左右に振るという作業は、頭の中での何らかの切り替え作業を伴うような気がする。だから逆に、ツールパレットの切り替えのような「何らかの作業の切り替え」を伴う作業であれば、その左右へ視線を移動する（自然と頭も左右に動かす）ということはとても自然な行為になる。しかし、それは一つのドキュメントを読むような場合には、いたって不自然な行為になってしまう。だから、一つのドキュメントというのは本来「上下に長い＝縦長」であるべきだと思う。

　そしてまた、「目が左右についているから」、人は上下方向を「一本道」に繋げて考える。例えば、絵画を眺めるとき、上に見える景色は多くの場合遠い景色で、下に見える景色は多くの場合近い景色だ。漱石の文学論の図を引くまでもなく、この「上下の遠さ、距離」というものを例えば時系列上の「一本道」に繋げるのは、いたって自然な連想だと思う。「遠い上」に見えるものは「遠い過去」で、下に来ればくるほど新しいことになる。それは、ドキュメントを読む場合に対応させて考えると、とても自然だ。それに対して、左右に並ぶものは決して「一本道」ではないのである。それは、「選択肢＝分かれ道」であって、決して一つの道ではないのである。左右に並ぶものは「複数の何か」なのである。

　だから、一つのドキュメントは上下に並び、上下に長いべきなのである。ドキュメントの表示も同じく、縦に長いべきなのである。
 

「文学の焦点」

漱石　「文学論」より

　最近のPCであると、ディスプレイは通常横に長い。だから、本来縦に長くあるべきドキュメントを眺めようとする場合には、表示を90°回転させてやることもある。そうすると、本の一ページのようにして画面表示を眺めることができる。例えば、AcrobatReaderで表示画面を回転させたり、PivotProなど使ってPCの画面表示自体を回転させてやれば良いわけである。
 

Acrobat Readerで90°回転表示をする

回転させない場合

回転させた場合

PDF表示を90%回転させている例

縦長のドキュメントを読むことができる

　このように、ドキュメント表示のための縦横比については、単にディスプレイの表示を90°回転させてやれば問題は解決する。しかし、表示のためのもうひとつの条件、表示品質が問題になってくる。そもそも、液晶(二十世紀においてきたCRTは無視しよう)の解像度はまだま低くて、それを改善するための技術としてClearTypeやCool Fontがあるのだけれど、AdobeのCool Typeはともかく、Clear Typeの場合には表示が90°回転しているという情報をClearTypeが取り扱わない（知らない）ために、上手く動かなくなってしまう。ClearTypeにしてもCool Fontにしても、液晶のRGBのカラーフィルターの並び方を利用してやることで解像度を高めているわけで、その並びの変化（表示の回転）に対応できない場合には表示品質を大幅に落とすことになってしまう。

　次に、「ファイト！縦文字文化　-縦と横の解像度を考えよう - (2001.04.29)」で考察した、文字の解像度についてもう少しちゃんと考えてみることにする。

水平思考と垂直思考 - 文字の縦横解像度 -　(2002.08.29)

　ドキュメントを表示させるためには、文字を表示させてやらなければならない。しかし、液晶ディスプレイの解像度は必要十分には高くないから、文字はつぶれてしまうことが多い。例えば、「現実問題春夏雪雹資本主義電計算機」なんて文字を表示させてみるとかなり潰れてしまい、非常に読みにくいのが判るはずである。これが、英語の"RealProblem seasons Snow capitalism Computer"なんて文字であれば、まだマシである。

　この日本語と英語の文字の解像度の差について考えてみる。比較例は下に示した、「漢字」と「英語」のテキストを用いることにする。
 

日本語と英語の文字の解像度

「漢字」

「英語」

　まずは、600dpiで20ptのMS Pゴシックのフォントを展開して上のような画像にした後に縦・横方向のそれぞれの解像度を考えてみる。ここでは、縦・横方向の黒い線（あるいは線でない部分）の太さ（幅）の分布を測ってみることにした(今回解析のために作成したソフトはここ（RunLength.lzh）においておく)。テキストのような二値の画像の「解像度特性」を計測するのであれば、このような解析にしなければならない。「ファイト！縦文字文化　-縦と横の解像度を考えよう - (2001.04.29)」でやったようなフーリエ解析は適切な方法ではないのである。

　下の図が縦・横方向の黒い線（あるいは線でない部分）の太さ（幅）の分布である。縦方向に計測した黒い線（あるいは線でない部分）の太さというのは、結局のところ横線の太さ（あるいは線の間隔）であり、横方向に計測した黒い線（あるいは線でない部分）の太さというのは、結局のところ縦線の太さ（あるいは線の間隔）ということになる。どれだけの細かさで「太さ」（あるいは「位置」）を描いてやらなければならないか、を示すグラフということになる。
 

600dpiで20ptのMS Pゴシックのフォントをビットマップに展開してみた場合

「漢字」の場合

「アルファベット」の場合

　「漢字」の場合には「Vertical 方向で計測した線の太さ（あるいは線の間隔）、すなわち横線の太さ（あるいは線の間隔）」が「縦線の太さ（あるいは線の間隔）」に比べて、大きく小さい方にシフトしていることが判ると思う。また、横線の量が縦線の量に比べてずっと多いことも判ると思う。後者は「数字文字の画像学　-縦書きと横書きのバーコード - (2000.01.21) 」で考えたことと全く同じで、「日本語は横線が多い」ということを端的に示している。そして、前者は「Vertical方向で計測した（すなわち横）線の太さ（あるいは線の間隔）」が縦のそれより大幅に小さいということは、「漢字」の解像度は縦方向に大幅に解像度が高い、ということを示している。漢字は縦書き文字故に鉛直思考志向なのである。

　一方、「アルファベット」の場合には、これも「数字文字の画像学　-縦書きと横書きのバーコード - (2000.01.21) 」で考えたことであるが、縦線と横線の量においてはむしろ縦線の方が多いことが判る。水平方向に対して情報量が多いのである。アルファベットは水平思考志向なのである。「アルファベット」の情報量はそのかなりの部分が縦線によるものなのである。そしてまた、線の太さ（あるいは間隔）は横線の方が細い（あるいは線間隔が短い）が、その横線であっても「漢字」の縦線程度の解像度であることが判る。「漢字」に比べて「アルファベット」の解像度は低いのである。

　ただし、文字の解像度を「線の太さ（あるいは間隔）の最小値」だけで論じることはできない。「適切な線の太さ（あるいは間隔）」にすることができるほどに解像度が十分高いか、ということも重要である。もし、そうでなかったら線が妙に太くなったり、細くなったりしてしまったり、あるいは、線の間隔が妙に近づいたり離れてしまったり、つまりは文字のプロポーションが崩れてしまったりするだろう。上の場合は600dpiで文字を表示させた場合の解析例だが、次に現在の液晶と同じような解像度（例えば）150dpiでこの文字を表示（展開）させてみる。こうすることでことで「適切な線の太さ（あるいは間隔）」にできていない様子を確認してみたい。
 
 
 

細かくすると楽（粗く）になる？ - ClearTypeの一番の秘密-　(2002.09.09)

　まずは、「現実問題春夏雪雹資本主義電計算機」という漢字と"RealProblem seasons Snow capitalism Computer"というアルファベットを現在の液晶と同じような解像度（例えば）150dpiでこの文字を表示（展開）させてみた。そして、前回と同じようにそのビットマップ画像の「縦・横方向の黒い線（あるいは線でない部分）の太さ（幅）の分布」を調べてみる。その結果が下のグラフである。また、前回に調べた、これよりも４倍程解像度が高い「600dpiで20ptのMSPゴシックのフォントをビットマップに展開してみた場合」をさらに下に比較用として示してみる。
 

150dpiの解像度で20ptの文字を出力してみた

「漢字」の場合

「アルファベット」の場合

600dpiで20ptのMS Pゴシックのフォントをビットマップに展開してみた場合

「漢字」の場合

「アルファベット」の場合

　150dpiでTrueTypeをビットマップに量子化した場合には、漢字・アルファベットの場合共に、縦・横方向とも600dpi単位で4,8pixelの太さ＝150dpiで1,2ピクセル幅のパターンが発生していることが判る。このようなパターンは、600dpiで20ptのMSPゴシックのフォントをビットマップに展開してみた場合には見られなかったものである。つまり、、着目すべきは例えばアルファベットの場合、

• 縦方向には幅10pixel(600dpi単位)=2.5pixel(150dpi単位)以下の高い周波数は存在していなかった
• 横方向には幅13pixel(600dpi単位)≒3pixel(150dpi単位)以下の高い周波数は存在していなかった

• 縦・横方向共に幅4,8pixel(600dpi単位)=1,2pixel(150dpi単位)以下の高い周波数が生じている

• 縦方向には幅7pixel(600dpi単位)≒2pixel(150dpi単位)以下の高い周波数は存在していなかった
• 横方向には幅11pixel(600dpi単位)≒2.5pixel(150dpi単位)以下の高い周波数は存在していなかった

• 縦・横方向共に幅4,8pixel(600dpi単位)=1,2pixel(150dpi単位)以下の高い周波数が非常に多く生じている

　また、これらの文字の場合には本来18〜15≒12pixel(600dpi単位)の線幅・線間のパターンが多いわけであるが、それを150dpi単位（　=600dpi単位で4pixel　)で量子化してしまうと、場所により4/12 = 33%もの線幅・線間の位置の誤差が生じてしまうことになる。不必要に狭い幅のパターンが作成されたり、不必要に広い幅のパターンが作成されたりして、これでは文字の線が太くなったり細くなったり、線の位置が狂ったりしてしまい、見にくいことこのうえない。これはすべて、150dpiという低解像度で量子化してしまったためである。「低解像度の表示系の解像度に合わせて量子化（ビットマップ化）してしまうと、ますますその表示系では表示しづらい高周波のパターンが生成されてしまい、結果として読みづらい」という一見逆説的に思えてしまう（しかし当たり前の）現象が生じている。

　ところで、本題のClearTypeの場合には横方向（通常の液晶はRGBの3つのサブピクセルが横方向に並べられているから）の解像度を3倍だと仮想的に考えて、横方向を3倍の解像度で量子化を行うことになる。ここで、話の単純のために3倍≒4倍と思うことにすれば、つまりはClearTypeの場合には本来150dpiの解像度であるにも関わらず、サブピクセルを考えて600dpiの解像度で量子化している、ということである。それは結局上の二つのグラフの比較と同じであって、ClearTypeを使うと実は表示すべきパターンが「より表示しやすい低い周波数のパターン」になっているのである。それは、「文字の線が太くなったり細くなったり、線の位置が狂ったりしてしまう」ことがなく、目にとってはとても見やすいパターンになるだろう。この量子化の段階について触れている情報は見たことがないが、実はこの量子化の段階にClearTypeの隠された（しかし、一番重要な）メリットがあるように思う。また、アルファベットの場合にはHorizontal方向に振幅を持つパターン（＝縦線）が支配的に多いため、Horizontal方向に仮想的に高解像度の量子化を行うことは非常にメリットを効果的に得られると考えるのが自然である。

　次に、このように量子化されたデータをClearTypeで表示する際の問題点・その解決方法について考えてみていくことにしたい。

　P.S.ちなみに解析ソフト（RunLength.lzh）をアップロードしました。
 

■pdf995　

　Hardでloxseな日々を読んでて思い出した。Bitmapを印刷しようとしても、純正のAdobe Acrobatでは上手くいかないことがある。だけど、このpdf995ならちゃんと出力できる。というわけで、Acrobatを入れてる人でも、このpdf995 PDFプリンタドライバーを入れると便利なことも多いと思う。（リンク）（リンク）

■SDKライセンス変更？　

　SDKライセンス変更？ASNに入ると会員用のサイトで日本語化されたドキュメントなんかも見ることができるのだけれど、あぁいうのだってフリーで閲覧できるようにして欲しいなぁ、と思う。それに、ASNに加入する時の書類だってちょっとめんどくさすぎだと思う。少なくとも日本版はそうだった。
　とりあえず、ASNでは11/18 Photoshop 7.0 SDK API Guide日本語版がアップデートされています。

■続々・桜雷さんの特許申請の話 - 二通目のメール -　

　人に書くメールというものはやはり丁寧に書きたいので、桜雷さんへの返事は日曜日にでも書くつもりですが、先に今朝届いた二通目のメールで述べられていた内容の概略を紹介しておきます。

(2003.11.22追記)
「私信として送ったメールなので、公開するのは止めて欲しい」と桜雷さんからの要望を頂きました。とりあえず、できるだけ文脈を保持しつつメールの元の文章は削除しておこうと思います。なお、削除作業以前の以前の文章も記録として別途保存してあります。

二通目のメールの概略現在、該当する特許申請については申請中であるため、公開停止を求める通知を取り消す。もし特許の申請が通れば、申請日までさかのぼり問題となる。別のアルゴリズムによる同機能のソフトを開発する場合には問題はない。

> hirax.netに「ご理解いただけましたら、私が同じ原理で特許を出している旨を> 掲示していただけたらと思います」ということを目立つように書いた場合には、> 異議申し立てをする会社や人が現れる可能性が高くなると思います。> なので、それは必ずしも桜雷さんに対して良い方向に向かうとは限らない> です。これは桜雷さんの好きな選択を尊重したいと思います。

　お久しぶりです。平林@hirax.netです。お問い合わせを頂いた件からまず先に回答させて頂きます。また、以前メールを頂いたときの記録が桜雷さんの手元に残っていないということなので、以前の返事と重なる部分はそのメールをなるべく引用しながらお答えさせて頂きます。> http://www.hirax.net/dekirukana5/bokeboke1/index.html> http://www.hirax.net/dekirukana6/rin/index.html> > は当方の出願中の特許に重なるもだと思います。> 日本とアメリカで申請中(アメリカは現在審査中)です。> アメリカの方は日本の申請のものを基本に、範囲を広げて申請しています。(中略)> これらの特許に抵触しないと確信された上でソフトの公開をされているのでし> ょうか、お考えをお聞かせください。　JP（日本特許）に関しては請求項に規定されているような対数変換の式は使っておらず、（仮に特許が成立したとしても）特許には抵触しないように配慮してあります。そのため、> 当方としましては、これにあたるものだと判断していますので、という判断の具体的な理由を参考までにお聞かせ頂ければ幸いです。> また、これらの記事を見て私の出願を知らずにこのアルゴリズムでソフトを作> っている人もでてきていますので、もしアルゴリズムに関する記事を公開され> る場合には、当方が特許を申請中であることを明記してください。　桜雷さんが特許を申請中であるということは、以前桜雷さんが「同じ原理で特許を出している旨を掲示して欲しい」という同様の要望を書かれてきた際に、その後「よくページを読むと特許の記述も書いてあった」とご自身でご確認されているようにこの記事を書いた時点から記載しておりますので、この点については再度よく確認頂きたいと思います。　さて、ここから先は以前メールでお知らせした事項と重なる部分も多いですが、桜雷さんの参考にもなると思いますので、若干書かせて頂きます。　最初に桜雷さんから頂いたメールは「画像処理ソフトで、自然対数を使う数式を使ってピンボケを作り出すソフトやアルゴリズムが存在したか教えて欲しい」というという内容のお問い合わせでした。それに対して、> 　さて、特開２００１−２１６５１３をざっと眺めてみました。> 処理の流れは、画像データに対して、>１．コンボリューションを行う（ただし限られたコンボリューションカーネルを用いる）> ２．その際特許内で示された非線形変換を行う> という感じでしょうか。> 　特許という観点で見ると、> 1、2ともに公知の技術であって、その組み合わせ自体もおそらく画像処理関連の> 学会誌・レポートなどを探れば、通常の写真・レンズの研究の一環で既に発表されて> いそうなので、公知資料があるのではないか、と思います。>　>　ただし、公開された特許に対して、審査が通り、また、どこからか異議申し立て>が無ければ、特許は通るかもしれません。>　>　計算上は上記、１，２の組み合わせのソフトは結構ありそうですが、特許に書いてある> 式ずばりそのものを使ったものは無いかもしれません。> 　ただし、それは同時に特許の請求範囲が狭い（請求項に書かれている式に限定されて> いるので）ということも意味します。この特許の式を使わなければ良いわけで、特許が> 成立しても特許から逃げやすいかもしれません。と簡単に書きました。公知資料の方は例えば特開平8-241407 「画像処理システムの特許」SIGGRAPH97 Recovering High Dynamic Range Radience Maps from Photographなどの一例を挙げるに留めますが、このような画像をぼんやりさせる効果のために「非線形ガンマ変換→畳み込み→ガンマ逆変換」を行ったり、あるいは種々のボケ画像形成のために「フィルム特性を再現する変換カーブ→畳み込み→フィルム特性逆変換カーブ」を行う例を挙げている公知資料が見つかります。そのため、特許の新規性という点において、このような公知資料などと比較した上で、特許審査を通過するかどうかは若干の疑問があります。　また、上に書いたようにJPの請求項はそもそも規定範囲が非常に狭く特許回避は容易で、現実には他社技術の抑止力にはなりえないと思います。当然、請求項からすると「アルゴリズム」というような上位概念による抽象化は欠けており、そもそもアルゴリズムを規定する特許にはなりえていないように思えます。　この感想に対しては、前回桜雷さんも「請求項に式を書いてしまっているのは気になっている」「日本のは細かすぎたかもしれない」というような感想を書かれていましたから、同じご理解はされていたことと思います。また、同様の機能を有するソフトの作者の方々もおそらく「請求項に規定されている式は使っていない」と答える方が多いだろう、と思います。それだけ、規定範囲が非常に狭い特許申請になってしまっています。　また、USPの方ももし仮に通過したにせよ、現在のClaimであれば特許回避は非常に容易で、具体的な話は省きますが、他の類似のソフトも現状ですらほとんどがそのClaimを回避しているだろう、と考えます。　そのように、以前お話を伺ったときには、特許審査通過の可能性およびその実抑止力には疑問を感じましたが、とりあえずの感想としては> 　ところで、私自身は特許はあまり好きではないです。といっても、「個人としては」ですけど。> それに、特許を申請する桜雷さんの考えも良く理解できます。> > 　で、例えば実はワタシの手元にはIrisFilterと同様の機能を持つ自作Photoshop用のプラグインが> あります。こちらは従来からあるアルゴリズム組み合わせたものですが、私がどうしても> 欲しかった16bitモード対応、距離チャンネル対応（最新のバージョンではIrisFilterでも> 対応されたようですが）、そしてAdobeの通常のプラグインインターフェース、という> ものを備えたものです。あくまで、趣味で作成しているものですが自分で好きなようにできるので> 自分用にはなかなか良いです。で、こうした個人作成のソフトはインターネットに満ちあふれています。> そんな個人で作成してインターネットにあふれているソフトがさまざまな特許などで、出しづらい> 雰囲気を近年ひしひしと感じます。そんな雰囲気がそれほど好きでないのもまた確かです。 >　それで、少し知りたいのですが、私は自分で作ったプラグインなどもいつもそうしているように>何かの話のネタを作って、ソフト自体はフリーで配布すると思います。で、私以外にも>自分で画像処理やプログラミングをしている人は多いので、そんなこともあるだろう、と>思いますが、そういうときに桜雷さんはどうされるつもりでしょうか？> 　とはいえ、繰り返し書きますが、IrisFilterを拝見して、非常に面白く要望の高そうな> ソフトだなぁ、うれしく思いました。これからも、楽しみにさせて頂きます。 とメールで書かせて頂きました。それに対して桜雷さんの「特許を出したのは自分の研究が報われる部分が欲しいから」「自分や一部企業が独占して人が使えないような状態は望まない」「広く人に渡って安価で標準的に使えるように活動していきたい」「個人で作っている物に文句をつけても仕方ない」というような内容のお答えを頂き、「自分や一部企業が独占して人が使えないような状態は望んでいない」というお言葉と「いちいち個人で作っている物に文句をつけても仕方ない」というご判断を聞かせて頂き、納得しておりました。ですから、hirax.netで桜雷さんの特許申請についてさらに詳しく言及するかなどについては> > 目立つように書いた場合には、異議申し立てをする会社や人が現れる可能性が> > 高くなると思います。なので、それは必ずしも桜雷さんに対して良い方向に向かう> > とは限らないです。これは桜雷さんの好きな選択を尊重したいと思います。と、桜雷さんの希望を尊重することにし、「ややこしくなるのは避けたいのでそのままにしておいてほしい」という桜雷さんの判断をもとに、それ以降申請特許件には触れず、またなんのアクションもとらずにいました。　そういう桜雷さんからのご相談に乗っていた経緯で私自身は納得していたため、前回のメールのような> ソフトの公開を停止、回収されない場合には、ライセンス料の請求や法的な措置に出る考え> でおります。という対応には実に困惑を感じざるをえません。このようなことをされる予定であるならば、そもそも指摘の請求項には抵触していないので無関係である特許申請だと考えてはおりますが、そのような行為が私自身に及ぶことを防ぐために、特許庁への第三者による資料提供の制度に基づいて、公知資料の特許庁へ情報提供を行わせて頂こうと考えています。本当に、以前の桜雷さんのメールで書かれていた内容と今回の対応の違いは誠に残念でなりません。　また、多くの技術者は自らの特許申請・他社技術調査及び特許回避・あるいは異議申し立てなどを日常的に行っており、特許にいやでも慣れ親しんでいることが多い、ということはここに書き加えておきたいと思います。ですから、おそらく技術者以外の方が想像するよりも一般的に技術者は他者の特許を意識・尊重していることが多い、ということはぜひ理解しておいて頂きたいと思います。　最後になりますが、桜雷さんの特許申請というものは、後から他社から訴えられることを防止し、自分の技術の使用を保証するために、単に公開目的で使用するには有効であると思いますので、そのように活用されることを望んでいます。また、個人的には桜雷さんが良い製品をこれからも提供されていくことを願っております。　それでは、長文になりましたが、失礼させて頂ます。jun hirabayashi jun@hirax.net

■Photoshopアイコンピンバッジセット　

　Photoshopアイコンピンバッジセットのプレゼント・キャンペーン。