> > "Jan" == Jan Nieuwenhuizen <[EMAIL PROTECTED]> writes:
>
> Jan> No, latex doesn't know about '\property'. How do you think lilypond
> Jan> treats this ly snippet of yours:
>
> Jan>g\breve ^"\fbox{\large
> Jan>\property Voice.NoteHead \revert #'style %fix_long.py
> "Jan" == Jan Nieuwenhuizen <[EMAIL PROTECTED]> writes:
Jan> No, latex doesn't know about '\property'. How do you think lilypond
Jan> treats this ly snippet of yours:
Jan>g\breve ^"\fbox{\large
Jan>\property Voice.NoteHead \revert #'style %fix_long.py
Jan>\
Laura Conrad <[EMAIL PROTECTED]> writes:
> From: Laura Conrad <[EMAIL PROTECTED]>
> Subject: Lily producing bad latex
> To: [EMAIL PROTECTED]
> Date: 13 Jun 2002 14:52:47 -0400
>
> Lilypond processes the attached file with no reported problems, but
> latex doesn't like the latex:
> ! Undefined c
Lilypond processes the attached file with no reported problems, but
latex doesn't like the latex:
conrad@tuba prima]$ lilypond -v
GNU LilyPond 1.5.60.jcn1
lconrad@tuba prima]$ latex tenor.tex
This is TeX, Version 3.14159 (Web2C 7.3.1)
(tenor.tex
LaTeX2e <2001/06/01>
Babel and hyphenation patter
Jan Nieuwenhuizen <[EMAIL PROTECTED]> writes:
> * incorporate new strings into .pot, and update the available .po's
> by running:
>
>make po-update
This will generate the new stuff in po/out. If you're satisfied with
the results (or just want to take the risk), you may do
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> Well, correction: "I use". I suggest we don't fix this until a GCC is
> released that really removes the feature.
Or maybe until someone wants to create a translation of the manual.
In any case, I would suggest to use multiline strings only for
'doc
[EMAIL PROTECTED] writes:
> Hi !
>
> This patch (for the CVS) includes a few documentation (in refman.itely) and
> fixes some bug:
>
> - stringTunings now has a doc string
> - default tuning is (should be ? ;-) now right
> - tablature with even number of strings works.
>
> Jiba
ok, added to
[EMAIL PROTECTED] writes:
> Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
> > as a way of writing "foo\nbar". We use lots of instances of "foo
> > bar", eg.
>
> We use? Make that: during 1.5, al lot of instances ... were introduced.
> Those should probably be fixed, as they're deprecated in gc
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> as a way of writing "foo\nbar". We use lots of instances of "foo
> bar", eg.
We use? Make that: during 1.5, al lot of instances ... were introduced.
Those should probably be fixed, as they're deprecated in gcc-3.1, and
will thus probably not compil
Hi !
This patch (for the CVS) includes a few documentation (in refman.itely) and
fixes some bug:
- stringTunings now has a doc string
- default tuning is (should be ? ;-) now right
- tablature with even number of strings works.
Jiba
tab-lily-5.patch
Description: Binary data
[EMAIL PROTECTED] writes:
> >
> > It's never been valid C, afaik. I've been correcting (ie, removing)
> > multi-line strings for quite some time.
> >
>
> I don't understand. What's so bad about doing something like:
>
> printf("%d,%d,"
> "%d,%d\n",
> 1, 2, 3, 4);
I think t
On Thu, 13 Jun 2002, Jan Nieuwenhuizen wrote:
> Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
> > 1. Multiline string literals are valid in Python
>
> -> bugreport to gettext.
>
> > 2. I think that this is one the stupidest C++ decisions I've seen in
> >years.
>
> It's never been valid C,
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> 1. Multiline string literals are valid in Python
-> bugreport to gettext.
> 2. I think that this is one the stupidest C++ decisions I've seen in
>years.
It's never been valid C, afaik. I've been correcting (ie, removing)
multi-line strings fo
[EMAIL PROTECTED] writes:
> Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
> > Addendum: this is mostly correctly done in lily.
>
> ... in lilypond-1.4.0. Don't know what happened after.
>
> > Just did this. -- It seems that gettext chokes on multi-line string
> > literals, spewing complaint
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> Addendum: this is mostly correctly done in lily.
... in lilypond-1.4.0. Don't know what happened after.
> Just did this. -- It seems that gettext chokes on multi-line string
> literals, spewing complaints about non-terminated string literals.
M
[EMAIL PROTECTED] writes:
> * update source files, adding _ ( .. ) or _f ( .. ) whenever
> necessary. guidelines are: translate whole sentences rather than
> snippets, but try to minimise the number of localisation strings
> (eg, use one error message for 'cant open file', not 10 v
Kopecek Tomas <[EMAIL PROTECTED]> writes:
> I have to ask once more. Should I submit localization based on
> `lilypond.pot' or wait (or do) further localisation steps like updating
> source files?
Sorry to keep you waiting. I'm sort of the localisation guy around
here, but I've not been around
> The following at the en of the message, compiled like this:
>
> lilypond-book filename.mb
> latex filename.latex
> xdvi filename.latex
>
> does not display the norwegian characters.
Since the Lilypond generated TeX code uses low-level TeX
font selection mechanisms, not the ordinary LaTeX font
Rune Zedeler <[EMAIL PROTECTED]> writes:
>> ./autogen.sh
>> ./configure
>
> On a newcly checked out cvs:
> $ ./autogen.sh --prefix=/home/rz/lilypond/lilypond-devel --disable-optimize
> ...
> $ ./configure --prefix=/home/rz/lilypond/lilypond-devel --disable-optimize
> ...
> $ make all
> ...
w
19 matches
Mail list logo
