Hi all together, first, yes I'm the maintainer of oxygen-icons5 and there are png file the the origin svgz files.
I don't know how the svg rendering work in plasma, BUT the svg folder is 350 mb in size the png ones are 34 mb. I don't think it's a good idea to use the svgz icons. And here is the key "problem" oxygen-icons are in maintenance mode. Not really new icons the last 8 years and I'm not interested into change something in oxygen-icons. I will fix some tiny bugs but that's it. I don't think that use the svg files didn't help someone. The icons are way to complex Cheers Andreas 2018-02-09 19:45 GMT+01:00 Friedrich W. H. Kossebau <kosse...@kde.org>: > Adding Andreas as cc:, given he semi-maintains the oxygen icons. > > Am Freitag, 9. Februar 2018, 17:49:54 CET schrieb René J. V. Bertin: > > Friedrich W. H. Kossebau wrote: > > > Am Freitag, 9. Februar 2018, 10:07:35 CET schrieb René J.V. Bertin: > > > > Two questions arise: > > > > - why are they there so many more than there are png icons (= what > are > > > > they > > > > used for)? > > Too focussed on the second question, I missed this one. Hm, doing a quick > incomplete ls -1 | wc -l on some categories I would rather see more PNG > files > per size than SVG files. > > IIRC the scalable folder simply contains the raw data/sources used to > generate > the PNG versions, kept there as source material for any further icons or > modification of existing ones. > > Andreas should know actually :) > > > > > - where are the instructions on how to install (only) the > > > > scalable version? > [snip] > > > SVG versions no longer need handcrafted substitutes) that would not > really > > > be recommended, so no-one has yet added support for that. > > > > I actually discovered the existence of the scalable icons because of > > "oxygen- icons5-scalable" packages provided by Fedora and Arch. > > That is a decision of downstream then, compare e.g. the custom code to > install > the SVGZ icon data done for Arch: > https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD? > h=packages/oxygen-icons > > Possibly something to discuss with them, either their decision to also > provide > the scalable icons to the user makes sense, if the rendered results are > acceptable, or something to ask them to revert, if the rendered result > results > in visual glitches and leaves a bad impression of Oxygen/KDE. > (From what I tested, the latter seems more sane to me, but needs full > investigation by someone using the stuff in reality) > > Given you seem a user of Arch or Fedora as you found those packages, you > might > want to pick up this task? > Andreas, what would do you think about those downstream approach to the > Oxygen > SVG files? > > > Can we assume that QIcon will use the bitmap version if it exists for a > > given size? > > If the implementation of the QIconEngine deployed (e.g. by the Plasma > integration QPlatformTheme) correctly implements the algorithm as defined > by > https://specifications.freedesktop.org/icon-theme- > spec/icon-theme-spec-latest.html#icon_lookup > then yes. > > > If so, installing the scalable versions as well shouldn't hurt > > the smaller icons on normal resolution screens, while still given the > best > > quality where even on those screens a large/huge/humongous icon size is > > used (think application icons in the app switcher on Mac). > > "Best quality" deoends on the capabilities of the SVG renderer deployed by > the > QIconTheme. As you found yourself, chance is that not. > > > > indeed at least QSvg seems to fail on some icons by a quick test, so > that > > > might be the reason. > > > > Yeah, I also thought it might be a work-in-progress; I noticed some of > those > > too: > > > > view-list-tree.svg > > qt.svg: link use5411 hasn't been detected! > > qt.svg: tab-close.svg:6352: Could not resolve property: > radialGradient3709 > > qt.svg: document-new.svg:602:58: Could not resolve property: > > linearGradient5167 qt.svg: document-open.svg:4290: Could not resolve > > property: pattern5614 qt.svg: document-open.svg:4290: Could not resolve > > property: pattern5626 qt.svg: document-open-folder.svg:4224: Could not > > resolve property: pattern5614 qt.svg: document-open-folder.svg:4224: > Could > > not resolve property: pattern5626 > > IIRC it is less work-in-progress, but simply due to mismatch of SVG > features > used to do the Oxygen icons and of what the deployed SVG runtime renderer, > i.e. typically the QSvg* one, officially supports. > > "Qt supports the static features of SVG 1.2 Tiny." > http://doc.qt.io/qt-5/svgrendering.html > > While the Oxygen icons make use of more SVG features to achieve the desired > look. That's why even the higher sizes are installed pre-rendered as PNGs. > > So unless someone works on deploying a more powerful runtime SVG renderer > or > someone works on trying to port all the SVG features used in the Oxygen > icons > to SVG 1.2 Tiny (might not be even feasible), this situation is simply a > given > state. > > > Inkscape only complains about document-new.svg ("unknown type: ns:sfw"). > > Which version of inkscape? > > Cheers > Friedrich > > >