カテゴリー別

お絵描き、デザイン

写真、動画関連ソフト

アメーバピグ専用ソフト

ホームページ関連

画像処理

スキャナー用

SEO 関連

お楽しみ

その他

過去ログ

2017年03月21日(火)

GetGlyphOutline で取得できる GLYPHMETRICS の性質について、調査終了

前の記事 の続きです。

私のパソコンにインストールされている全てのフォントの
全ての文字について GetGlyphOutline する実験が終了しました。

やはり、得られるグリフを - gmptGlyphOrigin.x + 1
平行移動すると、図形の描かれる x 座標を 0 以上にできました。

もちろん、未知のフォントでそうならない可能性もありますが、
gmptGlyphOrigin.x の定義からいって、そうならないとしたら、
フォントか OS の不具合と考えてよさそうです。

次に、- gmptGlyphOrigin.x + 1 平行移動したグリフの x 座標が、
常に、gm.gmBlackBoxX + 2 以下になるかのテストもしました。

これについてはならないフォントが見つかりましたが、
やはり、gm.gmBlackBoxX の定義からいって、
OS か フォントの不具合と考えてもよさそうです。

で、そうならないフォントは、@Malgun Gothic、
ハングル文字用のフォントみたいですね。(@ なので縦書き用)

うまくいかない文字は、U+302E、U+303E。
それぞれ、文字コード表によると、
Hangul Single Dot Tone Mark、
Hangul Double Dot Tone Mark。

このページ にある、去声、上声 記号だと思われます。

ま、縦書き用のフォントだし、
現在ではあんまり使われない記号っぽいですね。

ちなみに、この実験は、 文字に縁取りするノ の改良のために行いました。

文字に縁取りするノは文字や文章を画像に一括変換するソフト
です。 ホームページとかで気軽にカラフルな文字を
使ってみたい人は、是非、お試しあれ♪#

最新版は、こちらのページからダウンロードできます

で、この実験結果を受けて、文字に縁取りするノを
ちょっとだけ高速化する予定です。お楽しみに〜。

文字に縁取りするノ
文字に縁取りするノ - ダウンロード
文字に縁取りするノ - 更新履歴
ご意見・ご要望連絡窓口


2017年03月17日(金)

GetGlyphOutline で取得できる GLYPHMETRICS の性質について、またまた調査

前の記事 で、再調査した GetGlyphOutline ですが、今度は
インストール中の全てのフォントについて調べてます。

まだ、途中ですが、次のようなことがわかりました。

ABC の abcA と、GetGlyphOutline で得られる gmptGlyphOrigin.x
は、ほとんどの文字で同じですが、全然違う値の場合がありました。

なのでおそらく GetGlyphOutline で得られるグリフの出力位置は、
- gmptGlyphOrigin.x + abcA で求めるのがよさそうです。

次に、全てのフォントでの調査が終わっていませんが、
得られるグリフを - gmptGlyphOrigin.x + 1 並行移動すると、
グリフの座標を常に 0 以上にできるっぽいです。

ちなみに、- abcA + 1 ではダメな文字が結構見つかりました。

さらに、そのときの、グリフの幅は、gmBlackBoxX + 2 で抑えられる
かと思いきや、ダメな (大幅にはみだす) 文字もありました。

ちなみに、この実験は、文字に縁取りするノ
の改良に必要なのでやってます。

文字に縁取りするノは文字や文章を画像に一括変換するソフト
です。 ホームページとかで気軽にカラフルな文字を
使ってみたい人は、是非、お試しあれ♪#

最新版は、こちらのページからダウンロードできます

うーん。なかなか複雑。

アラビア語の出力処理とか
作る人はもっと大変なんでしょうね〜。

文字に縁取りするノ
文字に縁取りするノ - ダウンロード
文字に縁取りするノ - 更新履歴
ご意見・ご要望連絡窓口


2017年03月14日(火)

ディスプレイの GetDeviceCaps の DPI、変じゃない?

わけあって、ディスプレイのデバイスコンテキストの
DPI 回りを調べてるんだけど、何かおかしいような。

GetDeviceCaps(LOGPIXELSX) で得られる DPI と、
HORZSIZE、HORZRES から計算される DPI が違いすぎない?

うちの環境だと、得られる DPI は 96 なのに、
計算される DPI は、92 あたりです。

↓ 実験の出力結果

531mm = 1920px 96/91.8418 DPI
299mm = 1080px 96/91.7458 DPI

