LaTeX and Vector/PDF Graphic Size


one of the great things about Latex is making pristine PDFs with good font renderings. Consequently, I avoid using PNG or any raster format when vectors work. Presently this means screenshots as vector PDFs. for raster images you can double click and adjust size in scrivener and it passes to latex, which is cludgy but works. Vector PDFs just exist however.

They vary in size, and the major issue I have is that if I insert them in the document, then size from \includegraphics[width=2in]{ has to be the same as it comes from the compile menu in a single location.

I need several different sizes, currently I created some text replacement shortcuts e.g. : xw4{ => \includegraphics[width=4in]{ . unfortunately this means I have to keep static paths in my scrivener, and compile is entirely latex specific.

is there any other way to do this? e.g. could I somehow store custom metadata, keep screenshot as its own subdocument, and use a reference to auto insert the desired size? That would preserve ability to export to Word?

(I usually export drafts to word for review to others, but keep my work in Scrivener until I can export)

any ideas?

That’s a pretty good approach, probably the one I would take as well. It’s worth noting however that working this way does not mean you are stuck making LaTeX files, nor does it mean you have to handle the image path yourself.

I’m not sure how you are handling image output in general. Are you using the Non-Fiction LaTeX starter template we provide? If not, I’d take a look at that for some ideas if nothing else. But to answer how this could be streamlined a bit, with how template works as context:

  • A figure is enclosed either by a paragraph style or a within a self-contained binder item. These constructs are responsible for enclosing the image in a figure environment.
  • The image itself is then generated from the settings in the Markup compile format pane. In the template, we generate the entire \includegraphics{…} line, including the native image’s actual width and height in points.

So if you wanted to handle the options passed to includegraphics, then this field could be reduced down to merely:


That will handle the image export and path linking for you, and with the image in the editor as a normal graphic, this alone will work fine when you switch to .docx.

That’s one of your problems solved, the other is making sure that when you switch to .docx, you don’t get clutter around the image from the Replacements. That is precisely why we have a Replacements pane [i]inside[/i] the compile format. You can expand your shortcut code to LaTeX syntax around the image in the LaTeX compile format—but for the Format you use with .docx, you can set its Replacements table to search for the same strings and then replace them with nothing. Obviously in this way you could turn your output into HTML if you wanted.
is there any other way to do this? e.g. could I somehow store custom metadata, keep screenshot as its own subdocument, and use a reference to auto insert the desired size?
That is definitely an approach you can take as well. With the stock LaTeX project template you would need to do a little rewiring to make that work right, especially if you wished to include images in the text without special figure type documents as well.

If you take a look at the Prefix/Suffix tabs in the “Figure w/ Caption” Section Layout, you’ll see where the figure environment is set up. You’ll also see a demonstration of how custom metadata can be inserted in the Suffix tab, where we take the “Caption” field from the inspector.

Hence, one could offload some of the figure generation syntax from the Markup pane into here, and use something like the following in the prefix:

\includegraphics[width=<$custom:Figure Width>][/code]

An important detail that cannot be conveyed through this medium is that this field does [i]not[/i] end in a carriage return. We of course want the Markup pane to insert the brackets and image path on the same line that this prefix ends, so that our final result is:

\caption{This is the caption.}

This Section Layout prefix could be copied over into the prefix field for the “Figure” Style, as well, allowing for hybrid use. Of course in the case of the style, if the idea is that one would have more than one figure in a document then this approach would not work so well in general—each binder item can only have on “Figure Width” custom metadata value assigned to it.

Oh, and as to that: since you only have a few sizes, you could create a “Figure Width” field of the List type and input those sizes as options; even leave the default at “2in” so that you don’t have to bother with changing the field unless it is necessary. And when you do, it’s just a few easy choices to select from, rather than typing in “4in” every time.

Let me know if you need any more specific information. Like I say I don’t know exactly how you are generating LaTeX, so what may work for the template may not for a project that uses another approach entirely.


I just want to say thank you! That level of detail was extremely useful. For that round of drafts, I stuck with the text replacement and styles method (I was using the LaTeX Nonfiction Template). I’m coming back to the issue for this round, and relying heavily on your awesome support.

I eventually settled on all images being in figure subdocuments. I added the options as a list and altered the Figure document prefix and suffix to have /includegraphics and the custom metadata width. This makes for a hyper-detailed outline, and opens options for non LaTeX compiles.

the hyper detailed outline is a mixed bag, to make lists keep working (images in list) I had to create subdocuments for enumerate list and list item. This is a big change to document organization.

While I love all the options and power of scrivener, having to use it for this is overkill that is costing me time/money tbh. Scrivener does not allow me to set size for vector PDFs as it does PNGs, which for many output formats is essentially just metadata. If Scrivener had that ability, then the workflow would be dramatically easier. (that is maybe a . revision feature)

Adding more metadata directly to images seems like a good deal anyhow… allow user set size and scaling, captions, hyperlinks, alternate text in addition to captions, and possibly even alternate assets for 1x/2x/vector. (that is probably a 4.0 idea). In my case I’m effectively doing that, I have vector PDF images for PDF/Print but autoconvert to PNG for html)

(shout out to paparazzi! for taking vector PDF screenshots of the web, having UI elements of a website rendered as searchable text in a output is sort of killer)

Glad to be of help!

Have you ever messed with Word’s outline mode? I like to think of it being a bit more like that, once you break things down to sub-topical levels. Of course Word flags each paragraph as a separate outline entity, so it isn’t quite to that level, but in overall feel it’s similar.

I do agree it’s a bit of a mixed bag, but in general I’ve come to like working that way more, over the years. One thing I like about it is you can flag these special items with metadata and then gather them automatically into collection lists. I have a list of figures, tables and other interesting elements in my more complex proejcts.

You’ll definitely get used to Scrivenings mode however, which of course reduces the burden of this workflow considerably.

Unfortunately how PDFs are embedded, as well as images and what metadata you can put into them, are details handled by the Mac text engine. It’s not an additive request you are making, rather a request to scrap large chunks of the text engine and rebuild them from scratch, for better image storage and handling.

What would be surely nice is if Apple had programmed their text engine so that it was modular and could have its various classes more easily extended. But the sad reality is that it is a black box that ceased core development almost 15 years ago. Despite that, it is still yet one of the highest quality and well-featured text editors available—certainly for free. It’s a lot to throw away, even with all of its old warts (like the assumption that PDF represents embedded documents, not images; hey, Y2K had barely just happened when that was added!).