[ashkulz]

what exactly do you mean by plugins? Do you mean the "rasterizer" and "post-processing" components that i'm talking about would themselves be composed of smaller pieces?

Yep, very much. The current script is getting too big, and not so easy to understand at first glance. The "plugins" would allow one to abstract out the steps to take in the pipeline, and then to weave the individual steps in any manner that the calling tool/app chooses.

From the point of view of the calling tool, there would be only one executable which would allow one to choose and setup the pipeline. All the plugins and other low-level details will be in code, and not exposed to the user.

Right now I was just thinking about a framework that handled image-based ebooks. For html, and indeed for a larger audience, you would need to support native-text formats (although i dunno.. native text would never look as good as dilated and processed images). To handle native-text you would need to create an intermediary text format with formatting and embeded links that could carry HTML, pdf, rtf, etc and then be reprocessed into lrf, pdf, starebook, etc. is... ambitious. And it'd have to work perfectly (ie just as well as a direct html->lrf conversion). If we just stick to working with images (and even claim that's the suprior way to do things) I think it makes things much simpler (and much easier to get right).

Agreed, but what I meant was that it is easily possible to theoretically visualize that some things that we develop here might be integrated as different types of "pads" or whatever. I'm not proposing to do anything on this at all, just that it leaves future scope for expansion -- the framework would already be there, and reuse would be dead simple.

We can omit things like sophisticated pads that keep track of their own dependencies. Simply moving images from one folder to another would be fine and would even make it easier for other developers to hook in. (It's still the same spirit as the pads, but just a simpler implementation.)

I never said anything about pads keeping track of their own dependencies. All I meant is, if a particular stage expects input as an image, then we shouldn't be able to pass in a PDF there (or vice versa). The stage should validate these things and then move on.

I disagree about the folder-to-folder thing -- that's a poor solution, as that means we have to create and maintain that many folders. Why communicate over the filesystem when you can communicate much more clearly via code? Also, you get around that in PDFRasterFarian by fixing the stages upfront and pre-creating folders in the installation directory. That is not feasible on other platforms, plus it implicitly means you can run only 1 instance of PDFRasterFarian at 1 time. PDFRead has no such limitation, and I think that supporting (simultaneous) batch processing is very important.

however, let's ask the question: if say we only work with images, what things could/would/would-want-to be done by others? Are there things that can't be done by a 3-layer framework of Create images, Reprocess images, Bind images (provided each layer exposes enough features)? What are the usage scenarios?

If each layer exposes enough features to turn on/off features individually, the command line options for it will grow quite a bit (see PDFRead). It is much better to approach it conceptually as a pipeline than as passing these set of parameters to stage1, another set to stage2 and so on.

Usage scenarios are simple:

1. User A wants to use the framework "as is" in one of the default profiles
2. User B wants to customize one of the stages in the pipeline. He/she runs a tool that will print the default pipeline for a profile, customizes it and then runs it directly (or saves it directly as a new profile).
3. User C wants to add or drop stages in the pipeline (e.g. remove dilation for comics, add a manual cropping stage, etc)
4. User D is a tool writer that wants to integrate the entire conversion process (with preview). This would be easy, as one would run a shorter pipeline or one customized only to process a few pages.

On the whole, I think the most compelling argument would be the transparency and simplicity from the user/tool writer point of view. It will also make the code much more modular and easier to maintain.