[Croppig by fixed ratio is inexact]

Those are just rounding errors. Images can only be an integral number of pixels, and each step along the way must be rounded to an integer. Across multiple operations, the rounding errors can pile up and get magnified. There's no way to keep context spread across multiple operations for paint.net to be able to go, "Oh he was doing a 6x4.5 crop, and now he's doing a Resize, and 1200/901 is actually slightly more than 6/4.5 but 1200/900 is perfect, so I'll use that instead." At least, there's no way to do this in a generalized way that makes things more predictable for the user, and without a significant increase in development time and frustration. As far as Paint.NET knows, you really do want a 1200x901 resize, and if it were to second guess the math it was doing then it'd make for an inconsistent experience. "Why does it do 1200x900 sometimes, but other times with the exact same input to Image->Resize, it does 1200x901?" It's kind of a darned-if-you-do, darned-if-you-don't situation.

If you want to ensure you get a 1200x900 resize, then you'll just have to notice that the image is 1200x901 and take appropriate steps. Either change it to a 900 or crop off the last pixel, e.g. with Image->Canvas Size.

Makes good sense to me, and just un-ticking maintain aspect works. One thought I had was a potential 'forced aspect' selection mode where only selections that exactly match the given ratio are offered.

Your explanation set off a rube goldberg machine in my head, too. Far beyond the scope of a bugfix. But I thought I'd share it.

The undo data contains a list of previous commands, doesn't it? If so, most of the information needed to make context-sensitive decisions is already there. But for most users, having a command do something different (if only slightly) based on when and where an action happens would be very frustrating. So what if there were a way, in some deeply buried menu, for advanced users to overload existing commands or define their own code. And a way to configure the heuristics as well.

In my example: Command 1- fixed crop, Command 2-resize

If these two commands are run in succession, run Magical-Handwavy-Function to check and force dimensions to 1200x900

No need to reply if I'm off my rocker. I need sleep!

[Croppig by fixed ratio is inexact]

I don't need sample images, the size should be sufficient. Please just provide very explicit step-by-step instructions to reproduce the problem.

1. Open or create a new file (while writing this, i'm using 4000 by 3000px)

2. Selection Rectangle tool, Fixed ratio (width 6, height 4.5)

3. Select an area and crop to selection

4. Image->Resize (Best Quality, absolute size, maintain aspect ratio; resolution: 200 pixels/inch; print size: width 6 inches)

If the selection is larger than 1200x900 pixels, the result is scaled down properly to 1200x900 (in this example)

If the selection is smaller, the result will be 1200x901. Scaling up results in a rounding error somewhere.

The resize action doesn't need to be completed to see the effect. In the resize window, the values for height are filled in. 901 pixels, 4.51 for print size.

[Croppig by fixed ratio is inexact]

This is fixed in the v3.5.7 update.

Something similar seems to be taking place in the resize tool. A 3888x2600 source image (jpeg 100%) is used.

In test 1, I cropped to an area larger than 1200x900 (fixed 6x4.5 crop) and resized (200dpi, fixed ratio, 6"x4.5". A 1200x900 image resulted as expected

In test 2, I cropped to an area smaller than 1200x900 (same fixed crop) and resized again with the same settings. A 1200x901 image resulted.

Source and test images are available upon request.