Bug 112856 - FILEOPEN DOCX Bad header display / rels with image from header2.xml but should display header3.xml
Summary: FILEOPEN DOCX Bad header display / rels with image from header2.xml but shoul...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.4.1.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:docx
Depends on:
Blocks: DOCX-Header-Footer
  Show dependency treegraph
 
Reported: 2017-10-03 09:02 UTC by Euclyde
Modified: 2023-07-28 03:16 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Bad docx (171.56 KB, application/zip)
2017-10-03 09:04 UTC, Euclyde
Details
Screenshot of badness (87.18 KB, image/png)
2017-11-02 17:49 UTC, Buovjaga
Details
The document in Word after resizing the paper and deleting the header text (119.01 KB, image/png)
2021-07-27 11:52 UTC, NISZ LibreOffice Team
Details
Modified example file showing the first image even in Word (176.06 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2021-07-27 12:06 UTC, NISZ LibreOffice Team
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Euclyde 2017-10-03 09:02:21 UTC
Description:
When I open my docx is look good with Word, OpenOffice Writer, OnlyOffice Writer but with LibreOffice Writer no.
LibreOffice display image rels in the Header but this is not the good header to display.
This happen only with one docx all others are good.

Steps to Reproduce:
1. Open my docx
2.
3.

Actual Results:  
Bad display with unwanted image include in the doc

Expected Results:
Bad pdf created with the docx from LibreOffice Writer


Reproducible: Always

User Profile Reset: No

Additional Info:


User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36
Comment 1 Euclyde 2017-10-03 09:04:15 UTC
Created attachment 136726 [details]
Bad docx

This is the bad docx
Comment 2 Buovjaga 2017-11-02 17:49:48 UTC
Created attachment 137479 [details]
Screenshot of badness

I guess this is what you mean.

In LibreOffice 3.3, though, the document is all mashed up into 1 page, so apparently AOO has fixed something in the mean time.

Arch Linux 64-bit, KDE Plasma 5
Version: 6.0.0.0.alpha1+
Build ID: fff7097f1ed8493de099d79aa0613ea6b309100a
CPU threads: 8; OS: Linux 4.13; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on November 2nd 2017
Comment 3 vihsa 2018-02-10 12:34:59 UTC
reproducible

similar to attachment on comment 2

Version: 6.1.0.0.alpha0+
core:7ea2311ab734d19b705cf98aa9506cbe122e74e4
tinderbox: pull time 2018-02-09 17:44:16
tinderbox: buildname: Android-ARM@24-Bytemark-Hosting
lyf flame 3, android 5.1
Comment 4 QA Administrators 2019-02-11 03:39:57 UTC Comment hidden (obsolete)
Comment 5 NISZ LibreOffice Team 2020-11-26 14:42:30 UTC
Still a problem in:

Version: 7.2.0.0.alpha0+ (x64)
Build ID: cb084f475db33a2cfc62bc9c8de37b8c3c87b3c7
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: hu-HU (hu_HU); UI: en-US
Calc: CL
Comment 6 NISZ LibreOffice Team 2021-07-27 11:51:56 UTC
After thinking a bit about this, in the document.xml we see this:

			<w:headerReference w:type="even"
                 				r:id="rId6"/>
			<w:headerReference w:type="default"
                 				r:id="rId7"/>
			<w:footerReference w:type="even"
                 				r:id="rId8"/>
			<w:footerReference w:type="default"
                 				r:id="rId9"/>
			<w:headerReference w:type="first"
                 				r:id="rId10"/>
			<w:footerReference w:type="first"
                 				r:id="rId11"/>
Word's UI shows there is no even or first header enabled, so we need to go with default. (there is a disabled even header though, which can be enabled in Word)
document.xml.rels shows this:
<Relationship Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/header" Target="header2.xml" Id="rId7"/>
and header2.xml contains two references to images:
				<v:shape id="_x0000_i1025"
       					type="#_x0000_t75"
       					style="width:573pt;height:733.5pt">
					<v:imagedata r:id="rId1"
           						o:title=""/>
				</v:shape>
and
				<v:shape id="_x0000_i1026"
       					type="#_x0000_t75"
       					style="width:535.5pt;height:624pt">
					<v:imagedata r:id="rId2"
           						o:title=""/>
				</v:shape>
header2.xml.rels shows then the real targets, which are
Relationship Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/image" Target="media/image1.emf" Id="rId1"/>

<Relationship Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/image" Target="media/image2.emf" Id="rId2"/>

So the images are definitely part of the default header, just open the Page Layout ribbon, select Tabloid (11x17) paper size and delete all text from the header.

What really happens is that these are fairly large images and don't fit in the small default header space of this document.
Word thus cleverly hides them, as can be observed in the attachments of bug 61305 as well. 
Then the question is: Why would a 25.88 cm tall image fit in the header of a Tabloid size, 43.17 cm tall paper, but only if there are no more paragraphs before it?
Comment 7 NISZ LibreOffice Team 2021-07-27 11:52:42 UTC
Created attachment 173876 [details]
The document in Word after resizing the paper and deleting the header text
Comment 8 NISZ LibreOffice Team 2021-07-27 12:06:28 UTC
Created attachment 173877 [details]
Modified example file showing the first image even in Word
Comment 9 QA Administrators 2023-07-28 03:16:45 UTC
Dear Euclyde,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug