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