ImageMagick ships with a file, /etc/ImageMagick-7/delegates.xml, that specifies how some conversions will be performed. In particular, it has the line <delegate decode="svg:decode" stealth="True" command=""inkscape" "%s" --export-png="%s" --export-dpi="%s" --export-background="%s" --export-background-opacity="%s" > "%s" 2>&1"/> which suggests that it uses inkscape to convert from e.g. SVG to PNG. I wouldn't swear to that, but imagemagick (even with USE=svg) doesn't depend on inkscape, and without it some breakage occurs. For example, when building the Gentoo devmanual from https://gitweb.gentoo.org/proj/devmanual.git the following command will be run, convert general-concepts/autotools/diagram.svg \ general-concepts/autotools/diagram.png With inkscape installed, that works fine. Without it, you get convert: no images defined `general-concepts/autotools/diagram.png' @ error/convert.c/ConvertImageCommand/3300. Currently app-doc/devmanual is depending on media-gfx/imagemagick[svg] in hopes of making that command work, but as you can see that's not enough -- you need inkscape installed. Please let me know what you think.
If this is the case, then adding it to PDEPEND would be necessary to avoid a circular dependency.
Maybe a postinst (or readme.gentoo) message would be more appropriate in this situation? Not all users may want inkscape to be pulled in with USE=svg.
This is a little bit more complicated than I thought. It looks like imagemagick's build system can detect both inkscape and rsvg, and that delegates.xml file is built from delegates.xml.in at configure-time. The good news is that imagemagick already knows one fallback SVG conversion program, namely rsvg-convert. But the arguments for it aren't compatible with the arguments to inkscape, and both of them wind up in delegates.xml even if inkscape isn't installed (the macro in configure.ac just leaves the path at "inkscape" if it's not found). From what I gather, inkscape is the better conversion program, so should be preferred; but it is a heavy dependency. This needs more testing, but here's my current suggestion: 1. Add a local "inkscape" USE flag to imagemagick for "improved SVG support using media-gfx/inkscape." 2. If USE="svg inkscape" is set, pull in inkscape. Problem solved. 3. If USE="svg -inkscape" is set, then drop the inkscape line from delegates.xml and make sure that the fallback to rsvg-convert works. The only possible downside to this is that people may start getting rsvg-convert (via "convert") in situations where previously they would have figured out that they had to install inkscape. As far as this affects the devmanual... I don't think it does. The images there are simple, and rsvg-convert is faster, so I think it may be wise to replace "convert" by "rsvg-convert" in the devmanual Makefile anyway. I can try this on another bug.
(In reply to Michael Orlitzky from comment #3) > This is a little bit more complicated than I thought. It looks like > imagemagick's build system can detect both inkscape and rsvg, and that > delegates.xml file is built from delegates.xml.in at configure-time. Does that mean that inkscape must be a build time dependency? If yes, we'd have circular build-time dependencies between imagemagick and inkscape.
(In reply to Ulrich Müller from comment #4) > (In reply to Michael Orlitzky from comment #3) > > This is a little bit more complicated than I thought. It looks like > > imagemagick's build system can detect both inkscape and rsvg, and that > > delegates.xml file is built from delegates.xml.in at configure-time. > > Does that mean that inkscape must be a build time dependency? If yes, we'd > have circular build-time dependencies between imagemagick and inkscape. Inkscape should be fine in imagemagick's PDEPEND. The configure script for imagemagick is a little weird, and maybe the circular dependency is why. It first sets SVGDecodeDelegateDefault='inkscape' and then later checks for that program, AC_PATH_PROG(SVGDecodeDelegate, "$SVGDecodeDelegateDefault", "$SVGDecodeDelegateDefault") But notice that if the progran is *not* found, that it defaults the value of the corresponding variable to $SVGDecodeDelegateDefault, i.e. 'inkscape'. And that's what winds up in delegates.xml: <delegate decode="svg:decode" stealth="True" command=""@SVGDecodeDelegate@" ... The end result is that if inkscape is not installed, the delegate is still configured, but with a path of "inkscape" instead of e.g. "/usr/bin/inkscape". That's why I think everything will be OK if inkscape is in PDEPEND.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/devmanual.git/commit/?id=6bff1eb8b62b9d07e1cc1098eb617f9302487907 commit 6bff1eb8b62b9d07e1cc1098eb617f9302487907 Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2019-12-10 03:10:18 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2020-01-27 19:57:02 +0000 Makefile: use rsvg-convert to generate PNGs from SVGs. Our Makefile currently uses inkscape (via imagemagick's "convert" wrapper) to turn SVGs into PNGs. This has a few downsides: * media-gfx/inkscape is a huge dependency, * inkscape is slow to perform the conversion, * installing imagemagick[svg] doesn't ensure that "convert" can convert an SVG to a PNG if inkscape is missing (bug 684686). The good news is that there is another SVG -> PNG conversion tool called rsvg-convert that is installed by gnome-base/librsvg. Compared to inkscape, librsvg is a light dependency and rsvg-convert is lightning-fast. Moreover, installing gnome-base/librsvg guarantees that the latter will exist and can actually perform the conversion. Inkscape is supposedly more powerful, but so far in the devmanual we're only using SVG to put words in boxes. The simpler tool is sufficient for that, and therefore preferable. This commit updates the Makefile to use rsvg-convert. Bug: https://bugs.gentoo.org/684686 Closes: https://bugs.gentoo.org/700904 Signed-off-by: Michael Orlitzky <mjo@gentoo.org> Signed-off-by: Ulrich Müller <ulm@gentoo.org> Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
(In reply to Larry the Git Cow from comment #6) I think we can remove devmanual from CC.
I'm going to add the dependency since this is breaking dev-python/sphinx. That said, I think requiring X apps is just an asinine move from upstream and it's gonna make people real sad.
...or I can't because of missing keywords. Just awesome.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e7dc825e4efa1d431354cf8e21f9be3722a8eeb4 commit e7dc825e4efa1d431354cf8e21f9be3722a8eeb4 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2020-06-02 08:14:54 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2020-06-02 08:16:11 +0000 media-gfx/imagemagick: Add missing inkscape dep Bug: https://bugs.gentoo.org/684686 Signed-off-by: Michał Górny <mgorny@gentoo.org> .../imagemagick/imagemagick-7.0.10.16-r1.ebuild | 268 +++++++++++++++++++++ 1 file changed, 268 insertions(+)
Should the svg dependency be an or? Seems like it pulls in inkscape, rsvg and potrace I've uninstalled imagemagick here, due to: [ebuild N ] media-gfx/inkscape-1.0::gentoo USE="cdr dbus exif jpeg lcms nls openmp spell -dia -graphicsmagick -imagemagick -inkjar -jemalloc -postscript -static-libs -svg2 -visio -wpg" PYTHON_SINGLE_TARGET="python3_8 -python3_6 -python3_7" 62,800 KiB [ebuild N ] app-text/gtkspell-3.0.10:3/0::gentoo USE="introspection -vala" 294 KiB [ebuild N ] dev-libs/gdl-3.28.0:3/5::gentoo USE="introspection" 529 KiB [ebuild N ] dev-cpp/gtkmm-3.24.2:3.0::gentoo USE="X wayland (-aqua) -doc -test" ABI_X86="(64) -32 (-x32)" 13,024 KiB [ebuild N ] dev-cpp/pangomm-2.42.1:1.4::gentoo USE="-doc" ABI_X86="(64) -32 (-x32)" 862 KiB [ebuild N ] dev-cpp/cairomm-1.12.0-r1::gentoo USE="X svg (-aqua) -doc" ABI_X86="(64) -32 (-x32)" 772 KiB [nomerge ] media-gfx/inkscape-1.0::gentoo USE="cdr dbus exif jpeg lcms nls openmp spell -dia -graphicsmagick -imagemagick -inkjar -jemalloc -postscript -static-libs -svg2 -visio -wpg" PYTHON_SINGLE_TARGET="python3_8 -python3_6 -python3_7" [nomerge ] app-text/aspell-0.60.8::gentoo USE="nls unicode" L10N="en -af -be -bg -br -ca -cs -cy -da -de -de-1901 -el -eo -es -et -fi -fo -fr -ga -gl -he -hr -hu -hy -is -it -la -lt -nl -no -pl -pt -pt-BR -ro -ru -sk -sl -sr -sv -uk -vi" [ebuild N ] app-dicts/aspell-en-2018.04.16.0::gentoo 181 KiB [ebuild N ] app-text/aspell-0.60.8::gentoo USE="nls unicode" L10N="en -af -be -bg -br -ca -cs -cy -da -de -de-1901 -el -eo -es -et -fi -fo -fr -ga -gl -he -hr -hu -hy -is -it -la -lt -nl -no -pl -pt -pt-BR -ro -ru -sk -sl -sr -sv -uk -vi" 3,405 KiB [nomerge ] dev-cpp/gtkmm-3.24.2:3.0::gentoo USE="X wayland (-aqua) -doc -test" ABI_X86="(64) -32 (-x32)" [ebuild N ] dev-cpp/atkmm-2.28.0::gentoo USE="-doc" ABI_X86="(64) -32 (-x32)" 871 KiB [nomerge ] app-text/gtkspell-3.0.10:3/0::gentoo USE="introspection -vala" [ebuild N ] app-text/enchant-2.2.8:2::gentoo USE="hunspell -aspell" 954 KiB [nomerge ] media-gfx/inkscape-1.0::gentoo USE="cdr dbus exif jpeg lcms nls openmp spell -dia -graphicsmagick -imagemagick -inkjar -jemalloc -postscript -static-libs -svg2 -visio -wpg" PYTHON_SINGLE_TARGET="python3_8 -python3_6 -python3_7" [ebuild N ] dev-cpp/glibmm-2.64.2:2::gentoo USE="-debug -doc -test" ABI_X86="(64) -32 (-x32)" 7,264 KiB [ebuild N ] dev-libs/libsigc++-2.10.3:2::gentoo USE="-doc -static-libs -test" ABI_X86="(64) -32 (-x32)" 4,452 KiB [ebuild N ] dev-cpp/mm-common-1.0.0::gentoo 263 KiB [ebuild N ] dev-python/numpy-1.18.3::gentoo USE="-doc -lapack -test" PYTHON_TARGETS="python3_8 -python3_6 -python3_7" 5,308 KiB [ebuild N ] media-gfx/scour-0.37::gentoo PYTHON_TARGETS="python3_8 -python3_6 -python3_7" 94 KiB [ebuild N ] sci-libs/gsl-2.5-r1:0/23::gentoo USE="deprecated -cblas-external -static-libs" 7,145 KiB
Wouldn't it be better to mask the svg useflag for imagemagick? Right now it has the very surprising effect to pull in inkscape - which might be annoying, but not that big a deal on a desktop system. On a X-less server system that uses (for example) php-imagick installing an X program is more than surprising - it's completely out of the question.
Right now USE=svg needs inkscape. It sucks, but it's going to require someone with both the time and interest to fix properly. If you don't want inkscape, don't set USE=svg for imagemagick. Comment #3 and comment #5 were attempts to summarize the problem and solution. If I'm remembering correctly, some work upstream should be done so that when inkscape is not detected, the fallback to rsvg-convert works properly. Then the dependency on those two can be made an "or". But for now (well, a year ago, at least), inkscape gets used for conversion even when the build system detects that it's missing.
*** Bug 727098 has been marked as a duplicate of this bug. ***
ImageMagick with SVG use flag enabled required by some other packages. I CANNOT disable it! I don't need INKSCAPE! I can build and run ImageMagick without inkscape! Please remove it from dependency list. Inkscape pulls Python2.7 as yet another dependency. I really don't need that mess on my system. It doesn't solved ANY problem. Anyone who need inkscape may use inkscape USE flag. Please stop that nonsese!!!
(In reply to Alex from comment #15) > ImageMagick with SVG use flag enabled required by some other packages. > > I CANNOT disable it! > > I don't need INKSCAPE! > > I can build and run ImageMagick without inkscape! > > Please remove it from dependency list. > > > Inkscape pulls Python2.7 as yet another dependency. > > I really don't need that mess on my system. > > It doesn't solved ANY problem. > > Anyone who need inkscape may use inkscape USE flag. > > > Please stop that nonsese!!! USE="-svg" emerge -a imagemagick
(In reply to Michael Orlitzky from comment #13) > Right now USE=svg needs inkscape. It sucks, but it's going to require > someone with both the time and interest to fix properly. If you don't want > inkscape, don't set USE=svg for imagemagick. Wrong solution! Totally wrong! Any one who need inkscape for what ever reason can enable inkscape use flag if one will be added. Please DO NOT BREAK existing and working functionality! svg use flag cannot be disabled just like that! other programs have it as depedency! ImageMagick is a Library! There is very high probability it may be a dependency of some other packages. Inkscape is a client an end user program. It cannot and should not be a dependecy of ANYTHING. Anything opposite is wrong design. I don't care who is wrong here. Just restore the old and WORKING functionality. pulling inkscape and then pulling python 2.7 is a nightmare. Absolutely ANYONE who need or like that solution will have no problem to add inkscape as use flags and be clear of circular depedency it creates. The current design is WRONG. Stop it.
Yes there is a problem upstream, for some reason inkscape is required for svg, that's the discussion on this bug, otherwise simply "+svg" is pointless.
> USE="-svg" emerge -a imagemagick You can't read or what? I type for you once again USE=svg IS required. period. Inkscape is not required and not desired. You want make USE=-svg working, then go all over the portage tree and remove the depdendence: imagemagick[svg] Plus explain me why do I need to have 2 pythons just because I need imagemagick? P.S. One python is too many already.
(In reply to Vasco Gervasi from comment #18) > Yes there is a problem upstream, for some reason inkscape is required for > svg, that's the discussion on this bug, otherwise simply "+svg" is pointless. You have got it wrong. inkscape is NOT required. Everything works well without it. And it has worked for years! Those who really required inkscape can use it. why not? Why pushing others to install a yet another software, if they don't use it. Inkscape is a GUI software. Imagine - I don't even have a monitor, nor mouse. nothing like that. inkscape pulls not only python2.7, but also cairo with enabled X use flags and so on. Tell me WHY do I need that ton of bullshit on my system???
(In reply to Alex from comment #20) > > Inkscape is a GUI software. Imagine - I don't even have a monitor, nor mouse. > nothing like that. > > inkscape pulls not only python2.7, but also cairo with enabled X use flags > and so on. > > Tell me WHY do I need that ton of bullshit on my system??? You're wasting too many outrage points on this. There are worse problems and you might need them later. We know this is stupid, read Michal's comment #8. But imagemagick can't convert SVGs without inkscape installed, so for now, we need it installed. The inability to convert SVGs is causing real problems; that's why I reported this bug, and why Michal fixed it. The fact that imagemagick tries to use inkscape even when (a) rsvg-convert is available, and (b) imagemagick knows inkscape isn't installed is an upstream bug. If you want this fixed to everyone's satisfaction, that's where you should go scream.
As I said. It is obvious GENTOO bug. NOT upstream! No way! Upstream can do what ever they pleased. Please don't break the system and don't break the logic. Any GUI app cannot be a dependency of ANY library. No way. Anyone who says the oppostite is incompetent and should be banned from being a developer! In that particular case there is a solution. Was suggested not by myself, but it is the way to go. Introduce inkscape use flag and let people o what they want to. Why the hell it cannot be accepted? What is the problem with that? What Gentoo is doing is breaking the rules. If some one else does things wrong, it doesn't mean we should follow and change the sane behaviour. Why not pull directly all KDE, QT and Chrome as kernel dependency? Kernel is obviosly not enough to watch youtube and ALL people do only that, because they have no time to learn how proper system should work! I won't stop yelling till you change things backwards!!!!!!! P.S. OMG. I have to think about moving back to FreeBSD. Those kids will kill what once was one of the best Linux distro. P.P.S. Just pull systemd everywhere and call it Arch or Debian and keep your fingers away from keyboard. Really it would be the best in that case...
(In reply to Alex from comment #22) > > Introduce inkscape use flag and let people o what they want to. > > Why the hell it cannot be accepted? What is the problem with that? > This was the very first thing I tried. It doesn't work because there's an upstream bug: imagemagick tries to use inkscape even when inkscape is not installed. Specifically bullet point (3) in comment #3: "make sure that the fallback to rsvg-convert works" should be fixed upstream, because of the (upstream) code in comment #5. If you would rather install an imagemagick with USE=svg that is unable to convert SVGs, then you should feel free to add inkscape to package.provided.
(In reply to Michael Orlitzky from comment #23) > This was the very first thing I tried. It doesn't work because there's an > upstream bug: imagemagick tries to use inkscape even when inkscape is not Why it does work for me? I just removed inkscape as dependency and there is NO single issue. Before that there was also no single issue... For years... Why repair something, which is not broken? What exactly is not working? Why it impossible to see?
(In reply to Alex from comment #24) > > What exactly is not working? Why it impossible to see? It's in the original bug report: imagemagick can't convert SVGs to any other format without inkscape installed. If you try, you'll get an error: $ convert general-concepts/autotools/diagram.{svg,png} convert: no images defined `general-concepts/autotools/diagram.png' @ error/convert.c/ConvertImageCommand/3300. The same underlying issue was causing problems for dev-python/sphinx (comment #8 again). The easy solution is to install inkscape, because that's what imagemagick is trying to use. The better (but more involved) solution would be to fix the detection of inkscape upstream, and to have it fall back to rsvg-convert when inkscape is not found.
(In reply to Michael Orlitzky from comment #25) > (In reply to Alex from comment #24) > > What exactly is not working? Why it impossible to see? > It's in the original bug report: imagemagick can't convert SVGs to any other > format without inkscape installed. If you try, you'll get an error: > > $ convert general-concepts/autotools/diagram.{svg,png} 1. It works for me! I don't see any issue! I used a different svg file for testing. 2. Who cares whether or not it can convert or not??? svg file can be read it can be generated etc. file conversion is ONLY 1 possible action. If some one need it and for that person it doesn't work he or she can install inkscape or kde or even Windows 10. It is not my problem. Neither it is a problem of Gentoo! I remind you - Gentoo is about to provide FREEDOM, not about to insist users do what someone want. If second is true, then there is no place for Gentoo. Use Arch, Deb or Ubuntu! Why it is so difficult to understand? Any one can explain me that?
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5a021ef16b9f4916a061c9fbb055bc6cb02ab0e5 commit 5a021ef16b9f4916a061c9fbb055bc6cb02ab0e5 Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2020-06-04 20:22:53 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2020-06-04 21:57:31 +0000 media-gfx/imagemagick: don't pull in inkscape This will revert commit e7dc825e4efa1d431354cf8e21f9be3722a8eeb4. ImageMagick comes with delegates.xml which tells ImageMagick how to convert various formats. However, this is optional and will be hard to deal with all possibilities: For svg, ImageMagick utilizes inkscape if its in your execution path otherwise RSVG. If neither are available, ImageMagick reverts to its internal SVG renderer. For example for Portable Network Graphics, ImageMagick knows about bpgenc. However, bpgenc is not even available in Gentoo repository as of today. ImageMagick also knows about soffice utility which can be used to convert docx files. However, we are not pulling in LibreOffice for obvious reasons. Bug: https://bugs.gentoo.org/684686 Package-Manager: Portage-2.3.100, Repoman-2.3.22 Signed-off-by: Thomas Deutschmann <whissi@gentoo.org> .../{imagemagick-7.0.10.16-r1.ebuild => imagemagick-7.0.10.16-r2.ebuild} | 1 - 1 file changed, 1 deletion(-)
I have checked 2 systems 1 - A desktop with XORG MATE etc installed 2 - Server - a different CPU, different RAM, no XORG, no Desktop Only 1 thing is in common. Both systems don't have Inkscape installed on them. Both systems run "convert favico.svg favico.png" wthout any error!
Now that librsvg is a more annoying dependency than inkscape thanks to its use of rust, I think this dependency should be svg? ( || ( gnome-base/librsvg media-gfx/inkscape ) media-gfx/potrace ) AFAIK you never need librsvg when inkscape is available.
I guess this is showing up again because now unmask >x11-libs/pango-1.42.4-r2 pulls in x11-libs/cairo[X]. Based on my testing this shouldn't be needed and was likely an error introduced via https://github.com/gentoo/gentoo/pull/13498#pullrequestreview-327283137 ... mattst88 should be on it.
(In reply to Thomas Deutschmann from comment #30) > I guess this is showing up again because now unmask > >x11-libs/pango-1.42.4-r2 pulls in x11-libs/cairo[X]. Based on my testing > this shouldn't be needed and was likely an error introduced via > https://github.com/gentoo/gentoo/pull/13498#pullrequestreview-327283137 ... > mattst88 should be on it. All that's changed for me is that now librsvg is a worse dependency than inkscape. In the past this was "fixed" with a hard dependency on librsvg because everyone had that installed anyway, and not many people had inkscape. But now that I would rather have inkscape, it would be nice if imagemagick could use it instead of rsvg-convert. (ImageMagick already can, the ebuild just needs to accept it.)
Am I missing something? I just wanted to test if using just inkscape for USE=svg would work and tried what you proposed but I still end up with librsvg because >=media-gfx/inkscape-1.0.2-r1 pulls in x11-libs/gtk+ which will pull in gnome-base/librsvg.
(In reply to Thomas Deutschmann from comment #32) > Am I missing something? I just wanted to test if using just inkscape for > USE=svg would work and tried what you proposed but I still end up with > librsvg because >=media-gfx/inkscape-1.0.2-r1 pulls in x11-libs/gtk+ which > will pull in gnome-base/librsvg. Oh, no, I didn't notice the transitive dependency. I guess there are two problems. I've also opened bug #788016 to see if gtk+ can be used without librsvg. In any case, making inkscape a substitute for librsvg in imagemagick should be OK, right?
Created attachment 705987 [details] SVG test data with results Please see the attached test data with results. I basically just run `strace -f -o /tmp/convert.log convert $input.svg $output.png` and verified via convert.log used method (therefore I had to remove librsvg and rebuilt IM for example; install inkscape; had to ensure that neither inkscape or librsvg was present). Based on my tests, inkscape is not a 100% replacement for librsvg like it doesn't convert complex.svg without errors. In addition, using librsvg will result in smaller images. Without librsvg or inkscape at all, IM is still able to convert SVG files. However, converted simple.svg doesn't look like expected and it doesn't understand complex.svg.
(In reply to Thomas Deutschmann from comment #34) > > Based on my tests, inkscape is not a 100% replacement for librsvg like it > doesn't convert complex.svg without errors. In addition, using librsvg will > result in smaller images. > How did you decide on the expected output when converting an animation to a PNG? They're both reasonable, given the impossible task. I'll just add inkscape to @world and leave USE=svg unset. I have to do this in the meantime anyway since most USE=svg conditionals will prefer librsvg otherwise.
(In reply to Michael Orlitzky from comment #35) > How did you decide on the expected output when converting an animation to a > PNG? They're both reasonable, given the impossible task. The initial state is clearly defined and the PNG should show that state, i.e. frame 0. However, inkscape's converted PNG shows lines which shouldn't be visible at any moment. So it isn't just showing any later frame, it's showing layers which shouldn't be visible together at any time (compare with https://upload.wikimedia.org/wikipedia/commons/6/6c/Trajans-Column-lower-animated.svg in browser).
(In reply to Thomas Deutschmann from comment #36) > (In reply to Michael Orlitzky from comment #35) > > How did you decide on the expected output when converting an animation to a > > PNG? They're both reasonable, given the impossible task. > > The initial state is clearly defined and the PNG should show that state, > i.e. frame 0. Says who?
Created attachment 706047 [details] SVG layers in Adobe AI Read the SVG? Please see the attached screenshot. Like you can read in SVG file, wire6 layer has property 'visibility="hidden"'. When you view file in a graphical editor, I used Adobe AI in this case (sorry), you see that the "eye" symbol is missing for any element in wire6 layer (=because not visible).
Created attachment 706050 [details] wire6 switched to visible And here's the proof showing how wire6 layer looks when visible.
Thanks for taking the time to explain. My question isn't about that hidden layer per se, but rather, what it is that you are expecting to happen when exporting an animation to a single static image. It looks like an unfair test to me because it's a nonsense operation in the first place. (I admit that the rsvg-convert output looks better.) ImageMagick's "convert" is supposed to convert between image formats; and despite the extension, an SVG with animation elements just isn't an image format. In any case, I do appreciate all the time you've invested in this. I'm not trying to be overly argumentative. I am perfectly happy disabling USE=svg and installing imagemagick myself, since that's necessary to override the default order in || ( gnome-base/librsvg media-gfx/inkscape ) anyway.
> || ( gnome-base/librsvg media-gfx/inkscape ) That wouldn't work: IM will link against librsvg ($(use_with svg rsvg)) but will not fail if librsvg is missing. With this change you could end up with an image built against librsvg but binary package would be satisfied by existing inkscape package which would cause problems. So I think you need USE=-svg and manually install inkscape and rely on delegates. Ofc, this will be a problem for any package depending on imagemagick[svg].
(In reply to Thomas Deutschmann from comment #41) > > || ( gnome-base/librsvg media-gfx/inkscape ) > > That wouldn't work: IM will link against librsvg ($(use_with svg rsvg)) but > will not fail if librsvg is missing. Embarrassingly enough, I never realized that IM was linked to librsvg. > So I think you need USE=-svg and manually install inkscape and rely on > delegates. Ofc, this will be a problem for any package depending on > imagemagick[svg]. It does complicate things. Probably some implementation flags would be needed to make it precise, e.g. IUSE="inkscape +librsvg svg" REQUIRED_USE="svg? ( inkscape librsvg )" But the workaround is acceptable to me. Maybe today is a good day to give GraphicsMagick a try =P
I'm gonna close this since noone has complained for the last 2 years. Please make a new bug if you have specific improvement ideas.
