Re: [frogs] Regression in docs: Output-suffix does not work as documented in AU 3.2.1

[Ian Hulin <ian@xxxxxxxxxxxx>]

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


---

----
Join the Frogs!