Bug Hunting Session
Bug 106486 - DOCX,FILESAVE: Textbox height goes to zero when saving to docx and reloading
Summary: DOCX,FILESAVE: Textbox height goes to zero when saving to docx and reloading
Status: RESOLVED DUPLICATE of bug 101627
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.0.0.5 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, filter:docx, regression
Depends on:
Blocks:
 
Reported: 2017-03-10 22:14 UTC by Oliver Sander
Modified: 2017-03-16 07:42 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
The test file (31.74 KB, application/vnd.oasis.opendocument.text)
2017-03-10 22:14 UTC, Oliver Sander
Details
The test file saved as docx (28.08 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2017-03-10 22:15 UTC, Oliver Sander
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Oliver Sander 2017-03-10 22:14:10 UTC
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
Comment 1 Oliver Sander 2017-03-10 22:14:38 UTC
Created attachment 131808 [details]
The test file
Comment 2 Oliver Sander 2017-03-10 22:15:04 UTC
Created attachment 131809 [details]
The test file saved as docx
Comment 3 Oliver Sander 2017-03-10 22:20:01 UTC
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?
Comment 4 Patrick Jaap 2017-03-13 15:49:23 UTC
The meta data in "meta.xml" says

LibreOffice/5.2.5.1$Windows_x86 LibreOffice_project/0312e1a284a7d50ca85a365c316c7abbf20a4d22

is the creator of the document.
Comment 5 Patrick Jaap 2017-03-13 16:09:10 UTC
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
Comment 6 Buovjaga 2017-03-15 13:14:47 UTC
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
Comment 7 Xisco Faulí 2017-03-15 16:56:44 UTC
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 ***
Comment 8 Oliver Sander 2017-03-15 21:20:09 UTC
Does the offending commit also cause the fact that the odt file displays with several incorrect text boxes to begin with (see comment 3)?
Comment 9 Patrick Jaap 2017-03-16 07:42:35 UTC
(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.