devinganger wrote:Okay, that’s the piece I was missing – that you’re changing the image on disk, specifically the DPI metadata?
Yup that’s it. And that relationship between intended point scale and physical raster (DPI) is all Scrivener has to work with for producing a similar looking HTML result.
nontroppo wrote:Actually I think what Ioa said is not true at least for images in the Binder that are “linked” into a document.
That’s correct, linked images are different. To provide a consistent experience we have to go with the limitations of the most limited object in the system though.
The pixel size of the image and the intended point dimensions are stored in the RTF as well as in the image. It’s for parsing, similar to the practice of stipulating an image’s w/h in HTML, to avoid page length creep as the images load in. Unlike HTML though, it is not a method for storing arbitrary sizing values that differ from what is stored in the image itself. The image itself will match the numbers you see.
This is all rather academic though. We’re just describing in greater detail what has already been defined as how things work, earlier in the thread: the images are referred to and processed as print images from start to finish. You have your pixel size and your point size, and the HTML conversion process tries to generate a result that looks the same as the intended print size.