Re: [PATCH 1/2] enhmfdrv: Always set ExtTextOut bounding rect if we're not inside path bracket

[Huw Davies]

On Tue, Apr 26, 2016 at 02:19:27PM +0200, Piotr Caban wrote:
> Signed-off-by: Piotr Caban
>
> dlls/gdi32/enhmfdrv/dc.c             |  6 ++++++
>  dlls/gdi32/enhmfdrv/enhmetafiledrv.h |  1 +
>  dlls/gdi32/enhmfdrv/graphics.c       |  4 +++-
>  dlls/gdi32/enhmfdrv/init.c           |  1 +
>  dlls/gdi32/tests/metafile.c          | 11 +++++++++++
>  5 files changed, 22 insertions(+), 1 deletion(-)

I think we need a better understanding of paths on metafiles.  There
have been a number of patches which mainly hack ExtTextOut when it's
clear that the issues extend beyond that single record.

For example, I've just noticed that a Rectangle within a path doesn't
update the emf's bounds.  This unfortunately was not spotted by
test_emf_GetPath() because for some reason compare_emf_bits() doesn't
check them.

Huw.

[PATCH 1/2] enhmfdrv: Always set ExtTextOut bounding rect if we're not inside path bracket

[Piotr Caban]

Hi,

On 04/28/16 12:14, Huw Davies wrote:
> I think we need a better understanding of paths on metafiles.  There
> have been a number of patches which mainly hack ExtTextOut when it's
> clear that the issues extend beyond that single record.
>
> For example, I've just noticed that a Rectangle within a path doesn't
> update the emf's bounds.  This unfortunately was not spotted by
> test_emf_GetPath() because for some reason compare_emf_bits() doesn't
> check them.

I've sent patches that modify all functions that can be used within the 
path. I've also tested most other functions that are not affected by 
BeginPath call (like StretchBlt, SetPixel, etc).

Please let me know if anything else needs to be done.

Thanks,
Piotr