I did a search but only found threads related to very old versions of Scrivener for Windows, before V3.0, when the img tag wasn’t supported yet.
I have manuscripts with images including the full path using commands such as <$img:/path/picture.jpg> that work fine when compiled in the Mac version.
The images are inserted correctly.
However, when compiled into the PC version, the images are not compiled. Given that the use of these tag is now documented in the PC version help and manual, I assume that it is supported now.
I tried to use a direct path as simple as possible (d:/picture.jpg) but that doesn’t help.
Is there any global option that could prevent these images from being compiled in the PC version?
I tried using a default compile format, it doesn’t help.
In case it matters, the images are on the same drive as the project, so there should only be a need for a path, not a drive, which hopefully will make the same path compatible both for Mac and PC compilers.
Thanks, but you missed that I tried with a path specifying the drive (it’s the first thing that came to mind), it doesn’t help.
There doesn’t seem to be a way to get the software to compile the image, even with a full path including the drive.
As I said, I tried this:
I tried to use a direct path as simple as possible (d:/picture.jpg) but that doesn’t help.
Have you tried using D:\picture.jpg, as that would be the correct way to print a path?
It does need a full path, regardless of where the project is in relation to the images. You would need to able to copy and paste the text into File Explorer’s address bar and get a valid result.
Okay, just checking, since d:/picture.jpg does not equal D:\picture.jpg.
The only thing I can think of, if the path is correct, is that the image isn’t right in some way. Maybe it is a PNG with a .jpg extension for example.
If you can’t get it working, you can also use File ▸ Import ▸ Research Files as Shortcuts..., to bring a link to the image into the binder, and then refer to it by name in the image tag. So if we call it “picture” in the binder, then all you need is <$img:picture>.
Thanks, I changed it with D:\image.JPG and that works, so the manual is incorrect (it uses the same format as the Mac path description)
I’ll try to see if I can deal with this using replacements.
Yes, replacing the Mac paths by a PC path in the compile options works fine. Thanks! You might want to correct the manual and placeholders help section for the PC version.
Could you point me to where it is incorrect? The example I give under Image Identification is:
<$img:E:\MyThesis\python_chart.jpg>
Replacements are one way to handle cross-platform usage, another is styled text, where you have say a Mac-Only and a Win-Only character style. You can then set each respective platform’s compile Format to delete the text associated with the other platform’s style. You should be able to have both paths in the same placeholder tag, rather than two tags entirely (one invisible to the other):
But, if all of your images are in the same place, and thus you’ll always want the path to be the same save for when switching systems, replacements are more than sufficient. Something like “@@@picture.jpg” where the @@@ gets turned into whatever is needed.
You are correct, the examples are right in the manual, it’s only in the placeholder list (help / list all placeholders, that opens scrivener-placeholders.pdf) that the path is wrong. The examples are:
That’s where I looked first, and I didn’t notice the change in the manual when I looked because I was only checking that the tag was supported.
I should have thought of the forward slash issue given that I started computing with a ZX81, way before my first MS-DOS PC, but frankly I don’t use paths regularly, except in the GUI… That and the fact that html paths are like the Mac, so I tend to forget the PC way…
Anway, thanks again for your help. Yes I have a couple of paths per volume, all the pictures are in one of two folders, so I only need to add these paths as global replacements only on the PC software and that works fine, both for the ebook and PDF compile.
