https://bugs.kde.org/show_bug.cgi?id=432036
Bug ID: 432036
Summary: Crop Tool: Aspect ratio lock ignored when trying to
resize cropped area beyond image border
Product: krita
Version: 4.4.2
Platform: Compiled Sources
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: Tools
Assignee: krita-bugs-n...@kde.org
Reporter: si...@fdpl.io
Target Milestone: ---
SUMMARY
The Aspect ratio lock is ignored when trying to resize a cropped area beyond
the image border.
Note that the steps and results described below can be observed both in the
horizontal and vertical domain - i.e. by interchanging both portrait/landscape
and width/height in the steps below, the problem can be reproduced on either
axis.
Video Demonstration:
https://fdpl.io/locked_ratio_crop_overflow.mp4 (<400kb, 28sec)
(Note: In the video also pay attention to the aspect ratio jumping around while
resizing the cropped area *without* aspect ratio lock enabled - maybe
symptomatic of why the problem happens *with* the lock, also UX wise feels a
bit unclean that it jumps around, although functionally it poses no problem as
it jumps back)
STEPS TO REPRODUCE
1. Have open a document with a portrait-type aspect ratio
2. Select the Crop Tool - make sure "Grow" is disabled
2. Begin a crop with a *locked landscape-type aspect ratio* (e.g. 1.9)
3. Resize the cropped area in width, going beyond the image border
OBSERVED RESULT
The height of the cropped area increases and increases, even when the cropped
area already spans the full width (and thus does not expand anymore), therefore
the locked aspect ratio is not maintained anymore at some point
EXPECTED RESULT
As soon as the cropped area spans the full width of the document it should not
grow anymore, neither in width, nor in height - thereby the aspect ratio would
be maintained, as the lock dictates.
SOFTWARE/OS VERSIONS
Observable in master as well as in latest released Krita (4.4.2)
ADDITIONAL INFORMATION
As far as I can see Dmitry has implemented an abstract rectangle class that
handles these resizing constraints (width/height/aspect ratio), I haven't
studied it in detail but I suspect the way it is implemented maybe doesn't
cover this specific case documented here (yet) (hopefully the implementation
model can cover it).
I might potentially look into a fix for this myself if available hands on the
team are short for this, but either way I think it would be good if someone in
the krita team first triages this, either laying out a preferred approach for a
fix (if it needs larger changes) or maybe even fixing it right away if it
happens to be a quick fix. :)
--
You are receiving this mail because:
You are watching all bug changes.
