If Adobe is using WKHTMLTOPDF, they are probably using an older version. There are some occasional rendering bugs in WKHTMLTOPDF that will never be resolved by Adobe using older versions of WKHTMLTOPDF or adding a built-in CFML wrapper to make it easier to use. If "not a bug", the response will be "works as expected". We were assisting a third-party transition to WKHTMLTOPDF and their entire report was a single table with lots of embedded tables. (I'm not even sure that their HTML was 100% valid.) WK was overlapping images while CFDocument didn't. Our advice was to use modern HTML5/CSS3 and avoid using tables for layout.
Back in ColdFusion 8/9, I was having issues when using small PNG images with CFDocument. Regardless that all filenames were unique, the first used PNG image would be cloned to all following PNG images when rendering. Adobe uses a very outdated version of iText and was unable to fix it. (They said they couldn't even reproduce the bug.) My response to their inaction was to find an alternate solution.
Regarding my solution (using GraphicsMagick to fix rotation), I don't think Adobe should add extra steps to internally download & optimize images when generation a PDF using CFHTMLTOPDF. This will hurt performance and potentially introduce other problems.
The reported bug ID is CF-4210961 https://tracker.adobe.com/#/view/CF-4210961 (If you tweet it, the URL may become mangled.)
Thank you all for help. I did what BKBK suggested, namely to "open each of the JPGs in MS Paint, then chose "saved as" to overwrite the existing image." The "saved as" images were not rotated. So everything is OK. I still wonder how the HTML browsers were able to display all my photos correctly. I assume that the HTML ignored the EXIF data. But then, if the EXIF data is not necessary to correctly display the photo, I wonder why the camera puts it in there.
Maybe what I should do is to use some Coldfusion code to remove the EXIF data whenever a photo is uploaded.
Anyway, thanks for your.