Bug 116194 - table content from .DOCX shown as text in Writer
Summary: table content from .DOCX shown as text in Writer
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.3.0.4 release
Hardware: All All
: high major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
: 111679 120256 120512 122608 (view as bug list)
Depends on:
Blocks: DOCX-Tables
  Show dependency treegraph
 
Reported: 2018-03-05 09:06 UTC by nikisch
Modified: 2019-06-06 16:29 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
doc with truble (14.97 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2018-03-05 09:07 UTC, nikisch
Details
Screenshot this doc in other office (look ok) (45.53 KB, image/png)
2018-03-05 13:56 UTC, nikisch
Details
Compare DOCX in MSO and LO (535.18 KB, image/jpeg)
2018-03-05 14:41 UTC, Timur
Details

Note You need to log in before you can comment on or make changes to this bug.
Description nikisch 2018-03-05 09:06:28 UTC
Description:
In libreoffice table with checkboxes on first page gone. 
In mso and onlyoffice all look ok.

Steps to Reproduce:
1.open my doc
2.
3.

Actual Results:  
The whole document was melted

Expected Results:
Everything should look normal


Reproducible: Always


User Profile Reset: No



Additional Info:


User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0
Comment 1 nikisch 2018-03-05 09:07:23 UTC
Created attachment 140342 [details]
doc with truble
Comment 2 Dieter Praas 2018-03-05 10:25:10 UTC
Can you add an attachment that shows how the document should looks like?
Comment 3 nikisch 2018-03-05 13:56:24 UTC
Created attachment 140353 [details]
Screenshot this doc in other office (look ok)
Comment 4 Timur 2018-03-05 14:41:33 UTC
Created attachment 140359 [details]
Compare DOCX in MSO and LO

Bugzilla is not "document based", like "this document doesn't display nice". 
Bugzilla is "issue based", so a single issue must be pointed at, after a search for not being a duplicate. 
Bug report is not correct but issue exists: table content from .DOCX shown as text in Writer
This docx is old 2007 format but that's not the reason.
Comment 5 Timur 2018-03-05 14:53:59 UTC
This behavior started in 4.3. But also wasn't correct before. 
So not a regression but bibisect would be useful.
Comment 6 nikisch 2018-03-06 05:13:19 UTC
I do not know what the problem is. I hope it's just fixed.
There are many rtf with a similar problem. In them, too, the tables disappear, although they are present in openoffice 4.1.5 or mso or onlyoffice. Attach an example? Is this the same problem?
All these rtf are generated by the Russian program consultant +
Comment 7 Dieter Praas 2018-03-06 08:21:28 UTC
> There are many rtf with a similar problem. In them, too, the tables
> disappear, although they are present in openoffice 4.1.5 or mso or
> onlyoffice. Attach an example? Is this the same problem?
> All these rtf are generated by the Russian program consultant +

I would open a new bug report for the rtf problem. See also the meta-bug 112765 about RTF Table bugs and enhancements
Comment 8 Justin L 2018-08-20 18:05:53 UTC
Used bibisect43max to identify commit cf33af732ed0d3d553bb74636e3b14c55d44c153
    Author:     Lubos Lunák
    CommitDate: Wed Apr 23 14:57:36 2014 +0200
    
handle w:gridBefore by faking cells (fdo#38414)
    
Docx's w:gridBefore means that there should be this given space in the table
grid before any cells come. But writer requires tables to be rectangular, so
the space needs to be faked using cells without border. So far so good, but
now reality in the form of the retarded overdesigned writerfilter comes.
The internal representation of table data (and not just one actually) is
pretty non-obvious and hard to modify, seems to be modelled just to follow
the parser data the way it comes. Moreover dmapper gets notified of w:gridBefore
only after cells in the row have been already processed. So after futile attempts
to add the fake cells somehow in dmapper I've eventually given up and hacked up
input handling to fake input as if the fake cells were actually there (which
was tedious to find out as well, but at least it's reasonably doable).

https://cgit.freedesktop.org/libreoffice/core/commit/?id=cf33af732ed0d3d553bb74636e3b14c55d44c153
Comment 9 Timur 2019-01-09 18:05:42 UTC
*** Bug 122608 has been marked as a duplicate of this bug. ***
Comment 10 raal 2019-01-09 18:48:40 UTC
(In reply to Justin L from comment #8)
> Used bibisect43max to identify commit
> cf33af732ed0d3d553bb74636e3b14c55d44c153
>     Author:     Lubos Lunák
>     CommitDate: Wed Apr 23 14:57:36 2014 +0200
> 
> https://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=cf33af732ed0d3d553bb74636e3b14c55d44c153


Adding Cc: to Luboš Luňák
Comment 11 Timur 2019-01-10 08:10:23 UTC
Another example: attachment 148176 [details] DOCX from Bug 122608 that should look like attachment 148177 [details] PDF.
Comment 12 Timur 2019-01-10 09:37:37 UTC
*** Bug 111679 has been marked as a duplicate of this bug. ***
Comment 13 Timur 2019-01-10 09:38:27 UTC
Also DOCX attachment 135443 [details] from 111679 Bug.
Comment 14 Timur 2019-06-06 13:08:23 UTC
*** Bug 120512 has been marked as a duplicate of this bug. ***
Comment 15 Timur 2019-06-06 13:08:30 UTC
*** Bug 120256 has been marked as a duplicate of this bug. ***
Comment 16 Xisco Faulí 2019-06-06 14:03:51 UTC
regression from LibreOffice 4.3, I don't think it deserves high priority at this point...
Comment 17 Gabor Kelemen 2019-06-06 16:27:11 UTC
(In reply to Xisco Faulí from comment #16)
> regression from LibreOffice 4.3, I don't think it deserves high priority at
> this point...

It's actually a quite bad one when looking at the consequences. Several duplicates too - I'd say high priority is warranted.