I have a reference to a .jpg file in the side bar, and I have dragged the image to my Scrivener document source. I thought that when I edited or replaced the jpeg file, the image in Scrivener would automatically update, but it doesn’t seem to do that.
I am unclear if there is any way I can add an image to a Scrivener document and have it update when I edit the image. This would be a great feature, so that you would know that all your images are up-to-date, and not have to check each one by hand.
Interestingly, the “Modified” date in the side bar updates when you change the image, but the image in Scrivener doesn’t change.
First, just to be clear about which sidebar we are talking about, there are two of them. One is located in the Inspector, and items dragged here are referred to as references. References are just links to files on your hard drive, and when you edit them on your computer, the next time you double-click on the item in Scrivener, it should be updated. The other sidebar is referred to as the Binder. When you drag items there they are copied into your project. The original file on the hard drive is no longer linked to it. From what you are describing, it sounds like it is the binder that you are using. If you right click on an image in the binder, you can choose to open it in the default external editor. This should update the file. However the original will not be updated, of course, because this is a copy. If you would prefer your resources in Scrivener to be linked to the original files, you might be better off using the inspector.
Thank you, Amber, for your detailed reply. I am referring to links in the inspector. Look at the following
I made a jpg, and I put it in the Document References. I then wrote some text and dragged from the Inspector to the document.
I was hoping that every time I updated the jpg on my disk, it would update in the Scrivener document. Or, failing that, I could ask Scrivener to update the link (like in, say, Adobe Illustrator). What I find is that double-clicking the link in the Inspector opens it in the default application (Preview), and that the only way I can find to update the image is to delete the reference in the file, drag from the inspector again, and resize, which is sort of annoying.
Okay, yes that is another variation. I was so focussed on sidebars that I forgot about the third case and that is images embedded in an RTF file. That’s really the key thing to note there, and this is incidentally the same anywhere on the Mac, so long as the application is using Apple’s RTFD format. When you drag an image into a text, it copies the image into the RTF file’s resource folder. So even though the reference image in the sidebar is a link to the file system, once you drag an item into the RTF file it ceases to be a link, it is it’s own file. After that point there is nothing binding the inline image back to the reference item it came from.
Now the upcoming version of Scrivener will be transitioning away from RTFD to pure RTF, but this same limitation will exist—and perhaps even more so because in pure RTF the image gets encoded into the actual text itself, rather than being stored as a separate file “beneath” it.
If your workflow dictates that you need images inline from the start, but those images are constantly changing, then you might do better by using placeholders until things settle down.
Well, Amber, I did some more fiddling—which I probably should have done before posting the first entry.
Here is what I found. If you drag from the inspector to the document, you get a copy of the image, as you say.
However if you control drag the link, then you get an alias (presumably an alias in the rtfd document, and every time you relaunch Scrivener the link is updated, which is exactly what I want.
An interesting side effect of this is that the “resize” popup menu item goes away, and Scrivener seems to think that the embedded image is “sort-of like” a character. I am not going to experiment with the various pop-up menu items that are available for this image, as I honestly don’t need to know!
So, since you seem to understand Scrivener very well, do you think that this behavior is a bug or a feature? And what do you think that the future will bring—should I put in a request that Scrivener 2.0 retain this behavior?
It’s probably a feature! Every once in a while I do miss something. The weird behaviour surrounding it though would suggest that while it may be a feature of the OS RTF engine, Scrivener might not be addressing the capability—or might not be able to. If it actually is an alias in the RTFD folder, then it could be confusing Scrivener and thus not providing ordinary image controls. I’ll play with it a bit and see what I come up with.
Firstly, in trying to replicate what you are doing, I can’t even control-drag from references. Naturally, if I control click directly on the reference to start the drag, that only opens up the contextual menu. If I press Ctrl after starting the drag, then nothing drops. I tried Option, Cmd, and Cmd+Option (the latter would make the most sense since that makes aliases in Finder), but no dice. Those make Scrivener links to the resource—or is that what you mean by it? The image doesn’t show up, just the name of the image with a Scrivener link to the image. If that is all you want then yes that is possible (and future-proof)—but it sounds like you are describing an actual image in the text that is being generated by an alias.
One important thing to note: As mentioned above, this trick will not work indefinitely as the file format is moving to RTF plain, which of course will have no notion of aliasing. You could try putting in a feature request (Keith will probably see it here too, though), but like I say it will be more tricky to retain whatever you are doing, if I understand what you are doing at all. RTF spec might have a way to link resources dynamically instead of embedding them, so there may be a possibility—but I couldn’t say without doing some research.
Update: I figured out what was going on and why I couldn’t replicate what you were doing. I had dragged some items into the references bar from the Binder. It turns out that you can’t create aliases from items that way, because by the time it gets to the references pane, it turns into an internal scrivener link object, not a file link object. At any rate, that I can now do what you are seeing doesn’t change that it isn’t very future proof at the moment, alas.
Well that makes no sense that you can’t replicate a control drag. I’m not doing anything special. I grab the icon in the inspector, start dragging, push down control key, the cursor changes to the alias cursor and Bob’s your uncle! If you don’t push any modifier keys or if you push the shift key, you get a green-plus cursor, and if push the command key, you get a plain cursor, but the effect is the same as if you had the green-plus cursor (a copy is made).
Unfortunately, based on your comments I tested my entire workflow, and I find that the control-dragged images don’t appear when I Compile Draft, so that is out. (Hence, I think that this control-dragging is a bug, not a feature).
Having to update the figures by hand is a real “drag”.
I now have about 100,000 questions, which I will ask in a subsequent post.
You’re right, that is a minor bug - I didn’t know you could drag in image aliases like that and it shouldn’t be allowed. I’ll disable this in 2.0, given that 2.0 saves in RTF and wouldn’t be able to store them anyway. (Image aliases are a unique feature of Apple’s RTFD format, so don’t get exported to other formats.)
For the record, I just got through fixing this for 2.0. You can now rescale images dragged in as symbolic links, and they get saved and reloaded correctly even using the new RTF format. If you export to a format such as RTF, any symbolic links get “flattened” in the exported file as embedded images. For RTFD files, which support symbolic links, you can choose whether to have them flattened or not - useful for Pages, which doesn’t support symbolically linked images but does support regular images in RTFD files. Unfortunately Pages doesn’t represent the scale of images, though. (I also added a menu item, Edit > Insert > Image Linked to File… as an alternate way of adding images.)
What all this means is that in 2.0 you can bring in an image only as a link if you choose to - it will appear as an image in the text, but won’t actually import the image itself, so you can continue to update the image on disk. Then you can have the images flattened into the compiled draft for sending on to others.
Interesting and promising, indeed. Have you ever looked into Apple’s take on “fingerprinted”, shared previews? For example, if you import/place a preview from Aperture in an application like Pages or Indesign via the “Photos”-Section listed under “Media” in the left pane of an open dialog, you will get a lightweight preview of the actual image including an UUID that is written into the image’s IPTC Special Instructions field. This enables consistent and easy workflows across applications with a possibility to link back to the original image and replace the preview at the very end of an editing process. An example of InDesign integration can be found here: macosxautomation.com/applesc … index.html
I don’t know, however, if there is a chance to maintain IPTC metadata in embedded RTF images. If yes, it would open very interesting possibilities.
The weird behaviour surrounding it though would suggest that while it may be a feature of the OS RTF engine, Scrivener might not be addressing the capability—or might not be able to. If it actually is an alias in the RTFD folder, then it could be confusing Scrivener and thus not providing ordinary image controls. I’ll play with it a bit and see what I come up with.