I have recently completed writing three 40-50k word business books in Scrivener. They all have lots of graphics. I have used two-cell tables each time, with the graphic in the top row and the caption in the bottom row. I now need to work out how to minimize the work involved in compiling for Kindle / KDP, as well as low-volume print. The main challenge is that since I want universal Kindle compatibility, I need to work with the lowest resolution as my norm, as far as I can tell. The lowest-res kindles are 600 pixels wide. Clearly, print resolution needs to be much higher. I have also been using Word with my line editor and test readers. The 600-wide format is far too wide for Word, where I have to limit myself to 450 wide to avoid the graphics going off the side of the page.
Anyway, I found the discussion below in this forum. Is it the best current suggestion as to how to handle different formats? AmberV’s answer is the relevant one and is from November 2015. It suggests linking to images, rather than having them in the documents directly, and having different sizes for different purposes. It seems to me that I would have to then abandon the table approach and edit the caption directly into each image, since the table sizes are independent of the image sizes. For reference, I am not interested in any eBook format other than Kindle, though I realize I may ultimately need to go via another format and program like Calibre to get there.
This may be too technical an option, but have you considered using Multimarkdown and Pandoc? Compiling from Scrivener to a markdown file you could then easily make a small script which would edit the markdown to add different “width=x” markup and compile to an EPub and DOCX. You could automate this to then convert the EPub to mobi using kindlegen. This should be very flexible if you can set it up, and far less hassle than editing images with hard-captions…
While I am still unclear about all this, I now believe that the best practice is the exact opposite of what I suggested when asking the question. In short, I now believe you have to use the resolution of the highest-res kindle device. This means 1072 pixels wide. I have to admit that I find this information difficult to reconcile with the Amazon recommendation of 2560x1600 for cover illustrations. That is considerably more than the highest-resolution Kindle, so I don’t see the point.
Scrivener is not a WYSIWYG editor. You shouldn’t be overly concerned about how images look in the Scrivener editor. However, for both performance and aesthetic reasons you may find that you’re happier if you use low-resolution placeholders while writing and replace them with the production-quality versions when done.
Cover illustrations in particular appear in a lot of places throughout the Amazon store and potentially in marketing materials, not just on the Kindle itself. That’s probably why Amazon wants larger versions.
“Pixels” is not really the right metric for graphics that will appear in print. Even an inexpensive small office printer can achieve 300 dots per inch resolution. So a graphic that is only 450 pixels wide will be either very tiny or very poor quality when printed. (Sorry, I’m not enough of a Word expert to have good advice on how to handle the running off the page issue.)
Bottom line: images that are designed to span the full width of a Kindle device must have a minimum horizontal dimension of 1200 pixels. The section implies, but does not actually say, that larger images will be scaled to fit the device being used.
9.4.2 Image Size and Quality Standards
Images must meet the minimum quality standard of 300 ppi for the intended display size. The minimum
standard for a full-page image in a book after allowing for margins, running heads, page numbers, and
captions is an image size of 4” by 6”. At 300 ppi, this image must be a minimum of 1200 x 1800 pixels.
Testing this morning using the Kindle previewer reveals a minor issue. Most of my graphics are in two-row, single-column tables. I do this to keep the caption with the image. The table border takes at least a pixel, as far as I can see. This means that 1200-wide graphics that have a border down the right side get cut off. I will have to play a little with the resolution, trying things like 1198, or find a way of not needing to use tables.