Thanks for the detail — that scanimage success is exactly the clue I needed. Two things stand out: Those three options aren't scantpaper features. overscan, swcrop and ald are just passed through to your Fujitsu driver. Since your working scanimage line used none of them, they're not required — and my earlier advice to turn overscan and swcrop On was wrong for your case. That black border is precisely what overscan adds (it inflates the ADF margin on all sides), so please turn both back Off. You...
Please start scantpaper with scantpaper --log=log, Enable overscan = On (the missing piece — it adds the ADF margin on all sides) Enable swcrop (software auto-crop, trims the black border) Keep ald = On and the custom paper 210×449 Scan, then manual-crop if a hair of border remains Quit, and post the log file, which scantpaper should have compressed with .xz
Thanks for the bug report. As soon as scantpaper has migrated to Debian testing, I intend to deprecate gscan2pdf and turn its Debian package into a transition package pulling in scantpaper, which is a drop-in replacement.
I've almost finished a complete rewrite. It's probably going to be called scantpaper. Needless to say, the aim to be better in lots of ways, including error handling. I've just got to nail the last couple of bugs and write a few more tests.
gscan2pdf hangs on File Save
I've almost finished a complete rewrite. It's probably going to be called scantpaper. Needless to say, the aim to be better in lots of ways, including error handling. I've just got to nail the last couple of bug and write a few more tests.
Thanks for the report. Please start gscan2pdf from the command line with the --log=log option, reproduce the error, and post the log file.
This bug has now hit Debian sid. I'll have to skip the test in sid to avoid FTBFS. Your bug report is now seeing some attention.