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().
That's a good point. EMF contents get tested in test_emf_ExtTextOut_on_path() and test_mf_ExtTextOut_on_path() though. Alistair, please add a test for EMF contents in addition to what GetPath() returns, see other tests how to do that, there is a helper that will generate appropriate data for you.
What I'm wondering is whether we need to do this to more than just ExtTextOut.
That's also a good point, but it would be a separate effort I'd guess.