On Thu, 13 Apr 2006 16:39:02 -0400 Eric Frias efrias@syncad.com wrote:
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...
We have to do this conversion one place or another, and I supposed that reading/writing metafile from disk is used less frequently than other metafile operations (mostly record addition and playback).
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.
Yes it really does...
However, I don't think there are a lot of programs using these APIs... I mean, let's implement it one or another way and wait till some such programs break (when ported to big-endian machines;) and see how exactly they will break and fix it then.
Also, when we're dealing with WineLib, we can just document the endianness-behaviour of these functions and developers can do byteswapping in their apps where needed or use other APIs (e.g. CopyEnhMetaFile instead of GetEnhMetaFileBits followed by a disk write).
-- Ph.