The Calc HTML importer is completely confused by unclosed HTML tags. If you try to open an HTML file in Calc which contains unclosed HTML tags, it will import only up until the unclosed tag. The Writer HTML importer is much more resilient, and will gracefully ignore unclosed tags. Reproducibility: Always Steps to reproduce: 1. Create an HTML file containing a table with unclosed tags. Example: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <title>spreadsheet</title> </head> <body> <table> <tr><td>a1</td><td>b1</td><td>c1</td></tr> <tr><td>a2</td><td><a href="foo">b2</td><td>c2</td></tr> <tr><td>a3</td><td>b3</td><td>c3</td></tr> </table> </body> </html> 2. Open the file in Calc. (If the file has an .htm or .html extension, you will need to set the filter to "HTML Document (OpenOffice.org Calc) (*.html;*.htm)" in the file selection dialog, or else OpenOffice.org will try to open it with Writer.) Observed behaviour: 3. Calc renders the spreadsheet as follows: spreadsheet a1 b1 c1 a2 Expected behaviour: 3. Calc should have rendered the spreadsheet as follows: spreadsheet a1 b1 c1 a2 b2 c2 a3 b3 c3 This bug also affects OpenOffice.org; see Bug 115301 there: https://openoffice.org/bugzilla/show_bug.cgi?id=115301
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
I checked this in LO 3.5 beta, Calc still does not import the whole table, only till a2. The import Writer/Web is fine. Setting status to NEW
Created attachment 55960 [details] Sample HTML File as descripebed in first Comment
Confirming problem still exists with LibreOffice 3.6.0.4.
The HTML importer is only confused by this unclosed anchor tag. I've tried other tags like <div>, <span> or <font>, but the import works fine. Also <a name="foo"> works. The only problem exists with <a href="eu">. A solution would be to manually end the started anchor if the next </td> is found, but that's some kind of spaghetti: --- a/editeng/source/editeng/eehtml.cxx +++ b/editeng/source/editeng/eehtml.cxx @@ -319,6 +319,7 @@ void EditHTMLParser::NextToken( int nToken ) case HTML_TABLEHEADER_OFF: case HTML_TABLEDATA_OFF: { + AnchorEnd(); if ( nInCell ) nInCell--; } A far better solution for all non-well-formatted HTML documents would be to clean them up in a first step. This could be done like http://www.mostthingsweb.com/2013/02/parsing-html-with-c/ Do we want to include tidy in our project? In my opinion this could be a huge benefit.
Created attachment 87404 [details] [review] Proposed unit test for this bug
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.