Adding multiple page options depending on scanner source #734
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description: This pull request introduces a better solution than the workaround in #401. Instead of creating multiple "virtual" scanners to either set
--page-height
or not, this implementation allows different page height variables for each source.An example is provided in
12-recipes.md
.Different Page Height Variables for Each Source
The
--page-height
option will default to--page-height
if neither specific option is set. Even if the default option is set, it will try to use the specific option first before falling back to the default. If you don't want to set the option for the flatbed, for example, you must not set the default option, as it will fall back to this value instead.If the page height option should only be set for an ADF scan, use this configuration:
The drawback is that the user might have to set a few more variables, but it should not break any current config. The web scan works pretty flawlessly with the
device.features[].default
value. If someone wants to customize this value even further, they can provide the override values via the API.Example: Assuming the above config with all the values set:
This would override the corresponding value in the SANE command with the new value provided in the API.
Drawback: If the value is not specified in the device features, it cannot be overridden. So in the second config example, a user with API usage intents could only override the
pageHeightADF
value, as it is the only one set. Even if they provided the newpageHeightFB
value via the parameters, it should be different in my opinion.