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

[Ian Hulin]

On 26/02/12 18:51, address@hidden wrote:
> 
> Comment #10 on issue 2343 by address@hidden: Faulty file-naming when 
> outputting multiple \books 
> http://code.google.com/p/lilypond/issues/detail?id=2343
> 
> Ian, the patch does not change the use of "output-suffix".  As long
> as you don't declare a book specific suffix with \bookOutputSuffix
> (or an assignment to book-outputsuffix or book-filename in a \paper
> block), the old usage will work as before.
> 
\bookOutputSuffix was intended to replace output-suffix, which was
secret-squirrel Scheme stuff and undocumented.  I reckon this could be
deprecated.
> Would it make sense to use the paper variables output-suffix and,
> uh, output-filename instead? Looks redundant to have "book-" in
> the variable name, and, after all, there seems little wrong with
> just declaring \book { \paper { outputsuffix = "xxx" } }
It's OK you hiding the variables in a paper block for use by
\bookOutputFilename and \bookOutputSuffix so they DTRT as far as the
OP's complaint goes.

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" } ... }
?

If we do this, we are far closer to implementing what users requested
in the original Enhancement Request for configurable output file names.

I got side-tracked during the original implementation by thinking of
these (wrongly) as properties. This raises questions of \set vs
\override, and also caused other developers to ask the question of
what these "properties" had to do with translating source-code to
notation, and of course the answer is absolutely zilch.

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.

WDYT?

BTW, a lot of my test files for this contain use of extended Latin
characters like č þ æ ß ř ů etc. in output file-names and suffixes.
These used to cause problems for some of the back-ends, like GS.

Cheers,

Ian