On Fri Jun 19 15:42:20 2026 +0000, Rose Hellsing wrote:
Wines EMF handling appears to be lossy so I made this a `todo_wine` for now since fixing that seems out of scope for this MR Oh, this is the possibility I was worried about.
Currently, Wine is converting to EMF in all cases, so the enumeration behavior matches native (other than Wine's WMF->EMF conversion being broken it sounds like?). So changing it to the WMF records risks causing a regression as an application might depend on that. I hadn't realized before reviewing this that Wine's gdiplus has a working (if flawed) route for drawing WMF images, and after that I didn't re-evaluate what you needed for this bug, and so I sent you on an unnecessary side-quest. Sorry about that. It sounds like all you *really* need is the format detection and encoding fix. Unless you know another case where native does use the WMF records, we should probably not introduce the separate WMF enumeration path so we don't risk a regression, and keep depending on the EMF conversion as we did previously. Storing the WMF handle is a good change though (as that lets us properly manage the lifetime), even though we don't actually use it for anything else. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11180#note_143651