So… I’ve produced a document, composed in MMD, in Scrivener, compiled to XeTeX, output to 52pp. A5 pdf file, using a heavily-edited memoir-class leader.tex file:
\documentclass[a5paper]{memoir}
So far so good.
Now I find I’d like to reproduce / scale the whole document to A4 output — which can be achieved by up-scaling the output PDF, (using A5>>A4 ratio of 142%), with some loss of resolution to images etc.
However, I’d like to achieve a similar effect, using LaTeX output directly, (which can be downscaled by my printer, when a5 output required with a preferable result to up-scaling) hence begin:
\documentclass[a4paper]{memoir}
Result: text output is too small for my use, as are images, tables etc. I want to finish with an ouput A4 pdf that is more or less precisely the same as SCALED output A5, same no. pages etc.
Can anyone advise:
Is there a way to simple increase the font size, within my *.tex leader file?
Is there a way, within Scrivener, to tell it to output images, tables to “fit width” settings?
It is probably not exactly what you are looking for, but in your compile screen, under the cog tab is a “scale images to page width” check box. However it is not an option within all settings. It depends upon what you have chosen in "Compile for ___ " at the top center,
It is available when you compile to the second group (rtf, docx, doc and odt), though I don’t know if it affects tables if they are not images.
As far as image handling goes, the best way to see what Scrivener is doing is to compile to plain “MultiMarkdown” and look at the .md file in a text editor. At the very bottom you’ll see how it is marking each image’s size.
This may or may not work for you, depending on the types of images you have, but a neat trick specific to MultiMarkdown is that if you give no image size data in this part of the file, then its LaTeX output will use this output for the graphic:
That will work no matter the paper size, though as I say it does depend on the image type. I can’t often use this trick because I sometimes use smaller images and this blows them way up to visible blurry pixels. I suppose you could get fancy with this and make a proper script that not only checks the image line, but determines whether its specified point width is too wide for the intended output, and strip it, but otherwise leave it alone if it is smaller.
As for how to get these stripped out straight from Scrivener, you’d need to dip into the Processing compile format tab to some extent. You could either use a sed, perl or ruby one-liner here, or do that in a script and use the command here to call on the script. I’d go with a one-liner, as stripping those out would be a pretty simple regex operation.
Thanks, as ever, Amber, for your helpful suggestions.
I’ve found a practical workaround that suits me: I create two versions of the image, one for a4, one for a5 compiled outputs, then simply filter out the unwanted images, using Scrivener labelling system, at compile.
That’s definitely how I approach it! Leaving images to on-the-fly scaling will almost always reduce their quality, or conversely result in PDFs that are way bigger than they need to be when making a smaller version of the document. It’s good to establish this kind of setup in case you ever need an ePub as well, as you can provide even more compressed images for that format.
Just a few thoughts from someone conversant with the LaTeX side.
As you have noted, the font size specification is set in the \documentclass opening.
One input is all that is needed to the \includegraphics command to scale the width of a figure to the full text width. A simple command construction that I use is
The size of an image on a page in a PDF has no bearing on the size of the final PDF file. The file size of the final PDF is controlled by the file size of the image itself. Suppose that you use MyImage.pdf for both the A4 and A5 paper sizes and set both to show at the \textwidth of the page. Your final file sizes will be (close to) the same and the image resolutions will be the same in both documents. When you generate a MyImageSmaller.pdf image with a smaller footprint (memory) size, you do so at the expense of decreasing the image resolution. The smaller image may make your overall file size smaller, but the smaller image will become pixelated at a magnification setting that is lower than the MyImage.pdf itself.
An alternative approach to using different size/resolution images (ostensibly to make the final PDF file size smaller in one case versus another) is to use a post-processing method that reduces the overall size of the final PDF itself. By this post-processing approach, you need not create two versions of the images. Various PDF applications offer a method to reduce file size, and (at least on macOS) you can likely find a terminal command or home-brew option to do the same thing.
When you are going to HTML (for Web posting), you should still consider that smaller image sizes offer lower resolution as the tradeoff. In the old days (dial-up modems), we’d offer a low resolution image up front that would link to a higher resolution image behind it. Such cases are not the limitations any more. Now we scale the image size in the html code for the image and post the highest resolution that we deem important independent of its size.
I am curious why the command is given with all three parameters specified: aspect ratio, width, and height. Inevitably, something will break. By example, putting a 3x5 aspect ratio landscape figure onto a portrait oriented letter paper will honor only two of the three fixed settings. Is this purposefully over-specified approach being used to avoid having to know in advance whether the figure is oriented properly to the page layout (with the thought that LaTeX will work it out for you in the end)?
I couldn’t give you a definitive answer for why MultiMarkdown produces that kind of markup, myself. That would be a good question for the MMD Github discussion area, especially if you do find a combination that breaks it. I would think that the ‘keepaspectratio’ option supplied to \includegraphics would protect the image from squashing, but I’ve never deliberately tested it. All I can say is that I’ve never run into a case where I had a really narrow or really tall image break (and I do that, with toolbars and sidebar screenshots). Whether that was because of the image size being specified literally or this particular code handling it the way it should, I don’t know for sure. We’re just talking years of having used this converter and not recalling a time where an image “broke” (aside from the aforementioned cases of it being blown up too large).
And yes, since this is a fallback behaviour, I would suspect it is being overly cautious to avoid processing of the image’s physical dimensions. But again, I can’t really know for sure what the designer of MMD had in mind.
For bulk image processing, that can be automated via command-line; have a look at ImageMagick. This is what I use to take high-quality PNG image originals for the user manual, and step them down to compressed JPG to reduce the PDF size from something like 60mb down to 15–20ish. I suppose I could use PDF Utils or something to smash the size down, but I’d rather use a dedicated image manipulation suite for that.
As for resolution targets, it depends on your source material. Most of what I use are screenshots, and triggering high resolution / retina mode is the best way to do that (back in the day I would upscale 2x with interpolation disabled so each pixel just got bigger without the blur). I do agree the best approach is to oversize the image and shrink it down. It makes the PDF better for full screen viewing, and that is the sort of image that looks good in a web page. I prefer to go with about 180 DPI in most cases, which is a bit over the 144 DPI retina target. This lets people zoom in a bit more and doesn’t cost much, while consuming less space on the page than “full size” would.
Actually, the answer is in the information for the graphicx package. The keepaspectratio boolean is a (clever) way to handle all possible options with how the figure might be sized.
keepaspectratio Boolean valued key like ‘clip’. If set to true then specifying both ‘width’ and ‘height’ (or ‘totalheight’) does not distort the figure but scales such that neither of the specified dimensions is exceeded.
In any case, I am keen to go directly Scrivener → LaTeX → PDF, bypassing MMD altogether. I should hope to learn how naive I am on this option as I continue my explorations.
The discussion on best resolution, image size, and file size to view or print can (and does) fill textbook chapters in books on image processing. My primary note to the OP was a suggestion that should help avoid the need to have two different images, one for A4 and one for A5 documents. The confusion may have been the notion that one benefits by having a smaller source image to print on a smaller page size (for PDF documents). In truth, unless one is really really keen to define the absolute pixel resolution up front for each printed image, the extra effort to have two different image sizes for two different page sizes is simply not worth it, certainly not for any hard-copy printing or even basic Web-viewing documents.
I prefer going through GraphicConverter on macOS but appreciate that ImageMagick is a well-respected tool in its own right.
You could start with the LaTeX project template in the non-fiction category. It offers a broad range of examples for how Scrivener can automate syntax generation in a manner similar to how Scrivener can generate MultiMarkdown.
The help file at the top of its binder goes over these examples, so you can choose which of them to implement, or where to go in the compile settings to change how they function.