Strange behavior of images in LaTeX compilation

Scrivener Scrivener for macOS
1

I’m not sure if this is feedback or technical support. :smiley:

I’m writing a family memoir using Amber’s LaTeX for non fiction template. I have a relatively high density of images, I think. As far as I know I haven’t changed anything in the template since i Downloaded version 3.03 of Scrivener. My platform is a MacBook Air running High Sierra MacOS 10.13.6.

I’ve been having curious results with images since the start back in May, I thought it was all due to my running afoul of image caching, but I am not going to review those – I wasn’t keeping adequate records, anyway. But my problems have been getting worse.

In order to reduce the number of variables I copied my project file into a top level folder in my home directory, and likewise copied all my images into the same folder. One exception for the images – I had an image in the Preface called “ZahideAndJohnAtSuesWedding-2.jpg”. I apparently had imported the figure itself using the Figure Style from the LaTeX template. All the other images were put in the same folder with the project and imported using “insert->image linked to file”.

As it happens, an image with file name “SusansDanceProgram.jpg” was copied into the compiled output file, and used for all the images but one. . But it was given the file name “ZahideAndJohnAtSuesWedding-2.jpg” ! The one exception was the only figure that got into the compiled chapter correctly. For the record, there were 7 images in the preface and first chapter.

Well, here is the evidence. I will include the details for one of the 6 problem images. The others are basically the same.

Here is a shot of the editor page for the figure:

Just to be on the safe side, I checked “reveal in finder” before compiling. This is what I found:

And here is what showed up in the PDF produced by TexShop:

[img][ResultingPDF.png/img]

In the above I have erased the last names of the dancers using an app called Photoscape. This has unfortunately resulted in a compromised image, but I think you can still read the adjoining text to verify it is the same part of the document.

Finally, here is a shot of the actual LaTeX produced (taken from a rendering by MacVim):

(I see that the images themselves don’t show up in the preview, at least not on this mac.First time I’ve tried to submit images.) I will summarize here:

The images were in the same folder as the project
The Reveal in Finder showed the correct photo
The Compiled LaTeX changed the photo path to the path of a different image
The image that showed up in the PDF (and in the compilation result folder) was yet a different image. The same one was used for all but one of the 7 images in the compiled PDF

If this is my doing, I’d appreciate any advice. Otherwise there is a bug somewhere. I’m kind of obsessed with getting my project moving, so if I find a workaround or a cause, I’ll let you know. I can’t really concentrate on anything else until I get this project back on track. One thing I may try is to use the <$img:path> option for including the images.

Thanks.

John V

2

I did decide to try the <$img:path> option. Here is my code from the Scrivener editor:

\begin{figure}[h] \centering <$img:ZahideAndJohnAtSuesWedding.jpg;w=290 > \end{figure}

Here is the LaTeX output:

\begin{figure}[h] \centering \includegraphics[width=978pt,height=1024pt]{ZahideAndJohnAtSuesWedding.jpg} \end{figure}

But the Scrivener manual says:

The $img did not change the size of the image. According to Preview metadata for the image, it is in fact 978 pixels wide and 1024 pixels high. Not points. The metadata also says: 72 pixels per inch. So it comes out to a little under 14 inches wide.

I think I can continue by pre-editing my figure scale outside of Scrivener.

I will further note that:

Using the “insert → image linked to file” It does scale properly using the contextual editor. BUT, you have to press the RETURN key, just clicking on ‘OK’ button doesn’t change anything. I’ve been meaning to mention this, but simply getting the figures into my project has taken precedence in my mind.

John V.

3

After resizing the figure to a width of 290 pts using Pixelmator (remembering to save the original), I still need to include the width measurement. That is, using

<$img:ZahideAndJohnAtSuesWedding-S.jpg >

resulted in the “includegraphics” line being left out of the LaTeX produced. When I put instead

<$img:ZahideAndJohnAtSuesWedding-S.jpg;w=290 >

it worked beautifully.

I suppose I could have put any number at all in the $img line, based on my previous experience, but I used the actual width I didn’t want to test my luck.

– John V.

4

Whichever it is/was, it should have been posted in the LaTeX and MultiMarkdown forum, as should a number of other threads here on LaTeX/MMD/PanDoc issues. With the forthcoming advent of Windows v. 3, it is reasonable to expect that there may be Windows users who will encounter similar issues or look for solutions to similar requirements, but who will be unlikely to go to Technical Support (Mac) for help.

