Keith says doing a maths conversion would mean adding width and height for all images.
https://forum.literatureandlatte.com/t/image-pixels-points-and-the-css-reference-pixel/39356/2
Would that be a bad thing to do?
Devin: my calculations are that 375 CSS px is expected given Scrivener’s DPI conversions; I’ve added a test project with predicted vs. actual values on the other thread: viewtopic.php?f=3&t=50135&p=257489#p257489 — I think you are mistaken when you say Scrivener ignores DPI, it doesn’t and you can confirm it with my test project 
Bridey: I don’t think Keith will need to do that, he should still use the same rule that anything > 600 CSS px should get a width=100%. The issue is only for the calculation for images that are < 600 width (remember the original Kindle 1 was 600 x 800 portrait resolution, and that is the resizing yardstick that Scrivener uses).
Hi everyone, just looking in on the hornet’s nest I created. Did anything productive come from my rants? I hope L&L support doesn’t hate me for starting all this, I might need your help with some other matter one day! Just for the record, Scrivener is still the best product ever!
M
Maybe that’s the fix – allow us to define the resize threshhold, with the default being 600 wide for the original Kindle? A little more control over image output would be welcome, especially if we can do it in the same way we’re doing text output in Compile and make simple settings that can be easily re-used.
Many thanks. Will be interesting to see if any changes are implemented. Been a very interesting (for me, at least) thread.
That’s already possible. Given that type of decision is device based, it is located in the compile format designer, in the Text Layout pane.
As to the rest, sorry I haven’t updated the thread in a few days. We’re still talking things over, hopefully to find a better way to communicate why Scrivener is doing what it is doing, and maybe work in a little extra dichotomy between screen/print if possible. No promises though.
The concept of having image size truly divorced from output size is going to be a little more difficult I suspect. The image is all there is in many cases. If you change the print settings with the slider, that actually changes the image’s settings on the disk. When the file is loaded from the Binder, or when it is compiled, its size is determined by the settings (however they got that way). There is no separate setting somewhere for embedded graphics, no place to store “50%”. It’s just a graphic, jammed into an RTF file.
Meanwhile, don’t worry about it Mick. You may be wrong, but we won’t hold that against you. 
It’s a good discussion to have, and nice to have this wealth of technical information on the forum now, for those that want it.
Since I haven’t said it lately, I VERY MUCH appreciate how much behind-the-scenes information you all provide to us via the forums. This thread has been extremely educational, and if I have come across as pushy or argumentative, please know that it is because I am mainly arguing against my own lack of understanding.
Devin, you didn’t come across to me as aggressive, just keenly curious! 
Yes, this thread has been pretty fascinating for all involved I suspect (Mick shouldn’t worry!), I’ll be curious if Keith and Ioa can come up with a slightly more transparent rescale UI, considering the complexity that underlies something apparently so simple!
Okay, that’s the piece I was missing – that you’re changing the image on disk, specifically the DPI metadata? I assume so, since the same file is both converted to a smaller image for RTF/DOCX and brought through at original size but with height/width set for HTML.
What about just changing the slider so that it tells us it is directly changing the DPI…and have the dialog show us both the resulting size in points (for print) and CSS pixels (96/72) so that we can see ahead of time how it’s going to come out in our desired compile format?
Actually I think what Ioa said is not true at least for images in the Binder that are “linked” into a document. My DPI.scriv project shows the image on disk is not changed by changing the rescale slider for the image.
Perhaps this only applies for embedded images, but then how does the linked image retain these settings if they are not saved to disk?
EDIT: for linked images this is stored in the RTF itself (this is my 100x600 300DPI image which gets 240x144point size):
\{$SCRImageLink[w:240;h:144]=$PROJECT://CF34190E-7B59-4E6C-AE86-BD03232CEFBE.jpeg\}\EDIT EDIT: for embedded images it also uses RTF metadata:
{\*\shppict{\pict {\*\nisusfilename content}\picw1000\pich600\picwgoal2400\pichgoal1440\jpegblipYup 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.
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.
So then I don’t really understand. I’ve tried both types of links (binder links and linked to an external file), and embedded images (where there is no disk file) and nowhere is a file on disk edited or changed when changing the scaling? Do you mean after a compile? Yes this is a purely academic query! 8)
Try this:
- Drop a graphic into the text editor to fully embed it.
- Double-click and set its DPI to something unorthodox and click OK.
- Right-click on the image and “Save Image”.
- Open image in Photoshop. The file should be tuned to the DPI you set in step 2.
And to clarify what I mean by the design reflecting the most limited object in the system: I meant that purely by what additional sizing sliders we could provide for images. The sliders currently operate directly on what can be expressed with RTF on an embedded graphic. Even if the RTF file was driving the image size rather than the image being sized and the RTF describing its size, it will still all be rooted in those four flags that print pixel size and intended size in points.