On Tue, Feb 16, 2016 at 07:38:33PM +0800, Dmitry Timoshkov wrote:
Huw Davies huw@codeweavers.com wrote:
diff --git a/dlls/gdi32/path.c b/dlls/gdi32/path.c index e09cd0b..166b6b2 100644 --- a/dlls/gdi32/path.c +++ b/dlls/gdi32/path.c
...
@@ -1513,6 +1523,14 @@ static BOOL pathdrv_ExtTextOut( PHYSDEV dev, INT x, INT y, UINT flags, const REC struct path_physdev *physdev = get_path_physdev( dev ); unsigned int idx, ggo_flags = GGO_NATIVE; POINT offset = {0, 0};
DWORD type;
type = GetObjectType(dev->hdc);
if (type == OBJ_METADC || type == OBJ_ENHMETADC)
{
PHYSDEV next = GET_NEXT_PHYSDEV( dev, pExtTextOut );return next->funcs->pExtTextOut( next, x, y, flags, lprc, str, count, dx );}
if (!count) return TRUE; if (flags & ETO_GLYPH_INDEX) ggo_flags |= GGO_GLYPH_INDEX;
Why the special treatment for ExtTextOut()? I can believe we may need to do something with Begin/EndPath, but why this?
According to the tests a path on metafiles just creates a EMR_EXTTEXTOUT record instead of generating a bunch of actual path representation records.
But isn't that just because we only test ExtTextOut()? For example, we don't even test the contents of the emf created in test_emf_GetPath(). What I'm wondering is whether we need to do this to more than just ExtTextOut.
Dmitry, is this the reason you don't want to send it?
No.
That doesn't exactly inspire confidence in this patch...
Huw.