I am writing a family history. I have a slew of images that I want to include as a document in the Draft. I have both Word and Pages and have tried to build the document using each. All of the image sizes are random and need to have some width and height adjustments on the page. In a word both of these word processors are clunky when manipulating images.
Instead, I have started to test MultiMarkdown as a place to build a document file. In my testing, everything looks good in MMD but when I import the file into Scrivener it is just plain text. I have included an attachment.
I like the MMD because I can create descriptive captions for the images (family groupings have a lot of names.)
Am I on the right track, but need an adjustment, or is this not going to work? Is there a better way?
Progress report: When I import the MD file I am now using the Import and Split option and Convert Markdown. The markdown file is converted to documents and the images and captions are working just fine. But —
The images are not reflecting the sizing specified in the original Markdown. This would be the easiest way for me to inflict a standard vertical size across all images in the document. Is this possible or is the Markdown height= and width= lost?
You are on the right track I believe, and there is one small ingredient you need to add to make image handling a bit more dynamic, and allow Scrivener to manage image export when you compile this document:
First you will need to import the image resources into the project binder. There are two ways of doing this, either fully imported (just drag them into the binder) or as links, back to the file system (with File ▸ Import ▸ Research Files as Aliases…). If you anticipate many hundreds of megabytes of images for this project, the latter is a good way of keeping the project size trim, which is important for taking frequent backups.
Next, you want to type in the MMD syntax around the image reference. Now I see you are using the caption for both its intended purpose and the ID. That’s fine I think (I’ve never tried it), but you may find it to be a bit less cluttered if you use your own shorter ID. For example:
[code]![This is the caption your readers will see][Appleton Family]
[Appleton Family]: name_of_image.jpg …[/code]
Now what this tip is concerned with is the “name_of_image.jpg” part. Don’t type that in, rather drag the image from the binder into the text editor with the Option key held down, and drop it where the name of the image should go. You will get a hyperlink pointing back to the image. The hyperlink text that you see in the editor can in fact be whatever you want. When this is compiled, Scrivener will detect that this is a link to an image, export the image into the compile folder, and then replace the text with the name of that image.
Next for handling the image sizes themselves. Unless they are all precisely the same aspect ratio, you probably don’t want to apply a universal height and width to them all, as some will get squashed or squished by doing so. You’re probably most interested in having a uniform width, so you can just supply that by itself, leaving the “height=x” part out, and let the output handle what that means for the height of the image.
The way I would handle the width setting is by using Replacements in the compiler (refer to §23.4.4, Project Replacements in the user manual PDF for details). Using this approach, you can create a simple shorthand syntax, like “#width” that gets replaced to “width=468pt” (or whatever you need). While one nice thing about this approach is that you don’t have to type as much, the stronger advantage is that if you need to change your output requirements you can do so in one single place. You can even relocate this Replacement into the compile Format, rather than global to the project. Points might make for a good measurement in print, but pixels might do better for online work. You get that flexibility of changing the size and unit by handling the width by format.
Honestly if you’re going to take that approach, it would be better to use Pandoc or MultiMarkdown to generate the word processor file and then import that into Scrivener—nothing is going to do a better job than either of those tools. Scrivener’s Markdown conversion is intentionally simplistic and mostly just there for convenience with very simple files. But it’s also important to note that flag (or the better process of creating a .docx or .odt file to import) is also for those wanting to abandon Markdown once they start using Scrivener.
There are other ways of doing what you want that don’t involving using MMD, and they have some of the same advantages (proper captions are not among them though) in that they are text-based tokens that can thus be controlled with Replacements. Refer to §15.7.5, Image Placeholder Tags for details on that method.
Thank you for such a thoughtful response. I have imported the images as research resources as you suggested and it is working like a charm. I had been importing the images from files and the system was slowing as I imported more and more images. I knew that I would not be able to complete the document. With your suggestion, there are no delays and the images are rendering properly to the PDF.
I will have a look at simplifying the naming as you suggest. The current naming is a left-over from scanning the images years ago. It seemed at that time that it was best to use the file name as the caption. Now I am not so sure that was a good idea. I will rethink this.
