Launchpad has imported 9 comments from the remote bug at https://bugs.freedesktop.org/show_bug.cgi?id=35756.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2011-03-29T01:14:21+00:00 Marco wrote: By importing a document (a HTML file named as .XLS or .HTML) with lots (more than 15000) of rows, OpenOffice Calc truncates data without showing any error or warning. The issue can be reproduced by importing attached file into calc. On my machine it imports just 13635 of the 20000 rows. Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/480130/comments/6 ------------------------------------------------------------------------ On 2011-03-29T01:18:17+00:00 Marco wrote: Created attachment 44977 20000 rows as HTML table Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/480130/comments/7 ------------------------------------------------------------------------ On 2011-03-29T05:41:03+00:00 Libreoffice-z wrote: The effect is reproducible with reporter's sample document and "LibreOffice 3.3.2 – WIN7 Home Premium (64bit) German UI [OOO330m19 (Build:202 / tag 3.3.2.2)]" I saw a lot of documents with name extension .xls having nothing to do with an EXCEL spreadsheet, the user or his application only used that name because of "somehow table contents". To be honest, I do not know much about EXCEL HTML document, except that it is a mess to work with them. Imho that's an EXCEL problem, EXCEL should create documents with correct syntax. Reporter's sample is no correct html, although source text is pretending to be html. At least html type information is missing. I'ts also not an EXCEL type spreadsheet. MS EXCEL viewer will not open that document. Some other observations: OOo3.1.1. (from open WRITER document) will by default open the document as WRITER-HTML document in writer with correct table view until "A12800", then table view stops and strings from table will be shown as endless plain text line. I can force OOo to open the document as html-calc, then it will open the document as spreadsheet, "E13105" is the latest content shown correctly, then table formatting breaks. Exactly the same with OOo-dev 3.4 My result: My aversion against such documents has nothing to do with the reported problem, LibO should reject the document or open it correctly (may be with a warning message). Low priority, imprtant data should be exported to a document with correct syntax, that's a problem of the application creating such documents. @Marco: You get such documents from what application? Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/480130/comments/8 ------------------------------------------------------------------------ On 2011-03-29T05:54:31+00:00 Libreoffice-z wrote: Although the "html" code is completely different, I see something similar to the reported problem with the attachment of OOo bug Bug 111579 - Opening large html excel document from SAS <http://openoffice.org/bugzilla/show_bug.cgi?id=111579> Opening that document with LibO CALC (from WIN Explorer) the last correctly shown cell 'F6712' will have contents "PXXX09.001.AAAA.BBBB 1728". Next cell will be broken, no further contents will be shown, Table ends with date 15/09/2009 Renaming document to .html and opening with Seamonky shows: there is much ocntents behind "15/09/2009" Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/480130/comments/9 ------------------------------------------------------------------------ On 2011-03-29T06:27:28+00:00 Marco wrote: (In reply to comment #3) > Although the "html" code is completely different, I see something similar to > the reported problem with the attachment of OOo bug > Bug 111579 - Opening large html excel document from SAS > <http://openoffice.org/bugzilla/show_bug.cgi?id=111579> > Opening that document with LibO CALC (from WIN Explorer) the last correctly > shown cell 'F6712' will have contents "PXXX09.001.AAAA.BBBB 1728". Next cell > will be broken, no further contents will be shown, Table ends with date > 15/09/2009 > > Renaming document to .html and opening with Seamonky shows: there is much > ocntents behind "15/09/2009" Yes I agree, it seems to be same issue. Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/480130/comments/10 ------------------------------------------------------------------------ On 2011-03-29T06:39:44+00:00 Marco wrote: (In reply to comment #3) > Although the "html" code is completely different, I see something similar to > the reported problem with the attachment of OOo bug > Bug 111579 - Opening large html excel document from SAS > <http://openoffice.org/bugzilla/show_bug.cgi?id=111579> > Opening that document with LibO CALC (from WIN Explorer) the last correctly > shown cell 'F6712' will have contents "PXXX09.001.AAAA.BBBB 1728". Next cell > will be broken, no further contents will be shown, Table ends with date > 15/09/2009 > > Renaming document to .html and opening with Seamonky shows: there is much > ocntents behind "15/09/2009" The .XLS extension is used for users convenience - as those extensions are associated with LibreOffice or MS Excel by default. Trying with MS Excel 2010, it imports that example file without a problem. It just showed a warning that it's not an Excel file. Such files are generated by applications which cannot create native .XLS (or .XLSX). The example file is one I was creating manually to demonstrate the issue. However, the main issue I see here is that LibreOffice cannot import huge HTML tables. It should either import the whole data or show warning message. Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/480130/comments/11 ------------------------------------------------------------------------ On 2011-08-22T07:14:10+00:00 Ctibor-brancik wrote: I can confirm this bug too in libreoffice 3.4.2. Happens for me on slightly less huge tables with around 3000 rows. The interesting thing is, that borders of the table are rendered to the last row, but data are truncated randomly in each file somewhere in the middle. Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/480130/comments/12 ------------------------------------------------------------------------ On 2011-12-23T19:45:48+00:00 Björn Michaelsen wrote: [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 Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/480130/comments/15 ------------------------------------------------------------------------ On 2011-12-24T07:04:19+00:00 Marco wrote: The issue is still open and reproducible with "3.5.0 beta2". Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/480130/comments/16 ** Bug watch added: openoffice.org/bugzilla/ #111579 http://openoffice.org/bugzilla/show_bug.cgi?id=111579 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/480130 Title: [upstream] Calc truncates data from HTML based .xls To manage notifications about this bug go to: https://bugs.launchpad.net/df-libreoffice/+bug/480130/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
