Hi Sportegioco -

Two things:

1. Can you attach a small icon that you have tried and that is seen as pixelated (as well as one that is seen as fine). This way we can see exactly what you are seeing with the same exact image.

2. For the second issue, please report a second bug (the title being funky) - always one bug per report.


Marking as NEEDINFO - once you attach the images please set to UNCONFIRMED. Thanks for helping us out!

I have attached an image that rapresent the problem. The image show the thumbnail that create version 4.0 of libreoffice and the thumbnail that create version 4.2
I try to attach the image a second time bat i don't know why you cannot see tha attachment
Thank you.
Paolo

Created attachment 103503 [details]
Thumbnails pixelized, good and bad character

In the future please read my entire message....NEEDINFO bugs never get QA attention so I requested that you put the bug in UNCONFIRMED once you attached the requested things. Marking as UNCONFIRMED.

I can confirm the described effect. The quality of the preview depends on the width and height attributes of the root svg element, not on the content. Insert the attached pictures to the gallery (right click theme > item properties > tab Files > find files > select with Ctrl-click > Add). Right click the imported pictures > Preview.

Created attachment 103828 [details]
svg picture with width="5cm" and height="5cm"

Created attachment 103829 [details]
Same picture with width="0.5cm" and height="0.5cm"

The only difference in the two files is in the outer width and height. Because these are mapped to the same viewBox, there is no difference in the content.

Created attachment 103857 [details]
Example of file with the same image to add gallery

Thanks for the reply but I can not insert the image in this way. I have a number of sized images on a page and I have to add them one by one in the gallery. Unfortunately, the thumbnails are ugly for the little image and are good for the big image. I attached a file, the same svg file in the page if i add the little the thumbnail are bad, if i add the big the thumbnail are good. You can create a gallery and try. Thank you

J have attached a file  "Example of file with the same image to add gallery"

Unfortunately the problem is not yet resolved. 

I tried to test the old versions and noticed that it works to the last stable version of the 4.0 branch, ie LibreOffice_4.0.6.2

The next versions add some functionality, but this option does not work well

I think it would be simple to add a setting in the Advanced Configuration of the experimental features to adjust the thumbnail size option by placing a flag 'auto' that maintains the current configuration and the ability to set the size in pixels of the thumbnail

*** Bug 117330 has been marked as a duplicate of this bug. ***

The issue is actually not specific to svg files in any ways.

It also happens with drawings made with LibO itself which are saved to the gallery, with emf files, with wmf files, with pdf files, in general with anything that is rasterized to the gallery.

In fact, as indicated in bug 117330, the issue happens whenever the image being pushed to the gallery is "small".

the problem is that the preview bitmap is taken at a fixed resolution ignoring the drawing size. This is not the best thing to do as it results in wasted resources when the image is big and in a poor rendering in the gallery when the image is small.

Consider the following example:

1) A 10 inch X 10 inch vector object (e.g., a whole drawing) is placed in the gallery. Assuming that the preview bitmap is taken at 100dpi (I do not know the exact resolution being used), a 1000x1000 pixel bitmap is used for the preview. When the preview appears in the gallery, given that the object will likely be offered a 0.5x0.5 inch space, the preview will have a quite redundant 2000 dpi effective resolution.

2) A small vectory symbol 0.25 x 0.25 inches is placed in the gallery. Assuming that the preview bitmap is taken at 100dpi (I do not know the exact resolution being used), a 25x25 pixel bitmap is used for the preview. When the preview appears in the gallery, given that the object will likely be offered a 0.5x0.5 inch space, the preview will have a poor 50 dpi effective resolution.

Imho, the preview bitmap in the gallery should be created with a fixed number of pixels on the x and y axis (e.g. 256), so that it always shows well when the gallery is opened.

Changing summary per Sergio's comment in the duplicate: "Note that the issue is not specific to svg files as in bug 81593. In my test case, the images are actually drawings made with LibO itself. The issue is actually related to the "pixel size" of the images and appears with any type of vector image."

applying changes from https://lists.freedesktop.org/archives/libreoffice-bugs/2019-March/176649.html

"I am also noticing that zooming is in some cases excessive. Attaching a test
case. Updated the bug title accordingly.

Also, these are all regressions. I still have in the gallery some objects that
were put on the gallery with older versions of LibO (maybe even OO). At that
time, LibO/OO used to create gallery previews where the background transparency
was not evidenced in any way. However, all the present resolution/scaling
issues were absent. All those objects that had been put in the gallery at
ancient times look fine even when I explore the gallery with a recent version
of LibO. Yet, if I take those objects out of the gallery and then I try to put
them back in the gallery, their preview is broken.  Updated the bug title to
make the regression nature of the bug stand out."

on the outage we had to rollback to a database backup - so while comments can be restored from mail notifications, attachments can not, so please reattach your sample 
"Test case for excessive zooming/enlargement of the image in the gallery preview

To test this attachment, open the document, select the object and try to put it
in the gallery. The gallery preview will look like an horrible square blob. It
used to look like a dot (as it should) with older versions of LibO/OO."

- thanks a lot

Still a problem in Version: 7.0.0.2 (x64)
Build ID: c01aa64b6c3d89ebe5fe69c28c7adb24eb85249c
CPU threads: 8; OS: Windows 10.0 Build 18362; UI render: Skia/Raster; VCL: win
Locale: de-DE (en_US); UI: en-US
Calc: CL

Not reproducible for me with Version: 7.4.0.0.alpha0+ / LibreOffice Community
Build ID: 8b327cd86d71d71d2f5f883321e5d53e3b42ed4e
CPU threads: 8; OS: Linux 5.13; UI render: default; VCL: gtk3
Locale: fr-FR (fr_FR.UTF-8); UI: en-US
Ubuntu_20.04_x86-64
Calc: threaded

Closing as WorksForMe. Please feel free to reopen if you disagree.

Best regards. JBF

Created attachment 178103 [details]
thumbails from LO 7.4.0.0.alpha0+

Created attachment 178107 [details]
Comparison of gallery thumbnail views from Openoffice to today.

Reopening. In LibO 7.3, the situation has certainly improved wrt LibO 7.2 but it remains evidently worse than it was with way older versions of LibO and OO.

Please, check the attached comparison of gallery thumbnail views form OO to today.

In my system I have a gallery that has been built over time, so some of the entries go back to OO age. Because of how the thumbnails are generated, the older entries keep the thumbnail that was initially made and this allows for a comparison of the thumbnail generation strategy.  The attachment includes 6 entries. From left to right, top to bottom:

1. The three entries in the top row were generated with a very old LibO or even OO. They look *perfect*, apart from the fact that it is not evident that the background is transparent. Another minor issue is that the item at the top left corner is excessively enlarged.

2. The left entry in the bottom row was generated with the just released LibO 7.3. The resolution is insufficient. One line of the drawing is completely invisible.

3. The center and right entries in the bottom row were generated with some relatively recent LibO. It has the same poor resolution as the entry made by LibO 7.3 plus excessive enlargement.

Altogether, I think that anyone can agree that the best thumbnails are those made with the oldest versions of LibO.

Incidentally, this is really a minor glitch that affects usability in an extremely marginal way. Unless things really differ just for tiny details, one can quickly learn to match in the mind the thumbnail with the expected objects, no matter how large the loss in the details (there may be usage cases where the details really count though). The only actual issue is that it makes the application look less professional than counterparts.

My two cents:

- The thumbnail resolution should be a bit higher.
- When the thumbnailed objects are really very small, three should be some minor enlargement.

Dear sportegioco,

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://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug