I don’t have hands-on experience with image cropping/scaling in an A12 context and I’m not aware of any project that has implemented this. That said, I have some thoughts on how you could approach it.
Have you already started implementing something on your own? If so, it would be great if you could share what you have so far — that would help the community give more targeted feedback.
Here is a condensed approach of how I would start implementing that:
1. Frontend — Cropping UI via a custom widget
There is no built-in A12 widget for image cropping. You’d need to integrate a JavaScript cropping library into a custom widget.
For Form Engine and Overview Engine they support customizing how attachment previews are rendered:
- Form Engine: Use the
WidgetMapto replace the defaultDefaultFileUploadwidget for your attachment control with a custom React component that wraps the cropper library. You can also customize theSelectorMap(specificallyattachmentThumbnail) to render a cropped preview instead of the raw image. - Overview Engine: Similarly provides a custom
SelectorMapwithattachmentThumbnail— so you can render cropped thumbnails in list views as well.
Further reading:
2. Backend — Print Engine and other consumers
Every backend endpoint that renders the image visually (most notably the Print Engine) needs to be aware of the crop metadata and apply it before rendering. The Print Engine’s AttachmentProvider gives you the raw ByteArrayInputStream — you’d need to wrap or extend it to apply crop/scale transformations before passing the result to the print job.
The same applies to any custom download or export endpoint that should serve the cropped version.
3. Storing crop metadata
I’d recommend storing the crop/scale parameters as a sibling group next to the attachment group in your Document Model — something like an image_crop_settings group with fields for cropX, cropY, cropWidth, cropHeight, and scale (all numbers).
Adding custom fields directly inside the attachment group is technically possible since it’s just a regular group, but the standard attachment fields (attachment_id, content, mime_type, etc.) are managed by the AttachmentHandler/AttachmentLoader pipeline and I would be cautious about mixing custom fields in there — it could lead to unexpected behavior when attachments are replaced or deleted.
A sibling group keeps things separated and future proof: the attachment group handles the binary, the crop-settings group holds the visual framing. Both live on the same document and are always saved together.
Note: If you have multiple image attachments per document that each need independent crop settings, consider making the crop-settings group repeatable or pairing each attachment with its own dedicated crop group.
Thanks for that sophisticated question I am interested in if you’ve already explored any of these directions or have specific constraints that i had not considered right now.
And 
like stated often, feel free to create a dedicated requirement ticket for the A12 platform if you think this is a feature that should be added (go to https://support.mgm-tp.com/)