↓ 実際のプログラム、抜粋

CClientDC dc(NULL);
const double INCH_MM = 25.4;
 
CSize sizeMm, sizePx, sizeDpi;
sizeMm.cx = dc.GetDeviceCaps(HORZSIZE);
sizeMm.cy = dc.GetDeviceCaps(VERTSIZE);
sizePx.cx = dc.GetDeviceCaps(HORZRES);
sizePx.cy = dc.GetDeviceCaps(VERTRES);
sizeDpi.cx = dc.GetDeviceCaps(LOGPIXELSX);
sizeDpi.cy = dc.GetDeviceCaps(LOGPIXELSY);

double dpiX = (double)sizePx.cx / ((double)sizeMm.cx / INCH_MM);
double dpiY = (double)sizePx.cy / ((double)sizeMm.cy / INCH_MM);

std::wcout
  << sizeMm.cx << L"mm = "
  << sizePx.cx << L"px"
  << L" " << sizeDpi.cx << L"/" 
  << dpiX << L" DPI" << std::endl;

std::wcout
  << sizeMm.cy << L"mm = "
  << sizePx.cy << L"px"
  << L" " << sizeDpi.cy << L"/" 
  << dpiY << L" DPI" << std::endl;

うーん、何でやねん?
わかる人いたら、コメントでも残してね。

ご意見・ご要望連絡窓口


2017年03月10日(金)

GetGlyphOutline で取得できる GLYPHMETRICS の性質について、再調査

少し前の記事 で、調査した GetGlyphOutline ですが、
思い違いがあったので再調査しました。

前回の調査では、GetGlyphOutline を GGO_BEZIER を指定して呼び出し、得られたデーターを、 Gdiplus::GraphicsPath に変換。
GetBounds して、実際の図形の範囲を取得していました。

が、GetBounds はベジェ曲線の正確な範囲を
返さないのを忘れていました。

仕様書には何も書かれていないようですが、
全ての制御点を含む範囲を返してるような気がします。

ちなみにベジェ曲線は、制御点を結んだ多角形の中に収まる性質がある
ので、その範囲にベジェ曲線が収まることは保証されていますが、
一般的には、実際に描かれる図形よりは大きめになっちゃいます。

で、自作の Bounds を計算する関数で調査しなおすことにしました。

結果は、それほどかわりませんでした。

MS Pゴシックの場合
bounds.X - abcA の全ての文字での最小値は、
-1
bounds.X - gmptGlyphOrigin.x だと
-0.484375
なので、abcA は、実際の開始位置の切り上げっぽい値、
gmptGlyphOrigin.x は四捨五入っぽい値のようですね。

abcB - bounds.Width の全ての文字での最小値は、
-1
gmBlackBoxX - bounds.Width だと
-0.96875
なので、abcB、gmBlackBoxX ともに
実際の文字幅の切り捨てっぽい値のようです。

以上の結果からわかることは、GetGlyphOutline で取得した図形を
- abc.abcA 並行移動したり、- gmptGlyphOrigin.x しても、
負の座標を含む場合があるということですね。

全てのフォントで成立するかはわかりませんが、少なくとも
MS Pゴシックでは、さらに +1 並行移動すれば、
図形の x 座標は、0 以上を保てそうです。
(ベジェ曲線の制御点は負になる可能性があります)

座標が負になるということは、普通に 0 以上の定義域を
持つスクリーンに描いた場合に欠けるということですな。

ちなみに、この実験は、文字に縁取りするノ
の改良に必要なのでやりました。

文字に縁取りするノは文字や文章を画像に一括変換するソフト
です。 ホームページとかで気軽にカラフルな文字を
使ってみたい人は、是非、お試しあれ♪#

最新版は、こちらのページからダウンロードできます

文字に縁取りするノ
文字に縁取りするノ - ダウンロード
文字に縁取りするノ - 更新履歴
ご意見・ご要望連絡窓口


2017年03月02日(木)

GetGlyphOutline で取得できる GLYPHMETRICS の性質について

2017/03/10 追記 ---------------
ベジェ曲線の場合、GraphicsPath::GetBounds が図形の描かれる範囲
よりも広い範囲を返しがちなのを忘れていたので、実験しなおしました。
再調査の記事 ですが、意外に結論は同じっぽいです。
---------------

