Bug 116170 - FILESAVE OOXML Content_Type structure changes upon roundtrip
Summary: FILESAVE OOXML Content_Type structure changes upon roundtrip
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
Version:
(earliest affected)
6.1.0.0.alpha0+
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:ooxml
Depends on:
Blocks: OOXML-Export-Cleanup
  Show dependency treegraph
 
Reported: 2018-03-04 01:28 UTC by Aron Budea
Modified: 2021-06-06 00:23 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample PPTX (30.21 KB, application/vnd.openxmlformats-officedocument.presentationml.presentation)
2018-03-04 01:28 UTC, Aron Budea
Details
[Content_Types].xml (original) (3.19 KB, text/xml)
2018-03-04 01:28 UTC, Aron Budea
Details
[Content_Types].xml (roundtripped) (5.08 KB, text/xml)
2018-03-04 01:29 UTC, Aron Budea
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Aron Budea 2018-03-04 01:28:06 UTC
Created attachment 140319 [details]
Sample PPTX

See the attached sample PPTX created in PowerPoint 2013, plus the original and roundtripped [Content_Types].xml files. DOCX/XLSX seem to be the same.

The main difference is that the original [Content_Types].xml has Default entries like this:
<Default Extension="rels" ContentType="application/vnd.openxmlformats-package.relationships+xml"/>

The roundtripped file doesn't have that (except for xml), but has several individual entries like this instead:
<Override PartName="/_rels/.rels" ContentType="application/vnd.openxmlformats-package.relationships+xml"/>
<Override PartName="/ppt/slideMasters/_rels/slideMaster1.xml.rels" ContentType="application/vnd.openxmlformats-package.relationships+xml"/>
etc.

Same with the embedded PNG.
In general MS Office OOXML files seem to have a Default entry per extension, plus possible specialized entries.


Additionally, the original XML has the "standalone" attribute set for [Content_Types].xml and all the *.rels files:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
The roundtripped files lack this (it's there in the content XMLs).


This is by no means a bug, because the file is valid either way, but LO could possibly create a [Content_Types].xml that resembles more of the original.
Actually, it might be a subset of bug 50090, but that seems to be more general, and I can't test with Windows Phone, so would prefer to keep this separate.

Observed using LO 6.1 daily build (96d551636e9179eb6874a5156b191ef3bff0a10c, 2018-02-27_00:54:40) / Windows 7.
Comment 1 Aron Budea 2018-03-04 01:28:39 UTC
Created attachment 140320 [details]
[Content_Types].xml (original)
Comment 2 Aron Budea 2018-03-04 01:29:12 UTC
Created attachment 140321 [details]
[Content_Types].xml (roundtripped)
Comment 3 Buovjaga 2018-03-11 10:41:52 UTC
I'll just set to NEW.

Btw. Windows Phone as a platform is essentially dead https://www.theverge.com/2017/10/9/16446280/microsoft-finally-admits-windows-phone-is-dead
Comment 4 Stéphane Guillou (stragu) 2021-06-05 12:43:41 UTC
(In reply to Aron Budea from comment #0)

What would be the precise steps to reproduce this, Aaron?
Comment 5 Aron Budea 2021-06-06 00:23:38 UTC
The sample is PPTX, which can be unzipped, and the [Content_Types].xml in the root of that zip (also attached as attachment 140320 [details]) is the original.

Then you take the PPTX, open and save it in LibreOffice , unip the result, and take the [Content_Types].xml, and compare to the original, in particular the points mentioned in the description.

Browsers can display XMLs nicely, but one can also use an editor that can display XML files formatted, or the xmllint command line tool.

As far as I can see, the situation with the XML is pretty much the same in LO Version: 7.2.0.0.alpha1+ (3b57ebb445df8a2bc3d916ea79f8af45e20e4e62) / Windows, as before.