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 mask size would have a problem with gmBlackBoxX being 0. But it would be best to skip updating min_x, min_y, max_x, and max_y in this case, since we don't really need the mask to include the position of an empty glyph. Does Wine's GGO return a non-zero value currently? That would mean a regression in gdiplus drawing only empty glyphs when you fix GGO.
I didn't mean that. Native GGO returns a non-zero gmBlackBoxX/Y value. Wine's GGO currently returns a zero gmBlackBoxX/Y value for empty glyph. I ran some tests [1] before submitting. Please read that, for details. [1] http://newtestbot.winehq.org/JobDetails.pl?Key=2170
Skipping updating min-max variables might be a good idea, but I feel this is the off topic issue. The patch intends to avoid regressions after fixing GGO. In other words, the aim is creating the same mask before and after the commit.
The loop isn't going to have a problem with 1 either. As long as the calculated mask size includes the whole area where glyphs will need to be drawn, there won't be a problem. Adding some extra pixels to it isn't going to do anything take a little bit of extra time.
The logic you're adding still potentially makes the mask larger than necessary, and it doesn't appear to do this better than the existing logic in any meaningful way. And since the correct solution would remove the new code entirely, I don't see the point of adding it.