Quote:
Anyway, what's certain is that we need to split the project up into a backend and frontend. The backend could then be used by other people for their front-ends. It should also be modular, so that, e.g., people could pass to it documents like pdfs or they could pass raw images and have them be post-processed and collated. Or they might pass a pdf and the output resolution, and then receive a folder of images they could collate themselves. Thus, the back end could be extended for use with unforseen input and output formats.
Thus the backend is in three parts: a rasterizing stage (this stage is capable of autocropping, it can also produce output directly for the frontend for showing previews and for setting manual cropping), a processing stage (which takes lists of images, cropping parameters, processing parameters, etc.), and a collating stage.
|
I think we should keep things as simple as they can be, as it makes for easier maintainability. Let's just create one (or maybe two) command line tools, and that's it. The GUI simply calls these and gets its job done. It will also enforce clean separation and make sure that additional frontends can be added.
What we really need to think about is packaging. On Windows, it is quite easy to package all the required stuff, it will much more difficult to do so for Linux or OS X.
Quote:
One fun question is how can the processing stage be made better. Right now it's a dilate and a sharpening. The dilate is straightforward but the sharpening has many parameters. I used defaults for PDFR 2.1 but tweaked them for 2.2 for more effect. I don't think anyone actually got to see the 2.2 changes, but Ashkulz currently feels the benefits of sharpening are negligible (at least on his monochrome LCD device).
I disagree, but what I think is certain is that in the vast world of photoshop filters, there's gotta be something impressive. Come on... who here's been C&Ping beavers on monkeys and passing them off as paris hilton pics? Speak up!
|
Well, I was checking the effects of sharpening on my desktop, not on the reader -- I couldn't see any noticeable difference in the images.
Either way, I see that a standalone GUI has very little utility value -- the rudimentary GUI on Windows is good enough for most people, and on Linux/OSX people are OK with the command line. The real benefit as I see it is integration with a device communication app like libprs500/rebcomm, integrated into a rudimentary library management system (like libprs500-gui). That would offer a 1-stop solution for ebook creation, management and communication with the device.
Ideally, we should develop the GUI on a
plugin-style architecture, so that people can easily integrate various apps (rss/word/whatever) without touching the main code.