abstract: AllowsResolution ignores ResolutionRange (range-only profiles reject every resolution)
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- Half a day
- Newbie friendliness
- 52/100
Research direction
Start in abstract/settingsprofile.go at AllowsResolution, where the FIXME sits after the Resolutions loop, and read Range.Within in range.go for the step semantics to follow. Check FillRequest in scannercapabilities.go to see how the rejection surfaces as ErrUnsupportedParam. Done means a range-only profile accepts in-range, on-step resolutions and still rejects off-step or out-of-bounds ones, with tests covering both. The author has already offered a patch and two open design choices (step 0, list-before-range priority), so confirm with the maintainers before starting.
Written by the indexing model from the issue text.
Description
Summary
SettingsProfile.AllowsResolution never consults ResolutionRange, so range-only profiles reject every resolution inside FillRequest. I ran into this while tracing scan negotiation after #121, and there is a // FIXME sitting on the exact spot.
Location
The function lives at abstract/settingsprofile.go:56-70 (master).
Current behavior (with code)
for _, supported := range prof.Resolutions {
if res == supported {
return true
}
}
// FIXME -- check ResolutionRange
return false
A profile carries an empty Resolutions list but a populated ResolutionRange (the field is declared at settingsprofile.go:23 with the note // Zero if unset), and the function returns false for every non-zero resolution it is given. Downstream, FillRequest (scannercapabilities.go:377-387) asks every profile in turn and, finding none that allows the request, fails the scan with ErrUnsupportedParam("Resolution"). The default path breaks the same way, because defaultResolution can only select 300x300 through AllowsResolution as well. Range-only advertisement is legal eSCL: abstractto.go:275-283 fills discretes and the range independently of each other, so a device that sends only ResolutionRange lands exactly in this hole.
Expected behavior
The function should check the range per axis (XMin/XMax/XStep and YMin/YMax/YStep) after it checks the discrete list, and it should follow the existing Range.Within semantics (range.go:39-50, where a step of 1 or less disables stepping). Checking the list first keeps the behavior of discrete profiles bit-identical.
Possible fix
The change is about fifteen lines: the range check inside AllowsResolution plus one unexported step helper in the same file, with tests for in-range and on-step acceptance, off-step and out-of-bounds rejection, and continued rejection for empty ranges. There are two calls I would leave to you: treating step 0 as unstepped (as Within does) and keeping list-before-range priority, and I have implemented it that way unless you would rather differ.
if this matches your intent, I will build it and test it..!
- Dominant language
- Go
- Stars
- 23
- Forks
- 13
- Avg merge
- 3h 35m
- Merged PRs (30d)
- 10
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from OpenPrinting/go-mfp
-
Difficulty 1/5 Under an hour Newbie friendliness 86/100
OpenPrinting/go-mfp#124 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 80/100
OpenPrinting/go-mfp#123 ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
OpenPrinting/go-mfp#30 · 2 comments ·
Maintainers usually reply within 1 day
All issues in OpenPrinting/go-mfp
Similar issues
-
status:needs-review type:bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Gentleman-Programming/engram#2079 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
limitlessprojects/Go-Hybrid#1377 ·
Maintainers usually reply within 1 day
-
bug report
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 3 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
Maintainers usually reply within 1 day