Created attachment 104358 [details] how the start center looks I was going through the pptx files found at < http://cgit.freedesktop.org/libreoffice/core/tree/chart2/qa/extras/data/ > and noticed that most of the entries dont have previews in the start center. This was tested on 4.3.2 (2014-08-08).
Also of note is that bnc882383.pptx has a blank thumbnail, when the first slide has a pie chart on it, similar to percentage-number-formats.pptx.
OK thumbnails are really odd for most of these files on OSX and win as well. also tested linux and while I see a thumbnail it is not what the file looks like: http://cl.ly/image/2B2w0w1x323W NEW
Each of these are problem OOXML .PPTX files that LibreOffice has issues with opening and rendering. So, in reality they are not representative of the handling of Thumbnail views in the StartCenter. On Windows 7 sp1, 64-bit en-US with Version: 4.3.2.2 Build ID: edfb5295ba211bd31ad47d0bad0118690f76407d A .PPTX or .PPT file opened correctly in LibreOffice records a Thumbnail image into the users' registrymodifications.xcu as a recent document entry. That image is parsed and rendered in the Thumbnail view panel of the Start Center. That all functions correctly. Closing.
Hi Stuart, Kohei was the one who added these files and stated that libO opens them fine, which is why i went ahead and tested them. It is possible that most of them are not rendered correctly, but bnc882383.pptx is rendered correctly and still shows a blank thumbnail in the start center. Or am i still mistaken?
OK, so I've tested the bnc882383.pptx that is a slide with only a chart. The problem here is that the chart is not visible in the thumbnail. When I insert a new slide as the 1st slide, with some text inside that, it gets a thumbnail with the text etc. So now it is not that pptx'es wouldn't get any thumbnails, it is that the exact chart here is not thumbnailed... Unfortunately this is a rather low priority for me, so cannot commit to fixing this any time soon, so I am not sure it makes sense to keep the bug open; I'd suggest to re-open if we get more reports of missing elements in the pptx (or Impress in general) thumbnails.
Turned out that the core of the issue here was something else; with some of the files, even with no change, LibreOffice asked for saving the file - and when you dismiss that, the thumbnail is not updated (which is correct behavior). So closing this bug is the correct thing to do, all works fine when confirming that the file should be saved.
When i open a odt file and i make changes to it and when the close the doc and tell it not to save changes, a thumbnail is still created, so how is this behaviour any different here.
Jay, *, (In reply to Jay Philips from comment #7) > When i open a odt file and i make changes to it and when the close the doc > and tell it not to save changes, a thumbnail is still created, so how is > this behaviour any different here. Although you do not save it, you have recently used it. So it gets added to the history of recent documents--and a thumbnail view is generated and displayed on the backing window of the Start Center in the thumbnail views panel. The same happens for any document, ODF, OOXML, MS, etc., that LibreOffice can fully open. That all works correctly. The source of the thumbnail view is the same--it is regenerated when opening any ODF document, and is only refreshed when/if document is saved. Thumbnail views can be recorded into two locations--inside any ODF document when it is saved, and always into the per-user configuration file holding the recent documents list. A thumbnail preview that is associated with an ODF document is recorded into its zip'd archive Thumbnails folder as thumbnail.png -- but only when the document is saved. OOXML also have a facility to save thumbnails but I don't believe we exploit it (e.g. in docProps as thumbnail.jpeg)--that would be in the ww8 export filter. A new thumbnail view is generated when any document is opened, and is immediately added to the recent documents listing (per user in the registrymodifications.xcu configuration file) The thumbnail view obviously can not be written back to document formats that don't support it. So those thumbnails will only exist with their recent documents list entry per-user in registrymodifications.xcu. The thumbnail view recorded into registrymodifications.xcu will be the initial page view of any document when opened. Or--only if password protected--the generic LibreOffice icon for the ODF type. Finally, if no "preview" thumbnail can be generated, the Start Center thumbnail views panel displays the LibreOffice icon associated with the component that can open it. A Base project for example.
Thanks for the explanation Stuart, but that doesnt solve the issue. If i open the pptx files and then close it and click save changes though i didnt make any changes to the file, a thumbnail appears for the document in the start center. If i open the pptx files and then close it without saving changes, no thumbnail appears in the start center. This is the problem.
(In reply to Jan Holesovsky from comment #6) > Turned out that the core of the issue here was something else; with some of > the files, even with no change, LibreOffice asked for saving the file - and > when you dismiss that, the thumbnail is not updated (which is correct > behavior). The issue of the undos is in bug 82400, but if dismissing changes doesnt update the thumbnail, why wasnt a thumbnail added when i first opened the file, as stuart states below. (In reply to V Stuart Foote from comment #8) > Although you do not save it, you have recently used it. So it gets added to > the history of recent documents--and a thumbnail view is generated and > displayed on the backing window of the Start Center in the thumbnail views > panel. The same happens for any document, ODF, OOXML, MS, etc., that > LibreOffice can fully open. That all works correctly. > ... > > A new thumbnail view is generated when any document is opened, and is > immediately added to the recent documents listing (per user in the > registrymodifications.xcu configuration file) @Maxim: Can you enlighten me on this, as it never sat well with me since kendy closed it as invalid.
(In reply to Yousuf (Jay) Philips from comment #10) @Jay, not sure how Maxim will respond, but I just verified that a .PPTX simply opened and closed into Impress does generate a thumbnail view recorded into the per-user registrymodification.xcu routinely. Not sure, but expect if it were password protected the document would not receive a Thumbnail view--just its generic 128px Impress icon placeholder.
(In reply to V Stuart Foote from comment #11) > @Jay, not sure how Maxim will respond, but I just verified that a .PPTX > simply opened and closed into Impress does generate a thumbnail view > recorded into the per-user registrymodification.xcu routinely. Well i was asking Maxim to look into the code as kendy is on holiday and was quick to dismiss this issue, when there is an issue. I can verify that opening ( http://cgit.freedesktop.org/libreoffice/core/plain/chart2/qa/extras/data/pptx/chart.pptx ) and xkill'ing LO will not generate a thumbnail, but doing the same with a docx will generate a thumbnail. So your statement, "A new thumbnail view is generated when any document is opened", is not correct. > Not sure, but expect if it were password protected the document would not > receive a Thumbnail view--just its generic 128px Impress icon placeholder. Well we werent talking about password protected documents, as they are not supposed to have thumbnails. What this boils down to is that LO has inconsistent behaviour for generating thumbnails when opening a document (of course xkill'ing LO after the file is open to see if the thumbnail is in the start center). * Open some pptx - thumbnail generated (http://cgit.freedesktop.org/libreoffice/core/plain/chart2/qa/extras/data/pptx/percentage-number-formats.pptx) * Open some pptx - no thumbnail generated ( http://cgit.freedesktop.org/libreoffice/core/plain/chart2/qa/extras/data/pptx/chart.pptx )
[Sorry for the long post] We create/refresh saved thumbnail at different times, like file open/save/close (see Bug 37775). But we do this only if the document is flagged as non-modified, otherwise a generic icon is used, or a previously saved thumbnail if there is any. In this bug a document is erroneously flagged as modified right upon opening, so no valid thumbnail will be created. The reason for this behavior (I guess) is that if a document is modified but not saved, we don't want the unsaved modifications to be shown in the thumbnail. What's not clear to me is: 1. This check seems to be needed only at file close, i.e. a user is closing the file, while rejecting the changes he made to it. But I wonder why do we need to refresh the recent list at all at this stage? In order to close a file, one first needs to open it, isn't it? So the recent item is *already exists*. And if modifications were made and were saved - then again, the thumbnail will be updated already at this stage. The only uncovered case is when a user clears the recent list using the "Clear List" menu item, while the document is open. But I wonder whether it's a good idea to re-add the document to the list upon closing, even though the user clearly showed his intention to keep the list clear for now. In case all of the above is correct - it means that the thumbnail creation doesn't have to depend on whether the document was modified or not, and it will solve this bug. 2. At least when the thumbnail creation method is called upon file open, why should we care whether the document is flagged as modified (for some reason), given that we know for sure that the document is just opened, and the user hadn't a chance to make any manual changes to it? As kendy is the one who introduced this is-modified check, would be great to hear his opinion on this, and in particular what were the reasons for introducing this check in the first place. -------- But I must clarify 2 things: 1. The real bug here is that documents are flagged as modified while they're not. (BTW I looked at SfxObjectShell::IsModified, and it seems that the modified state comes from the embedded charts. I commented there the code that checks the status of embedded objects, and this caused all of those files to show thumbnails in the start center.) 2. I don't like the idea of changing a working code (which is always a recipe for regressions), just to workaround some uncommon cases. We should consider this only if we'll see a critical mass of documents that won't show in the start center. We're still not there.
(In reply to Maxim Monastirsky from comment #13) > [Sorry for the long post] Thanks for the detailed explanation. :D > 1. This check seems to be needed only at file close, i.e. a user is closing > the file, while rejecting the changes he made to it. But I wonder why do we > need to refresh the recent list at all at this stage? In order to close a > file, one first needs to open it, isn't it? So the recent item is *already > exists*. I would assume saving a more recent version of the thumbnail to the ODF file, so that new preview could appear in something like a file manager preview would be the intent here, as there wouldnt be a benefit for the start center. > 2. At least when the thumbnail creation method is called upon file open, why > should we care whether the document is flagged as modified (for some > reason), given that we know for sure that the document is just opened, and > the user hadn't a chance to make any manual changes to it? Yep that doesnt make sense to check if the modified flag is set right after LO opens the doc. > 1. The real bug here is that documents are flagged as modified while they're > not. (BTW I looked at SfxObjectShell::IsModified, and it seems that the > modified state comes from the embedded charts. I commented there the code > that checks the status of embedded objects, and this caused all of those > files to show thumbnails in the start center.) Yep this does seem to be the root of the problem (bug 82402). > 2. I don't like the idea of changing a working code (which is always a > recipe for regressions), just to workaround some uncommon cases. We should > consider this only if we'll see a critical mass of documents that won't show > in the start center. We're still not there. This issue came to mind again when i saw a screenshot of the start center with missing thumbnails in a review of 5.0 ( http://me.pcmag.com/libreoffice-50/3008/review/libreoffice-50 ), though it was for calc openable files. http://im.ziffdavisinternational.com/t/pcmag_me/review/l/libreoffic/libreoffice-50_q6rn.320.jpg
(In reply to Yousuf (Jay) Philips from comment #14) > I would assume saving a more recent version of the thumbnail to the ODF Saving to ODF isn't affected by this, we're talking only about the thumbnail that's stored in the user profile. (And the actual file shouldn't change anyway, unless the user decides to save it.) > This issue came to mind again when i saw a screenshot of the start center > with missing thumbnails in a review of 5.0 Maybe those are for password protected files? I'm usually testing a lot of files from bugzilla, and never saw such thing except in this bug.
(In reply to Maxim Monastirsky from comment #15) > (In reply to Yousuf (Jay) Philips from comment #14) > > I would assume saving a more recent version of the thumbnail to the ODF > Saving to ODF isn't affected by this, we're talking only about the thumbnail > that's stored in the user profile. (And the actual file shouldn't change > anyway, unless the user decides to save it.) Yes correct. > > This issue came to mind again when i saw a screenshot of the start center > > with missing thumbnails in a review of 5.0 > Maybe those are for password protected files? I'm usually testing a lot of > files from bugzilla, and never saw such thing except in this bug. Just happened to me today that if i open any file in calc which has a chart, it will ask me to save on exit even if i do not modify it. So i assume that is what happened in that same screenshot.
So it will happen with any file that has a chart in it for calc and impress. http://cgit.freedesktop.org/libreoffice/core/plain/chart2/qa/extras/data/odp/chart.odp (thumbnail is in the file) http://cgit.freedesktop.org/libreoffice/core/plain/chart2/qa/extras/data/xls/chart.xls http://cgit.freedesktop.org/libreoffice/core/plain/chart2/qa/extras/data/ods/chart.ods (thumbnail is in the file)
Created attachment 120153 [details] screenshot from files in comment 17 retested under Win8.1 x64 using LibO 5.0.3.1 and a recent 5.1.0.0 alpha build there's no thumb for the .XLS the thumb for the .ODS is off center the thumb for the .ODP is correctly shown
(In reply to tommy27 from comment #18) > retested under Win8.1 x64 using LibO 5.0.3.1 and a recent 5.1.0.0 alpha build > > there's no thumb for the .XLS > the thumb for the .ODS is off center > the thumb for the .ODP is correctly shown All three files have no thumbnails if the already saved thumbnail (/Thumbnails/thumbnail.png) was removed from within the odf files.
Created attachment 120161 [details] screenshot without internal thumbnail.png
hod did you remove the thumb? manually?
(In reply to tommy27 from comment #21) > hod did you remove the thumb? manually? You can either rename the odf files to .zip and simply open them in the compression software (e.g. 7zip) and goto the thumbnail folder and delete the image.
Ok, but why a user should hack that file? if you don't hack those file you correcly see the thumbnails except the .xls... am I missing something?
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.6 or 5.2.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170103
still present. Version: 6.0.0.0.alpha0+ Build ID: 7315f325ff7ada3d6bd85a471058fdaeaff8cdb0 CPU threads: 2; OS: Linux 4.4; UI render: default; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-09-17_06:58:21 Locale: en-US (en_US.UTF-8); Calc: group
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Dear Yousuf Philips (jay) (retired), To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Tested with 6 files (thumbnail stripped when applicable): http://cgit.freedesktop.org/libreoffice/core/plain/chart2/qa/extras/data/odp/chart.odp (thumbnail is in the file) http://cgit.freedesktop.org/libreoffice/core/plain/chart2/qa/extras/data/xls/chart.xls http://cgit.freedesktop.org/libreoffice/core/plain/chart2/qa/extras/data/ods/chart.ods (thumbnail is in the file) http://cgit.freedesktop.org/libreoffice/core/plain/chart2/qa/extras/data/pptx/percentage-number-formats.pptx http://cgit.freedesktop.org/libreoffice/core/plain/chart2/qa/extras/data/pptx/chart.pptx https://cgit.freedesktop.org/libreoffice/core/plain/chart2/qa/extras/data/pptx/bnc882383.pptx Using version 6.3, all files listed above show a thumbnail except for the XLS file. Version: 6.3.6.2 Build ID: 2196df99b074d8a661f4036fca8fa0cbfa33a497 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3; Locale: en-AU (en_AU.UTF-8); UI-Language: en-US Calc: threaded Starting with LO 7.1, the XLS file does not ask for saving changes when there's no changes + shows a preview in the start centre. Version: 7.1.8.1 / LibreOffice Community Build ID: e1f30c802c3269a1d052614453f260e49458c82c CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Marking as Resolved - Works for me, unless someone can point to a file that still doesn't show a thumbnail in the start centre (and even so, maybe better to file a new, more specific bug)