lilypond-devel
[Top][All Lists]
Advanced

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

Patching the output file naming code (Was: thanks to whomever put this i


From: Reinhold Kainhofer
Subject: Patching the output file naming code (Was: thanks to whomever put this in the LSR...)
Date: Wed, 10 Jun 2009 19:17:12 +0200
User-agent: KMail/1.11.3 (Linux/2.6.28-11-generic; KDE/4.2.3; i686; ; )

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Dienstag, 9. Juni 2009 23:29:34 schrieb Ian Hulin:
> Hi Reinhold,
> I'm having a look at seeing if I can pick up the work Marek Klein did on
> -devel.  It covered amending the coded generating output file suffixes
> to allow users to code user-specified names as the suffix.  It changes
> the function print-with-book in file lily-library.scm so one of the
> internal variables uses a Scheme alist.
>
> How much more work would it be to implement Patrick's suggestion below?

Almost none, see below for a consistent proposal.

> But it would be nice to have an option to override the file-name for
> any arbitrary book.  Something like
>
> \book {
>    \paper {
>      output-file-name = "Blah"
>    }
>    \score {
>      ...
>    }
> }
> .
> .
> .
>
> As I understand it, the above would allow allow you to have a file
> called something like "mozsym40.ly" and use
> \paper {
> output-file-name="SinfoniaK550"
> }
> to generated SinfoniaK550.pdf, .png, .mid, .midi or whatever.

That would not be hard to implement (if you look at the print-with-book code, 
you'll see that currently the file name is concatenated from base and suffix. 
You'd have to add another check and not use the base name for this). However, 
it will be a little harder to make this system consistent and easy to use.

Currently, we have:
    basename-suffix(-nr)
where the number will become optional with the patch.

Of course, one can add another layout variable 'output-basename, which will be 
used instead of the basename (so the suffix will still be used), however, in 
this case the numbering within suffixes will not be ideal. You can then get:

mybase1-suffix
mybase1-suffix-2
mybase2-othersuffix
mybase2-suffix-3

I.e. the numbering will be only within each suffix, even if it is for a 
different 
basename...

The alternative is to use the basename-suffix combination as the key in the 
alist to look up the naming. This would probably be the ideal way.

So, if you really want to generalize the naming even further, I would propose:
- -) A layout variable 'output-basename (default: the input file name, like now)
- -) A layout varialbe 'output-suffix (default: empty)
- -) The naming will then be: basename-suffix[-nr] (or basename[-nr] if no 
suffix is 
set), where the numbering is done like in the almost-finished patch, only that 
the key will not only be the suffix, but the complete "basename-suffix" string 
(or 
if no suffix is set, then "basename" will be the key).

This way, the user has complete control over the output file naming, while the 
behavior without explicit settings stays the same as it is now.

Oh, and it might be a good idea to move the code to determine the file name out 
of print-with-book and into a separate function, which is called from the let 
block in print-with-book.

Cheers,
Reinhold

- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, address@hidden, http://reinhold.kainhofer.com/
 * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iD8DBQFKL+qZTqjEwhXvPN0RAgltAKDCcUb63j8uH9EWVIIW0AT9qAb27ACfUAv1
WTVtj9dSe0MHV6VJR8JrJRk=
=yugo
-----END PGP SIGNATURE-----




reply via email to

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