Description: LO doesn’t save thumbnails of Non-ODF docs in Windows Explorer - even though ‘General’ tab in ‘Properties’ menu has the option ‘Save preview image with this document’. This is enabled by default. And if you disable the option before saving a ODF doc, LO will remove the thumbnail from Windows Explorer. Option works with ‘classic’ ODF formats, but fails with ‘flat ODF’, OOXML, RTF, TXT docs (and any other format supported by LO). Steps to Reproduce: 1. Create a document in LO on Windows. 2. Save it as a ODF document (don’t close LO). 3. Start Explorer and open folder with this file. -> You will see a thumbnail of the new document. (In case you don’t, please click right on the folder and choose ‘icons’ in ‘view’ menu.) 4. Switch back to LO. 5. Open ‘Properties’ in ‘File’ menu. 6. Disable option ‘Save preview image with this document’ in the ‘General’ tab. 7. Save file again. 8. Switch to Explorer 9. Change the folder and then open the original folder again. → Thumbnail view got updated and now thumbnail is gone. 10. Switch back to LO. 11. Do the same stuff with a Non-ODF or a ‘Flat ODF’ doc. → Option ‘Save preview...’ has no effect here. No Thumbs are saved. 1. Save a document in any supported format with LO on Windows. 2. LO saves a thumbnail of it in Explorer. 3. Disable option to save a thumbnail by LO. 4. Save document again. 5. LO removes thumbnail from Explorer. Actual Results: Thumbnails of Non-ODF docs are not saved to Windows Explorer Expected Results: Thumbnails of all docs are saved to Windows Explorer Reproducible: Always User Profile Reset: No OpenGL enabled: Yes Additional Info: LO 3.3 – LO saves of thumbnails of ODF docs in Windows Explorer (tested with ODT, ODP). Non-ODF formats aren’t supported (tested with RTF, DOC, DOCX, PPT and PPTX) LO 4.2 – Start Screen introduces thumbnails, but for ODF only. LO 5.0 — Start Screen saves and displays thumbnails of all supported formats (tested with DOCX, RTF and TXT). LO 5.1 — LO gets option “Save preview image with this document” in the ‘General’ tab of the properties menu. This feature is enabled by default and is offered to every user. LINUX: I could not get a thumbnail view of any document I made with LO, but I’m not a Linux expert. I used the standard Ubuntu file manager (16.04 LTS). As thumbnails of images are displayed there, I assume that thumbs are not available for docs. IMHO fixing the issue would be extremely helpful for Windows users that have to deal with OOXML files. And almost everyone has to deal with it on a daily base (especially outside of the Linux world), if the user likes open standards or not. :-( The option “Save preview image with this document” is offered to the user since 5.1, so I filed it as an issue since then. Even though the inconsistency is there since OOo. Searched for„thumbnail save”, but found no dupe of this issue. User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Created attachment 138771 [details] Screenshot of different LO Start Screens
This works correctly with current builds of LO (5.4.4 and 6.0.0), preview thumbnails are written into the Start Center thumbnail backing panel. Also, from 5.2.0 builds on the user profile has settings (RecentDocsThumbnail and the PickListSize settings in Expert Configuration) to suppress the thumbnail creation--resetting user profile to defaults is needed. Please upgrade and retest.
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping-20180703
Visuals: Issue still there. Additional observations: a) All possible anchors of a frame are affected (Page, Paragraph, To Character, As Character) b) Every change between the anchors makes the shape (anchored to frame) disappear. (e. g. If you insert frame, change anchor to character, insert Shape, anchor it to frame and then change anchor of frame to paragraph.) c) Additionaly to shapes, fontworks are also affected. d) Only anchor 'To frame' affects Shapes and Fontworks. e) Inserted Charts, Formula and Images are not affected. f) Objects, that can only be anchored to frame (Hyperlink, Horizontal Line) are not affected. g) Enabling "Protect Position" in Shape properties does not help. h) You need one step to make shape disappear ('Change Style:Frame1'), but a second Undo to make it reappear ('Undo: Apply attributes')! Test cases suite a.) Export did not improve: Of the 36 test cases Gordo provided, 23 were exported incorrect. These export issues are still in 6.1RC2. There are no variations of the export issues (different issues). b.) Import *did* improve: 3 of those 23 were additionally imported incorrect with 4.4. The shape was displayed partly outside of frame. In MSO13, shape is displayed complete outside of it. Same with LO now. (c. Gordo provided a great spreadsheet with the test results in “objects in frames test results v1.1.odt” One of the 3 was marked as working in it ('object in frame 4.docx'). There is no regression. I tested file with 3.3 and 4.4: It had always issues.) Version: 6.1.0.2 (x64) Build ID: b3972dcf1284967612d5ee04fea9d15bcf0cc106 CPU threads: 4; OS: Windows 10.0; UI render: GL; Locale: de-DE (de_DE); Calc: group threaded
Created attachment 143830 [details] Gordo's spreadsheet with test results, updated by me
Mike: it seems your comments 4 and 5 were meant for some different bug. Putting this back to needinfo.
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping-20190321
Dear Mike, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp