[v3 PATCH] gdi32: Support Begin/End Path for metafile DCs

[Huw Davies]

On Tue, Feb 16, 2016 at 07:38:33PM +0800, Dmitry Timoshkov wrote:
> Huw Davies <huw at 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.