Magic for xlsx

[fursich]

this PR is to demonstrate reproduction case that I described with #35 .

Attached xlsx is a simple blank sheet, generated by google sheet (by exporting the original spreadsheet to xlsx).

[fursich]

this would allow marcel to look up wider range (I have to admit it's heuristic though) for [Content_Types].xml.

I'm guessing it can be intentionally done for low cost operation, but let me know what you think.

[georgeclaghorn]

This is fine, thanks. Could you do the same for the .docx and .pptx matches above?

[fursich]

The composing parts of google-generated office documents seems to have reversed order. Consequently, the larger the file gets, the later magic strings appears in the file - meaning, we have to go searching for longer bytes, and some sort of trade-off would be needed at certain point.

pptx naturally has larger components (even though test fixture is nothing more than a blank slide), so it has to be at least 30:28168 to find out the string (but that'll be not enough for a pptx with a few contents, so tentatively I put 65536 bytes as maximum search range)

Looks like we have two choices here:

1. to align with mimemagic that searches the string upto ~5000 bytes. In this case we cannot add google-generated pptx fixture, as it naturally fails.

2. to take bigger range than mimemagic does, so that it can identify (at least) some office files.

I'm assuming the latter might make sense, but please feel free to correct me if I'm wrong.

In any case we might have to rely on other fallback strategies for larger google-generated office files. Probably the question would come down to "to what extent do we want to try hard to find out embedded magic string?" - let me know what you would think.

[fursich]

At least for a blank xlsx file 4096 would be sufficient. I used a common range for the three different format though, so as to make these numbers less cryptic.