Description: Consider the attached odt document. In the footer there is a text box saying "Kein Zugang für...". When I save the document as docx, close LibreOffice, and open the docx file, then that text box appears to have (almost) zero height. Hence the text has become invisible. Actual Results: Expected Results: Reproducible: Always User Profile Reset: No Additional Info: Version: 5.3.0.0.alpha1 Build ID: f4ca1573fcf445164c068c1046ab5d084e1b005f CPU Threads: 4; OS Version: Linux 4.9; UI Render: default; VCL: gtk2; Locale: de-DE (de_DE.UTF-8); Calc: group User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0
Created attachment 131808 [details] The test file
Created attachment 131809 [details] The test file saved as docx
Incidentally, several text boxes in the footer appear to have incorrect heights to begin with. Curiously, when opening the odt file with MSOffice(!), it looks much better. I suspect that the file was originally created with MSO (is there a way to tell?). So who's to blame for the incorrect textbox heights in LO?
The meta data in "meta.xml" says LibreOffice/5.2.5.1$Windows_x86 LibreOffice_project/0312e1a284a7d50ca85a365c316c7abbf20a4d22 is the creator of the document.
The initial view of the document seems to be correct in LO, since the text frame of "Bankverbindung" is 2.88cm in height and the neighbored text frame of "Zufahrt" is only 2.752cm in height causing some text to be missing. (measurements taken from the original odt xml files). So there is something strange in the original data. The almost disappearing lower textbox in the docx-export seems to be related to https://bugs.documentfoundation.org/show_bug.cgi?id=101627 since deactivating the special treatment for docx textboxes in the footer results in a much better rendering of the document. Why MSO renders both files correctly is an open question for me. Is there a documentation that states the behavior in the case, if the text frame is smaller than the actual text? Regards, Patrick
Yep, seems to be the same cause as bug 101627 It does not go hiding in 4.3. Let's leave this open for now. Win 7 Pro 64-bit Version: 5.4.0.0.alpha0+ Build ID: eb7b03b052ffe8c2c577b2349987653db6c53f76 CPU threads: 4; OS: Windows 6.1; UI render: default; TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2017-02-26_22:34:18 Locale: fi-FI (fi_FI); Calc: CL
Regression introduced by a4dee94afed9ade6ac50237c8d99a6e49d3bebc1 which is the same as in bug 101627. Closing as RESOLVED DUPLICATED *** This bug has been marked as a duplicate of bug 101627 ***
Does the offending commit also cause the fact that the odt file displays with several incorrect text boxes to begin with (see comment 3)?
(In reply to Oliver Sander from comment #8) > Does the offending commit also cause the fact that the odt file displays > with several incorrect text boxes to begin with (see comment 3)? Can you specify which box? The position and size of the text boxes is hard-coded in the odt file with absolute values. Strangely, the text does not fit in some of the boxes (e.g. "Zufahrt"). MS Office seems to overwrite this size, I don't know why.