文字画像コンバーターの、文字に縁取りするノ
で字形を取得する API を、 GraphicsPath::AddString から
GetGlyphOutline に変更する作業をしたのですが、
そのときに、わかったことを書きます。

まず、GetGlyphOutline で取得できる GLYPHMETRICS
の gmptGlyphOrigin.x は実際に得られる字形の
下限にはなっていないみたいです。

具体的には、GetGlyphOutline を GGO_BEZIER フォーマットフラグ を指定して呼び出し、得られたデーターを、 Gdiplus::GraphicsPath に変換。
GetBounds すると、gmptGlyphOrigin.x よりも小さい x 座標が返ります。

もちろん、常にというわけではなくて文字によってはです。

いいかえると、字型を - gmptGlyphOrigin.x だけ並行移動すると、
GetBounds の x は負になりえます。ざっと眺めてみると、- 0.5
よりは大きいみたいなので、四捨五入的値のようですね。

ということで、字型を - gmptGlyphOrigin.x 並行移動して
画像を出力すると、文字が欠ける可能性があるわけですな。

同様に、GLYPHMETRICS の gmBlackBoxX も、
実際に得られる字型の幅の上限にはなっていない模様。

やはり、四捨五入的値のようです。

そんなわけで、文字の縁ぎりぎりに線を引くには、
GLYPHMETRICS の値が使えますが、文字に被る可能性
もあるので、絶対に文字に被らない線を引きたい場合には、
GetBounds とかを使って自分で調べる必要がありますよって話ですわ。

ちなみに、GetCharABCWidths で得られる abcB も
だいたいの文字ではうまくいきますが、やっぱり、
実際の幅を越える場合があるので要注意ですよ。

・・・

文字に縁取りするノはもうそろそろ、最新版を公開予定ですが、
ホームページとかで気軽にカラフルな文字を
使ってみたい人は、是非、お試しあれ♪#

最新版は、こちらのページからダウンロードできます

文字に縁取りするノ
文字に縁取りするノ - ダウンロード
文字に縁取りするノ - 更新履歴
ご意見・ご要望連絡窓口


2017年02月28日(火)

DoModel で表示するダイアログを最大化状態で表示する方法は?その2

まだ、よくわかりません。ぱーと2^^。

Windows API 的には、DialogBoxParam とかで表示されるダイアログを
最大化状態で表示したかったのですが、今のところできてません。

というか、あきらめました。

複雑な方法を取れば、できると思いますが、
複雑な方法を取ると、OS によってうまくいったり
いかなかったりしかねないので、やめときます。

で、前のブログの最後に書いたとおり、
モードレスダイアログで、モーダルダイアログを
シミュレートする方法をとりました。

自分の場合、昔書いたコードがあったので、
一瞬で終わりましたが、ゼロから書くとすると
少し大変かもしれませんね。

具体的には、Dialog の作成には、 CreateDialogParam を使用します。
ATL/WTL だと、CDialogImpl::Create にラップされてるやつです。

で、自前の DoModal っぽい関数から、CreateDialogParam して、
自前のメッセージポンプを書くと、シミュレートできます。

さらに、メッセージポンプの最初の処理として、 IsDialogMessage
呼んだり、親ウィンドウを EnableWindow で使用不可にしたりすると、
モーダルダイアログっぽくなります。

そんなにコード量は多くないけど、
よくわかってない人には書けないかも。

・・・

あんまり、関係無いけど、
文字画像生成ソフト、文字に縁取りするノ
の新機能実装中の出来事です。

ホームページとかで気軽にカラフルな文字を
使ってみたい人は、是非、お試しあれ♪#

最新版は、こちらのページからダウンロードできます

ちなみに、新機能はだいたいできて、あと少しというところ。
根幹の部分をいじったので、少しテストに時間をかけるかも。

文字に縁取りするノ
文字に縁取りするノ - ダウンロード
文字に縁取りするノ - 更新履歴
ご意見・ご要望連絡窓口


2017年02月27日(月)

DoModel で表示するダイアログを最大化状態で表示する方法は?

まだ、よくわかりません^^。

Windows API 的には、DialogBoxParam とかで表示されるダイアログを
最大化状態で表示したかったのですが、今のところできてません。

最初は、普通のコードとして、WM_INITDIALOG メッセージで
ウィンドウサイズを変更。最大化状態にしたい場合は、
WM_APP みたいな適当なメッセージを自身にポストして、
そのメッセージの処理で最大化してみました。

