HELP: More File I/O Interface Clarifications

@jan.cosmigo, I’m working on updating the File I/O Plug-in Interface documentation and working on some actual code too: but there are a few clarification I’d like to ask you regarding some plug-in functions.

Plug-in Registration Functions

If my understanding is correct, some functions are called only once, when PM launches and need to register all the available DLL plug-ins — for clarity sake, let’s call them “plug-in registration” functions.
These should be the functions in question:

  • initialize()
  • getFileTypeId()
  • isReadSupported()
  • isWriteSupported()
  • isWriteTrueColorSupported()
  • getFileBoxDescription()
  • getFileExtension()

Q1: Does the canExtractPalette() belong to these functions? i.e. is it’s purpose knowing if the plug-in is able in general to extract only the palette from files, or is instead used on a per-file base, to get actual confirmation whether the plug-in is able to extract the palette from the current file specifically?

About Unused Plug-in Function

Most of the DLL functions are either tied to reading or writing.
Since usually a file i/o plug-in is going to be either an import or an export plug-in, only the corresponding functions need to be implemented.

For example, an import plug-in shouldn’t expect any calls to beginWrite() or
writeNextImage(), and an export plug-in shouldn’t expect any calls to getTransparentColor() or isAlphaEnabled().

Q2: Does the DLL need to define those functions that shouldn’t be expected to be used? or can it just omit them entirely, on the assumption that (based on the plug-in info provided at registration-time) PM won’t attempt to call these functions at all, ever?

So far I’ve been covering all of the interface DLL functions, in every plug-in, and just returning nil or false, to be on the safe side; but leaving out their definitions would lead to cleaner and more readable sources (and possibly a slimmer DLL too).

I’ve been testing with the plug-in Logger Module to verify which functions are called at start-up and which ones during actual import/export operations, but the number of actual calls is higher than I expected, and their order and frequency seems to change depending on the context in which a plug-in is being used, so working out the above questions by trial and error it’s not as easy as I first thought.

I still don’t understand why some registration functions are being called more than once for the same plug-in — a single call should suffice.

Exporting True Color Data

The documentation mentions isWriteTrueColorSupported(), but doesn’t explain how true color data is passed to a plug-in (only indexed palettes are covered).

Q3: Since there are no other special functions for true color, nor variations of the beginWrite() and writeNextImage(), how does the plug-in know when to expect true color images? Or are true color images just the results of merging together multiple 256-colors layers?