Apache OpenOffice (AOO) Bugzilla – Issue 113860
docx: certain graphic not imported at all
Last modified: 2016-01-12 00:18:28 UTC
This MSOffice docx file doesn't display or print the embedded graphic logo when opened with OpenOffice 3.2.1: http://lava.net/~tony/sealstuff/Turtle_Bay_windshield_doc...docx
Created attachment 71094 [details] MS Office docx file with embedded logo
MRU->HBRINKM: see attached docx, the graphic in it will not be imported at all. May due to its wrapping style "in line with text" the filter does not recognize it?
While missing a logo might not seem so bad, in my case, there were two missing diagrams which were important to fully understand the document. I don't know if the document author would like me to disclose any of the document content, but I can examine it to determine any technical details you may think are relevant to solving this bug.
Are you referring to some other diagrams or the missing logo itself? In OpenOffice the logo/diagram doesn't import at all. In NeoOffice, the logo/diagram is shown but cropped so that the lettering along the border of the logo/diagram is partially missing.
Missing a logo is not a trivial issue. There is a workaround, which is to save as a .doc file from Word, and use that format exclusively - then the pic shows up fine, for me at least. But that's hardly a satisfactory solution.
*** Issue 126310 has been marked as a duplicate of this issue. ***
Created attachment 85244 [details] Docx with graphics that do not load apache does not open document with notary graphic and adds unnecessary page breaks
Created attachment 85245 [details] PDF demonstrating the .docx layout (In reply to matt from comment #7) > Created attachment 85244 [details] > Docx with graphics that do not load > > apache does not open document with notary graphics and adds unnecessary page > breaks I confirmed (1) that the text frames (not graphics) show properly using Microsoft Office Word 2016. Also, (2) saving the document as a Word 97-2013 .doc file preserves the document. The uploaded PDF demonstrates the layout of the .docx when opened in Word 2016. I confirm that AOO 4.1.2 fails to present the frames having the notary text in the .docx and there are other issues related to page margins/layout that cause some of the original pages to overflow onto second pages, resulting in 6 pages instead of 4. (LibreOffice 5.0 retains the text frames but manages to overflow everything in a manner that produces 8 pages instead of 4.) The .doc document is presented by AOO in a form consistent with the Word presentation when the .doc form is opened in Apache OpenOffice. The .doc text frames appear and the page layout is maintained. AOO says there are 5 pages, but in fact only 4, there being no page 2. The text frame on page 1 does not have its bottom line(s) included, so there still are layout defects and this may factor in the page-count error. (LibreOffice 5.0.0 shows the complete text frames but pagination makes 6 pages instead of 4.) The difficulty appears to be related to the use of text frames as part of a fairly complex page structure. The original .docx is in "compatibility mode" and that may or may not be a factor.
(In reply to michael.ruess from comment #2) > MRU->HBRINKM: see attached docx, the graphic in it will not be imported at > all. > May due to its wrapping style "in line with text" the filter does not > recognize it? In looking at that attachment, the logo is a graphic image, not a text frame, and it remains the case that the graphic does not appear when the .docx is opened in AOO 4.1.2. LibreOffice 5.0 opens the document perfectly in this particular case. Technically, although there may be a common underlying cause, the recent case of the text blocks having a form for notarization is a different issue, and has tail-gated onto this 2010 issue. In any future analysis, we may need to separate these.
Document structure quite different than what is used for ODF 1.2.