[EMAIL PROTECTED] writes:
> Lilypond couldn't find its init files. I moved them all from
> .../share/lilypond/ly into .../share/lilypond and then it worked.
> Also, 'make install' left some .ly files in the lilypond directory
> (and some .afm files).
OK, I'll look into it.
>
> The situation with semicolons has gotten worse, in my opinion.
Sorry for all the confusion: .15 is more like a grand hack at the
parser. It's not finished (neither are the new style tuplets, but
you found that out.)
> including a fix below. I'm a little but uncertain about exactly what
OK.
> it should do because of the behavior of the other sizes. Why is it
> that if I make the size smaller, the line width shrinks too? Is there
> some good reason for this behavior? (I would expect changing the font
> size to be independent from changing the margin size.)
The linesize shouldn't be more than the paperwidth. Scaling the
linesize sems like a good solution.
> Also, the default margins for 20pt look like they must be very tiny
> for A4 paper. (They look pretty good on USA letter size which is 7mm
> wider.)
Yup. This is to reflect normal shete music (which is larger than A4)
>The computations for the default margins look somewhat odd to
> me. For the line width, it appears to be
I don't know the details. Jan?
> What controls the text height? I can't figure this one out. The
> "textheight" variable that is being set in the init files is never
> used. (Grepping for it in the source turns up nothing.)
Its controlled by the choice of TeX fonts.
> In an effort to make the papersize mechanism do something useful, I
> moved 'papersize="a4"' into declarations.ly. This way, a user can
> actually change the paper size by resetting it at the top level and
> then re-loading the paperXX.ly and so on. I also removed the spurious
> and misleading entries from the paper??.ly files that set the
> textwidth and textheight only so it can be overwritten later with a
> totally different value.
OK.
> The size of the time signature marks is wrong for sizes: 11pt, 13pt
> and 26pt. (It is only correct for sizes 16pt and 20pt). This appears
> to be the result of the line
> texsetting = "\\input lilyponddefs \\musixsixteendefs ";
> which appears (in some form) only in paper16.ly and paper20.ly.
> But adding this line (suitable altered) to other paper??.ly files
> gives various font errors. For the small sizes, the font errors seem
> to be that I lack computer modern in some weird size. For 26pt, the
> error is that I lack some feta font called feta-nummer14.
Yep. The meter code needs to be rewritten anyway: Lilypond should do
the positioning of the numbers, not TeX.
> I also noticed that the feta font seems to be available in sizes 23
> and 19 but there are no paper*.ly or table*.ly files for these sizes,
> making it unclear how one might access them.
table* and paper* are TODOs.
> I tried out the new \times keyword. I used the following
Its not finished yet
> It appears that 'make dvi' is aborting when bibtex gets errors, which
> it always does for the reference manual because there's no
> bibliography.
>
> I guess bibtex returns false and so the rest of the && chain short
> circuits. This means references don't get fixed and the table of
> contents is screwed up. I'm not quite sure what is intended here, so
> I didn't try to produce a fix. (Why the long chain with && instead of
> just a list of commands?)
because of the cd $(outdir)
> $(outdir)/%.dvi: $(outdir)/%.latex
> (cd $(outdir)&& \
> latex \\nonstopmode \\input $(<F)&&\
> (bibtex $(basename $(<F))&&\
> latex \\nonstopmode \\input $(<F)&&\
> latex \\nonstopmode \\input $(<F) ) || true)
>
> PS. Good progress on the first name. My last name is mAriano, not mOriano.
Urg! Shoot Me With a chaingun.
> redef(code)(1)(tt(ARG1))
>
> +COMMENT(
> +
> +TODO:
> + the use of semicolons needs to be documented once it settles down
> + \times needs documentation with examples somewhere once it works (?)
> + paper size?
> + the explanation of how lyrics mode parses words seems ridiculous.
> + Is there a simple way to explain this, or is the behavior
> + too complicated for a reasonable explanation?
The behaviour is too complicated. We have a bit of a dilemma here:
we want to change all kinds of things, but radical changes will break
old files. Our current plan is to branch development 1.0.x is a
"stable" branch and we will start grand hacking at 1.1.x.
> -dit(code(\tempo) var(duration) = var(perminute)) Used within
> -code(\midi) to specify the tempo. For example,
> -`code(\midi { \tempo 4 = 76})' requests output with 76 quarter notes
> -per minute.
> -
> +dit(code(\tempo) var(duration) = var(perminute)code(;)) Used within
> +code(\midi) or within music to specify the tempo. For example,
> +`code(\midi { \tempo 4 = 76;})' requests output with 76 quarter notes
> +per minute. Note that if the music contains several tempo commands,
> +only the last one is used to set the tempo for the entire MIDI output.
> +COMMENT(Is this true?)
Yep . And it is broken, for tempo changes should be within the music,