I think the “Using Scrivener with Dropbox” thread should be moved somewhere else more appropriate for Windows and iOS users too, It’s only where it is because it started when there was only Scrivener for Mac.

Ioa?

Mark

1 Edit to insert a missing word.

5

As an aside, I think the placement of this report is fine here. You don’t seem to be wishing to discuss how to use LaTeX specifically, as a technology, but reporting a potential bug or problem with Scrivener. The problems you are describing would happen no matter what template you were using it sounds like, so long as that template used the same basic building blocks the LaTeX template does.

Unfortunately none of your screenshots came through, so I’m a bit in the dark as to what is wrong with a lot of this. I’ll answer what I can.

I can’t reproduce that. Return should be the same as clicking the OK button in fact. For me the image resizes dynamically behind the panel, and the only thing that reverts the display to its original state is the Cancel button.

That aside: the route you took eventually, of resizing the graphic so that it is the correct size already, is what would be the optimum approach anyway. In general it is best to have as few things as possible touching the image file itself, particularly if they are calibrated for print. My practice in fact is to set things up so the .tex file uses the same original images Scrivener links to, meaning my use for the graphic itself in Scrivener is more as a thumbnail reference and a way to generate syntax. That is a step further than most people would need to take, granted, but the rule of thumb still holds true: if you have a graphic that is mathematically almost four times larger than it needs to be to print correctly, then the best answer is to actually change the raster to a more appropriate size, so that the physical width of the image is paired with the output density recommended by the printer (usually 300 DPI). I see people cranking the slider down in Scrivener and ending up with 2,700 DPI images—you wouldn’t even print an ultra-high quality coffee table art book with stuff like that. :slight_smile: Even 300 DPI is a very high estimate, chosen specifically because there is almost no circumstance where a printer needs that much data, but it’s always better to downsample than upsample.

Matters of graphic design and publishing aside…

Might that be a clue right here? If you are indeed including all of your images as references to files on the disk, and then one day decide to move all of the images to a different location, then all of those links will have been broken.

When using thumbnail style links, via Insert ▸ Image Linked to File…, the break will be obvious because when you next load the project you’ll get “MISSING_IMAGE” tags and no images. It’s easy to fix though, in that case, since after the warning tag the path to the image will be printed in text, meaning you can run a global search and replace to repair the paths.

But if you’re using <$img style links then Scrivener is not “aware” of any files at all until you compile. What would ordinarily happen in that case is that nothing would happen. There would be a blank line in the output where the image should appear, or a caption on its own for example. With a template like this however, where one might be assigning a style to an image in order to wrap that image in additional structure—well, you can end up with just the apparatus, like so:

[code]\begin{figure}[htbp]
\centering

\caption{Image Caption }
\label{customlabel}
\end{figure}[/code]

I can’t reproduce this result myself. To test, I created a new test project using the LaTeX Non-Fiction starter, and placed a test image in the same folder. I then pasted a few paragraphs of dummy text into the provided starter section.

Between the first and second paragraphs, I added:

<$img:test_image;w=400>

I did not include a caption or a label to keep things simple, just wrapped the line in the Figure style.

The result was expected behaviour:

\begin{figure}[htbp] \centering \includegraphics[width=401pt,height=360pt]{file_test.png}\end{figure}

And when the output image was examined in Photoshop, the metadata for it had been modified to match the above. (Yes, there is a rounding error in here—but that’s just one reason why this sort of stuff should be done in dedicated tools.)

Perhaps there is a bug that needs to be fixed, but if there is I do not see how to get to it, and will need some configuration & setup help. If you cannot reproduce the problem outside of your project, what might help me is to do similar to what I have above, and drag one binder item with an example image into an empty new project’s draft folder. Test it, and if the problem persists, close the project and zip it along with the necessary graphics, as they should be organised together, and send me a copy via PM or our tech support system, making sure to note the thread URL so whoever gets it can alert me.

6

Not a bad idea; I’ve moved it to Using Scrivener. Even folder sync is pertinent to Windows as well at this point.

P.S. I can’t stand that thread. :slight_smile: ~30 pages of mostly the same questions being asked over and over, chiefly because the previous instances of that question are buried in 30 pages of topic.

7

