It is a mystery to me where the compiler gets the values from. They correspond neither to the dimensions of the file (1260x1994) nor to the points shown in the edit image dialog (302x366) – whatever these “points” are.
I find that I get better results in different viewers by simply omitting the dimension specification. Wouldn’t that anyway be more in the spirit of a “reflowable document”?
The PDF is fine. I’ve checked the epub in Apple Books, Kindle Previewer, Calibre and Sigil. The images are always displayed smaller than I would like and then look fine if I remove the dimension specification.
The general options pane of the main Compile screen allows you to tell Scrivener to downsize images, either by setting the maximum DPI or the maximum dimensions (in points). Those options are discussed in Section 23.4 of the manual.
For ebooks in particular, our recommendation is that you specify dimensions as a fraction of the screen size, rather than as a number of points. See Section 15.6 in the manual for more information.
Not sure I fully understand everything here. One thing I now know is that my original claim that the HTML dimensions are unrelated to the size of the image in the editor is wrong: the “points” in the editor correspond to the “px” in the dimension specification. (I just had to check more carefully!)
It’s not clear to me why the editor sets the points/pixels it does when the image is imported into the editor. But anyway, one possible solution is to simply resize the image in the editor so it takes up more of the space. This works.
I also tried the downsize option (72ppi and 0 max size pts) and found a curious result: If the image has been resized in the editor, the resulting HTML lacks a dimension specification – example:
If the image hasn’t been resized, then the size is taken over into the HTML. Changing it back to the original size after it has once been changed does not result in the dimensions reappearing. You don’t even have to compile in between resizing: just change the size, and then change it back, and that somehow removes the “magical” status of the size in the editor. Note, however, that everything goes back to the beginning if I uncheck the downsize option – that is, the HTML dimension specification is back again.
I have achieved what I wanted – no dimension specification – but the behaviour of the compiler seems bizarre…
Could we step back for one minute here? I finally figured out what is meant by “points” in the scale image dialog. I prepared my images to be 4.2" wide at 300ppi, which, when multiplied by 72, yields the points given in the dialog – 302. Got it!
But points aren’t directly equivalent to pixels and the display of an ebook reader is not reckoned in inches. Why is the value in points simply passed on to the size specification in epub, as seen in the following?
style="height:479px;width:302px"
Consider what would result if I was generating a large format book with a high-resolution image: The value in points would be very high, exceeding the number of pixels available in an ebook reader. I suppose the reader would downsize the image to fit and no one would be wiser. But this example shows that equating the size in points to pixels is wrong.
I’m not sure I want to start swapping anything, but I found this in the manual (15.6.5):
<$img:IMAGE_NAME;w=WIDTH;h=HEIGHT;ebook=WIDTH>
Am I right in thinking that if I provide the following line in the document:
<$img:path_to_my_image;ebook=100%>
the compiler will do the following:
a) The image file is embedded exactly as is in the PDF file.
b) It is added to the epub file with the dimensions specified as 100% – i.e. it will take up as much space as possible in the ebook display.
But what else does the Compile command have to go on?
The underlying image is measured in pixels, because that’s – ignoring compression for the moment – what’s actually stored in its representation on the disk.
If you were using an image editor, it would be able to intelligently interpolate “missing” data to go from 72dpi to 300dpi or whatever resolution you wanted. (With more or less success, depending on the sophistication of its algorithm.) But Scrivener is not an image editor. The only information it has to work with is in the image file you give it.