#130 Manual duplex scanning with uneven number of pages

[FeRD]

So, I attempted to do something — admittedly — a bit strange with gscan2pdf, and the result wasn't what I expected. I'm filing it as a feature request, because maybe my expectations aren't the same as what most other users' would be. I'll leave it to you to decide whether the current behavior (in this instance) is a bug.

The situation:

1. I have a scanner with single-sided ADF, so duplexing is manual
2. I had a seven-page double-sided document to scan, meaning four sheets of double-sided paper, the back of the last one blank.
3. I configured gscan2pdf for ADF scanning, Double-sided document, Facing sides, All sheets.
4. The scanner duly produced four images, added as pages 1, 3, 5, 7.
5. The scan-other-side dialog came up, I clicked OK, and gscan2pdfauto-reconfigured for scanning Reverse sides, 4 sheets.
6. Because I knew I didn't need to scan the back of the last sheet, I removed it from the stack and fed in the other three sheets.
7. To compensate for the above, I manually reduced the number of pages in the dialog from 4 to 3 before scanning.

What I expected

gscan2pdf would scan in the 3 sheets as pages 6, 4, and 2, filling in the lowest-numbered page gaps so that the end result is a continuous set of pages numbered 1-7.

What actually happened

gscan2pdf scanned the 3 sheets as pages 8, 6, and 4, leaving me with no page numbered 2 and all of the back sides out of order in the final set. (Which was easy enough to correct, of course.)

"Correct" behavior?

So the question, in my mind, is whether anyone would really ever WANT the "actually happened" behavior, and/or whether there's any real-world situation where the current behavior is useful/expected? If not (I can't think of any), would it be reasonable for the application to instead match the "what I expected" behavior, on the assumption that it's almost certainly what any user who performs those same steps actually wants?

Alternative approaches

(Just brainstorming here...)

One possible alternative would be if the Reverse scanning mode, instead of setting a "# Pages" option, instead had a setting for "First page number". That would automatically populate to 8 instead of 4 (in the scenario above). Framing it that way would make the consequences of adjusting the value upwards or downwards unambiguously clear and obvious.

Because if you think about it, the indication that scanning is finished in the Reverse mode is really the same as in the Facing mode: The ADF runs out of pages. So in actuality, gscan2pdf doesn't need to know the number of pages to be scanned, even in Reverse mode. It only needs to know where to start numbering them from.

[Jeffrey Ratcliffe]

In the Scan window, on the "Page options" tab, there is a checkbox "Extended page numbering", which should allow you to select the start page number. Does this achieve what you want?

[FeRD]

In the Scan window, on the "Page options" tab, there is a checkbox "Extended page numbering",

You know, I knew that was there, and then I apparently forgot it was there.

which should allow you to select the start page number. Does this achieve what you want?

1. Yes, it absolutely does.
2. I notice, in fact, that the "# Pages > #:" field is linked to the "Page number > Start" field — if I lower "Start" from 8 to 6 (in my example above), the "#:" field automatically drops from 4 to 3.

So, while Extended page numbering is absolutely a useful workaround for this, I'm still wondering if it might make sense to link "#:" and "Start" in both directions, so that manually decrementing "#:" automatically adjusts "Start" the same way that manually decrementing "Start" automatically adjusts "#:"?

The user can still use Extended page numbering to set the starting page to 8, in the (IMHO unlikely) event that they actually want to scan 3 pages numbered 8, 6, and 4. But the (again, IMHO) more-common 6, 4, 2 case wouldn't require the Extended configs.

[FeRD]

You know, I knew that was there, and then I apparently forgot it was there.

Partly because Adwaita's dark theme really makes certain controls, especially switches, blend in to the window background much more than they do in light mode.

The difference between these two is pretty severe, really.

But that's a GNOME problem, not a gscan2pdf problem.