Thanks Amber for your reply. A couple comments here, more substance later I hope:

  • I well know that pressing the return key and clicking OK should produce the same result (when the OK button is active, anyway). I’ve had a difficult time trying to overcome the habit of clicking on the OK.

  • I’m also well aware that moving a referenced image should result in “MISSING IMAGE”. Called ‘reference’ vs ‘value’ in programming terms.

  • A more complete history is as follows:

  • I was using ‘by value’ originally. Everything worked well. But the app close times were getting excessive. Also, at the same time, my photo storage on my disk was very disorganized. So at the same time I decided to organize my files, and include images by reference. I organized my files to keep all Project images in one directory, in DropBox, with a hierarchy that included both ‘master’ and ‘edited’ in separate folders,
  • After spending hours replacing the ‘value’ images with the ‘reference’ images I started having the problems.
  • Then I moved them out of DropBox. Replaced all the references again. Still had the same problems.

  • I’ve lost track in my mind of the exact sequence, Where I ended up was with the images in the same folder with my project, at top level of my user directory. Still same problems, even using the <$img;photo; size>. I noted previously that if the size is left out, this doesn’t work.

  • I’ve made some preliminary investigation of just using native capabilities of LaTeX for reference . That is, I can use

That is a working example, in fact.

You will notice the relative path reference (…/path); You will also notice, though it may not be immediately obvious, I’m using your Caption and Label styles; I also put into my LaTeX a picwidth length, with a default, which I can of course reset per context.

  • I can readily put a special style into my project for the \includegraphics with a prefix up through the / immediately prior to the actual image name (SaiingNov75.jpt) and a post consisting only of ‘}’. That should work, I’ve had no problems with text replacement, only with image by reference :smiley: :smiley:

  • I will try to see what I can duplicate with a special test project when I get a chance, within the next day or two.

*I found that I need to include photos in the forum by reference (URL) not by value. Google photos might work, but their URLs are horrendous. Will be checking Amazon Prime Photos. It would really have been helpful for you to understand my issue, I think, If I could have sent actual images. Next time.

  • I’ll note again, my Mac is a MacBook Air, model identifier MacBookAir6,2, macOS High Sierra 10.13.6. Hope my mac hasn’t gone crazy.

And my Scrivener is 3.0.3, purchased from L&L.

Thanks again for your template and your attention to my issues.

John V.

8

So long as the overall upload is below 3mb, you can also attach screenshots. The attachment tab is found below the drafting area when writing a post. There is an option to place the attachment inline. Otherwise, yes, the [img] tag is synonymous with <img src="…"> in HTML. It would potentially take a relative reference, but only if you have server level access to place the image within the forum folder. :wink:

By the way the only behaviour I can think of that would be intentionally coded to work in a manner similar to what you describe is a space-saving technique the compiler uses where if the same image is included multiple times (regardless of link vs embed), it will do its best to only export one copy of that image and route all references to it in the output back to that one image. This behaviour will not trigger if the same image is linked in two different places and the size of the image is specified differently—in that case it will edit both to have the requested size and export them as separate files, serialising the name to avoid filesystem collisions.

So on the surface that sounds a bit like what you are describing, but it would likely take a live example for me to see how it getting to the point where completely different graphics with different names are getting treated as one duplicate image.

One other thing I thought of that you could test is to create for yourself an extremely simple compile format that uses the same tech the LaTeX format does to handle images. Here’s how I’d do it:

  1. In your main project, open Compile and in the Format sidebar create a new format.
  2. In the Markup pane, copy and paste the following into the Replace images with text field:

Filename: <$filename> Width: <$width> Height: <$height>

  1. For the sake of consistency, I would also check off Export images, since the LaTeX format uses that option.
  2. Save the format. Briefly check the project’s Replacements pane and make sure there is nothing in here that would be of impact to images. Temporarily uncheck anything that might be.
  3. Test compile (it’s fine to leave Section Layout assignments null).

We would expect the same result, but if not, the next step would be examining what is different between this simple test and the more complex LaTeX compile format.

(And yes, by the way, if you do want to have your .tex file reference the same original graphics that Scrivener is using, disabling that Export images option in your main format would be the trick for doing so. It may speed up compile as well, and certainly save disk space.)

9

I just noticed this one:

If you mean that literally, then yes that would fail to work since the name of the file you are requesting is “ZahideAndJohnAtSuesWedding-S.jpg ”, with a space after the extension.

It started working after you put a size in, because now the space is moved into the image width request. But of course “290 ” is an invalid number and so it fails to work, which is why you never got sizing to work with placeholders.

If you look at my working examples, there are no spaces in the brackets like that.