I needed to render a png to SVG and thought I'd use graphicsmagick, which has USE=svg enabled. As it turns out this does nothing since the SVG coder has been disabled by default since ~2009; it's hidden behind a magic #define. Enabling this magic #define results in a built SVG coder that indeed does not work, as advertised. :{ The USE flag should be removed. Reproducible: Always Steps to Reproduce: 1. build graphicsmagick with USE=svg 2. no SVG functionality 3. sadness I'll cook up a PR to remove the svg USE flag.
To avoid any potential confusion: by default the SVG *writer* is not built; however the libxml-based SVG reader _is_. Unfortunately this is also basically useless due to missing features. Since removing the svg flag turned out to be more difficult than expected due to dependent packages and flag propagation in the imagemagick-tools virtual, I would like to suggest that we add at least a conditional warning that SVG support is broken (when enabled). Would that be acceptable?
(In reply to Holger Hoffstätte from comment #1) > Since removing the svg flag turned out to be more difficult than expected > due to dependent packages and flag propagation in the imagemagick-tools > virtual, I would like to suggest that we add at least a conditional warning > that SVG support is broken (when enabled). I'm not sure what's wrong with the svg(-)? suggestion I made before?
(In reply to Sam James from comment #2) > (In reply to Holger Hoffstätte from comment #1) > > Since removing the svg flag turned out to be more difficult than expected > > due to dependent packages and flag propagation in the imagemagick-tools > > virtual, I would like to suggest that we add at least a conditional warning > > that SVG support is broken (when enabled). > > I'm not sure what's wrong with the svg(-)? suggestion I made before? Nothing wrong with it, as far as I can tell it would work but make things more weird/inconsistent overall. I just don't want to remove the flag and create churn (and possible more bugs) because strictly speaking the capability required by the virtual is there.
(In reply to Holger Hoffstätte from comment #3) > (In reply to Sam James from comment #2) > > (In reply to Holger Hoffstätte from comment #1) > > > Since removing the svg flag turned out to be more difficult than expected > > > due to dependent packages and flag propagation in the imagemagick-tools > > > virtual, I would like to suggest that we add at least a conditional warning > > > that SVG support is broken (when enabled). > > > > I'm not sure what's wrong with the svg(-)? suggestion I made before? > > Nothing wrong with it, as far as I can tell it would work but make things > more weird/inconsistent overall. I just don't want to remove the flag and > create churn (and possible more bugs) because strictly speaking the > capability required by the virtual is there. But that's not what would happen -- it's the opposite? Right now, it looks like the functionality is there, but it isn't. By dropping USE=svg properly and adjusting the virtual, anything which demands USE=svg from the virtual will no longer be wrongly satisfied by gm. What am I missing?
(In reply to Sam James from comment #4) > Right now, it looks like the functionality is there, but it isn't. By > dropping USE=svg properly and adjusting the virtual, anything which demands > USE=svg from the virtual will no longer be wrongly satisfied by gm. What am > I missing? You're not missing anything, I'm trying to figure out the best way forward and minimize collateral damage, nothing else. If you agree that removing the flag from GM and relaxing the constraint in the virtual are the right way forward then I can do that (once the jpeg2k stuff is resolved). This has been broken since 2009 so I don't think it's urgent anyway, but all this is just frustrating. I've tried IM and it's vastly slower, and vips is not a useable replacement either.
