Following bug 788016 and bug 911533, I've finally hacked together a replacement for librsvg's pixbuf loader, media-libs/libsvgtiny-pixbuf. It's not a perfect replacement and should only be used as a fallback. (If you install both at the same time, librsvg takes preference). The rendering is not nearly is good, but it does greatly improve one's situation compared to putting librsvg in package.provided and letting all of GTK's icons be broken. For the people who can't/won't use rust, it's nice to have the option. CC xfce@ in case this can work for xfce4-meta[svg], too.
Do gtk and gtk+ tests pass with it?
As my initial 2 cents, I suspect a plain `|| ( )` between them might be too generous too, unless it can really render most SVGs (like the ones that non-rust librsvg breaks on too). So just to throw it out there, maybe it's a case for a pixbuf svg renderer virtual where we could have both of them via an annoying USE flags + REQUIRED_USE thing, but then package.use.mask the libsvgtiny-pixbuf option with an appropriate message? Or that's maybe almost as good as package.provided + manual install of the libsvgtiny-pixbuf renderer? To me the main question is if it can handle building adwaita-icon-theme - I'm not sure gtk tests do much anything with it (librsvg is higher in the stack, so a bit surprised if they test it much in gtk test suite, but there's probably something there too). Basically whether gtk-encode-symbolic-svg works with it for all packages that use it (and offhand I only know of adwaita-icon-theme).
(In reply to Sam James from comment #1) > Do gtk and gtk+ tests pass with it? I'm glad you asked, because no. There's one test for gtk+ that checks for byte-equality of a rendered image involving an icon and that fails "expectedly," since the rendered PNGs are never going to look the same with libsvgtiny. The same test fails for gtk4, and then there are a few others in gtk4 that I'll look into today. (In reply to Mart Raudsepp from comment #2) > To me the main question is ... Basically whether gtk-encode-symbolic-svg works with it for all packages that use it (and offhand I only know of adwaita-icon-theme). Yes and no. Yes, I specifically added support for encoding of symbolic SVGs, built adwaita-icon-theme, and tested the result with epiphany and evolution using both light and dark themes. No, the result is not correct, because while libsvgtiny does support CSS, it doesn't support it via a separate <style> element at the moment. I'm sure that becomes important in some cases, but I don't know what they are.
GTK3: 18/194 gtk+:gtk / defaultvalue FAIL 5.22s killed by signal 5 SIGTRAP 67/194 gtk+:gtk / objects-finalize FAIL 10.38s killed by signal 5 SIGTRAP 134/194 gtk+:reftest / reftest icon-vfuncs.ui FAIL 1.39s exit status 1 The icon one is due to a rendering issue. The SIGTRAPs, I dunno. GTK4: 85/724 gtk:gsk+gsk-compare+gsk-gl+gsk-compare-gl / gl texture-scale-stripes FAIL 2.44s exit status 1 86/724 gtk:gsk+gsk-compare+gsk-gl+gsk-compare-gl / gl texture-url FAIL 2.44s exit status 1 152/724 gtk:gsk+gsk-compare+gsk-cairo+gsk-compare-cairo / cairo texture-scale-stripes FAIL 0.71s exit status 1 153/724 gtk:gsk+gsk-compare+gsk-cairo+gsk-compare-cairo / cairo texture-url FAIL 0.72s exit status 1 202/724 gtk:gsk / parser texture-scale-filters.node FAIL 0.92s exit status 1 425/724 gtk:css / parser doubled.css ERROR 0.12s killed by signal 5 SIGTRAP 641/724 gtk:reftest / reftest icon-vfuncs.ui FAIL 3.03s 0/1 subtests passed 711/724 gtk:reftest / reftest symbolic-icon-translucent-color.ui FAIL 3.00s 0/1 subtests passed SIGTRAP question mark again. I can't explain texture-scale-filters.node either, but the rest are rendering issues. The first four I would say are buggy tests though. They're carefully checking some texture properties after rendering, <svg><rect width="10" height="10" style="fill:red"/></svg> But, devoid of any context, it's not clear how that SVG should be rendered. What's its height/width? The viewBox? How big is the viewport? Etc. The test just assumes that whatever librsvg does is right. If anyone is interested in the trivia, I already looked into that before, and librsvg is basically guessing. It's rendering the SVG to a cairo surface and then making a best guess at the size and aspect ratio based on the result. Libsvgtiny will only come to the same conclusions when the SVG includes a height, width, and viewbox inside the <svg> element. Fortunately, most real icons do. Based on some gitlab comments I've seen, the author of librsvg is not happy about the guessing either. Anyway: I'm curious about the texture-scale-filters.node failure and the SIGTRAPs, but the rest have to be ignored -- it's what you're signing up for. Would hiding the dependency behind USE=libsvgtiny be agreeable? That has a few benefits: 0. It's off by default 1. You can explain why it exists and its downsides in metadata.xml 2. It allows you to selectively disable the tests that are known to fail in src_prepare. Or if you really want to nuke them, have USE=librsvgtiny block USE=test. 3. You can force-enable it in non-rust profiles
Ionen Wolkens<ionen@gentoo.org> AttachmentSat, Aug 26, 2023 at 5:59 PM Reply-To: gentoo-dev@lists.gentoo.org, gentoo-dev-announce@lists.gentoo.org, gentoo-dev@lists.gentoo.org To: gentoo-dev-announce@lists.gentoo.org Cc: gentoo-dev@lists.gentoo.org Reply | Reply to all | Forward | Print | Delete | Show original Noticed that the following packages have been dropped to m-n back on August 9 2023, but no mail been sent: acct-group/maradns acct-user/duende acct-user/maradns app-admin/ryzen_monitor app-admin/ryzen_smu app-portage/pkg-testing-tools app-shells/zsh app-text/zathura dev-libs/girara dev-libs/libdispatch dev-python/pyfuse3 media-gfx/feh media-gfx/gpicview media-libs/nanosvg media-sound/deadbeef net-libs/libtorrent-rasterbar net-misc/httpie net-p2p/nicotine+ net-p2p/qbittorrent sys-apps/pmount sys-auth/ssh-import-id sys-fs/mergerfs sys-fs/mergerfs-tools sys-fs/snapraid sys-power/RyzenAdj x11-misc/sunflower x11-misc/xclip -- ionen Seems like there is also this for parsing svg's: media-libs/nanosvg
(In reply to stefan11111 from comment #5) > > Seems like there is also this for parsing svg's: > media-libs/nanosvg I looked at that and IIRC I was put off by the "This project is not actively maintained" as the first line of README.md. The main thing that's missing from libsvgtiny (with respect to GTK) is the ability to handle the <style> element that GTK prepends to its symbolic SVGs. I don't think it would take more than a few hours of hacking to implement it. dev-libs/libcss supports any DOM abstraction, and in particular the one that libsvgtiny uses, net-libs/libdom. So it's just a matter of writing the code to make shape->foo return the computed CSS value of foo rather than the value of shape's foo attribute. But, so far, I haven't actually noticed a real problem with the symbolic SVGs that I've generated with libsvgtiny. All of my symbolic icons show up correctly in both light and dark themes despite them being "wrong," so I haven't been very motivated to spend a day on it.
(In reply to Sam James from comment #1) > Do gtk and gtk+ tests pass with it? My SIGTRAPs have disappeared as mysteriously as they appeared in the first place. And I fixed those upstream tests in gtk-4: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6359 That leaves only the one expected failure with gtk3: 134/194 gtk+:reftest / reftest icon-vfuncs.ui FAIL ... Ok: 193 Expected Fail: 0 Fail: 1 And the two with gtk4: 641/724 gtk:reftest / reftest icon-vfuncs.ui FAIL 711/724 gtk:reftest / reftest symbolic-icon-translucent-color.ui FAIL ... Ok: 721 Expected Fail: 0 Fail: 2
(In reply to Michael Orlitzky from comment #6) > > The main thing that's missing from libsvgtiny (with respect to GTK) is the > ability to handle the <style> element that GTK prepends to its symbolic SVGs. > > I don't think it would take more than a few hours of hacking to implement > it... I have to retract that a bit. I wrote a proof-of-concept, and structurally it went as expected. But libcss is missing support for the special SVG properties like "fill", "stroke", and "stroke-width". Adding them would not be especially difficult either but now we're two TODOs deep.
Update: 1. media-libs/libsvgtiny-pixbuf is now stable on amd64. We were waiting for new releases of some dependencies to fix segfaults and to get the test suites passing. 2. dev-libs/libcss-0.9.2 supports the SVG fill-opacity and stroke-opacity properties. I added these as a proof-of-concept for myself, to make sure that I could do it. We still need fill-color for GTK's symbolic icons though. 3. I've added true CSS support to libsvgtiny using dev-libs/libcss in a branch at http://gitweb.michael.orlitzky.com/?p=libsvgtiny.git;a=shortlog;h=refs/heads/libcss. I posted it to the ML a while ago but it's a lot to review. This lets libsvgtiny parse <style> tags and inline style= attributes; the former is needed for GTK's symbolic icons. 4. In practice, I still have not actually noticed a problem with any symbolic icons. I've switched to sway/wayland from xfce, but am still using a lot of GTK programs. For the future: 0. Wait for my libcss branch to get merged into libsvgtiny. 1. Submit a PR to GTK to use "fill-color" instead of "fill" in gtk/gdktextureutils.c (fill-color is easier to implement). 2. Implement fill-color in libcss by copying some other color property. 3. Success.
By the way, the last non-rust version of librsvg is now masked in the base profile, not just in the ebuild, so it's pretty clearly on the way out: > # matoro <matoro_gentoo@matoro.tk> (2024-08-18) > # Pre-rust versions of librsvg. Has vulnerabilities, so masked by > # default and only unmasked on wd40. > <gnome-base/librsvg-2.41 Enabling the use of librsvgtiny instead would be a very good thing. I support.
