[gdi] bug reading/writing metafiles on sparc
phil at newstar.rinet.ru
Thu Apr 13 18:22:02 CDT 2006
On Thu, 13 Apr 2006 16:39:02 -0400
Eric Frias <efrias at syncad.com> wrote:
> 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...
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).
More information about the wine-devel