https://bugs.kde.org/show_bug.cgi?id=512876
--- Comment #6 from Branislav Klocok <[email protected]> --- Additional context on the startup/restore behaviour (ksanecore 26.04.2, HP LaserJet Pro MFP M26nw flatbed), in case it helps with the fix: When saved scanner options are restored on startup (Skanpage::loadScannerOptions -> Interface::setOptionsMap), the page-size combo ends up reflecting the saved GEOMETRY (tl/br), not the saved KSane::PageSize value. Verified by editing skanpagestaterc directly: - KSane::PageSize=A4 + a custom/resized geometry (e.g. tl=0,0, br-x=210, br-y=160.99) -> loads as "Custom". - KSane::PageSize=A4 + matching A4 geometry (tl=0,0, br=210x297; br-y clamps to the device max ~296.93 on this flatbed) -> loads as "A4". So KSane::PageSize=A4 in the saved state is not enough on its own to restore A4 -- the geometry is authoritative. Note also that PageSizeOption::restoreOptions() detects the size with an exact qFuzzyCompare against the nominal page size and does NOT take wiggleRoom into account, so a flatbed-clamped A4 height (296.93) vs the nominal 297 would not match there either. This is a separate code path from the in-session preview regression, so it does not change the proposed patch (attachment 193158) -- I'm noting it as context. The patch's single bidirectional updatePageSize() (driven by the tl/br valueChanged signals and using wiggleRoom) makes the combo consistently track the actual geometry in both directions, which keeps this restore path consistent too. -- You are receiving this mail because: You are watching all bug changes.
