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:
- Prefixing the visible image, I place an inline annotation into the text that contains a file hyperlink to the source file.
- Now when I need to make an edit, I click the link and the source opens in the native editor.
- …
- 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.