| Summary: | Custom properties with "_x005F_" keep growing escapements when roundtripping as OOXML formats | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Aron Budea <aron.budea> |
| Component: | filters and storage | Assignee: | Eike Rathke <erack> |
| Status: | VERIFIED FIXED | ||
| Severity: | normal | CC: | erack, xiscofauli |
| Priority: | medium | Keywords: | bibisected, bisected, regression |
| Version: | 5.4.0.3 release | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | target:6.3.0 target:6.2.5 | ||
| Crash report or crash signature: | Regression By: | ||
| Attachments: |
Sample ODT
Sample ODT How it looks in LibreOffice 6.3 master |
||
|
Description
Aron Budea
2019-05-14 11:04:49 UTC
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. |