Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Google Docs exported .ods fails to load... (in Chrome only) #872

Closed
chrisbeech opened this issue Feb 25, 2015 · 3 comments · Fixed by #874
Closed

Google Docs exported .ods fails to load... (in Chrome only) #872

chrisbeech opened this issue Feb 25, 2015 · 3 comments · Fixed by #874

Comments

@chrisbeech
Copy link

To replicate:

  • Create spreadsheet in Google Docs.
  • Add something to the first cell: e.g. "something"
  • Choose File > Download as > OpenDocument Format (.ods)
  • Upload to your server where ViewerJS resides
  • Try and load the document in Chrome

U'll notice that the file works fine in FireFox and IE. However, in chrome the console spits out the following:

PluginLoader.js:115 Found plugin by mimetype and xhr head: application/vnd.oasis.opendocument.spreadsheet
webodf.js:35 WARNING: refreshOdf called but ODF was not DONE.
webodf.js:35 ERROR: Unable to load styles.xml
15webodf.js:35 will be back later...

@kossebau
Copy link
Contributor

Thanks for the report. Seems that Chrome's DOMParser fails on the UTF-8 BOM at the start of internal xml files in an ODS file exported from Google Docs. Surprised to see that happen.
No fix for that yet, possibly can be worked around by cutting off the BOM on Chromium-based browsers.

BTW, seems the ODS as created by Google Docs is breaking the ODF spec. I tested with https://odf-validator.rhcloud.com/ and a few other tools and all complain about problems.
Please report this to Google, they need to fix creating invalid ODF files. (Just because some other tools have possibly added workarounds to deal with that does not change that these are invalid ODF files, killing the idea of a standard format)

@kossebau
Copy link
Contributor

Having looked more into it, actually it seems not a failure of Chromium. After all the type of the parameter passed to DOMParser.parseFromString is a string, not raw data of a string. So there is no more place for a BOM.
Which is good news in the end, so it's actually a bug in WebODF and can be fixed. No need for workaround or getting another project to fix their code :) First draft of a fix seems to work fine.

@chrisbeech
Copy link
Author

Legend! Thanks so much!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants