Re: Issue 2343 in lilypond: Faulty file-naming when outputting multiple \books

[David Kastrup]

Ian Hulin <address@hidden> writes:

> However, if we are going to make manipulating the output filename
> exposed to the LilyPond UI in a \<block> declaration like \paper,
> \layout or \header then I object violently to using the \paper block.
>
> \bookOutputFilename and \bookOutputSuffix affect all types of file
> produced by a LilyPond backend.  They have a \book prefix because a
> \book block (either explicit or implicit) is the entity which determines
> a single back-end output unit from a LilyPond compilation.
>
> If you intend to allow users to declare a block which affects all output
> files then we need to bite the design bullet and put this stuff in its
> own block, how about
>
> \book {\output { file-suffix="foo" } ... }
> or
> \book {\output { file-name="bar" } ... }
> ?

I think it would be a rather bad idea to have an output definition
called \output.  People would not understand that \layout, \midi, and
\header are output definitions as well.

Books don't _have_ midi or layout blocks.  All midi parameters are set
globally.  The midi filename still is taken identical with the paper
output filename.  Not terribly consistent, but convenient.

The paper block basically is what records book-specific parameters.

> My instinct is to deprecate the use of the output-suffix global Scheme
> variable, keep the \bookOutputName and \bookOutputSuffix functions,
> and implement the new \output block with the new variable names.
>
> Also document that the new \output block variables affect the output
> for the current \book block, but if they are absent then the defaults
> are applied, i.e. a decimal version number counter is generated for
> output-suffix, and the output-name is the basefilename part of current
> input file.  Document, too that you can't play with these variables
> reliably using \set or \override.

I don't get at all why you are talking \set or \override here.  Those
are used for manipulating context properties, and the output filenames
never had anything at all to do with contexts as far as I can tell.
"you can't play with these variables reliably using \set or \override"
is about as meaningful as saying "you can't play with these variables
reliably using \clef and \markup".

> WDYT?

I am not saying that I consider using \paper variables particularly
beautiful.  But since that considers the naming of the PDF files, I
don't consider it unfitting either.  It would be a possibility to make
the filenames an integral part of a Book, in which case you would need
separate setter and getter functions.  I don't really see the point with
that.  The paper block is what we have in the line of book-specific
data.  That's reasonably straightforward.

-- 
David Kastrup