This is actually a bigger issue than most people realize. All of the charts in Excel and PowerPoint are embedded as EMF files, which indeed are poorly documented.
But even worse than WMF/EMF is the EMF+ Dual format used in recent versions of Office. It is an almost completely undocumented format that hides GDI+ commands within EMF comment records in parallel with the normal GDI-based records. Because only Microsoft knows the format of the secret comment records, only it can leverage them to produce higher quality results by rendering via GDI+. Applications which understand EMF will skip over the comments, oblivious to the secret data (which is perhaps why awareness of this issue isn't more widespread). Knowledge of these records would be especially useful when converting to other vector formats such as SVG or PDF.
Many people have written to Microsoft in an attempt to get EMF+ documented, so far to no avail (and it was introduced no later than Office 2000).
Exactly, if the code expects the PNGs in the datastream to be one after the other (I know there is code out there that does this, my Java PNG library supports it by request), after the first frame of an APNG it won't find a PNG header, which means there will be an error due to the presence of the APNG. I really don't see any way to prevent this breakage without using a new signature/mime type and encouraging people to support APNG...instead of trying to be tricky about backwards compatibility.
This would be much better as a scaled-down profile of MNG. To make APNG backwards-compatible they've just stuck a bunch of user chunks after the IEND chunk, which of course is supposed to be the last chunk. Besides being a violation of the specification (which is no small matter) this also breaks existing code which reads multiple consecutive PNGs from a datastream. In other words you cannot always use EOF to detect the "actual" end of the image as they seem to assume!
They've had this at Berkeley for a while too, and it has been written about extensively. You can even sign up to use the service online if you are a programming teacher or TA at another school.
I used it as a TA for a lower division class at Cal and it really was quite impressive--color coding similar sections, etc. A human review is necessary or course, but there was never really any doubt that the top few catches were cheating.
FYI, after realigning the message text you can generate a png yourself by prepending
P1
127 2149
to the top of the message, and running the command: pbmtopgm 1 1 output_stream.txt | pgmtoppm white | ppmtogif | gif2png -fO > msg.png
Slashdot Mirror
This is actually a bigger issue than most people realize. All of the charts in Excel and PowerPoint are embedded as EMF files, which indeed are poorly documented.
But even worse than WMF/EMF is the EMF+ Dual format used in recent versions of Office. It is an almost completely undocumented format that hides GDI+ commands within EMF comment records in parallel with the normal GDI-based records. Because only Microsoft knows the format of the secret comment records, only it can leverage them to produce higher quality results by rendering via GDI+. Applications which understand EMF will skip over the comments, oblivious to the secret data (which is perhaps why awareness of this issue isn't more widespread). Knowledge of these records would be especially useful when converting to other vector formats such as SVG or PDF.
Many people have written to Microsoft in an attempt to get EMF+ documented, so far to no avail (and it was introduced no later than Office 2000).
I recently wrote about this issue in more depth.
Exactly, if the code expects the PNGs in the datastream to be one after the other (I know there is code out there that does this, my Java PNG library supports it by request), after the first frame of an APNG it won't find a PNG header, which means there will be an error due to the presence of the APNG. I really don't see any way to prevent this breakage without using a new signature/mime type and encouraging people to support APNG...instead of trying to be tricky about backwards compatibility.
This would be much better as a scaled-down profile of MNG. To make APNG backwards-compatible they've just stuck a bunch of user chunks after the IEND chunk, which of course is supposed to be the last chunk. Besides being a violation of the specification (which is no small matter) this also breaks existing code which reads multiple consecutive PNGs from a datastream. In other words you cannot always use EOF to detect the "actual" end of the image as they seem to assume!
I used it as a TA for a lower division class at Cal and it really was quite impressive--color coding similar sections, etc. A human review is necessary or course, but there was never really any doubt that the top few catches were cheating.
See MOSS and the 1998 Wired article about it.
-- Chris
P1
127 2149
to the top of the message, and running the command:
pbmtopgm 1 1 output_stream.txt | pgmtoppm white | ppmtogif | gif2png -fO > msg.png
--Chris
Here is the message as a monochrome png.
--Chris