Does it support scanners that duplex i.e. scan each side of a piece of paper before going on to the next paper? My XSane GUI has a duplex on/off button.
That depends on your scanner and its driver.
Some Sane scanners/drivers show duplex scanning as a different scan source (Fujitsu scanners). In that case it’s already working in Paperwork. Other scanners show it as a separate option. In that case, it’s something I still have to add in Libinsane (If you’re a C programmer, contributions are welcome on this point, of course 
; doc ).
Since you said that XSane has a specific button for it, I assume your scanner/driver uses a separate option. If your scanner is already in the OpenPaper’s database (or if you add it 
), I can tell you for sure in which case you’re.
Alternatively, does Paperwork support stack scanning, where a paper stack has all odd-numbered pages scanned in, then I turn the stack over the scan all the even numbered pages and Paperwork orders them correctly?
No yet. You can open a ticket on the bug tracker if you want.
And related, does Paperwork have a feature to -skip- blank pages, in the event that it scans the back of a page that has nothing on it?
No yet. You can open a ticket on the bug tracker if you want.
does it support the “SCAN” button my on scanner that starts it scanning?
As far as I know, no Linux application support that.
If I’m not mistaken, the point of these buttons is to start the scan application when pressed. There is a daemon available for that: scanbd. I’ve never used it.
If what you want is being able to start Paperwork, and press the scan button as many times as you want it to scan, it may be doable, but it would be far from easy. The root of the problem is that Sane provides no official mechanism for that. From what I’ve seen, it provides the state of the buttons as a read-only scanner option. These options are not normalized at all (no predefined name/value). There is no way to be notified when one of these option values change (–> polling only). Sane backends tends to be unstable, so I assume that polling the option continuously will make some backends crash.
You can open a ticket on the bug tracker but it won’t happen before a very long time.
I’m glad Paperwork is written in Python, as I’m a Python programmer and may be able to help with development, if I can figure out Flatpak.
You don’t need to figure out Flatpak. For development, you can install it in a virtualenv as any other Python program (well ok, the dependency on Gnome librairies and Libinsane makes it slightly different…)
However, beware that development happens in the branch ‘develop’. The branch ‘develop’ currently contains a rewrite of Paperwork (what-will-be-Paperwork-2.0). I’ve decided to rewrite Paperwork because the version 1.x was too much of a huge spaghetti code, making its maintenance unpleasant (and I do it for almost-free, so it better be pleasant ). The rewrite is based around the concepts of plugins (with just a minimalist core).
Currently, the core, backend and shell commands are working. I’m working on the GTK interface. The documentation is really incomplete. Currently available and close-to-up-to-date documentations:
You may want to wait for Paperwork 2.0 to be released (or at least in testing phase) before contributing.