I've discovered that the serialisation of properties from EscherOptRecord isn't behaving on some EscherOptRecords in PowerPoint files. The result is that they are serialised to a different (and I suspect incorrect) set of bytes (compared to the bytes used to build the record). I've added a (disabled) test to the end of TestEscherOptRecord which shows up this bug - the serialised form will differ at byte 28. (I'm going to have to leave a few HSLF tests disabled for now, as they're being incorrectly tripped by byte-stream changes in EscherOptRecords)
I also discovered this bug some time ago but put it aside for a while until my hands are free. The problem is in org.apache.poi.ddf.EscherArrayProperty. EscherArrayProperty.checkComplexData overrides the record data if the size of the array is 0. Regards, Yegor
From some more debugging, it looks like my problem is an EscherArrayProperty, but not an empty one. It's a problem in the simple part, more debugging is required though.
Ah ha! After much poking with a debugger, I finally properly understand Glen's cryptic comment in setArrayData I've added a new flag, to record when the simple part's size doesn't include the header length, so we can write it out the same. I'm not sure if this'll help the zero size or not though, I'll have to find one to be sure.