I am interested in knowing if anyone has put together “best practices” for image handling in Scrivener documents. While there are references to using images in the Scrivener Corkboard, the manual does not appear to contain recommendations for handling included images in the text.
I have a document which will include twenty or so maps and photographs.
For the print version, two images with captions per page would work well. For the epub/mobi version that won’t work, putting aside epub3 for the moment. A single image will display well on a smartphone if given its own page.
If I drag a photograph as a separate file to the binder, I get the following error message:
“The Draft folder can contain text and folder documents only. To add an image to your draft, either drag an image into the text of one of the documents or place the cursor where you wish the image to be placed in the text end use the Edit=>Insert menu.”
I can create a blank page, enter a caption and a page break, and then insert an image. This gives me an additional 20 separate image pages in the binder, which is a bit unwieldy. Can these be placed inside a folder?
When compiling, will Scrivener automatically scale the images? Is there a recommended image size for epub files?
This question does not concern cover images or the Corkboard; the instructions for those are quite clear.
Not Ferris, but using images as part of your written material is covered in the Writing part of the manual, in the Writing and Editing chapter, under §15.5, Inline Images, starting on page 221.
Some advice on handling print-size images is given, but in particular I would review §15.5.3, which discusses methods of linking to an image on the disk, outside of Scrivener. How will this help you? Quite simply you can put all of your print-size graphics into one folder, and your mobile e-book graphics in another folder (or however many variations you require). Since Scrivener only looks for images in the folder name they were originally linked to, you can rename the master folder for the batch of images you require during compile. I personally recommend leaving the lower resolution images as the active folder while writing and working in Scrivener as that will improve performance in the editor.
You have full control over image size. What is “best” is a constantly changing thing that has no right answer for all devices. Some people even maintain several different sets of images for various e-reader vendors and devices. What looks good on a Kindle might look bad on a Kobo.
That method will require more post-compile editing from you, just so you’re aware. Scrivener’s automated systems assume section breaks are actually section breaks, not used to enforce internal formatting within a section. In other words, your images will become “chapters” in the e-book ToC. You can fix the cosmetic one yourself in Scrivener (details in the relevant chapter of the manual on creating a table of contents), but that won’t impact the built-in ToC that is used to display navigation points in menus, as well as chapter-based navigation features in readers.
Like I say, one has full control of e-book presentation, but with full e-book editors (like Sigil or Calibre). So some of these questions are entering into the category of “how do I make an e-book”. I highly recommend the mobileread.com community forum for those kinds of general questions. Scrivener itself is designed more to get all of the hard work done for you, and in parallel produce a result that is good for a huge majority of relatively simple books (at least in terms of structure, something like a novel rarely needs much more than a few chapter breaks).
Hmm, not sure, maybe your PDF viewer is trying to be “smart” about search results and sorting those results by some internal magic. If you can do a straight linear search from the top, the word ‘image’ is first found on page iii in the Table of Contents, pointing to the sub-section, “Inline Images”. I try to keep the ToC as detailed as possible so that it can serve as an index of topics.
Well you can’t do everything in one program. Speaking in general of course, Scrivener is a writing program, the large majority of development effort goes into the writing and organisation interface. Exporting is important and a lot of effort goes into that as well, but as a premise there is no way it can replace dedicated production tools. There are more ideas for how to make books than we could possibly fit into checkboxes! That said, this is one area that has bothered us, and we will hopefully introduce a more flexible solution in the future. It’ll be a ways off though, so don’t plan on it any time soon.
Speaking in general of course, Scrivener is a writing program, the large majority of development effort goes into the writing and organisation interface. Exporting is important and a lot of effort goes into that as well, but as a premise there is no way it can replace dedicated production tools. There are more ideas for how to make books than we could possibly fit into checkboxes! That said, this is one area that has bothered us, and we will hopefully introduce a more flexible solution in the future. It’ll be a ways off though, so don’t plan on it any time soon.