Created attachment 62962 [details] produces corrupt docx file Problem description: If character # is contained in the hyperlink, saving the file to docx corrupts the whole file. Steps to reproduce: 1. open lowriter 2. write: www.google.com/#a 3. press enter -> this produces hyperlink 4. save as DOCX 5. docx file cannot be opened with msoffice, calligraoffice ... 6. if we open the docx file the text after the link is not visible with ODT everything works. Browser: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20100101 Firefox/13.0 Example of xml from docx: <w:r><w:instrText> HYPERLINK "http://Www.google.com/" \l "a"</w:instrText></w:r><w:r><w:fldChar w:fldCharType="separate"/></w:r><w:r><w:rPr><w:rStyle w:val="style15"/></w:rPr><w:t>Www.google.com/#a</w:t></w:r><w:r><w:fldChar w:fldCharType="end"/></w:r></w:hyperlink></w:p>
Created attachment 62963 [details] corrupted docx file produced by lowriter
Same problem with lowriter 3.6 beta 1
Confirmed with: LO 3.5.4.2 Build ID: own W7 debug build Windows 7 Professional SP1 64 bit Saved file could not be opened in Word 2010. Reopening in LO shows www.google.com/# instead of www.google.com/#a.
*** Bug 52175 has been marked as a duplicate of this bug. ***
Reproducible! For details please see "Bug 52175 has been marked as a duplicate of this bug" Still [Reproducible] with parallel installation of Master "LOdev " 3.7.0.0.alpha0+ - WIN7 Home Premium (64bit) ENGLISH UI [Build ID: 25608fb]" (tinderbox: 2008R2@20, pull time 2012-07-14 00:31:17) Already [Reproducible] with "LibreOffice 3.5.1.2 German UI/Locale [Build-ID: dc9775d-05ecbee-0851ad3-1586698-727bf66] on German WIN7 Home Premium (64bit) (no more early 3.5 tested) Worked fine with "LibreOffice 3.3.3 German UI/Locale [OOO330m19 (Build:301) tag libreoffice-3.3.3.1] on German WIN7 Home Premium (64bit), Worked fine with "LibreOffice 3.4.5 German UI [Build ID: OOO340m1 (Build:502)]" parallel Server installation on German WIN7 Home Premium (64bit) so REGRESSION May be bibisecting can help to narrow down appearance of the bug? @Michael: Please set Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug
FWIW, this is not a regression at all AFAICS -- I can reproduce the bug with 3.4 without issues. Anyway, it seems the exporter is just fine, this will be a docx import bug, I'm looking into it.
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9c53a7f94f3bdcb694498db335a01af25257853a fdo#51034 fix docx import of HYPERLINK field, l param
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6ff70708b4a39011a61aa0f53541eb7eec09c813 fdo#51034 testcase
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=cadbe56429244c300d01b0abad8f66077cf40e7c&g=libreoffice-3-6 fdo#51034 fix docx import of HYPERLINK field, l param It will be available in LibreOffice 3.6.1.
Fixed in master and -3-6, requested -3-5 backport as well. Marking as resolved.
Created attachment 66225 [details] existing docx produces corrupt docx on save I'm using LO 3.6.1 RC2 on Windows 7 64-bit. This bug is still happening although it's listed as resolved in http://wiki.documentfoundation.org/Releases/3.6.1/RC1. I experienced this bug with the existing .docx document that had hyperlinks with #.
The original Bug has been fixed (you can test with "produces corrupt docx file". but indeed, there is a very similar bug with very similar symptoms. due to <https://wiki.documentfoundation.org/BugReport_Details#How_to_reopen_Bugs> I created a new "Bug 54214 - FILESAVE: # in hyperlink corrupts .docx (OOXML) document" for the newly discovered problem. @Timur: Thank you for your attention!
Fix for original bug Verified with "LibreOffice 3.6.1.2 German UI/Locale [Build-ID: e29a214] on German WIN7 Home Premium (64bit)
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.