[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [frogs] Regression in docs: Output-suffix does not work as documen

From: Ian Hulin
Subject: Re: [frogs] Regression in docs: Output-suffix does not work as documented in AU 3.2.1
Date: Thu, 06 Aug 2009 12:22:52 +0100
User-agent: Thunderbird (X11/20090608)

Graham Percival wrote:
On Thu, Aug 06, 2009 at 12:12:59AM +0100, Ian Hulin wrote:
This is AU section 3.2.1
If ‘’ 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.

    #(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"

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.
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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]