普通のウィンドウだとこれでうまくいきますが、
(もちろん、WM_INITDIALOG のかわりに WM_CREATE)
DoModal だとダメみたい。一瞬、最大化しますが、
何らかのタイミングで普通のウィンドウに戻されちゃいますわ。

ちなみに、ウィンドウサイズを変更してから
最大化しているのは、「元に戻した」ときの
サイズを設定するためです。

話を元に戻して、レストアされちゃうタイミングを調べてみましたが、
かなりたくさんのメッセージが飛んできた後。
捉えづらいっぽいので、他の方法を模索することに。

うーん・・・

DialogBoxIndirect 系でダイアログを表示すれば、
DLGTEMPLATE の引数があるので、style メンバーで、
初期のウィンドウスタイルを指定できるようです。

そこで、WS_MAXIMIZE を指定すればよいのでは?
リソースをロードして、style を変更してみると、

・・・

お! プログラムが落ちた。何でやねん。

調べてみると、LockResource で取得したポインター経由で
メモリーを変更すると、その場で落ちますね。

共有リソースを変更するときは、UpdateResource
とか使って真面目にやらんとダメらしいな。

それにしてもメモリーに書き込みに行くタイミングで
落ちるとは、非常にすばらしい。こういう機能は、本当助かるわー。

で、共有リソースを編集する必要性は無いので、
メモリーをコピーしてそれを編集することにします。

ちなみにリソースのメモリーサイズは、 SizeofResource
で取得できるので、あとは、CopyMemory でもすれば OK です。

今度はどうかな?

・・・

うーん。落ちないけど、全然だめだな。

よく調べてみると、LockResource でロックした
オリジナルの style は、0xFFFF0001。
|= WS_MAXIMIZE しても変化ありません。

そりゃ、挙動が変わるわけないわ。
どういうことやねん。 ← 今、ココ

・・・

あんまり、関係無いけど、
文字画像生成ソフト、文字に縁取りするノ
の改良中に発生した現象です。

ホームページとかで気軽にカラフルな文字を
使ってみたい人は、是非、お試しあれ♪#

最新版は、こちらのページからダウンロードできます

・・・

たぶん、CreateWindow で、DoModal を
シミュレートしちゃった方がよさそうね。

文字に縁取りするノ
文字に縁取りするノ - ダウンロード
文字に縁取りするノ - 更新履歴
ご意見・ご要望連絡窓口


2017年02月24日(金)

コンパイル警告、shlobj.h(2228): warning C4091 を修正

windows kits 8.1 のヘッダーファイルをコンパイルすると
出力される警告が、いいかげん、うざくなったので、修正しました。

1>c:¥program files (x86)¥windows kits¥8.1¥include¥um¥shlobj.h(2228): warning C4091: 'typedef ': 変数が何も宣言されていないときは、'tagDTI_ADTIWUI' の左辺を無視します。

ってなやつです。

一応、ShlObj.h を ShlObj_bk.h みたいな
名前のファイルにコピーしてバックアップ。
ShlObj.h を編集してしまいます。

↓ 修正前。

typedef enum tagDTI_ADTIWUI
{
    DTI_ADDUI_DEFAULT               = 0x00000000,
    DTI_ADDUI_DISPSUBWIZARD         = 0x00000001,
    DTI_ADDUI_POSITIONITEM          = 0x00000002,
};

↓ 修正後。

typedef enum tagDTI_ADTIWUI
{
    DTI_ADDUI_DEFAULT               = 0x00000000,
    DTI_ADDUI_DISPSUBWIZARD         = 0x00000001,
    DTI_ADDUI_POSITIONITEM          = 0x00000002,
} DTI_ADTIWUI;

ま、たぶんコレで大丈夫でしょ。

DTI_ADTIWUI がほかの場所でも定義されてたりすると
別のコンパイルエラーが発生する可能性があるので、
何かもっとめちゃくちゃな名前を付けてもいいけど、
Microsoft のコーディングの癖的にはこんな感じでいいと思う。

・・・

あんまり、関係無いけど、 文字画像生成ソフト
文字に縁取りするノのコンパイル中に修正しました。

ホームページとかで気軽にカラフルな文字を
使ってみたい人は、是非、お試しあれ♪#

最新版は、こちらのページからダウンロードできます

文字に縁取りするノ
文字に縁取りするノ - ダウンロード
文字に縁取りするノ - 更新履歴
ご意見・ご要望連絡窓口


2017年02月23日(木)

