https://bugs.documentfoundation.org/show_bug.cgi?id=137548
Justin L <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
See Also| |https://bugs.documentfounda
| |tion.org/show_bug.cgi?id=12
| |3116
Blocks| |131304
Ever confirmed|0 |1
Summary|FILEOPEN Table in DOCX |FILEOPEN Table in compat14
|should be continuous, but |DOCX/DOC should split full
|breaks to next page |row, not move to next page
| |(compat15 is OK)
CC| |[email protected]
Whiteboard| |compatibilityMode14
--- Comment #6 from Justin L <[email protected]> ---
(The term "heading" is a bit misleading since the table doesn't have any
"header rows". So it is a "human" heading only.)
Technically this is a Word 2010 format document. If Word 2016 resaves it "in
compatibility mode" then it continues (in Word) to split the tall row. When
Word 2016 saves it in native compat15 mode, then the full-of-content-cell moves
to the next page.
Starting in LO 7.0, we now export DOCX as compat15 mode - so anything LO
authors should look proper in non-obsolete MS Word.
This is strictly a layout issue. If we add in the support for DOC, we might as
well add in support for compat14 DOCX as well. The question is whether it is
worth the effort to add more complexity to the layout - and what other side
issues this would trigger. [At this point, I would consider it a WONTFIX, at
least as a volunteer.]
See related bug 123116 and bug 105478 for code pointers (and warnings).
Referenced Bugs:
https://bugs.documentfoundation.org/show_bug.cgi?id=131304
[Bug 131304] [META] MS Word compatibilityMode = 15
--
You are receiving this mail because:
You are the assignee for the bug._______________________________________________
Libreoffice-bugs mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
