[gdi] bug reading/writing metafiles on sparc

Eric Frias efrias at syncad.com
Thu Apr 13 15:39:02 CDT 2006

Phil Krylov wrote:

>I have submitted a patch that fixes creation of on-disk _enhanced_ metafiles
>a few days ago:
Thanks for the pointer, I hadn't seen that patch. 

>It byteswaps EMF records just for writing to disk. Adding
>byteswapping for reading from disk seems very easy - just feed the file
>content to the same byteswapper functions. I think it is a bit more clean
>than your approach.
I like how yours works -- one function call converts both directions.  
My only hesitation was that all of the operations -- read, copy, get 
bits & set bits -- change from simple writes of a block of memory to 
looping through the records one-by-one to convert them.  That's not a 
bad price to pay for cleaner code...

Here's a question that I guess is worth asking: what kind of data do you 
expect to get when you call GetMetaFileBitsEx()?  Do you get bits in the 
in-memory format, where METARECORD structures have values in the native 
format?  Or do you get data in the on-disk format?  My first reaction 
was that you'd want the on-disk (platform-independent) format, because 
you would probably be writing the data to a file or to the clipboard, 
and you'd want that to be as platform-independent as the .wmf files 
are.   But I was looking over the API and there are also functions like 
EnumMetaFile() and PlayMetaFileRecord() that give or take one 
METARECORD, and that suggests that there are programs out there that try 
to make sense of the data in the individual records and that you'd 
expect to see native byte order used.

Like you, my immediate problem is just getting wine to write out 
metafiles that the rest of the world can read.  But as soon as I change 
the file writing, I feel like I should change the reading function to be 
consistent, and then it starts to get a bit confusing.


More information about the wine-devel mailing list