No Drawing: Is Scrivener the good choice for writing a book on cybersecurity?

I’m starting to write a book on cybersecurity, so I’m looking for a good writing software.
I like very much Screvener’s ability to organize content, collect research information, and so on.
But one thing is deal breaker for me: I can’t draw figure.
In my book about cybersecurity, there will be a lot of figures showing software components, flows of information, …
If the only solution is to insert images, that will not be practical at all for each modification: draw it in another app, copy the figure as image, insert it into Scrivener, keep track of the original file containing the drawing because I’ll certainly need to modify it and re-copy it over and over again.
Do you have a better way?

Thanks in advance,


Scrivener’s solution is linked images: instead of importing the image into Scrivener, just link to it. Edit as needed using the image application of your choice; the link will still work as long as there’s a file at the destination. (Doesn’t even need to be the same file. You can use the same method to assemble a manuscript with either high or low resolution images by swapping the appropriate folders around.)


Thanks for your response.
Using a link to an image file is definitively better. But I still need to re-generate this image file after each modification of my drawing (in PowerPoint for example), and I need pay attention to use the same file name. When I have a few dozens of figures, it becomes quickly unmanageable.

Linking to an image outside of Scrivener allows you to edit the image directly in its native application, which presumably has tools to simplify these tasks. (If it doesn’t, maybe you’re using the wrong tool?)

Phrasing it another way: Scrivener itself is not an image editing or image management tool. But several excellent tools of that kind exist, and Scrivener will work with whichever such tool you prefer.

1 Like

What I found useful when I wrote my thesis (which included dozens of images generated through different tools for diverse reasons) was that an Excel table with hyperlinks to the underlying source gave me everything that I needed. I can’t imagine how I could have done what I did through a single tool embedded in Scrivener, even without considering the technology changes that occurred over my 10 year journey. I experienced the version control, resolution, size aspects and numbering issues inherent in such an undertaking. I also included project specific instructions in the Excel file for applying the various tools.
For me, I think the linked image suggestion by @kewms is the way to go. The rest can be done better outside of Scrivener.


Good suggestion.
Maybe I can use “Notes” (in Inspector) of the image for storing the file path of the original drawing. This eliminates the use of yet another Excel file to maintain.

I don’t edit images (bitmaps), but vectorial drawings, so I have to (re)generate images from the drawing app each time.

The principle is the same no matter what you’re using. Good drawing applications have tools for managing and versioning large numbers of drawings.

Maybe I haven’t explained very well the issue.
Yes, you can have very good applications capable of managing large number of vector drawings, but the problem is at Scrivener side, it doesn’t have the capability to link directly to those drawings and show them inside your document. It can only link to images files.
So you have to export your vector drawings to an image file (JPG for example), insert this image in your Scrivener document as a link. If you only do it once it’s not an issue, but if you have a large number of drawings, and you modify those drawings frequently, you will need to keep track of which image coming from which drawing and vise versa. Neither the drawing application nor Scrivener can do this tracking for you. It’s why michaelhendrsn use his Excel file to maintain this relationship between images and his source application files (I believes he used quite a few different applications for different types of figures).
My simplified proposal is to add a note to each image linked in Scrivener, in this note you record the original drawing file name. So each time when you need to modify an image, you do the following:

  • Right click on the image, click on “Reveal in Binder”, this bring you to the image file in the Binder
  • Click on the image file so you can see the content of the note associated to the image, where you have recorded the original drawing file path.
  • Go to the disk, find that drawing file, open it in the corresponding application, modify the drawing
  • Before re-generating the image, you need to know which image file name is used by your image in Scrivener, so you come back to Scrivener, hopefully you still have your Scrivener open and your image file is still highlighted, so you don’t get the wrong image file name. (Here we can see michealhendrsn’s Excel file has its advantage: even if it takes two days for modifying a drawing, and you have in the meantime already closed your Scrivener, you can still know without risk of error under which filename you need to re-generate your image).
  • Re-generate the image file with the right file name.
  • You are done.

If you don’t want to use the Excel file nor the note for recording image-drawing relationships, you can also simply use the same name for both drawing and image files (only file extension is different). The only constraint in this case is that you will have to do a single drawing in each drawing file. If your drawings come from a scientific software which creates multiple figures in a single file, and you need to split those drawings into different image files, then the Excel file is still your friend.

  1. Use the same filename for the vector file and the jpg image you produce from it, and store them in the same Finder folder.

  2. If you have put aliases to your source images in the Research folder, and then dropped linked images of those into your documents, then double-clicking the placed images gives you a Reveal in Finder button. This will take you in Finder to a jpg which is directly next to the same-named vector file you want to edit.

Some orderliness in filenaming is required to keep that image folder sorted in a useful way for you, for sure.

1 Like

I would say that generally speaking it is expected to be producing compatible forms of images for integration with tools that are not specifically designed to read a wide variety of illustration formats. The implication then is that one keeps source for their own use and “print-ready” (maybe web/ebook-ready as well) images available and in sync with whatever tools are linking to them. I’ll go into a more direct alternative below, that may work for you.

What is needed for final output or even the writing environment is so very rarely going to overlap with a fully capable illustration program and the level of metadata and layering that the original source files have. I am not expecting Scrivener (or pretty much anything) to read native illustration formats. The requirements for developers to support such file types would be an enormous effort, and an ongoing one at that. I don’t think it is right to expect anyone other than graphic design developers to be embarking on such tasks (even then you will find it is difficult and most tools do not read other tool’s formats because of how difficult it is to just read something).

