On Thu, 13 Apr 2006 16:39:02 -0400 Eric Frias <[EMAIL PROTECTED]> 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.