[ashkulz]

Ashkulz, it is most important right now to create or plan for a framework that can be easily extended or repurposed for new things and by new applications. Anyway, all it'd be is just three executables. And they'll be doing the same things the monolithic thing is doing now. there'll just be a bit more work talking through a defined interface, but it'll pay off through much greater flexibility. Flexibility to change pieces

how about we discuss a spec?

Agreed. I've been thinking about this too (couldn't post as was too busy yesterday). The most sensible way to design the system to think of it in terms of a pipeline, exactly the way GStreamer is designed. So effectively, you write a lot of plugins which implement discrete actions in the whole process (rasterizing, cropping, dilation, etc -- all that you mentioned). Each plugin declares some input and output "pads". We can create different types of "pads", so that you can't accidentally connect an incompatible set of inputs/outputs. I will assume that we write all of this in Python, which I think is best as it is cross-platform. So now we have the following components in the system:

1. the base framework, which defines interactions and the various types of pads
2. the actual plugins, which use the framework and define various types of input/output pads
3. a low-level command line interface which will allow one to create a pipeline and execute it, similiar to gst-launch See this as an example.
4. a command line app, which will parse command-line parameters, do some validations and then finally create a pipeline and execute it via the plugins/framework.

So #4 will be essentially a replacement for what we currently have. Apps who want to use a part (or any combination of the pipeline) will essentially use #3 directly. So ideally, we should have very "thin" glue code in #3 and #4, with most of the logic being in #1 and #2. Also, trying out new approaches is very painless, as it is easy to add a new plugin and introduce in the pipeline via #3. As an example, the current process can be represented as

filesrc location=input.pdf ! pdftops ! gsrasterize dpi=300 ! autocrop ! dilate ! resize width=565 height=784 ! makelrf author=XYZ title=foo | libprs500-send

.

I don't know if you're familiar with electronics/IC design, but that's what essentially what you do there. It would make development MUCH easier and make the whole process much more easier to tweak for everyone (once the initial bump is past, of course). So let's say I want to use xpdf for rasterizing (it's much smaller than gs on win32), I replace gsrasterize with xpdfrasterize (which is the only thing I need to write) and then recreate/rerun the pipeline.

ok, so, the rasterizer exe would expose some of the things ghostscript, etc should be able to do:
-- input - pdf file or list of files
-- output - output folder and filename
-- output size in pixels and format (8bit, gray, color)
-- autocropping, explicit cropbox
-- (opt) output file type (png, jpg, bmp, raw)
-- (opt) rotation
-- (opt) device-specific features (eg ghostscript's font-rendering modes)
this exe prints out the names of the files it processes so that these could be piped or saved to a variable (or to a file). The other exes should be able to accept input filenames piped in (and maybe from a file).

the processing exe would be:
-- input/output filenames
-- output resolution, format
-- (opt) fit (centered, upper-left, stretched)
-- (impl-specific, opt) dilate factor
-- (impl-specific, opt) eg sharpen or other filter parameters

collating exe would just take a list of files and bind them into a format for some specific device. it would also accept a TOC as a file or something. (people could write new .exe's to add support for new/old devices and file formats)

misc ideas-
overcropping... option to crop not at the first black pixel but only after, say, a few dozen (so dust, dots, or lines don't mess up autocropping)
output filenames... imagemagic etc can take output filename as eg "fileA%02d.png" and produce fileA01.png, fileA02.png

All the features you mentioned above should be implemented as plugins, with the necessary parameters.

I think a standalone app would be used more than an integrated one. Personally, i just use sd cards and never sony connect. Also, a standalone app can focus better on adding support to do all the things that could give the best results. Maybe doing it in qt will make it more difficult to do something fancy that lets you preview, crop, rotate, etc. I don't know, but i know that manually cropping in acrobat is very, very helpful. However, I've never found a free alternative to do manual cropping.

To each his choice. I mean, PDFRead is working for most people and that's the way it should be for them. If someone finds they need to do something custom, then with this approach they have a gradual approach for delving in deeper and deeper. With the above approach, whether you use command-line app (#4) or just use the pipeline directly from GUI (#3) becomes irrelevant: both are equally easy to use for different set of people, and it allows other developers to leverage PDFRead as they see fit.

As an aside, we should call it something other than PDFRead or PDFRasterFarian: the above is not merely a tool, it is a ebook conversion framework. I mean, I can imagine that html being a source plugin sometime in the future, so this could be a standard way of interacting with ebook formats, devices and whatnot.