WM_DRAWITEM 来ないなーと思ってたら勘違い

久しぶりに新しい画面を作るために、
LBS_OWNERDRAWFIXED のリストボックスを作成。

WTL::CWindowImpl 派生クラスで、
ListBox をサブクラス化して
WM_DRAWITEM をキャッチしようとしたら、
メッセージが来なくて、少しはまりました。

ウィンドウスタイルを色々いじってみたりしたけど、
原因はそんなことじゃなくて、そもそも、
WM_DRAWITEM はリストボックスには来ない仕様の
メッセージで、正しい送り先は、親宛てでしたわ。

まぁ、長年プログラミングしてると常識みたいな感じ
のことなんですけど、うっかりしてました。

初心者は、こういうところでつまずくんだろうねぇ。

親宛てというのは、リストボックスの動きを変えるための
メッセージが、親ウィンドウに発生するという意味です。

で、リストボックス自身のウィンドウプロシージャーで
そういうメッセージを処理するための仕組みが WTL にもあります。

REFLECT_NOTIFICATIONS()

と、

MSG_OCM_DRAWITEM(OnDrawItem)

マクロです。

親クラスのウィンドウプロシージャーを定義する、
BEGIN_MSG_MAP_EX と END_MSG_MAP の間の最後の行に、
REFLECT_NOTIFICATIONS() を書くと、
親ウィンドウで処理されなかった
子コントロール制御用ウィンドウメッセージが、
送信元の子に再送信されます。

BEGIN_MSG_MAP_EX(親クラス)
  REFLECT_NOTIFICATIONS()
END_MSG_MAP()

で、子のウィンドウプロシージャーでは、
MSG_WM_DRAWITEM のかわりに、MSG_OCM_DRAWITEM
を使用してメッセージをキャッチすれば OK です。

BEGIN_MSG_MAP_EX(子クラス)
  MSG_OCM_DRAWITEM(OnDrawItem)
END_MSG_MAP()

・・・

ま、そんなわけで、文字に縁取りするノ最新版は
オーナードローのリストボックスを使った新機能がつく予定ですが、
文字画像生成ソフト にピンときた方は、現在公開中の
文字に縁取りするノを使ってみていただけると嬉しいです!

最新版は、こちらのページからダウンロードできます

 

文字に縁取りするノ
文字に縁取りするノ - ダウンロード
文字に縁取りするノ - 更新履歴
ご意見・ご要望連絡窓口


2016年09月20日(火)

Windowsのカーソルファイル (cur) の解析、その3

今日は、png から cur に変換するプログラムも
だいたいうまく動くようになりました。

私の勘では、カーソル画像の中央部分に、
ホットスポットの y 座標が来るようにするのかと
思いましたが、違うみたいです。

ウィンドウを移動する十字矢印のカーソルを調べてみたところ、
単純に、BITMAPINFO の高さはアイコンの高さの倍になってます。
(十字矢印のホットスポットは 0 じゃない)

なんとも変な仕様ですけど、きっと
歴史的な経緯があるんでしょうね。

そんなわけで普通に、BITMAPINFO での高さを倍にして
保存すると、正しいカーソルとして認識されました。

謎のゴミのラインについては付加しなくても大丈夫でした。
(前回の記事参照です)

意味不明だし、じゃないと困るわ〜。

・・・

そんなわけで、うまくいったので、
ミルノ PC フォトフレーム 2.0 からは
独自カーソルがきれいになります。

1.x では独自カーソルはあまり美しくないですが、
試してみてください。見れないほどじゃないですよ。

日本語の最新版はこちらのページから、ダウンロードできます
You can download the latest version of Miruno PC Photoframe here.

ご意見・ご要望はこちらからどうぞ
You can contact me by this mail form.

ちなみに、独自カーソルは、メイン画面の端にカーソルを
もっていくと表示される、「親フォルダーへの移動」を表すやつと、
クリックで選択が解除するときに表示されるやつがあります。

美しくないのは、解像度が 32 x 32 で
透明度情報に段階がない (透明か否か) からです。

2.0 からは、32 〜 128 サイズのアイコンが用意され、
透明度も 256 階調になるのできれいになる予定です。

まだまだだけど、お楽しみに〜♪

ミルノ PC フォトフレーム
ミルノ PC フォトフレームのダウンロード
ミルノ PC フォトフレームの更新履歴
ご意見・ご要望連絡窓口


| 1/3PAGES | >>