OS <3.2 support issues due to zip header changes

[a-a]

The readme states compatibility with OS 3.0.2 and later when converting Lua documents, however it is not made clear that the headers in the ZIP file are actually targetting a later OS version, and as such if opening a tns created by the current version of Luna, a handheld running an OS below 3.2 will display the message "You must update your software to the latest version to view this document." (In my case, this was OS 3.1.0)

Looking at older releases, before BMP support in the TNS file was added, byte 0x07 in the resulting header is 0x35, whereas in the current release, it is 0x37. This was first changed at commit 15b8187#diff-f1c061b8ba098a412c4fb2a096f39485
Modifying the resulting TNS in a hexeditor or recompiling with a modified "LOCALHEADERMAGIC2" value from zip.c , will cause the file to open on an OS 3.1.0 handheld instead of erroring, which leads me to believe that the header structure of the TNS files changed between these versions.

I have pondered a few different options:

1. Edit the readme to make clear that <3.2 will not work out of the box (zip.c required modification)
2. Add a command line flag to use the lower version header in the zip generation stage.
3. Check whether platform.apilevel = "1.0" is defined in the lua, and roll header version back only on this case? I am not sure if all script authors actually bother with defining api level.

Thoughts?

[Vogtinator]

Check whether platform.apilevel = "1.0" is defined in the lua, and roll header version back only on this case? I am not sure if all script authors actually bother with defining api level.

This is actually the correct solution as that's what TI software looks for in lua documents as well.

Luna should default to OS 3.1.0 compatibility unless platform.apilevel is set to a higher value or BMPs are added.

Can you open a PR?

[a-a]

Thanks, that makes sense, I'm working on it.
For now I've got minizip working with two versions of the header, but it's getting late here so I will pick up again tomorrow to finish off the logic in luna, and then get it tested.

[a-a]

Opened #11
Behavior when running with input from stdin has been left unchanged for now - I can't figure out a nice way to do this without first consuming stdin or requiring significant changes to the structure. At the moment stdin is taken well inside read_file_and_xml_compress(), which is after opening zip headers.