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

ODT template opens in Word, after saved by odfdo, error message #14

Open
rodolfolotte opened this issue Apr 15, 2021 · 3 comments
Open

Comments

@rodolfolotte
Copy link

Sounds ridiculous if I want to open the resulted file in Microsoft Word, but as I'm working in a project which requires any kind of user, I was testing the ODT to open in the respective, but it does not succeed.

So... I have created an ODT template, which is used to open, edit, and wrapped in a response object. The problem is that it can not be open Microsoft after the user save it. Still, the ODT template can be open. The message is something like:

"Error trying to open file in Word!

  • Check permissions
  • If There is free memory
  • Try to use text recovering"

Is there any trick to avoid this? Should I specify a metadata or something?

Thank you so much!

@jdum
Copy link
Owner

jdum commented Apr 15, 2021

Well, many underlying questions in your post. I should publish several pages of methodology on this, but not now :-)

.odt documents generated by odfdo should open within Word without problem (well except styles, fonts, ...)

Of course you know what follows, so I apologize for all these, but first a few sad rules:

  • don't trust the detail of any error message, the actual glitch may be elsewhere
  • "MS Word" does not exist, there are a lot of pieces of code of various nature and age under that name
  • "OpenDocument format" does not exist, there are versions and bugs, and many custom implementations and habits and extensions (from Libre Office, MS Word and others)
  • ODF and OpenXML are very different

Internet is evil :

  • Remove the "download" problem: downloading something from internet is always treated with anxiety by the operating system. Try to reproduce the bug locally. I mean: 80% chance that the bug is about opening a downloaded document. Basically you ask to the local computer to unzip a piece of data from remote origin... And maybe the data is considered as corrupted or whatever. Remember: internet is evil.

From my experience (including my recent odsgenerator script on github)

  • MS as a very decent implementation of ODF, but:
  • of course styles, fonts, macros are quite dead,
  • they are very close to the standard (too much?), and reject files that would be accepted by other implementations. They have not that politics as regards their own standards ;-)
    => try to furnish some "ODF compliant" document. Well, odfdo is quite ODF 1.1 compliant... More or less. That's a complex matter.
    You may try to open/save your generated document with LibreOffice or some office365 (I use some free MS account on the internet for that), google doc. Then check which version is then ok for Word. Then find what was the odfdo bug (what piece of XML was not accepted). Surprisingly, I would expect to be quite fast to find the part to remove to have a relevant document accepted by "Word".

Sorry, only generalities no precise clue here.

@rodolfolotte
Copy link
Author

That was a quite good answer, actually! Many thanks, @jdum ! :)

Ok, then, I will try to narrow down locally, and maybe we have some clue on what could be a solution to this. I will try to have it done without the need of opening in LibreOffice. Hopefully, I come back with some nice workaround!

Thank you again!

@bastien34
Copy link

bastien34 commented Jun 22, 2022

I also encounter this problem. People are complaining they can't open my generated TextDocument in Word because of "invisible part" which is well, quite hard to see. Any more concise idéa about this bug?

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

No branches or pull requests

3 participants