Han-Wen Nienhuys writes:
|
|pl 61.hwn2
| - revise / junk various input files.
| - junk Music_list_iterator
| - bf: declared paper + \shape
...snipped
Han-Wen,
I submitted a patch 1.1.61.jbr1 earlier this weekend:
Generated by [EMAIL PROTECTED] using package-diff 0.62,
>From = lilypond-1.1.61, To = lilypond-1.1.61.jbr1
o Documentation/ntweb/GNUmakefile: Made EXTRA_DIST_FILE style fix and
added dist-plain target as dependency to the default target.
o scripts/ly2dvi.py: getpid does not behave very well across platforms
so I am creating temp file names with the Python tempfile module.
The generate lilypond dependency file option was broken and
is now operational. I also changed the dependency switch
from -d or -M to match lilypond.
o stepmake/bin/package-zip32.sh: Added build of ntweb html
documentation
Most are tid bits, but the work on ly2dvi I consider to be important.
I can resend the patch if that would be helpful.
1. Is ly2dvi going to the way-side due to guile postscript output?
If ly2dvi still lives, I have been working on and propose a slight
change in ly2dvi operation. I purpose that the ly2dvi application
behaves much like a compiler.
ly2dvi -c file.ly
o Runs lilypond and produces .tex files
(like cc compile phase producing .o files)
ly2dvi -o target file1.tex file2.tex file3.tex ...
o Builds target.tex and produces target.dvi/target.ps/target.midi
(like cc link phase producing final result)
ly2dvi -o target -M file1.ly file2.ly file3.ly ...
o Runs lilypond with -M and builds target.dep which simply contains:
include file1.dep
include file2.dep
include file3.dep
.
.
.
This will make ly2dvi much more suitable for makefile operations and
save alot of time with larger multi-file scores.
2. Any comments on this proposal?
I have not been able to get lilypond -f ps to produce postscript code
that ghostview-5.10 can parse with out affending errors.
3. What is the correct procedure for running and printing the output
lilypond -f ps? (Probably RTFM)
Jeff
--
Jeffrey B. Reed
[EMAIL PROTECTED]
