Re: Make TOC entries available to LaTeX

[Thomas Morley]

2018-04-25 16:00 GMT+02:00 Urs Liska <address@hidden>:
> Hi Harm
>
>
> Am 19.04.2018 um 23:23 schrieb Thomas Morley:
>
> 2018-04-19 16:19 GMT+02:00 Urs Liska <address@hidden>:
>
> Hi all,
>
> I'm preparing an automated edition process using LuaLaTeX, Pandoc and
> LilyPond.
>
> After some experimentation I have come to the conclusion that I'll have to
> insert the multi-movement score as a single PDF created by LilyPond (but
> through lyluatex to make use of caching and the layout mechanics).
>
> I first had used lyluatex's facility to include the score's system by system
> and print all the titles with LaTeX, but this didn't work out - for the
> first time I realized that lilypond-book-preamble.ly makes the vertical
> staff-staff spacing as tight as possible, which often makes the page layout
> pretty bad. Creating the movements separately is not an option either
> because not all movements will start on a new page.
>
> So now I have included a multi-movement score in the LaTeX document and
> don't know how to add TOC entries (in LaTeX) for the movements. I can see
> two possible ways, but don't know if they are really possible and if so how
> to approach them:
>
> Is it possible to insert something in the PDF output that LaTeX can pick up
> as TOC entries?
> (actually I doubt this is possible, but since it would be the easiest way I
> thought I'd ask anyway)
> Can I reliably retrieve the current page number of a given score's title
> block?
> With that information I could write them to a log file and read that later
> in LaTeX.
>
> TIA
> Urs
>
> PS: I don't know if it matters but the file is produced using
> ly:book-process etc.
>
>
> Doesn't
> http://lilypond.org/doc/v2.19/Documentation/usage-big-page#sharing-the-table-of-contents
> do what you want?
>
>
> Thank you, yes, this is what I needed, and finally I got the time to make it
> work.
> I must admit I wouldn't have thought about looking in the *usage* manual for
> that information.
>
> On closer inspection of the code I have some questions about it.

I'll try to answer ...

> %%%
> #(define (oly:create-toc-file layout pages)
>   (let* ((label-table (ly:output-def-lookup layout 'label-page-table)))
>     (if (not (null? label-table))
>       (let* ((format-line (lambda (toc-item)
>              (let* ((label (car toc-item))
>                     (text  (caddr toc-item))
>                     (label-page (and (list? label-table)
>                                      (assoc label label-table)))
>                     (page (and label-page (cdr label-page))))
>                (format #f "~a, section, 1, {~a}, ~a" page text label))))
>              (formatted-toc-items (map format-line (toc-items)))
>              (whole-string (string-join formatted-toc-items ",\n"))
>              (output-name (ly:parser-output-name))
>              (outfilename (format "~a.toc" output-name))
>              (outfile (open-output-file outfilename)))
>         (if (output-port? outfile)
>             (display whole-string outfile)
>             (ly:warning (_ "Unable to open output file ~a for the TOC
> information") outfilename))
>         (close-output-port outfile)))))
>
> \paper {
>   #(define (page-post-process layout pages) (oly:create-toc-file layout
> pages))
> }
> %%%
>
> 1)
> If I see correctly the inner let* will only be evaluated if
> 'label-page-table has successfully been found and is not empty.
> If this object is not found or if there are no TOC entries in the file
> label-table will be an empty list, right?
> If that's true the (and (list? label-table) ... is redundant, isn't it?

Yep.

> 2)
> Assuming the TOC items are created using \tocItem then it should be
> guaranteed that there is the same label present as key in both label-table
> and one of the (toc-items) sublists. So (IISC) several further checks could
> be removed additionally (or am I missing something?):
>
>              (let* ((label (car toc-item))
>                     (text  (caddr toc-item))
>                     (page (assoc-ref label-table label)))
>
> should be sufficient? Therefore the whole function could be written as

Being always paranoid, I would do some thorough testings.

> #(define (oly:create-toc-file layout pages)
>   (let* ((label-table (ly:output-def-lookup layout 'label-page-table)))
>     (if (not (null? label-table))
>       (let* ((format-line (lambda (toc-item)
>              (let* ((label (car toc-item))
>                     (text  (caddr toc-item))
>                     (page (assoc-ref label-table label)))
>                (format #f "~a, section, 1, {~a}, ~a" page text label))))
>              (formatted-toc-items (map format-line (toc-items)))
>              (whole-string (string-join formatted-toc-items ",\n"))
>              (output-name (ly:parser-output-name))
>              (outfilename (format "~a.toc" output-name))
>              (outfile (open-output-file outfilename)))
>         (if (output-port? outfile)
>             (display whole-string outfile)
>             (ly:warning (_ "Unable to open output file ~a for the TOC
> information") outfilename))
>         (close-output-port outfile)))))
>
> 3)
> I think the inclusion in the TeX TOC can (now?) be done in a simpler way
> using the catchfile package:
>
> \documentclass{article}
> \usepackage{pdfpages,catchfile}
> \newcommand\includelilypond[1]{%
>   \begingroup
>     \CatchFileDef\currentlilypondtoc{#1.toc}{}
>
> \edef\x{\noexpand\includepdf[pages=-,addtotoc={\currentlilypondtoc}]{#1.pdf}}
>   \expandafter\endgroup\x
> }
> \begin{document}
> \tableofcontents
> \includelilypond{test}
> \end{document}
>
>
> (Answer from
> https://tex.stackexchange.com/questions/428239/merge-in-manual-toc-entries-in-a-lualatex-document)
>
> There's only one issue: The TOC will create wrong entries when LilyPond's
> first page number is not 1. So there should actually be an offset in place.
> How can I read the value of the first-page-number variable to set up this
> offset?

page-post-process has the layout-variable.
(ly:output-def-lookup layout 'first-page-number) should do the trick.

>
> Best
> Urs
>

HTH,
  Harm