31 ms·
There probably still exist some weird edge cases introduced by imagemagick that the developer(s) behind graphicsmagick haven't accounted for. That is, should
by yareally 6y ago
There probably still exist some weird edge cases introduced by imagemagick that the developer(s) behind graphicsmagick haven't accounted for.
That is, should graphicsmagick account for quirks introduced by imagemagick? If it's meant to truly be a drop-in replacement versus one with some strings attached, I would say the answer is yes. Otherwise, you can't easily just drop it into a system and let it run.
Systems built with libraries around long enough as imagemagick likely have all sorts of workarounds built in over the years for that kind of behavior and any deviation from imagemagick might break things more than one expects. We've all been bitten by libraries that claim backwards compatibility with previous versions, only to find out there's breaking changes in some non-trivial use cases the library devs didn't consider. Add those complications on top of switching to a library that is supposed to be a drop in replacement and it can get pretty messy for what seemed like a trivial task.