In practice what is needed, then, are formats that have broad community support and thus a higher likelihood of built-in native support for them in common programming tools, such as what Scrivener is built with. You already benefit from some of that with support for PNG, JPG and so on. We take it for granted, given how popular and well supported these formats are. Not only are these formats much easier to support as a concept (than actually drawing things from a set of instructions), but the world is filled with good programming toolkits for doing so.

So in that vein, there is in fact a vector format that commands a similar open specification and broad community support. As a Windows user, one approach is to make use of Scrivener’s native SVG support for vector illustrations.

Demo of simple gradient and transparency support

As shown in the lower right, when this is compiled the source is converted to alpha-mapped PNG automatically, so you do not have to maintain a separate archive of rasterised images unless you want to—or need to because the simpler SVG rendering in Scrivener doesn’t support an advanced feature you want for some figures.

The software I use for illustration is called Inkscape. It edits SVG natively, right in place, meaning all you have to do is right-click from Scrivener, load the image in the default external editor, edit, save, and reload the thumbnail if desired. You aren’t going to get much more than that from any workflow, in my opinion (outside of truly monstrously bloated software, like MS Office, I suppose).

My simplified proposal is to add a note to each image linked in Scrivener, in this note you record the original drawing file name.

So with a little trimming here and there, this is by and large what I do as well for stuff that can’t be natively made use of in Scrivener and that requires source files as well as output files:

  1. Prefixing the visible image, I place an inline annotation into the text that contains a file hyperlink to the source file.
  2. Now when I need to make an edit, I click the link and the source opens in the native editor.
  3. Back in Scrivener, right-click and “Reload from Original Image”.

That’s pretty much it! Obviously I’m cutting out the editing and saving/exporting steps taken in other software. That is always going to be there and doesn’t have much to do with Scrivener, but I did notice that the process you have described contains considerably more manual labour, and I don’t feel all of that is necessary. (Perhaps these are side effects of using certain programs like PowerPoint, which I always thought to be more of an self-contained presentation program rather than a general purpose illustration tool meant to work in a tool-chain. There is probably a large amount of overhead in exporting stuff out of it in general, given that.)

Other programs are going to make that easier. Inkscape for example saves the target output filename and path in the file itself, so you don’t have to look anything up, you just punch an export button to refresh the disk copy associated with the source. Gimp does the same, you can refresh the compatible raster output with a single menu command. Tools perhaps less oriented toward a graphics heavy workflow might be contributing to some of the friction here you describe, in other words!

But say one of these programs loses track of the raster copy, and I need to consult Scrivener for that information. This isn’t too difficult in general, and does not require me to be doing so much manual record keeping as you describe, if I understand you correctly. If I need to fetch the disk path for a linked image, I just right-click on it and choose “Scale Image”. You will note at the bottom the full path is printed, along with a button to re-home it, and another to reveal it. (The only flaw here is that the programmer did not enable selectable text in this dialogue box. You should be able to select the full path so you can paste it into the save dialogue and go. But even so, you at least do not need to be taking pains to record this in a separate binder item’s Notes sidebar.)

Hopefully that makes sense; what I’m getting at here is that Scrivener’s toolset is well thought out for orchestrating that job at a high level. It’s the result of much refinement in reflection of large-scale real world use (the user manual project for it has over 300 illustrations to manage). It seems efficient at doing so at any rate, and that there aren’t many rough edges to it. Its approach is also flexible enough to cater to preference. I mentioned using inline annotations, you might find a Bookmark in the inspector to be a better choice. Some might prefer binder shortcuts to the source files and raster, so that all of this can be organised in the project itself, with metadata and notes. That’s perfectly fine as well! Scrivener is great for managing lots of files like that, and you can link an image in the editor to a raster in the binder (where a binder link to the original source is kept conveniently near) which is in turn linked to an image on the disk keeping the whole production route flexible.

I also very much recommend what @gr has to say about establishing a strong file system convention for all of this. I strive for a system where source files are predictable rather than documented, and that means a good folder structure and naming convention. Many of the illustrations I use require multiple source files to assemble. For the Scapple and Scrivener manuals, this can mean from the original Scrivener/Scapple projects used to create the screenshot, to the saved .prefs file used to change appearance settings, to the graphics source files themselves that layer arrows and such on top of the screenshot. All of these elements need to be easily accessible, and all traced back from a simple piece of information in the Scrivener text editor: the output filename.

Experiment with combining different features, is what I’m getting at, as you have been. You might find something that works better, and over time better yet, until you have a finely honed workflow. For me, the vast majority of labour in any figure update is the time spent in the illustration software itself. The few button clicks and such around it is hardly worth remarking upon or substantially improving.


Thanks very much for your great explanation, with so much details.
I’ll experiment what you propose, especially SVG.
Thanks again.

1 Like

Hi Amber,

I would like to compile for Kindle, and it specifies SVG as the preferred format.

You explain that Scrivener compiles to a raster format. Is there a solution, either available now or in the pipeline?


Actually, SVG works, but is rarely used in KF8. JPGs and PNGs are the norm. So, only when you have veector drawings from Illustrator, SVG-files are a logical choice.

Added SVGs to your book can be done using the e-book editor Sigil.