In the current Icon-Sets there are already some Icons that exist in png AND svg versions. During my research for Bug 114699 I noticed, that the png versions can be deleted and LibO then uses the svg-versions of those Icons. Result is, that those Icons looks WAY better (perfectly sharp, no alias) then the upscaled png-versions.
So the question is, why does LibO still prefer the png-versions over the svg-ones?
Steps to Reproduce:
Open Writer (for example) and look at the icons.
They look badly (at least on HiDPI Screns).
The svg-icons should be used instead which look way better.
User Profile Reset: No
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.121 Safari/537.36 Vivaldi/1.95.1077.41
I know that libreoffice can use svg icons but the rendering is bad. So if you tell me that the svg rendering work well this is awesome. I will test it.
In the past only the breeze icon theme was available in svg so it wasn't to important to force the svg bug for me.
For 6.0 I update the elementary icon theme and with 6.1 an additional icon theme will be ready and available in svg.
Thanks for the feedback and please test as much as possible.
It would be really awesome if the svg support would work perfect but we are not there. As long as the png files look better they have to be generated.
In windows the svg support is better than on linux fyi, but also not perfect.
If needed I can upload the breeze_svg and elementary_svg icon theme to the extension webpage.
There are still a few issues but there is light at the end of the tunnel http://nabble.documentfoundation.org/Re-minutes-of-ESC-call-tt4229391.html#a4229645
Well, for me (on Windows) the SVG Rendering was perfect, but I tested only a few Icons that were available in the Tango-Set (I only deleted the PNGs where SVG where present). So, absolutely possible, that some icons don't render right, when there are attributes missing in the SVG.
But if a patch already exists, and only needs testing, Icon Sets could soon be delivered in SVG at least on Windows :)
PS: Does anybody have a link to Tango Icon Set in SVG? Would be interesting to see how many icons really are broken...
Tested the svg icon theme on linux work really good for me. In Virtualbox I had problem on a linux guest system. don't know why.
When I have time I'll upload the svg icon themes to the extension webpage.
(In reply to andreas_k from comment #5)
wrong icon theme the rendering on linux is way not perfect.
Yes, gtk3 backend has issues (because we use his way of doing HiDPI), which I know how to resolve (already did a proof-of-concept) but I need some spare time to implement it properly. The issue is described in ESC minutes...
*** Bug 115912 has been marked as a duplicate of this bug. ***
*** Bug 105489 has been marked as a duplicate of this bug. ***
*** Bug 105778 has been marked as a duplicate of this bug. ***
*** Bug 105950 has been marked as a duplicate of this bug. ***
*** Bug 106191 has been marked as a duplicate of this bug. ***
*** Bug 106682 has been marked as a duplicate of this bug. ***
*** Bug 110356 has been marked as a duplicate of this bug. ***
*** Bug 110457 has been marked as a duplicate of this bug. ***
*** Bug 114444 has been marked as a duplicate of this bug. ***
Dear Tomaz Vajngerl,
This bug has been in ASSIGNED status for more than 3 months without any
activity. Resetting it to NEW.
Please assigned it back to yourself if you're still working on this.
*** Bug 117158 has been marked as a duplicate of this bug. ***
*** Bug 117846 has been marked as a duplicate of this bug. ***
Wasn't work just done to introduce new icons in 6.1? Would it have made sense to work this as part of that?
Is calling this an enhancement accurate? It's a bug for hi dpi screens, which are really common nowadays. I would think when the interface breaks even if not functionally broken that it's an issue from a usability perspective. I love LibreOffice, but I keep reverting back to 5.2 so that the UI isn't broken.
*** Bug 120851 has been marked as a duplicate of this bug. ***
Please notice bug 121130. [Nevertheless, I support to release the svg-themes as soon as possible.]
Definitly true but only when the renderer give us the same quality as the png one.
*** Bug 122536 has been marked as a duplicate of this bug. ***
*** Bug 123480 has been marked as a duplicate of this bug. ***
Changing priority to 'high' since the number of duplicates is 5 or higher
(In reply to andreas_k from comment #24)
> Definitly true but only when the renderer give us the same quality as the
> png one.
As long as the quality didn't work, I will block the patch.
Just updated to Version: 126.96.36.199 (x64)
Build ID: b0a288ab3d2d4774cb44b62f04d5d28733ac6df8
First build since tracking the blurry/poorly rendered icons on high dpi screens that I've seen the issue fixed.
On a high dpi monitor (4k), seeing every SVG icon set render as expected, nice and crisp.
Not sure if my comment belongs here or a related issue. Just wanted to share.
(In reply to Matt from comment #29)
> Not sure if my comment belongs here or a related issue.
Thanks for the feedback. SVG is indeed the future, and once we have finished the testing phase we will switch completely.
SVG icons are rendered blurry on macOS, so adding bug #130678 as a dependency
> Just updated to Version: 188.8.131.52 (x64) Build ID: b0a288ab3d2d4774cb44b62f04d5d28733ac6df8
> First build since tracking the blurry/poorly rendered icons on high dpi screens that I've seen the issue fixed.
Well, lucky you. I'm on Ubuntu 20.04, LO 184.108.40.206 (also tested this in Arch and Fedora 32) and SVG icons are still blurry like in barely-recognizable-blurry.
Created attachment 159915 [details]
Breeze SVG icons in HiDPI screen (LO 220.127.116.11 in Ubuntu 20.04/Arch/Fedora 32)
This is the typical chicken-egg problem: LO's SVG rasterizer / icons broken => default to PNG. Everybody uses PNG (and some complain about blocky icons in HiDPI) => nobody fixes the LO's SVG rasterizer / icons. Some more background info is in bug 133877 comment 11.
And OTOH people can manually select an SVG icon set, so the pressure to fix this isn't really high.
While the SVG icons easily look better when scaled, the PNG icons definitely look better in 100% / non-scaled in Linux.
And it also doesn't help that gtk3 always scales the rasterized icons, so you get the worse 100% SVG icons scaled to HiDPI.
In general I think people with high DPI screens would prefer to use SVG icons and live with or report a small number of bugs with a small number of mid-rendered icons then live with 100% of all icons being pixelated and ugly. Perhaps making the SVG renderer default only for high DPi users of SVG-compatible icon themes would make everyone happy: high DPI users get nicer icons overall, while devs get more user eyeballs (and bug reports, and potential contributors) using the SVG renderer.
FWIW all the icons look flawless to me with the Breeze SVG icon theme and a global 250% scale scale factor
(In reply to Jan-Marek Glogowski from comment #34)
> This is the typical chicken-egg problem: LO's SVG rasterizer / icons broken
> => default to PNG. Everybody uses PNG (and some complain about blocky icons
> in HiDPI) => nobody fixes the LO's SVG rasterizer / icons. Some more
> background info is in bug 133877 comment 11.
I totally agree on that, the main problem is the SVG Rasterizer (I guess that's the same as a SVG Renderer?). But there are plenty of free OpenSource SVG Renderers out there: Inkscape, Chromium, Firefox aso... all support SVG Rendering. Isn't it possible to use the code of those, if the LibO renderer is so hard to fix?
I know its easy to talk like that when you are not a developer, so just my two cents on that ;)
Just for your information. As an icon designer and mauntainer now all icon themes have SVG versions. So I would say its safe if in some point we reach perfect SVG support, than the PNG version can be removed or moved to the extension sites.