All the configuration is at the begining of the script so it would be easy to move it to an extra file under /etc. Any preferences?
No, anything uniquely identifying works for me.
The script would also need an upstart config file and, potentially, a logrotate one as well.
For compatibility, I use old-style init scripts for packages that need them; that way they can be used with any of the various startup routines, and upstart (or whatever) can deal with it on the fly. This is simple for me to implement. I haven't looked at your script closely enough to see if it is generating enough output to justify a logrotate, but feel free to include that if you think it might be necessary.
I am unlikely to do anything with packaging for at least the next two weeks, although I hope to spend some time on it at some point in January. (I'm really hoping Samsung releases a new driver right before then, but they seem to have a habit of doing that right after I go through an update round.) So from my point of view, there is no urgency on this.
At the moment what it is anoying me is that Sane is slow with the Samsung devices conpared to scanning from Windows: it takes 45 second to scan a page in "Grayscale - 256 Levels" and 300 dpis while Windows or scanning to a USB memory plugged into the scanner only takes 15. My theory based on the number and size of the packages in my network capture is that the Windows driver is able to tell the scanner to scan and transfer the image already compressed in JPEG format. In Sane I only found support for PNM and TIFF...
I suspect you are correct. Personally I find that to be no loss, as I much prefer to take the time/storage penalty at the front end and decide later whether the compression is necessary/worthwhile. I'm probably in a minority, though, and it also doesn't really matter since I personally have no use for this script (no scanner on my printer). I doubt there is an easy solution to that, unless there is a physical printer configuration option to default to jpeg output.
Of course, it may also just be that the Windows driver is faster or more efficient in its transfer protocol. That would hardly be surprising given the massive investment in Windows support Samsung has compared to Linux.