ddf.EscherClientAnchorRecord assumes that it has 9 2 byte records, and hence is 26 bytes long. In some powerpoint files, it just has 4 2 bytes records, so the size is only 16 bytes. Because of its assumption, this breaks things. Attached is a patch to make it check that it has the data before trying to read the last 5 fields, which stops it breaking on 4 field records. (However, it makes no attempt to ensure that the first 4 fields correspond to the ones present in a short record, since there's no guide I can find to explain what the 4 fields in a short record actually correspond to)
Created attachment 14954 [details] patch for short records
Created attachment 14955 [details] Updated patch that also handles the size when writing back out Forgot to store the fact that we are a short record for when writing back out. This version uses that when writing out, and disables short record status if any of flags 5-9 happen to get set
Comitted, thanks. pls verify.
Created attachment 15172 [details] Patch to the unit test for EscherClientAnchorRecord Update to the unit test, to include a test for short records (Shows that the currently applied patch works just great)