Phil Krylov wrote:
I have submitted a patch that fixes creation of on-disk _enhanced_ metafiles
a few days ago:
http://article.gmane.org/gmane.comp.emulators.wine.patches/23393
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.
Eric
