Graham Percival wrote:
On Thu, Aug 06, 2009 at 12:12:59AM +0100, Ian Hulin wrote:
This is AU section 3.2.1
------
If ‘filename.ly’ contains more than one \score block, then the rest of the
scores will be output in numbered files, starting with ‘filename-1.pdf’.
------
This is a regression: you need to use \book instead of \score for the
compilation to produce two files.
E.g.
#(define output-suffix "violin")
\book { … }
#(define output-suffix "cello")
\book { … }
Good catch! Personally, I'm ok with the current program behavior.
I'd be happy to adjust the docs to reflect the "1 pdf per \book"
behavior.
Does anybody object to this? i.e. should this be considered a
program regression bug and changed, rather than simply adjusting
the docs to match the current behavior?
Errrm, sort of, because I found this while I was having a look at some
low-level trackers (714 and 404) about output-file naming.
You're right:
o there's a one-to-one relationship between \book blocks and the
output graphical back-end files.
o if there's no \book block in a file, lilypond assumes there is one,
so conceptually
lilypond-source-file :== {book-block, [book-block...]}
o each \book produces one copy of whatever graphical back-end file
the user has asked for .pfd, .svg, .png, whatever.
HOWEVER
o each \score block (which lily also puts in if there isn't one), in
conjunction with a \midi block will produce a .mid/.midi file.
o a \book block or source-file without a \book can legally contain
more than one \score block.
==> There's a one-to-many relationship between source-files/book
blocks and resulting midi files.
In this case the resulting .mid from the last \score block would
overwrite the previous \score block's efforts because they were all
using the same filename.
o the output-count and output-suffix parser variables were introduced
to prevent this. Using output-suffix used to produce unwanted
output-count suffix to the filename, even when the output-suffix had
just been changed.
I have a patch with changes to lily-library.scm which Marek Klein
prototyped which fixes the problem described in the last bullet-point,
but it needs a little more work to split the file-name handling stuff
into a seperate Scheme function.
I'd like to submit a patch as the first stage of work on 714/404, and
then would like to see about putting in a true lilypond language
interface to this rather than having to drop into Scheme to set the
value for output-suffix.
For the moment changing the docs looks like the way to go, but I'd like
output-suffix to appear in the index eventually.
Sorry if this is noise, but I'm still very aware I'm swimming around in
the shallow end of the bug-fixing pool here.
Cheers,
Ian
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel