Add support for files with tables.

[psobot]

This PR bumps keynote-parser to version 1.10.0.6 and adds support for packing presentations that contain tables. Prior to this change, running keynote-parser pack ... on presentations with tables would result in invalid .key files. (cc @kortenkamp - this should fix your 600+MB presentation!)

[kortenkamp]

Sounds good – thank you!

I just tried it, but now it fails at re-packing the unpacked presentation:

Traceback (most recent call last):
  File "/usr/local/Cellar/protobuf/3.13.0/libexec/lib/python3.8/site-packages/google/protobuf/json_format.py", line 589, in _ConvertFieldValuePair
    setattr(message, field.name, _ConvertScalarFieldValue(value, field))
  File "/usr/local/Cellar/protobuf/3.13.0/libexec/lib/python3.8/site-packages/google/protobuf/json_format.py", line 722, in _ConvertScalarFieldValue
    return _ConvertFloat(value, field)
  File "/usr/local/Cellar/protobuf/3.13.0/libexec/lib/python3.8/site-packages/google/protobuf/json_format.py", line 799, in _ConvertFloat
    raise ParseError('Float value too large')
google.protobuf.json_format.ParseError: Float value too large
[...]

Is there a way to get more debugging output (like more detailed info which .iwa file contains the wrong data)?

[psobot]

Hmm, interesting - I assume there have been other changes since you sent over your example presentation, as re-packing your large example presentation works on my end. I've just released v1.10.1.1 that should give more verbose error logging and help track down which .iwa file contains the corrupted data.

[kortenkamp]

yes, this has been growing, and I'll send you a refreshed copy.

Using v1.10.1.1 I found that the problem is in DocumentStylesheet.iwa.yaml due to the following line:

        tschchartseriesareasymbolsize: 3.4028235e+38

... which is indeed a bit large for the symbol size. But even then there is another problem with this value: It is actually larger than MAX_FLOAT due to rounding. It is more than the actual max float value 340282346638528859811704183484516925440.0000000000000000 – because 3.40282346e+38 is rounded up to 3.4028235e+38. The output of the maximum float should never be rounded up… but probably that is a bug in some other library you are using?

[psobot]

Huh, fascinating! This seems like it might be a bug in PyYAML. I'll take a peek at that.

[psobot]

@kortenkamp I can't seem to reproduce that error locally at all, but that could be because I have PyYAML==5.3.1 installed locally. Any chance you can upgrade your PyYAML version and tell me if you still see this issue? (Alternatively, it'd be great to see which version you have installed via pip freeze | grep PyYAML.)

[kortenkamp]

hm, pip freeze | grep PyYAML outputs PyYAML==5.3.1. Could it be a problem I am working on Big Sur aka macOS 11?

Here's my full list of python libraries installed via pip.

appdirs==1.4.4
colorama==0.4.3
distlib==0.3.0
filelock==3.0.12
future==0.18.2
keynote-parser==1.10.1.1
Pillow==6.2.2
protobuf==3.13.0
python-snappy==0.5.4
PyYAML==5.3.1
six==1.15.0
tqdm==4.48.2
virtualenv==20.0.21

And I am running Python 3.8.5.

[psobot]

Aha! I can confirm that this is an issue with protobuf==3.13.0, but not protobuf==3.12.0. Still investigating.