Help and feedback is appreciated, but:

You're defeating the purpose of packing the characters into a bitmap! If I wanted to write a PNG exporter with that function, how would I produce a png image from a bunch of disjoint pixel arrays? Would I have to write my own character packing routine when FS has just done that for me?

Further, the exporter should not have to change anything about the visuals of the font: colours, sizes etc. The user would have done this before exporting anyways.

Giving the plugin a raw uncompressed bitmap is the most basic data it can receive, so it should be able to encode this into any data format imaginable, present-day and yet-to-be-discovered. If you want to extract the individual characters out of that data for your own format, you can work the raw bitmap to do that.

I fully agree with C++/FPC compatibility and you are welcome to point out where I should make things AnsiString or packed record or whatnot, I dont have much experience writing cross-compatible procedures.
I also agree with the author, name etc. we'll have to have another procedure which communicates this sort of info between the host and the dll.

I went for 4/5 types of exporters because:
- It splits up the output into multiple files, giving the user more control.
Like if I wanted my alpha in JPG format and rgb in BMP format separate from my data in XML format, you can do that.
- It only has to give the plugin the data it needs, saving processing time.

But I agree it's a very nasty and complex situation because you have to handle:
* RGB and Alpha and Data all separate files
* RGB and Alpha in composite file, Data in separate file
* RGB, Alpha and Data all in one file. //Going to have to add this as another type of exporter.