>> > Typically, native GetGlyphOutlineW(hdc, ' ', GGO_BITMAP, &gm, 0, NULL, ...)
>> > returns gm.gmBlackBoxX = 1 instead of 0. Unfortunately, Wine's didn't,
>> > and existing source codes (winex11, gdiplus, gdi32) expect 0 in this
>> > case.
>>
>> I don't think the existing code for finding the mas
On Mon, 16 Sep 2013 11:33:34 -0500, Vincent Povirk wrote:
> > Typically, native GetGlyphOutlineW(hdc, ' ', GGO_BITMAP, &gm, 0, NULL, ...)
> > returns gm.gmBlackBoxX = 1 instead of 0. Unfortunately, Wine's didn't,
> > and existing source codes (winex11, gdiplus, gdi32) expect 0 in this
> > case.
>
> Thanks for you comments. The answer is yes, as you guessed.
> Typically, native GetGlyphOutlineW(hdc, ' ', GGO_BITMAP, &gm, 0, NULL, ...)
> returns gm.gmBlackBoxX = 1 instead of 0. Unfortunately, Wine's didn't,
> and existing source codes (winex11, gdiplus, gdi32) expect 0 in this
> case.
I don'
On Sun, 15 Sep 2013 16:32:25 -0500, Vincent Povirk wrote:
> This seems suspicious to me. Why can't we use those values in
> glyphmetrics if GetGlyphOutlineW returns 0? Does Windows provide bad
> values in this case, or is our GetGlyphOutlineW broken?
Thanks for you comments. The answer is yes, as
BTW, we should probably quit early if max_glyphsize is 0 at the end of
the first loop, rather than fail with OutOfMemory.
This seems suspicious to me. Why can't we use those values in
glyphmetrics if GetGlyphOutlineW returns 0? Does Windows provide bad
values in this case, or is our GetGlyphOutlineW broken? When does the
call to GetGlyphOutlineW in the second loop fail, and why ignore those
failures?
