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

[Rex Dieter]

René J. V. Bertin wrote:

> Rex Dieter wrote:
> 
>> I'm not aware of fedora providing any such thing.
> 
> I still had the link in my terminal scrollback:
> http://ftp.gwdg.de/pub/opensuse/tumbleweed/repo/oss/suse/noarch/oxygen5-icon-theme-scalable-5.42.0-1.1.noarch.rpm

That's an opensuse rpm, not fedora or arch (as you'd previously mentioned).

-- rex

Re: 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 :

> 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 

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

[René J . V . Bertin]

Friedrich W. H. Kossebau wrote:

> 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.

You're right actually, I see now that I missed directory level in one of my own 
ls commands (I blame a keyboard that's just too small =] )

> 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.

The thought did cross my mind, but in that case the release source tarballs 
contain over 380Mb "junk DNA" vs. only about 52Mb useful payload. A bit of a 
waste of bandwidth and download times, no?

> Given you seem a user of Arch or Fedora as you found those packages, you might
> want to pick up this task?

I'm not, in fact. I found them because I googled for scalable Oxygen icons, for 
a completely different reason (embedding a few in a binary resource).

> "Best quality" deoends on the capabilities of the SVG renderer deployed by the
> QIconTheme. As you found yourself, chance is that not.

Actually, for the examples I gave the rendered SVG still looks better at a 
larger size than an upscaled bitmap. The icon isn't exactly the same, but it 
doesn't look like a blown-up bitmap. This will differ from icon to icon of 
course; some may have weird rendering artefacts.

> So unless someone works on deploying a more powerful runtime SVG renderer or 

Isn't there a libsvg based on Cairo?

> 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.

It might also be (more?) useful to review and simplify the Oxygen icons. Not as 
an improved replacement, but as an alternative fork, say, Oxygen-Modern. I have 
no idea if the advanced SVG features have anything to do with the non-flat 
design 
or the incredible level of detail in some icons (cf. go-jump-locationbar.svgz), 
but both aspects could surely be tuned down a bit without changing the theme's 
character completely.

>> Inkscape only complains about document-new.svg ("unknown type: ns:sfw").
> 
> Which version of inkscape?

0.91 and 0.92.2 .

Cheers,
R.

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

[René J . V . Bertin]

Rex Dieter wrote:

> I'm not aware of fedora providing any such thing.

I still had the link in my terminal scrollback:
http://ftp.gwdg.de/pub/opensuse/tumbleweed/repo/oss/suse/noarch/oxygen5-icon-theme-scalable-5.42.0-1.1.noarch.rpm

R

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

[Friedrich W. H. Kossebau]

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

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

[Rex Dieter]

René J. V. Bertin wrote:


>> So all the PNG versions are there as handcrafted optimized versions of
>> their SVG counterpart, so the icons are still usable when needed in sizes
>> of 16,22,24,32,48,...
> 
> Isn't that an answer to the question "why are there also png icons" (or to
> "why are so many provided as svgs for a particular bitmap size")?
> 
>> 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.

I'm not aware of fedora providing any such thing.

As far as I know, the .svg icons included in the tarball is generally 
considered the "source code" for the shipped (generally png) icons

-- Rex

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

[René J . V . Bertin]

Friedrich W. H. Kossebau wrote:

Hi,


> So all the PNG versions are there as handcrafted optimized versions of their
> SVG counterpart, so the icons are still usable when needed in sizes of
> 16,22,24,32,48,...

Isn't that an answer to the question "why are there also png icons" (or to "why 
are so many provided as svgs for a particular bitmap size")?

> 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.

Can we assume that QIcon will use the bitmap version if it exists for a given 
size? 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).

> Hm, actually it seems the scalable versions are not even installed by the
> buildsystem?

Nope, and there is no index.theme file in the scalable subdirectory. 

> 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

Inkscape only complains about document-new.svg ("unknown type: ns:sfw").

Cheers,
R.

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

[Friedrich W. H. Kossebau]

Am Freitag, 9. Februar 2018, 14:11:34 CET schrieb Friedrich W. H. Kossebau:
> Am Freitag, 9. Februar 2018, 10:07:35 CET schrieb René J.V. Bertin:
> > - where are the instructions on how to install (only) the
> > scalable version?

Oh, my reply was done for a "how to install only" question, forgot the 
implicit variants here when typing the answer after having looked at the 
CMakeLists.txt to do some research for you (reading CMakeLists.txt is not for 
everyone it seems :) ). With that in mind, context of actual answer should 
still be valid and useful I hope.

Cheers
Friedrich

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

[Friedrich W. H. Kossebau]

Am Freitag, 9. Februar 2018, 10:07:35 CET schrieb René J.V. Bertin:
> I just discover that the huge source tarball size of the oxygen-icons5 theme
> is not a result of it using png icons, but of an enormous collection of SVG
> icons.
> 
> Two questions arise:
> - why are they there so many more than there are png icons (= what are they
> used for)?

AFAIK because the oxygen icons are more complex and detailed, the SVG version 
do not properly scale below a certain size, there are more "items" in the icon 
than what can be properly rendered onto e.g. 32x32 pixels and still be 
recognizable as result. Also are objects in the SVG not straight aligned to 
all the different pixel-sizes, given they are not based on simple 2^n scaling.

So all the PNG versions are there as handcrafted optimized versions of their 
SVG counterpart, so the icons are still usable when needed in sizes of 
16,22,24,32,48,...


> - where are the instructions on how to install (only) the
> scalable version?

Unless one has a high-dpi screen where any icon used is rendered at least as 
64x64 or 128x128 (not really sure if there is a given minimal size when the 
SVG versions no longer need handcrafted substitutes) that would not really be 
recommended, so no-one has yet added support for that.

Hm, actually it seems the scalable versions are not even installed by the 
buildsystem?
That might perhaps something worth to consider given more and more people use 
high-dpi screens. But then not sure if the svg icon rendering engine used 
supports all the SVG features used in the SVG code of the oxygen icons... 
indeed at least QSvg seems to fail on some icons by a quick test, so that 
might be the reason.

Cheers
Friedrich

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

[René J . V . Bertin]

Hi,

I just discover that the huge source tarball size of the oxygen-icons5 theme is 
not a result of it using png icons, but of an enormous collection of SVG icons.

Two questions arise:
- why are they there so many more than there are png icons (= what are they 
used for)?
- where are the instructions on how to install (only) the scalable version?

Thanks,
R.