Based on
@ThrillaMozilla 's comments and mine in this thread last week, I made some changes
1. Freehand placement of an image is now possible but for now there is a cost: the image will be isolated on it's own page (mostly because I dont' know how i'd handle accidental overlaps by the user). Once the option is activated, you can drag it around with the mouse or enter a position in inches or mm. This is complementary to the four custom margins I had implemented earlier so that you are able to get an image precisely where you want it on your page
2. We had moved to a single margin entry system to a four sided margin system. I added a button to copy over the left margin to the other sides (the lower limit is the smaller of 4 sides reported by the cups driver). This was mostly for myself. If I use 13x19 paper (A3+). I can enter a one inch margin, copy to all four sides and use "fit to page" option to get a 12x18 image that needs no crop from the original image from my camera
3. I added an option to allow a specific image to remain in it's natural orientation rather than orientated for paper savings like the default engine does (per image setting). It's not a full rotation option but whatever LLM model was tried (GPT, Claude, opensource) they all got it all wrong when I was asking a 0,90,180 and 270 rotation option
I blew through almost 20$ of credits before I decided to rollback and try another approach
4. the image inner/outer border color can now be changed from black to anything else with a color picker that includes some presets (this was never discussed here, just something I wanted to do).
5. "rule of thirds" lines are now shown in the crop editor (cosmetic change only)
6. I also added an alternative print path for someone who tried the software with a specialised dye sub printer and got a bad result (the printer would spit out blank paper). Rather than sending 16 bit postscript/pdf with embedded ICC profile, there is now an option in the preferences menu to send 8 bit tiff data with no embedded profile directly to the printer. the RGB values sent to the printer are still from conversion from the ICC profile so there should be any noticeable difference in the output. If there is, it would be coming from the 8 bit data but in reality this is hardly ever a problem.. most windows drivers are 8 bits. Qimage image itself didn't introduce 16 bit output until very recently. A side effect of this print path is that it's MUCH faster than the standard path if your printer will accept a TIFF through LPR. There is practically no new code here. I initially designed around 8 bit tiff and the code was simply disabled when I started chasing after every bit of theoretical quality and switched to 16 bit
