ImageMagick shells out to "delegates" to convert to/from many of the formats it supports: reading in a PDF results in a call to "gs", reading in a .docx results in a call to "soffice --headless", etc.

As for the wisdom of this approach...

This must expose an absolutely massive attack surface. Time to disable all these "delegates".

It's really a command-line tool at its heart. The library is essentially just a wrapper around this command-line tool.

You could feasibly do the same stuff in an interpreted language, but (I suspect) it would be substantially slower than directly running those compiled command-line tools underlying it.

> The library is essentially just a wrapper around this command-line tool.

That sounds bass ackwards if you ask me. A command line tool is usually a thin wrapper around a library, for a reason.

I realize it might seem crazy to duplicate functionality from gs into your library, but then the tool should link against those code bases as libraries instead of calling some gs executable (which of course in turn is just a wrapper around a gs library and so on).

Making a library call to re-scale an image or convert from formatA to formatB shouldn't be a shell execute call to begin with, and it shouldn't be making any shell exec calls of its own.

> That sounds bass ackwards if you ask me. A command line tool is usually a thin wrapper around a library, for a reason.

It's historically grown. The tool came first, the library was tacked on later.

And yes, it's a mess. That's why the much saner GraphicsMagick was forked off it… in 2002. People just never migrated.

GraphicsMagick is pretty lacking in terms of features compared to ImageMagick though, even to this day. I tried using it in a project that had just slightly unconventional image processing requirements and GM just didn't have the capabilities to handle it, whereas ImageMagick did.

It is a bit backwards, yes. As other users pointed out, this is for historical reasons.

That being said, I wouldn't be surprised if porting those things over from compiled languages to be a part of the library would prove to be substantially slower. For high-volume applications, it would very possibly make the library totally unusable.

I agree that it's a backwards way of doing things in a perfect world, but the perfect is the enemy of the good. Sometimes you've gotta make compromises for reality's sake.

> That being said, I wouldn't be surprised if porting those things over from compiled languages to be a part of the library would prove to be substantially slower.

I must have missed something, I thought ImageMagick was a collection of C libraries and C programs, which in turn occasionally called other libraries and programs (such as gs).

What I meant was that a graphics utility should be a c library that exports functions like

    scale_image(source_image, target_image, scale) 

to be used instead of running a command line utility

    convert image.jpg -resize 0.5

That can't ever be slower, but some times likely faster (e.g. to recode an image before inserting as a blob into a db or sending over a netwoek you wouldn't even write it to disk).

It's both a library and a series of command-line tools.

So is git, nuget etc. Either something is just a library, or it's just a command line tool, or it's a command line tool that uses a library (i.e. the command line tool is a simple wrapper that turns command line arguments into function call parameters basically).

I have never heard of a program where the command line program is at the heart, and a library is wrapped around it. I can't even imagine how such code would be structured.

Because we can never just let documents simply be documents.