Out on a limb with Scrivener+LaTeX

[scrive]

After several years of research, and then writing in Scrivener, followed by typesetting with Latex (LuaLaTeX actually), I’ve arrived at the initial stages of proofreading my document.

I’ve realized that, out of the hundreds of images in my Scrivener project, some of the images simply contain too much detail. Those images call for an option to expand the image to essentially full screen to allow the reader to browse in more detail. To streamline the readers experience, my thought is to give the user the option to view a single expanded image, separate and apart, but from within my multi-hundred page PDF document, w/o having to expand their view of the entire MAIN.pdf PDF document.

The option I have selected to do so requires that I typeset the full screen version of those single images as separate .tex files, apart from my MAIN.tex Scrivener project file.

This is understandably a unique requirement from what the vast majority of Scrivener users need to do, most of whom never touch LaTeX code. But for those who do so, I’d like to hear if anyone else has had any success in typesetting separate LaTeX .tex files within their MAIN Scrivener application to create full page .pdf images separate and apart from their MAIN.pdf file.

I’ve not made much progress on how I might structure the arara code within my TeXShop typesetting window, except to say that I tried adopting the following line of code which did not work out:

% arara: lualatex: { files: [ …/AUXfiles/OILvsCOAL/OILvsCOAL.tex, …/AUXfiles/PetroForm/PetroForm.tex ], synctex: on, shell: yes }

Any thoughts on how to typeset the above sample OILvsCOAL.tex and PetroForm.tex files separate and apart from my MAIN.tex Scrivener file to create corresponding (but separate) OILvsCOAL.pdf and PetroForm.pdf PDF files respectively, separate and apart from my MAIN.pdf file, would be appreciated.

FWIIW, I realize that what I am trying to do may simply not be possible within the Scrivener framework.

Thanks for reading,
scrive

[AmberV]

To look at this from another angle, as these represent special full-page illustrations, not part of the main PDF, are they really going to be changing from one compile to the next? Wouldn’t it be sufficient to generate the PDFs from them, and then just leave it be? Sure, if you need to make a revision then you rebuild it, but I don’t see why the entire compile loop would need to be involved with that since these are all external files.

[nontroppo]

Why do they need to be a separate PDF file? You should be able to resize a PDF page within document, so you could have a larger figure page than your usual text page:

\documentclass{article}
\usepackage{typearea}  % loaded automatically if using KOMA-Script class
\begin{document}

Some Text here.

\KOMAoptions{paper=a3}
\recalctypearea

A figure here.

\KOMAoptions{paper=a4}
\recalctypearea

Some Text here.

\end{document}

You could use a Scrivener section type or even style to inject this. The example I found relies on the typearea package (CTAN: Package typearea – I tested this code with LuaLaTeX), but as usual for LaTeX there are multiple solutions, hacks and workarounds.

If it has to be separate PDF files then (apart from some custom post-processing script which could cut main.tex up based on some tags and run several repeat runs of latexmk), doing this manually is the best route. To be honest you do not need LaTeX just to make a PDF from a figure, many GUI apps can do this, as could several other command-line tools?

[scrive]

Hi AmberV,

Thank you for your note.

You are correct in your assessment given the information I did not include in my initial post. The intent was to not completely confuse anyone reading my post as far too complex, without loosing anyone brave enough to read through my post. My bad.

The information I omitted included the round-trip nature of the switching to view the larger PDF images, with the option for the user to click on an icon within the larger PDF image to return back to the MAIN.pdf (which itself is not the real name of my main PDF file). On top of that, I anticipate that there may be many dozens of the larger PDF images that I would like to allow the user to select to inspect for details, then be able to switch back into the Scrivener+LaTeX MAIN.pdf file.

One other item I did not mention is the serial sequence of Scrivener versions I have developed during my years of development. My lack of familiarity and insight into the development tools available for LaTeX (or LuaLaTeX) have taught me that I needed to have complete, compilable, and error-free copies of earlier versions of my Scrivener+LaTeX projects available whenever I was presented with a new LaTeX error that is too cryptic to discern (sometimes saving me the better part of a week of coding that would otherwise have been lost). This required my providing each version of my Scrivener+LaTeX project file with a unique, sequential name that I could return to at a moments notice.

(I was fortunate to have the disk space to accommodate such a backup system.)

This brings me back to my desire to provide a round-trip option for the user to switch to view the larger PDF images, then to return to the MAIN.pdf file. Each time I create a new version of my Scrivener+LaTeX project file with it’s own unique version number, that new version number would also need to be detailed in the .tex code for each of the larger PDF images for the reader to view. This would require that each of the .tex files for the larger PDF images needed to contain (in the .tex code) the new version number of my Scrivener+LaTeX project file if I am to allow the user to return to the MAIN.pdf file after they have finished viewing the larger PDF image they are interested in.

Understandably, this quickly became somewhat complex, which is the reason why I did not mention it in my original post. I knew that it would be a challenge for anyone to provide any suggestions had I included all these details from the start.

At the start of my journey to provide this ability to the user, I experienced several file sharing errors whenever I attempted to access the larger PDF images that were included within my MAIN Scrivener+LaTeX build. Creating separate PDF images apart from the MAIN.pdf file appeared to circumvent the file sharing errors, so I continued along that line of development. That may have been a mistake. Time will tell.

As such, that brings me to nontroppo’s suggestion (See subsequent message) to use the typearea LaTeX package with KOMAoptions as a way to include the larger PDF images within my MAIN.tex, and subsequent, MAIN.pdf file. This could simplify my implementation of what it is I am trying to do with the larger PDF images within the Scrivener+LaTeX project enormously.

Thank you nontroppo. Implementation may be relatively quick, or it may take me some time to complete, but I am grateful for the research you did toward this as a solution. Thank you again.

Life has a way of intruding, so it may be some time b4 I am able to discern how this will go. My project includes well over a hundred LaTeX packages, so there may be some inappropriate crosstalk between the packages that I won’t be able to discern until I integrate all the packages together.

Thank you both, AmberV and nontroppo, for your questions and ideas. I will get back to you.

Thanks again,
scrive

[nontroppo]

@scrive

Creating separate PDF images apart from the MAIN.pdf file appeared to circumvent the file sharing errors, so I continued along that line of development. That may have been a mistake. Time will tell.

One worry I have is that it may work on your machine, but not for your readers. Links to external files are often absolute links, i.e. they depend on the user name etc. Now I am only mentioning this hypothetically, I don’t know how you are providing links and how those end up in the LaTeX PDF outputs.

If typearea has some sort of incompatibility with another package you use, there are several other packages that may do something similar, the good and the bad of LaTeX: cryptic error messages and baroque complexity counterbalanced with the fact someone has probably already solved your problem somewhere online or in a package…

[nontroppo]

@nontroppo

One worry I have is that it may work on your machine, but not for your readers.

I did just quickly test this, making a generic TeX file with relative links like \href{res.pdf}{test pdf link to local file} and at least for me if i move the resultant PDF and the linked PDF to another folder, the link still works which makes me assume relative links are preserved by href out to a PDF. Still it requires a user must keep multiple files in the same relative order you shared them…