Request to change .xlsx file content to match standard Excel

[hanginwithdaddo]

This is a request to change the Microsoft Open XML SDK to product .xlsx files that match Excel for Android, the OneDrive version of Excel, and Excel for Windows (Excel 2010 is the version that I tested).

Microsoft Excel for Android, the OneDrive version of Excel, and Excel for Windows (Excel 2010) all produce .xlsx files that contain a docProps folder and a _rels/.rels file whose xml content does not include a leading slash before the xl/workbook.xml reference.

The SDK, however, produces .xlsx files that do not contain the docProps folder and the _rels/.rels file includes a leading slash before the xl/workbook.xml reference (i.e., "/xl/workbook.xml").

This discrepancy with the SDK results appears to cause other utilities, such as Google Sheets, to view files produced using the SDK as outdated.

[hanginwithdaddo]

I should note that I am using the latest version of the SDK (2.6) as posted on github.

[EricWhiteDev]

Thanks for bringing up this issue. I've assigned to myself. I'll bring this up in a meeting with the folks in charge.

[hanginwithdaddo]

Awesome! Thanks in advance for looking into this and please keep me posted so I can update our local copy with any corrections/changes. This SDK is extremely useful!
Peace,
Dave

[hanginwithdaddo]

Eric, did you hear back from anyone about this yet?
Thanks,
Dave

[hanginwithdaddo]

Has there been any update on this issue?
Thanks,
Dave

[EricWhiteDev]

@hanginwithdaddo We're in the middle of doing the port for Office 2016, dealing with some issues associated with how 2016 writes files. Following that, I have some internal documentation tasks that are very high priority. It is possible I can look at this while doing the 2016 port, but can't promise.

Also, FYI, I am on vacation, will not be back in the office until Nov 16th, so nothing will happen for a while.

But I am keeping this issue in mind.

[hanginwithdaddo]

Thank you so much for your reply. I'll pass this along to the rest of my
team.

On Thu, Nov 5, 2015, 10:15 PM Eric White notifications@github.com wrote:

@hanginwithdaddo https://github.com/hanginwithdaddo We're in the middle
of doing the port for Office 2016, dealing with some issues associated with
how 2016 writes files. Following that, I have some internal documentation
tasks that are very high priority. It is possible I can look at this while
doing the 2016 port, but can't promise.

Also, FYI, I am on vacation, will not be back in the office until Nov
16th, so nothing will happen for a while.

But I am keeping this issue in mind.

—
Reply to this email directly or view it on GitHub
#59 (comment)
.

[Numpsy]

This issue seems to be causing problems for the SDK itself when trying to read files on OS X, because it thinks that the path to the custom.xml is absolute rather than relative, and throws.

(In InternalRelationShipsCollection.ProcessRelationshipAttributes(), the

Uri targetUri = new Uri(targetAttributeValue, UriKind.RelativeOrAbsolute);

returns a Uri of with an AbsoluteUri of "file:///docProps/custom.xml", and IsAbsoluteUri=true).

[Numpsy]

(above post of course relating to opening files which have custom document properties in the docprops/custom.xml file)

[tomjebo]

See the comments on #86. I did some testing and verified against the standard (ISO 29500-2 9.1.1 and 9.3.2.2) and:

1. absolute URI and relative path should both be correct for the Target attribute.
2. OpenOffice 4.1.2 (at least Calc) seems to handle absolute paths just fine, as does Microsoft Excel.

@Numpsy Can you provide sample code or a document that will show what you mentioned on Jan 27th.

[hanginwithdaddo]

Have you tried opening your document file using Google Sheets? We were writing an app for Android using your SDK and this is where we ran into a problem.

[tomjebo]

@hanginwithdaddo No I hadn't tested that yet. I saw the OpenOffice reference on the related issues and started there. I will try Google Sheets. However, the format of the Target attribute that the SDK writes should still be valid per the ISO 29500 standard.

[tomjebo]

@hanginwithdaddo I used the online version of Google Sheets to open the sample document created with code from #86 (correcting the InlineString attribute issue) and it opens fine. It has an absolute path like this:

<Relationship Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/worksheet" Target="/xl/worksheets/sheet.xml" Id="R07e895d31b004ef3" />

[hanginwithdaddo]

We will have to pull a new copy of the SDK and try this. Thanks again,
Dave

[emartell03]

Hi @tomjebo ,

I'm working with @hanginwithdaddo on re-testing this issue for our team's Android project. I came in here to pull a new copy of the SDK to test the fix for this issue, and I have a couple questions:

1. I went to https://github.com/OfficeDev/Open-XML-SDK to pull a new copy of the source, and saw that all of the dates were pretty old. I could not find any file modified recently. Is this the right place for the most recent source?
2. When you were testing, did you try to modify and then re-save the file in Google Sheets? That's where we were seeing the message given by Sheets stating that our file needs to be updated to the newer .xlsx format in order to save.

