[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
managing large documents with many snippets
From: |
Dan McMahill |
Subject: |
managing large documents with many snippets |
Date: |
Thu, 22 Oct 2020 18:11:00 -0400 |
User-agent: |
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 |
Hello,
I'm trying to sort out what will be the best flow for me to type up what
may grow into a fairly large LaTeX based document that has lots of
musical snippets from lilypond. Apologies for the long email that follows.
The normal way I might handle a large document in LaTeX is to have a top
level file, top.tex, that has some header stuff (possibly \input{} from
a standard header) and then lots of lines like:
\include{chapter1}
\include{chapter2}
\include{chapter3}
etc.
and each chapter (or major section) is in its own file to try to keep
things manageable and have flexibility for reorganization.
I've also done things like have a few varieties of the top level file
that have slightly different include lists or just set some conditionals
as a way of producing variations of a document. Examples may be company
internal vs external or customer A versus customer B or other things of
this nature.
In addition, I have often had reason to include many drawings created by
an external tool like tgif. I manage these large documents using make
and some pre-defined make rules that I include (latex-mk.sf.net). This
lets me do things like identify a list of directories that may have
figures that need exporting to postscript. So I might have a directory
structure like:
top.tex
chapter1.tex
chapter1_figures/
fig1.obj
fig2.obj
chapter2.tex
chapter2_figures/
fig1.obj
fig2.obj
fig3.obj
The make rules capture all the dependencies so if I edit the source file
for a figure, chapter2_figures/fig3.obj for example, the right commands
to re-export to encapsulated postscript are run and LaTeX is re-run
along with whatever invocations of bibtex or others may be needed. I
get to focus more on writing and drawing and the build system handles
all the mechanics of building and remembering stuff like "oh, I edited
this drawing, don't forget to export it again" and also I'm not wasting
time while my computer processes files that didn't change since last time.
As I think about documents that may make heavy use of lilypond, I'm
trying to now think about how to structure things and what flow will
feel good. One approach is I do exactly the same as before and
introduce suffix rules to convert .ly to .eps by way of running
something like:
lilypond \
-dbackend=eps \
-dno-gs-load-fonts \
-dinclude-eps-fonts \
--eps \
-I my_standard_header_location \
snippet1.ly
and proceed with importing into LaTeX with things like:
\begin{figure}[htbp]
\centering
\includegraphics{major_scales/snippet1.eps}
\caption{Major Scale}
\label{fig:major_scale}
\end{figure}
although I might turn that into a macro to make it shorter to type.
This seems doomed for headaches/failures if I ever hit something where
the music exceeds one page and it will start to look bad before then.
Plus, I do like the ability to embed short snippets directly inline.
I've looked some at lilypond-book and am having troubles seeing how it
would cleanly fit into a large project flow. Picture a dozen chapters
and hundreds of snippets. It appears that lilypond-book does a nice job
of dealing with snippets that are many musical lines long or even pages
long and so that seems pretty important. Not to mention, it handles
embedded lilypond.
When I try something like using a top level top.lytex with both
\begin{lilypond} .. \end{lilypond} as well as \lilypondfile{} I can run:
lilypond-book -f latex -o top_build top.lytex
(using -o to avoid really polluting my top level directory). However,
it looks like I have to then run latex within the top_build directory or
the includes in the generated files don't work. But I also found that
if top.lytex has stuff like:
\include{chapter1}
then lilypond-book doesn't follow those includes so something like
\lilypondfile{} in chapter1.tex doesn't work. So then I looked at doing
something like making the top level be pure latex with no lilypond and
running lilypond-book on individual chapters
top.tex:
\documentclass{article}
\usepackage{graphics}
\begin{document}
\include{ch1/ch1}
\include{ch2/ch2}
\include{ch3/ch3}
\end{document}
then per-chapter files with embedded lilypond stuff:
ch1.lytex
ch2.lytex
ch3.lytex
run
lilypond-book -f latex -o ch1 ch1.lytex
lilypond-book -f latex -o ch2 ch2.lytex
lilypond-book -f latex -o ch3 ch3.lytex
latex top.tex
but again I end up with a search path problem:
$ latex top.tex
This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020/Cygwin)
(preloaded format=latex)
restricted \write18 enabled.
entering extended mode
(./top.tex
LaTeX2e <2020-02-02> patch level 5
L3 programming layer <2020-03-06>
(/usr/share/texmf-dist/tex/latex/base/article.cls
Document Class: article 2019/12/20 v1.4l Standard LaTeX document class
(/usr/share/texmf-dist/tex/latex/base/size10.clo))
(/usr/share/texmf-dist/tex/latex/l3backend/l3backend-dvips.def) (./top.aux
No file ch1/ch1.aux.
) [1] (./ch1/ch1.tex
! LaTeX Error: File `00/lily-8028fbc5-systems.tex' not found.
Type X to quit or <RETURN> to proceed,
or enter new name. (Default extension: tex)
Enter file name:
So it seems like if I had a better way to control search paths that
maybe this approach would work. I actually wonder if the easiest
approach is to teach lilypond-book to add the output directory to all of
the includes in the generated files so the generated ch1/ch1.tex would have
\input{ch1/00/lily-8028fbc5-systems}
instead of
\input{00/lily-8028fbc5-systems}
and a similar thing for the generated \includegraphics{} lines.
Before I dig into the python code for lilypond-book and add an option to
include that extra directory path in the inputs/includes, does anyone
have suggestions for other ways that may be better? Perhaps I'm
misusing lilypond-book and a good solution already exists.
Thanks so much.
-Dan
- managing large documents with many snippets,
Dan McMahill <=