https://bugs.kde.org/show_bug.cgi?id=450123
--- Comment #5 from Branislav Klocok <[email protected]> --- I have a working implementation of this and would like to ask whether the approach is acceptable before proposing it as a merge request. The approach follows what Skanpage already does for rotation. Rotation is not destructive: DocumentModel::rotateImage() only updates rotationAngle in PageProperties, the original page stays untouched in its temporary file, and the transformation is applied by each consumer. Crop can work the same way as a QRectF in PageProperties, normalised to 0..1 against the original unrotated image, with every consumer loading the original, cropping, then rotating. A null rect means no crop, guarded the same way the existing rotationAngle != 0 checks are. That keeps the crop reversible and survives a change of DPI. That touches the same places rotation already touches: SkanpageUtils, DocumentModel, DocumentSaver, DocumentPrinter, OCREngine, DocumentList.qml and DocumentPage.qml. In my tree it is 304 added and 29 removed lines across nine files, with no new dependency, since the selection UI reuses KQuickImageEditor.SelectionTool the same way PreviewScanView.qml already does for the pre-scan selection. I have tested it on a three-page scan: cropping is per page, it combines with rotation without shifting the content, and both export paths agree, with the PDF page box shrinking with the crop rather than leaving the cropped image on a page of the original size. It is written against release/26.08 because KSaneCore 26.11 is not available here, and would be rebased onto master. Two things I would like guidance on. The first is where this belongs. Merge request 28 has had an imageEditing branch open since 2022 with a much wider scope, and I would rather not duplicate or cut across that work. If crop is expected to land through that branch, I am happy to leave it there instead. The second is that the selection UI currently has a problem that is not in Skanpage. Most resize handles of KQuickImageEditor.SelectionTool do not work: only the ones anchored to the left and top edges behave correctly, and the others either do nothing, move without changing the selection, or resize the wrong edge. It reproduces with a minimal QML file containing nothing but a SelectionTool, so it affects the existing pre-scan selection as well. I have reported it as bug 525665. Any post-scan crop built on that component inherits the problem until it is fixed. -- You are receiving this mail because: You are watching all bug changes.