Thanks for any additional information you can provide.

-Erin

[tomjebo]

@hanginwithdaddo, I did make a modification but didn't see any errors or warnings. Again, I am using the Chrome app on Windows and not on Android. I will find an Android device and test with that.

[emartell03]

@tomjebo That would be great, thank you. I pulled my file off the device, and testing with the Chrome app on Windows as well and do not see an error when making a modification. But with the same file on my device, after making a modification and trying to close the file, I see the attached.

[tomjebo]

@hanginwithdaddo ok, getting a device and testing. I will diff the files to see what it thinks needs to be changed.

[tomjebo]

@hanginwithdaddo I did test this on an Android device using Google Sheets.

Now I see the "To continue saving..." dialog and when I hit "UPDATE & SAVE", Sheets saves the document as a .xlsm instead of .xlsx. I then compared the resulting .xlsm with the original .xlsx and see that the changes are basically analogous to the changes that Excel makes when saving an SDK-genned document. Really just reorganizing some things without making functional changes. Relationship id's are changed and a few things like and are added and the xmlns for relationships is moved from the element to the workbook element.

I do see that the /xl/_rels/workbook.xml.rels part is changed and yes, it chose to use relative paths (as Excel does) instead of the SDK's absolute path (Target="/xl/worksheets/sheet.xml"). However, this doesn't indicate to me a problem.

So, effectively Excel does the same thing, it just doesn't refer to saving a "newer .xlsx format". I'm only guessing that Sheets is referring to .xlsm (macro enabled) format vs. .xlsx when it says, "newer .xlsx format".

[tomjebo]

@IMSEMartell @hanginwithdaddo In addition to the testing in my previous post, I also tried taking the same SDK generated file and changing only the Target paths to be exactly the same as the relative Target paths used in the Android Sheets-saved xlsm file. With only those changes, I then uploaded the file again to Google Drive and opened and modified with Sheets on Android device. Again, Sheets informed me that it was going to "update to a newer format" and proceeded to save as a .xlsm. So I'm fairly sure that this "newer format" issue is unrelated to the Target paths being absolute.

Let me know if you find otherwise.

[emartell03]

Hi @tomjebo, thanks for your testing. I was reading the comments above, as well as some of the comments on the other related issues noted (86,88), and saw that you used OpenOffice to test. I do not have the same results as you when opening my SDK-generated file with Open Office 4.1.3 (Calc). It opens without error, but the file is blank. Opening the same file with Excel shows me the data. I have attached my SDK-generated file to this comment.

I'm trying to decide where to go from here, I guess. In addition to users facing the "to continue saving" message for the SDK-generated files when modifying with Sheets, those SDK files are also not openable at all in other Android Office apps (Hancom Office and Polaris Office are two I tried). Whereas the files created by Excel or Google Sheets can be opened on other Android Office apps without issue.

Please let me know your thoughts on the above.
CallHistory.xlsx

[tomjebo]

Hi @IMSEMartell,
thanks for the follow-up information. I'm really not sure what the "new format" message that Google Sheets displays is trying to say. Having taken out the absolute paths from the document, I really don't think it's related to that. And also the fact that it saves in .xlsm (macro enabled) vs .xlsx leads me to believe it's something else (?). I would suggest following up with Google Sheets support or dev teams to find out if they can identify what Sheets is saying by this. I'm not even sure that this is considered a problem by them.

I did take an initial look at changing the Target paths to relative in the SDK but it's not as trivial as I suspected and the fact that it should be valid based on the standard made me refrain from making that kind of change. This project is free to fork and modify so if this is something that is a requirement for your project (or anyone's) you are free to do so.

As far as the CallHistory.xlsx, I'll take a look and see if I can identify what the problem is.

Tom

[tomjebo]

@IMSEMartell I changed only the worksheet Target relationship absolute path in CallHistory.xlsx to a relative path. After opening in OpenCalc 4.1.3, I still see no data. In Excel I see the data. Not sure what OpenCalc doesn't like. This is a very simple package. Perhaps you can bring this up with OpenOffice to narrow down the source of the problem?

[emartell03]

@tomjebo Ok, I've logged questions with both Google Sheets and OpenOffice. Hopefully their answers will help us narrow down what the issue is. I'll update here when I hear back. Thanks.

[Numpsy]

@tomjebo When testing the SDK against Mono on OSX a while back I saw some failures in its own unit tests related to the relative/absolute paths - no other test files needed. (I may have put more info in one of the other similar bugs, I don't recall).

I haven't had chance to look at any of this stuff recently as i've been snowed under with other things so i don't know if anything has changed in Mono etc (though i'm not sure if the current vNext branch will build with Mono anyway?)

[tomjebo]

@Numpsy I will test with Mono as well but there have been a lot of changes wrt .Net support including removal of the System.IO.Packaging mod that we were using before. Not sure if this will impact Mono but I will do the testing when I get time. Thanks for bringing it up.