Exporting to latex folder issue and multiple citations

Scrivener Markdown & LaTeX
1

Hello everyone :slight_smile:

I have two questions concerning latex/multimarkdown.

  1. I am trying to reference more than one sources next to each other like that:

document text [][#BarrettTradeWinds][][#BarrettKraftfelt]

but it just gets one of them in this weird output ([1] is the the only correct part):

document text [][1][#BarrettKraftfelt].

  1. I was fine working in my document, exporting it in the folder for latex in which it was replaced and automatically updated in TextMate ready to compile. All that until I had my first figure/image. Now every time I export a new folder is created in which I have to manually move my .bib file, navigate in and open the TextMate file to compile. Isn’t there a way to export the relevant files in a chosen folder replacing only the tex file and the images?

Best

Dionysis

2

I think you have the syntax backwards. The shorthand syntax I always use is [b][reference][][/b], not [b][][reference][/b]. That would perhaps explain why the ‘1’ gets placed as it does.

This has been much improved in 2.0. The problem you are experiencing is that Scrivener doesn’t correctly use the old directory and will create a serial-numbered directory even if you tell it to “overwrite” in the compile dialogue. The only hitch is, the folder itself will still be overwritten. It’s just that since it gets overwritten in place, TextMate picks up the changed file automatically so when you switch back to TM, you can hit Cmd-R and immediately see your compile changes.

The downside is that because the folder refreshes completely, any auxiliary material you place into it will be wiped out every time you compile. It’s the folder you are replacing when you confirm, not just the .tex file. What I do is compile into a folder that has all of the auxiliary stuff in it. Like:

Working/Project/ files_I_need.sty compile_folder.tex/ compiled_file.tex included_images.jpg

After compiling to ‘compile_folder.tex’, I drag in the stuff I need and then switch to TM and hit Cmd-R. So perhaps jot down that workflow so when you have 2.0 in your hands, you can make use of it.

3

Thanks once again AmberV :slight_smile:

You were right about the citations! Works perfectly now!
As for the second part, I will be patiently waiting for the upgrade
 :slight_smile:

All the Best

Dionysis

4

Hello, I am new to Scrivener (playing with it for two days now).

I would like to chime in on the discussion about the way Scrivener creates the extra folder when images are included.

My particular use case is the following: I am intending to use Scrivener for writing research papers. The publishers usually provide their own LaTeX document classes and a main tex file which uses this particular class.

Now my plan was to write the content of my paper in Scrivener, export to LaTeX using the latex-snippet.xslt stylesheet and include the result in my main tex file using the \include directive.

This works perfectly well until I insert images into my text and Scrivener puts the compilation result into an additional folder.

I could move my main.tex file into that folder, but as the complete folder gets deleted and recreated every time I recompile, I would have to do that over and over again, which I find a bit cumbersome.

Leaving my main.tex file in the parent folder and adjusting the path in the include directive to point to the tex file inside the folder produced by Scrivener isn’t an option either, because this would break all relative paths in the included tex file (e.g. the paths to the images residing in the same folder) as the LaTeX compiler considers all relative paths to be relative to the parent folder of the main file, not the included file.

I would really appreciate if there was an option to omit the creation of the extra folder and have Scrivener dump everything directly into the target folder, as it would if there were no images. Alternatively, do not overwrite the entire folder at compilation time but only replace the recompiled tex file.

Thank you for an otherwise amazing piece of software!

Cheers, Ralph

5

So you are compiling into a static support folder with class files and other such, right, and you get a “something.tex” folder? Have you tried symlinking? Since symbolic links are ignorant of whether or not their target actually exists, or if the file actually changes behind their back, you can set one up in the support folder, pointing to ./something.tex/something.tex.

6

Thanks for the quick reply.

Right.

Good idea. I would have to create a symlink to every image file, but still better than having to move things around after every recompilation.

Anyhow, I ended up writing an Applescript that moves all the files where I want them. I attached the script to a folder action so that it runs automatically after each compilation. The script also opens the tex files in TeXShop for review, launches pdflatex and opens the resulting pdf file in Skim.

In the end, I have spent a litte more time than I wanted, but I achieved a more than satisfactory level of automation.

The next days will show how well the script performs in practice. If everything is fine, I will happily put the script online.

Thanks,
Ralph

7

That’s true, though you can solve the image location problem by adjusting the LaTeX accordingly. I don’t actually use the images that Scrivener produces when compiling, so that aspect isn’t a problem for me. My setup for the user manual looks like this:

mbw/
mc/
wbw/
wc/
latex/
    (all .sty files and such)
    compile.tex/
    user_manual.tex -> (symlink to above and .tex folder inside)

All right, so the four cryptic folders at the top house my graphics. Mac-Black and White, Mac-Colour, Windows-Black and White, Windows-Colour. Depending on which user manual I’m compiling, I need different screenshots. Plus screenshots tend to change a lot, so using the embedded ones that Scrivener creates is way more trouble than it is worth—not to mention you can only have one, and not one out of four depending on compile mode, without a bunch of monkeying around with content filters and breaking sections apart wherever a screenshot appears.

The secret sauce is in the LaTeX preamble:

\graphicspath{{../MMD_VAR_PRINTMODE/}}

The all-caps in the middle comes from a custom MMD meta-data field, “PrintMode”, which I set to ‘mbw’, ‘mc’ or whatever according to the current version output. So in the actual output, I’ll get something like:

\graphicspath{{../mc/}}

The key thing here is that this LaTeX command enforces this as a prefix to any included graphics in the document. So while Scrivener+MMD produces something like:

\includegraphics{some_screenshot.png}

What actually gets used by the LaTeX typesetting engine is:

\includegraphics{../mc/some_screenshot.png}

And suddenly my directory structure above makes sense. All I’m using from Scrivener is the name of the screenshot figure itself and the caption that it generates, the actual graphic being used is located one folder up and in one of the specialised print mode folders. All I need to do is change one small MMD meta-data field, and every single graphic in the compiled document suddenly switches from Mac to Windows (other things happen as well, such as different page layouts for the B&W versions, which aren’t used yet, but when we start selling hard copies of this thing, that will be what I use).

I can get away with this because whenever I add a screenshot, I create the four variations and put them into these folders and then drop a “placeholder” into the Scrivener project. I don’t ever rely on the placeholder to do anything except generate the appropriate syntax in the correct location of the .tex file.

All of this is probably a lot more complicated than what you need, but the same principle could be applied. You could set the graphics path to the compile folder so that even though you are typesetting from one folder up, they would be correctly included in the dynamic compile folder. All of that would give you a system whereby you can completely ignore the scrivener_generated.tex/ folder contents itself. All you would ever be interfacing with is the symlinked .tex file, and it would be interfacing with the compile folder via the graphicspath prefix, pointing to compile.tex/image_name.png.

8

I have come up with a compromise for this situation.

I don’t want to abandon the current way of doing things - if Scrivener doesn’t create a folder to hold the files when images are involved, there is the possibility that the export could overwrite files without the user knowing. For instance, suppose the user drags a large image into Scrivener and resizes it, and then exports to the same folder in which the original image was contained - if Scrivener didn’t create a folder to store the MMD and images files, the smaller, resized image file could end up overwriting the original, without the user knowing (or there would need to be extra annoying “Confirm” messages).

Thus, I want to keep the folder solution to avoid this situation. However, I do see that this is annoying if you want to store other files in the folder, and for this reason I have come up with what I hope is an agreeable solution: as of 2.1, if the folder into which you are exporting has a title ending in “-mmd”, “_mmd”, or “.mmd”, Scrivener will not create a subfolder within it but will instead export all the files into that folder directly. This should prevent casual users from ever overwriting files accidentally, but should at the same time make it easy to get the behaviour you want when you need it - just add “-mmd” to the end of the name of the enclosing folder and Scrivener will take that as a cue to adopt the behaviour you are after.

As I say, this will be in 2.1, but a beta should be available on the “Beta Testing” forum in the next day or two.

Hope that helps.

All the best,
Keith

9

AmberV, you’ve made my day. I’ve been googling myself to death in order to find a latex command that adjusts the base path for all includes. All I could find was the TEXINPUTS environment variable that adjusts the search paths globally, which I didn’t want.

The graphicspath command does all what I need, and it works like a charm.

Thanks a lot!

Keith, that would be an optimal solution.

The more I use Scrivener, the more I love it. Besides being a great piece of software in itself, it’s the vivid community and a developer answering to his users’ requests that make Scrivener an outstanding product.

Thank you very much!

Cheers, Ralph

10

You’re welcome! I was quite thrilled when I came across it as well. :slight_smile: Saved mucking about with XSLT and changing the graphic inclusion code itself.