Setting global variable for width and height in image tag

Scrivener Scrivener for macOS
1

I use image tag to insert an image to break up paragraphs.
<$img:image_name;w=15;h=15>

Since this is used throughout the manuscript, if I want to adjust the size I have to do a global find and replace.

When I compile for mobi, the image size become tiny compared to when I compile for pdf or word. So for a mobi compile what I want to do is just set the width and height in one place as a global variable and then have the compile pick that up.

Sort of like this:
<$img:image_name;w=$w;h=$h>

Is that possible? And if so where would the variables be placed? Alternatively is there a way to increase the size of the image during a compile specifically for mobi?

Thanks!

1 Like
2

Yeah, this is one of the big advantages to using image placeholders in fact. Since the compiler has a built-in search and replace system, anything that is text can be modified on the fly, and since image placeholders are text—everything about them can become dynamic. Replacements can be saved per format so that PDF does one thing while ePub does another.

If you’ve never edited a Format before (you just click on “Ebook” in the sidebar or whatever), then just double-click on the one you use to duplicate and edit it. There are actually two different Replacement tables, one for your project in general, and then each saved Format can have its own. For what you’re describing it is the latter that will suit you. But the main bulk of documentation on how to use them is found in the discussion on general project Replacements, in §23.4.4 of the user manual PDF.

Also, consider using different images for each format, that are optimised to the right size depending on the output, instead of having one single image that you inflate or shrink. The quality of this can vary widely depending on the device displaying the book. Your image may be blurry or pixelated in some cases. But if you create different images that are the right size to begin with, in theory it should be crisp and sharp in all cases.

And of course since the file name in the image placeholder is text, it would be the name you are adjusting with Replacements, rather than the width and height (and you can in face leave that off entirely since you’ve sized them correctly already). For example you type in this:

<$img:separator>

The compiler turns it into this:

<$img:separator-epub>

Or:

<$img:separator-pdf>

So long as you have image variants named “separator-pdf” and “separator-epub” in your binder, that’ll work.

Of course another approach entirely is to use Separators in the compiler, and break down the text of your outline even further. This is the “scene file” approach that is demonstrated in the novel template for example, where it is intended that each scene in a chapter has its own section—and then the compiler is responsible for inserting the separator. It may be blank space, or it could be an image placeholder too.

Of course if you’re doing it that way, then your Format’s separator can be tuned to use the right placeholder directly, rather than search and replace. And now you don’t have to litter your book with these codes, too, while writing.

3

Thanks, I used the img tag and global replace on compile, and when I compiled it previewed correctly on my kindle previewer and on my kindle app on my Mac, so it looked like it was good. When I emailed it to my kindle app on my iPad though, a couple odd things happened. It removed all indents, and the image size was really big again. The same thing happens on the kindle app on iPhone too.

I’m investigating my settings, but can’t think why it would work on the kindle app for Mac correctly but not show correctly on the iOS device. I can use different image sizes as suggested which will be one of my next steps, but I want to figure out why it isn’t indenting on the iOS device, but it is fine in kindle previewer.

4

If what you’re saying is that a book looks one way in Kindle Previewer but another way in the reader, then that is probably a matter for Amazon technical support—at the very least it represents a failure of their preview engine.

That said, if you’re talking about loading .mobi files directly into Amazon’s reader software, they aren’t really made for that, they are for uploading to the KDP, rather distributing as an ebook. Refer to exporting file formats, in the Kindle Previewer documentation, for instructions on exporting preview files to different platforms.