Description: When there is a large document with multiple long images with captions, and other text, and it is saved as .docx, the images fail to load properly when re-opened. You get the little red triangle at some point and then the image complete with caption doesn't load from that point onwards. I believe this is a loading bug, rather than a saving bug, because the same file loads perfectly with Office 365, complete with captions and images. Unfortunately, I can't share the document with you because it is part of my work for an assignment, but I am working to reproduce this bug at the moment. It occurs with Libreoffice 6.0.7.3 (as it comes with Mint 19.1/Ubuntu 18.04), 6.1.4.2 (Fresh appimage), and 6.2.0.1 (prerelease appimage). I also tried it on Windows 10 with a different version (can't remember which), and it had the same issue. I will work to try and create a new file with the same issues so this is reproducable. Steps to Reproduce: 1. TODO - I will try to reproduce now. 2. 3. Actual Results: Images fail to load at the same places each time, with the red triangle after saving, even though the document opens in Office 365. Expected Results: Everything opens and displays as it did prior to saving and reloading. Reproducible: Didn't try User Profile Reset: No Additional Info: Version: 6.0.7.3 Build ID: 1:6.0.7-0ubuntu0.18.04.2 CPU threads: 2; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: en-GB (en_GB.UTF-8); Calc: group I don't know if OpenGL is enabled - what is the default for appimages?
Created attachment 148449 [details] Test file that demonstrates the issue. This attachment demonstrates the issue. The third image always fails to load about halfway through, no matter what version of libreoffice I open it with, or how many times I try.
You can reproduce by: 1. Creating a new document. 2. Add several paragraphs of text - eg lorem ipsum. 3. As you add the text, insert some images, some fairly small, and some fairly long (almost as long as the page), and add captions as you go. 4. If you add enough of them, some will fail to load when opening the saved document, even though everything was fine prior to saving and re-loading the document. You can also see the attached .docx file, which demonstrates the issue.
Hamish, could you please add the original odt-document (before saving as doc?). This might be the easiest way to confirm the bug. Thank you. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided.
So, weirdly, when I save as .odt from the get-go, then re-open and save as docx, it doesn't seem to happen! However, converting the broken .docx file to .odt gives a file which is still broken in .odt format - see new attachment. I'm not sure where to go from here!
Created attachment 148450 [details] Old attachement converted to .odt
don't repro with attached Docx in Version: 6.3.0.0.alpha0+ (x64) Build ID: eca59b6b8a0cf826ac59f77aec9acf045340c23f CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-01-16_03:48:12 Locale: ru-RU (ru_RU); UI-Language: en-US Calc: threaded and in Version: 6.2.0.1 (x64) Build ID: 0412ee99e862f384c1106d0841a950c4cfaa9df1 CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; Locale: ru-RU (ru_RU); UI-Language: en-US Calc: threaded
Hello Hamish, Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
I couldn't reproduce this by following the instructions this time. I don't have the same images I used before though, so does someone else fancy trying as well?
(In reply to Hamish McIntyre-Bhatty from comment #8) > I couldn't reproduce this by following the instructions this time. I don't > have the same images I used before though, so does someone else fancy trying > as well? Let set it as RESOLVED WORKSFORME for the time being. Please put it back to UNCONFIRMED if you can reproduce it again. Thanks
Managed to reproduce with a second attempt. Use attached images to aid reproducing - a larger (closer to full A4 page size) image seems to be needed to produce this issue.
Created attachment 150312 [details] Small image
Created attachment 150313 [details] Bigger image
NB: Particularly the bigger images don't load correctly, and the captions are often missing. Make sure you check all of them when attempting to reproduce!
You can't confirm your own bugs. Moving it back to UNCONFIRMED until someone else confirms it.
Oops, didn't intend to do that!
(In reply to Hamish McIntyre-Bhatty from comment #12) > Created attachment 150313 [details] > Bigger image I inserted this image 5 times into a document, gave each image a caption and saved directly to docx. There was no problem when reloading the file Version: 6.4.0.0.alpha0+ (x64) Build ID: ed882d693f37779e3a09641e7cd43b7a925d2312 CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-07-25_00:58:18 Locale: fi-FI (fi_FI); UI-Language: en-US Calc: threaded
Same here Version: 6.4.0.0.alpha0+ Build ID: 186d36a7036462ae641b35004b4ffba3eeeca46f 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 @Hamish, Could you please attach the .odt file before you convert it to .docx file ?
Created attachment 154520 [details] New test file (ODT). Upon converting to docx it shows the issue Done. If you convert this new attachment to DOCX it fails to load, but it loads fine as ODT.
Hello Hamish, Thanks for providing the file. After roundtripping the file to DOCX, I see there are some page breaks between some of the images, but all of them are displayed. Could you please attach a screenshot of the problem ?
Created attachment 154533 [details] Screenshots of new file failing to load Yes, I had to do page breaks, otherwise it tried to place all the images on top of each other for some reason. Attached are some screenshots. This is on 6.3.1~rc2 at the moment (from the launchpad PPA, on Ubuntu 18.04), but it's happened on every other version I've tried as well.
I get the same result when saving the ODT as DOCX. Re: the screenshots: 2.png does not make sense as it only shows that the images are not placed on pages matching the ODT. The actual issue is that the images/their frames are displayed as cropped, with red arrows in the bottom right corner. Arch Linux 64-bit Version: 6.4.0.0.alpha0+ Build ID: b9a776837462eeb6d50d0decc42604c0c3008eb1 CPU threads: 8; OS: Linux 5.2; UI render: default; VCL: kf5; Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US Calc: threaded Built on 11 August 2019
Also adding my build information, because I forgot earlier: Version: 6.3.1.2 Build ID: 1:6.3.1~rc2-0ubuntu0.18.04.1~lo1 CPU threads: 12; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: en-GB (en_GB.UTF-8); UI-Language: en-US Calc: threaded
Created attachment 168041 [details] The original document and its docx version in LO 7.1alpha The attachment #154520 [details] seems to reopen fine after docx export since: https://cgit.freedesktop.org/libreoffice/core/commit/?id=b6850bbe95418ecfde404be1696548f18d200c9b author Attila Bakos <bakos.attilakaroly@nisz.hu> 2020-08-06 13:49:43 +0200 committer László Németh <nemeth@numbertext.org> 2020-08-21 23:48:33 +0200 tdf#106153 sw compatibility: fix textboxes exceeding the page
*** This bug has been marked as a duplicate of bug 106153 ***
Verified in Version: 7.2.0.0.alpha0+ Build ID: 9df9208b7d0fd9dd49c681c3c1b546d8ca402925 CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded