Redmine

I tested this patch with LibreOffice Mac and Word 2016 for Mac, works fine. I think it is very useful to write documents based on wiki contents.

@Jan-Philippe, could this be included in 3.3.0?

I tested the patch on a copy of the Redmine wiki:

• exporting the whole wiki doesn't respond/is too slow (had to kill ruby after 15 minutes), we should probably disable this option. In comparaison, exporting every pages individually took about 2 minutes.
• some pages generate documents that seem invalid (at least for Word 2007 that complains about an unspecified error when opening the generated odt)
• some pages that contain URLs trigger this kind of error (seems to be caused by examples URLs that are not valid URLs):

ActionView::Template::Error (the scheme http does not accept registry part: proxy.domain.tld:port (or bad hostname?)):
    1: <%= raw wiki_page_to_odt(@page, @project) %>
  c:/utils/ruby/lib/ruby/2.0.0/uri/generic.rb:1203:in `rescue in merge'
  c:/utils/ruby/lib/ruby/2.0.0/uri/generic.rb:1200:in `merge'
  html2odt (0.3.0) lib/html2odt/document.rb:270:in `block in fix_links'
  nokogiri-1.6.7.2-x86 (mingw32) lib/nokogiri/xml/node_set.rb:187:in `block in each'
  nokogiri-1.6.7.2-x86 (mingw32) lib/nokogiri/xml/node_set.rb:186:in `upto'
  nokogiri-1.6.7.2-x86 (mingw32) lib/nokogiri/xml/node_set.rb:186:in `each'
  html2odt (0.3.0) lib/html2odt/document.rb:269:in `fix_links'
  html2odt (0.3.0) lib/html2odt/document.rb:209:in `prepare_html'
  html2odt (0.3.0) lib/html2odt/document.rb:55:in `content_xml'
  html2odt (0.3.0) lib/html2odt/document.rb:142:in `block (4 levels) in data'
  rubyzip (1.2.0) lib/zip/entry.rb:495:in `get_input_stream'
  html2odt (0.3.0) lib/html2odt/document.rb:139:in `block (3 levels) in data'

I attached a raw wiki page content. When formatting is set to Markdown, you should get the error, when formatting is set to textile, you should get the invalid odt (which is also attached).

Thanks a lot for testing this patch/feature.

I have just set up a Windows development machine to verify your feedback:

• exporting the whole wiki doesn't respond/is too slow (had to kill ruby after 15 minutes), we should probably disable this option. In comparaison, exporting every pages individually took about 2 minutes.

This is very surprising. On my newly set up development virtual machine (on 5 year old Macbook) running Windows 7 and Ruby 2.0 (using Ruby Installer), the example wiki page you provided was generated within 0.4 seconds. This also matches my experience on Mac OS and Linux.

• some pages generate documents that seem invalid (at least for Word 2007 that complains about an unspecified error when opening the generated odt)

Unfortunately this is true. xhtml2odt claims to handle only valid XHTML and we have already encountered cases where even valid HTML was not handled in the expected way. #22898 was one such case, the given example document is another. Attached you may find an updated one. All I did, was added new lines around the pre tags, so that they are not entangled with the previous paragraph. But since we cannot expect the user to write perfectly formatted content, I will have a look at how I can fix the problem at hand in any case. I just wanted to let you know about the underlying reason.

• some pages that contain URLs trigger this kind of error (seems to be caused by examples URLs that are not valid URLs)

Thank you for this bug report. Indeed, handling of invalid URIs was missing in html2odt. The latest release (0.3.1) fixes that. Running bundle update html2odt should add it to your installation.

I will have a look, at how I can handle the markup generated on your example content.

Could you try to narrow down, why generating the ODT is so slow on your machine? Should we gather more feedback by other developers? What do you think?

Gregor Schmidt wrote:

This is very surprising. On my newly set up development virtual machine (on 5 year old Macbook) running Windows 7 and Ruby 2.0 (using Ruby Installer), the example wiki page you provided was generated within 0.4 seconds. This also matches my experience on Mac OS and Linux.

Yes, I had good response times when exporting signle wiki pages, as I mentioned before. The problem was when exporting the whole wiki in one ODT file (by using the export link on the wiki page index). This was not a Windows issue as I get the same behaviour when testing under linux (I let it run for more than one hour before killing webrick).

This problem no longer occurs with the same wiki content and html2odt 0.3.3 so I guess it was a html2odt or nokogiri issue (html2odt 0.3.3 uses a different nokogiri version). Now I get the whole wiki export in a minute (with both windows and linux) but the resulting ODT seems to be invalid. You'll find it attached.

This feature seems to be usefull for a very few users and I prefer not to add it to the core. But I'd be happy to refactor a few things in order to make it easier for plugins to add new export formats, without having to patch views and controllers.

Thanks again for providing the erroneous ODT. Now that I see, that it is more than 800 pages long, I can imagine, why it's taking a minute to generate. I assume, the PDF export would not be a lot faster.

Concerning the ODT error, I was able to identify the root cause. It is related to the HTML generated by the collapse macro. The error was located in the export of this wiki page.

Attached you may find an updated patch¹, which further cleans up the HTML before handing it over to html2odt. I am leaving this here for future reference.

¹ replacing the first one

Previous versions of the patch contained a path traversal vulnerability, which allowed attackers to access image files outside of Rails.public_path. Attached you may find an updated patch, including the fix.