Bug 40428 - FILEOPEN MS2007 .docx: Frames ("Text Boxes") at wrong position
Summary: FILEOPEN MS2007 .docx: Frames ("Text Boxes") at wrong position
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.4.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: DOCX-Frames
  Show dependency tree / graph
 
Reported: 2011-08-27 16:54 UTC by Rogier van Vlissingen
Modified: 2022-04-13 12:23 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

Attachments
Contract form with text boxes at the top failing to render properly (46.49 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2011-08-27 16:54 UTC, Rogier van Vlissingen 		Details
Screenshot comparison (475.36 KB, application/pdf)
2012-05-03 22:21 UTC, Rainer Bielefeld Retired 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Rogier van Vlissingen 2011-08-27 16:54:55 UTC 
Created attachment 50625 [details]
Contract form with text boxes at the top failing to render properly

The boxes at the top of this doc do not render properly when it is opened with LibreOffice.

I can: 
Save it in MSWord2007 as .doc, or .odt and in both cases successfully open it in LOWriter

I can not directly open it as .docx or the boxes at the top will not display.
Comment 1 Björn Michaelsen 2011-12-23 12:41:31 UTC 
[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
Comment 2 sasha.libreoffice 2012-02-02 02:16:16 UTC 
reproducible in LibO 3.6.0 master on Fedora 64 bit
but this bug is duplicate of another bug, early reported
Comment 3 Rainer Bielefeld Retired 2012-05-03 22:19:33 UTC 
[Reproducible] with parallel installation of Master "LOdev 3.6.0alpha0+  – WIN7 Home Premium (64bit) ENGLISH UI [Build ID: 35ec153]" (tinderbox: Win-x86@6-fast, pull time 2012-05-02 06:53:41), pls. compare screenshots.

I found lots of Bug reports sounding similar, but I failed to find one to what this one is a DUP.

@Cédric:
Please set Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug
Comment 4 Rainer Bielefeld Retired 2012-05-03 22:21:02 UTC 
Created attachment 61008 [details]
Screenshot comparison
Comment 5 Teo91 2013-09-29 18:57:25 UTC 
The reported bug is no more in LO 4.1.1 on Windows 7, but now there is a second blank page who should don't even exist (the doc is made up by 5 pages, not 6).

With LO 4.2-master everything is OK, no reported bug and no blank page, all 5 pages correctly shown.
Comment 6 Jorendc 2014-07-20 16:29:09 UTC 
I fail to reproduce this bug. Tested using LibreOffice Version: 4.4.0.0.alpha0+
Build ID: a82ff18269e5b37348d402b7c21c3f200068265c
TinderBox: Win-x86@39, Branch:master, Time: 2014-07-20_02:34:36

All 5 pages show correctly (no 6 as described already in comment 5).

I'll attach a PDF export of this LibreOffice version.

Marking as RESOLVED WORKSFORME due the fact we don't know exactly which commit fixed  this issue.

Kind regards,
Joren