Created attachment 151398 [details] Sample ODT The attached ODT has a custom property set: "Company" is "Test_x005f_". (without quotes) - Save ODT as DOCX. - Reload DOCX. - Check the property. => It becomes "Test_x005F_x005f_". Upon further reload-save cycles, it keeps growing (Test_x005F_x005F_x005f_, Test_x005F_x005F_x005F_x005F_x005f_, Test_x005F_x005F_x005F_x005F_x005F_x005F_x005F_x005f_ etc.) Observed using LO 6.3.0.0.alpha0+ (0c0e73584f125025fb17d6be8f8050f3b7649c7d), 5.4.0.3 / Ubuntu 18.04. No issue with LO 5.3.0.3. => regression Bibisected to the following commit using repo bibisect-linux-64-5.4. Adding Cc: to Eike Rathke, please take a look. https://cgit.freedesktop.org/libreoffice/core/commit/?id=8b25b67d5268abbb260da968cc23b6f6c8dd31af author Eike Rathke <erack@redhat.com> 2017-03-02 17:06:54 +0100 committer Eike Rathke <erack@redhat.com> 2017-03-03 16:27:21 +0000
Seems we lack to unescape the content when loading. With MS-Word: 1. loading the .docx, what is the custom property then? 2. saving again, what is its content in the .docx file? 3. in a new document creating such property and saving to .docx, what is its content in file?
Created attachment 151405 [details] Sample ODT Apparently I uploaded an earlier iteration of the test file with an extra "x" at the end of the property value ("Test_x005f_x"). It makes no difference to the behavior, but I'm updating the sample to avoid confusion. > With MS-Word: > > 1. loading the .docx, what is the custom property then? > 2. saving again, what is its content in the .docx file? > > 3. in a new document creating such property and saving to .docx, what is its > content in file? In Word 2013 the answer to all of this is: Test_x005f_x005f_ Ie. when the ODT is saved to DOCX, it saves the property as "Test_x005F_x005f_". The only thing Word does is makes the "F" non-capital. Btw, I set this already longer string even for the 3rd test. But... if I use the original string for 3. ("Test_x005f_"), it becomes "Test_" during save. And if I manually change the XML to have that starting string, it also becomes "Test_" when opened.
So after saving "Test_x005f_" to .docx in LibO it is "Test_x005F_x005f_" in file, and after > 1. loading the .docx, what is the custom property then? viewing the property in the MS-Word UI it is still "Test_x005F_x005f_"? And then after > 2. saving again, what is its content in the .docx file? it is still "Test_x005F_x005f_"? For 3. you entered "Test_x005f_" in the MS-Word UI and saved to file it becomes "Test_"? That makes no sense..
(In reply to Eike Rathke from comment #3) > it is still "Test_x005F_x005f_"? Technically it's "Test_x005f_x005f_" (the first F isn't capital). Similarly, if I enter each property in Word, then reload the file, the following happens: - "Test_x005f_" becomes "Test_" - "Test_x005F_x005f_" remains "Test_x005f_x005f_" > That makes no sense.. Are we making assumptions about consistency in another software? :)
Disregarding the "nunances" in what Word does, I think discarding the repeating "x005f_" sequence, and keeping a single "_" in the end (which doesn't even need encoding) would be reasonable.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/f677885fec59f252f36673ee4d8c0b4863625a4d%5E%21 Resolves: tdf#125279 do not double _x005F_ escapement It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Pending review https://gerrit.libreoffice.org/73219 for 6-2
Created attachment 151943 [details] How it looks in LibreOffice 6.3 master Maybe I'm missing something but I can still reproduce the problem in Version: 6.4.0.0.alpha0+ Build ID: 0d6ec494f83fb26524bf3a5fc7af27c225293e87 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded after saving the ODT to DOCX...
@Xisco: One "Test_x005f_" has to become "Test_x005F_x005f_"; the fix is that upon the next save it does not become "Test_x005F_x005F_x005f_".
(In reply to Eike Rathke from comment #9) > @Xisco: > One "Test_x005f_" has to become "Test_x005F_x005f_"; the fix is that upon > the next save it does not become "Test_x005F_x005F_x005f_". oh I see, then I wrongly understood the problem, my bad. setting to VERIFIED. @Eike, thanks for fixing the issue ;-)
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-6-2": https://git.libreoffice.org/core/+/d93ebeb0f785489050dcbe55c5111d639b4b4c1e%5E%21 Resolves: tdf#125279 do not double _x005F_ escapement It will be available in 6.2.5. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.