what about the scalable subdir in the oxygen-icons5 sources?

[kainz.a]

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 <kossebau at 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20180209/60559872/attachment-0001.html>