Re: GDP: keep separate pdf files?
On 15.11.2007 (07:34), Mats Bengtsson wrote: Graham Percival wrote: Since the GDP docs are spread over the LM, NR, AU, and snippets -- not to mention MG and IR -- what about making a tarball / zip which contained all these manuals, and removing the download links for individual PDFs? This would avoid problems with people downloading only the LM and discovering all the links which wouldn't work. True! On the other hand, downloading a ZIP requires somewhat more computer experience than just clicking on a link to a PDF file, so I'm not sure we should remove the current links. I agree. A separate tarball link, perhaps also with a brief explanation of why it is a a good idea to download it all, is good, but I would hate to have to take down the whole thing and then unzip every time I for some reason don't have the docs at hand but need to have the pdf. eyolf -- And I beheld another beast coming up out of the sand; and he had two horns like a lamb, but his mouth was fanged and fiery as the dragon and his body shimmered and burned with great heat while it did hiss like the serpent. -- Revised Orange Catholic Bible ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: keep separate pdf files?
2007/11/15, Mats Bengtsson [EMAIL PROTECTED]: Graham Percival wrote: Since the GDP docs are spread over the LM, NR, AU, and snippets -- not to mention MG and IR -- what about making a tarball / zip which contained all these manuals, and removing the download links for individual PDFs? This would avoid problems with people downloading only the LM and discovering all the links which wouldn't work. True! On the other hand, downloading a ZIP requires somewhat more computer experience than just clicking on a link to a PDF file, so I'm not sure we should remove the current links. /Mats Please remember that Adobe reader can be installed as a browser plugin, in this case PDF links between different documents would work. I have seen links into PDFs that even have javascript scripts, e.g. history-go-back to the previous document. -- Francisco Vila. Badajoz (Spain) http://www.paconet.org ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: chattiness in @seealso
2007/11/15, Graham Percival [EMAIL PROTECTED]: I have a slight preference against #2 (sentences everywhere), since IMO in most cases it's obvious why somebody might want to look at other section. I don't! I like full sentences :) Option #3 is preferring no explanation at all, but allowing short phrases in parentheses. IMHO this is the best choice, by far. Valentin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR - lilypond docs
2007/11/15, Mats Bengtsson [EMAIL PROTECTED]: As I have said earlier, I think it would be a big loss if the web site could not provide the full documentation for multiple old version, including a complete set of example files with the correct syntax for the corresponding version. This is one of the reasons why I still haven't fully understood the point in tagging LSR snippet as docs: if a snippet is documentation relevant, then it should probably be added to the documentation as a real example, shouldn't it? I'm fully aware of all the advantages of LSR and exploiting this examples in the official docs, but I don't want to lose the support for multiple versions. Thank you for rising the question of the *future* compatibility; it's a fact that until now I've mostly been thinking about previous versions issues. Graham Percival wrote: Yes, but this is unavoidable. Lilypond GIT needs to compile with the specific version of lilypond. The best we can do is run the snippets through convert-ly. That's all I wanted you to make clear. If you're going to ask about upgrading LSR, bear in mind that this involves an unknown amount of work from Sebastiano, and that 2.11.34 contains known serious bugs. Based on the reaction to .35, I might propose .36 as a candidate for LSR-upgrading. Oh yes; anyway, I'm fine with LSR running 2.10. I've just rewritten the LSR contributing page with that in mind, and I'm fine with my idea of marking not-yet-working snippets with [needs LSR upgrade] or something. I know you're not fond of it, but as long as it applies to a dozen snippets it's perfectly manageable. Regards, Valentin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: church rests
On 15 Nov 2007, at 00:57, Graham Percival wrote: GDP: http://web.uvic.ca/~gperciva/ Take a look at NR 1.2.2 Writing rests: Multi measure rests is church rests a real musical term? There's some question over whether we should use church rests or Kirchenpausen. Mensural notation preceded modern notation (ca 1600), but indicated rests are modern. I have dictionary that calls them Length UK english US English French 1/2 minim rest half restla demi-pause 1 semibreve rest whole rest la pause 2 breve rest la double pause It does not say for length 4, but in mensural notation, the note is called longa. In fact http://en.wikipedia.org/wiki/Rest_%28music%29 just calls it long rest. For shorter rests, in English, one just uses the note name plus pause. For example Length UK english US English 1/64 hemidemisemiquaver rest sixty-fourth rest In French, the 1/4 rest is called le soupir, and the other rests are given fraction names of that. For example Length French 1/64 le seizième de soupir Hindemith suggests using |---| with a number over for rests of nine measures or longer. 9 |---| Hans Åberg ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: preferred terms
On 15 Nov 2007, at 00:57, Graham Percival wrote: I've started a list of preferred terms in policy.txt. These are words where people have asked me which spelling/term we prefer, and I don't want to give different answers to different people. I think this is a bit late; I'm certain that I've flip-flopped on bar lines, but at least this time (once they're added to this list) I won't change my mind again. There's a few more terms to add to this list: - bar vs. measure. Whenever possible, we use the same term as the internal lilypond syntax uses... but I've seen both bars and measures in those docs. Should we just leave this up to individual doc writers, or pick one word? Harvard Concise suggests using bar line, i.e., the line delimiting the measure, and measure, the stuff usually delimited by the bar lines. I think the use of bar meaning measure is informal. - barline vs. bar line. I believe that the lilypond syntax is barline, but that could just be because we can't have spaces in property names. The dictionary above and Merriam Webster's Third New International Dictionary uses bar line, and Hindemith bar-line (1946). As for LilyPond syntax, probably best to give words forms that are easy to remember exactly when typing; so barline would be fine to me. Hans Åberg ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: church rests
Hans Aberg wrote: Hindemith suggests using |---| with a number over for rests of nine measures or longer. 9 |---| The default rule in LilyPond is to do this for 11 measures or longer, see section Multi measure rests in the manual for information on how to change this value. /Mats ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: preferred terms
Greetings - *** Graham wrote: - bar vs. measure. Whenever possible, we use the same term as the internal lilypond syntax uses... but I've seen both bars and measures in those docs. Should we just leave this up to individual doc writers, or pick one word? - barline vs. bar line. I believe that the lilypond syntax is barline, but that could just be because we can't have spaces in property names. *** My preference would be to use measure and [barline or bar line]. That is, I think bar is sometimes used as a synonym for barline; therefore, staying consistently with measure for the unit of music and barline (or bar line, I don't care) for the symbol delimiting a measure, might help achieve clarity. Ralph + Ralph Palmer, CEM Energy/Administrative Coordinator Keene State College Keene, NH 03435-2502 Phone: 603-358-2230 Cell: 603-209-2903 Fax: 603-358-2456 [EMAIL PROTECTED] ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: church rests
On 15 Nov 2007, at 14:24, Mats Bengtsson wrote: Hindemith suggests using |---| with a number over for rests of nine measures or longer. 9 |---| The default rule in LilyPond is to do this for 11 measures or longer, see section Multi measure rests in the manual for information on how to change this value. Blatter uses it (in parts) for rests 2 measures or longer, but broken up by section marks. For example: 2 (B) 6 ... |---| | |---| | ... And one may add measure numbers (and cue marks). Hans Åberg ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: church rests
2007/11/15, Hans Aberg [EMAIL PROTECTED]: On 15 Nov 2007, at 14:24, Mats Bengtsson wrote: Hindemith suggests using |---| with a number over for rests of nine measures or longer. 9 |---| The default rule in LilyPond is to do this for 11 measures or longer, see section Multi measure rests in the manual for information on how to change this value. For the term church rests, Finale for example simply says use symbols for multimeasure rests up to nine measures -- Francisco Vila. Badajoz (Spain) http://www.paconet.org ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: posting snippets
OK, the page has been updated: http://lsr.dsi.unimi.it/LSR/html/contributing.html Thank you very much Seba! Cheers, Valentin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: church rests
On 15 Nov 2007, at 17:19, Francisco Vila wrote: Hindemith suggests using |---| with a number over for rests of nine measures or longer. 9 |---| The default rule in LilyPond is to do this for 11 measures or longer, see section Multi measure rests in the manual for information on how to change this value. For the term church rests, Finale for example simply says use symbols for multimeasure rests up to nine measures Hindemith's book has the diagram above, so it is clear that he would use it for rests of length 9 measures. Hans Åberg ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: church rests
2007/11/15, Hans Aberg [EMAIL PROTECTED]: On 15 Nov 2007, at 17:19, Francisco Vila wrote: For the term church rests, Finale for example simply says use symbols for multimeasure rests up to nine measures Hindemith's book has the diagram above, so it is clear that he would use it for rests of length 9 measures. Hans Åberg Here I do not advocate for the number 9, but for the word symbols -- Francisco Vila. Badajoz (Spain) http://www.paconet.org ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR - lilypond docs
Valentin Villenave wrote: 2007/11/15, Mats Bengtsson [EMAIL PROTECTED]: As I have said earlier, I think it would be a big loss if the web site could not provide the full documentation for multiple old version, including a complete set of example files with the correct syntax for the corresponding version. This is one of the reasons why I still haven't fully understood the point in tagging LSR snippet as docs: if a snippet is documentation relevant, then it should probably be added to the documentation as a real example, shouldn't it? Do you mean documentation or manual? - if something is in the manual, it can only be upgraded by about half a dozen people on the planet -- me, Mats, John... maybe some of the other developers if it was really urgent. Note that none of the GDP helpers are able to do this. - if something is in LSR, it can be upgraded by anybody. OK, you need to approve the change, but if necessary we could have more LSR editors. I mean, the only technical ability you need is the use of a web browser (instead of git, building the docs, permission to upload to lilypond git, etc). - if something is in LSR and is tagged with docs, it AUTOMAGICALLY becomes part of our documentation. The Snippets link on the main doc page points to files built from input/lsr/*/ . This is part of our _documentation_, although not part of the _manual_. Oh yes; anyway, I'm fine with LSR running 2.10. I've just rewritten the LSR contributing page with that in mind, and I'm fine with my idea of marking not-yet-working snippets with [needs LSR upgrade] or something. I know you're not fond of it, but as long as it applies to a dozen snippets it's perfectly manageable. There's another dozen such examples in input/new/ . I really don't see the point of adding them until LSR is upgraded. - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR - lilypond docs
Mats Bengtsson wrote: As I have said earlier, I think it would be a big loss if the web site could not provide the full documentation for multiple old version, including a complete set of example files with the correct syntax for the corresponding version. It does! input/lsr/*/ is the same thing as input/tweaks/ At least, they were the same when LSR first started. Now they've diverged a bit, but the basic premise is still the same: input/lsr/*/ is simply a sorted version of the old input/tweaks/ Different GIT revisions will contain different files in input/lsr/*/ just like different GIT revisisions (pre-2.11) contained different files in input/tweaks/ . From the standpoint of the lilypond website + build system + git, there is NO DIFFERENCE between the old input/tweaks/ and the new input/lsr/*/ - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: church rests
On 15 Nov 2007, at 18:34, Francisco Vila wrote: For the term church rests, Finale for example simply says use symbols for multimeasure rests up to nine measures Hindemith's book has the diagram above, so it is clear that he would use it for rests of length 9 measures. Here I do not advocate for the number 9, but for the word symbols -- Francisco Vila. Badajoz (Spain) http://www.paconet.org So what should the multi-measure rest symbol k |-| be called? Hans Åberg ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Lilypond in MikTeX
Hello,
I tried the LaTeX example from the Lilypond manual and ran it with MikTeX on
Windows XP.
Unfortunately LaTeX doesn't know lilypond at all.
! LaTeX Error: Environment lilypond undefined.
See the LaTeX manual or LaTeX Companion for explanation.
Type H return for immediate help.
...
l.3 \begin{lilypond}
Does anybody know how to fix this?
Best regards,
Helge
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond in MikTeX
Helge Kruse wrote: I tried the LaTeX example from the Lilypond manual and ran it with MikTeX on Windows XP. Try reading the manual as well. It discusses the lilypond-book script, which you must run. I have no idea if this is compatible with MikTeX. - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond in MikTeX
You cannot run the TeX files containing the lilypond environment directly with latex oder pdflatex. You have to use the script lilypond-book which is part of the lilypond package. That script runs lilypond to make pdf files (or other image files) out of the lilypond code. Then it writes a new TeX file which contains \includegraphics commands or something similar for the insertion of your notes. Now you can run latex or pdflatex on that TeX file. As Graham already recommended you should read the manual to understand this and to know what you exactly have to do. Dominic 2007/11/15, Graham Percival [EMAIL PROTECTED]: Helge Kruse wrote: I tried the LaTeX example from the Lilypond manual and ran it with MikTeX on Windows XP. Try reading the manual as well. It discusses the lilypond-book script, which you must run. I have no idea if this is compatible with MikTeX. - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user -- DNVerlag, Inh. Dominic Neumann Lessingstraße 8 D-09130 Chemnitz Telefon: (+49) 3 71 / 2 83 93 74 Fax: (+49) 3 71 / 2 83 93 76 E-Mail: [EMAIL PROTECTED] WWW: www.dnverlag.de ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: chattiness in @seealso
Good questions! (another overdue discussion question, sorry) IMHO this isn't a problem. The crucial thing to remember is that program documentation isn't for programmers (they have comments in the working code), its for us non-programmers who struggle with programs like lilypond because it requires us to learn to think differently about notes and music than we are used to. Full sentences in the language of the documentation is preferable. A full sentence engages, or draws the reader into the program in a way that the terseness of choice 1 or 3 cannot do. It can also prevent the reader from ducking into blind alleys. This prevents much head banging (less risk of permanent damage to) and general frustration. Links and see also references are good ways to redirect someone who is not quite sure where to look for what they are looking for. Many times I have a question which I do not know the correct words for. I guess at how the question might be worded. I am right about 50 percent of the time. When I am not right, those see also references usually are the ones that save me from much head banging. I have (on occasion) actually sat in a chair away from the computer and read computer documentation. I don't believe documentation is simply on-the-fly reading. It should be a well thought out description with instruction on how to use the program it accompanies. It is a literary work of its own. The skill and craft of it is to be on point; engaging and readable all at the same time. What I am saying is that presentation matters. It is essentially first contact for newbies using lilypond. The longer you use lilypond, the less you depend on documentation. The speed with which that happens is in large part due to the skill with which the documentation is written. Without a doubt, number 2 is the best option. I had not intended to use so many words, but this sums up my thoughts on documentation and specifically on this question. Take a look at the see also sections in NR 1.1.3 Displaying pitches: Instrument transpositions and NR 1.2.1 Writing rhythms: Durations In 1.1.3, we have a short, compact format: Notation reference: Quoting other voices, Transpose. In 1.2.1, there's much more explanation of why people might want to look at each link: For ways of specifying durations for the syllables of lyrics and ways of aligning lyrics to notes see Vocal music. For a description of how to enter rests see Writing rests. A note with the duration of a quadruple breve may be entered with \maxima, but this is supported only within ancient music notation; see Ancient notation. Optionally, notes can be spaced proportionately to their duration. For details of this and other settings which control proportional notation see Proportional notation. I have often found the footnotes in a book or article as interesting or more interesting than the main piece of writing. Cheers, David -- David Fedoruk B.Mus. UBC,1986 Certificate in Internet Systems Administration, UBC, 2003 http://recordjackethistorian.wordpress.com Music is enough for one's life time, but one life time is not enough for music Sergei Rachmaninov ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
lp with korean/utf8 lambda dvipdfmx
Hi forum!
I'm a German latex-user and new to lilypond.
My intention is to place a few lines of melody and lyrics of a wellknown Korean
folksong (Arirang) in a certain korean font into a latex-document, probably
within a minipage (or a table). All should end up in a PDF.
I entered \begin{lilypond} ... \end{lilypond} into the .tex-document then.
After finishing my first 'composition' following the main lp-doc and the
'regression/collated-files'-doc (near the end, for the multilingual section)
and, of course I'd like to see now how it looks like~
Unfortunately, this is impossible because lilypond-book invokes latex only
but, I need it to run lambda, so the mess showed up with the no files
output-error only!
((Nevertheless there's been some output: a .aux, .log and an .out-file,
seemingly without any use for now.))
Some more explanation:
My system is linux with utf8. Further, I use hlatex (Korean LaTeX), which I
have to include into the .tex-preamble with the obligatory \usepackage{hangul}.
On a non-UTF8-system, one can use simply pdflatex for creating PDFs directly.
In my case, a latex-document built with hlatex (based on EUC-KR/KS-encoding)
must be compiled into PDF in to steps:
$ lambda korean.tex
$ dvipdfmx korean.dvi
while lambda is some kind of latex-extension for 'switching' to UTF8 (otherwise
latex breaks off with too many errors).
So, now the only thing that had been formated is the lyrics in the particular
font~ For a temporary solution the musical notes could be handled by lilypond-
book and the lyrics by latex seperately. But before I wouldn't see any no
notes, I won't paste any lilypond-code here.
Are there any options then for lilypond to invoke lambda?
How would the example utf-8.ly in collated-files have been compiled, if
it's used with latex?
Thanks you
Minsu
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: chattiness in @seealso
Eyolf Østrem wrote:
On 14.11.2007 (16:18), Graham Percival wrote:
I have a slight preference against #2 (sentences everywhere), since IMO
I know you have, and you know this is the one I prefer. Giving a hint at
WHY one should seealso ain't fluff. This isn't dungeons and dragons (you
are in a dark cave. To the east there is a link to Proportional notation,
to the south is a snippet. etc).
I think you mean this isn't zork, not DD. :)
in most cases it's obvious why somebody might want to look at other
section.
... I'd say that in SOME cases it's obvious, but in many it's not, and if a
general rule is needed, I'd go for 2 (with 3 as a variant).
Well, you're the one who'll have to go through and write sentences for
every single @seealso section, so it's no skin off my back... what about
the new Durations? (see tomorrow's GDP; should be online in about two
hours. If you're not certain if you're seeing the updated ones or not:
the updated one stick things in an itemized list)
At the very least, I want it clear which sentence refer to the Notation
Reference, and which sentences refer to the other parts of the docs.
... I _really_ think this is completely unnecessary, though. And if you
want to add full sentences to every single notation reference @ref{}, I
assume you want to do the same for every @lsr{dir,snippet}, every
@internalsref{}, etc ?
Mats, you're the yardstick for efficient NR use. What do you think of
the compact vs. full sentence form of @seealso ? I don't want to
approve any change that makes the NR harder to use for knowledgeable
users, and IMO this is one such change.
Cheers,
- Graham
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: chattiness in @seealso
On 14.11.2007 (16:18), Graham Percival wrote: I think we should have a consistent format for the NR; which one do people prefer? I have a slight preference against #2 (sentences everywhere), since IMO I know you have, and you know this is the one I prefer. Giving a hint at WHY one should seealso ain't fluff. This isn't dungeons and dragons (you are in a dark cave. To the east there is a link to Proportional notation, to the south is a snippet. etc). In other words ... in most cases it's obvious why somebody might want to look at other section. ... I'd say that in SOME cases it's obvious, but in many it's not, and if a general rule is needed, I'd go for 2 (with 3 as a variant). eyolf -- Law always chooses sides on the basis of enforcement power. Morality and legal niceties have little to do with it when the real question is: Who has the clout? -- Bene Gesserit Council Proceedings: Archives #XOX232 ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: chattiness in @seealso
On 15.11.2007 (16:19), Graham Percival wrote:
At the very least, I want it clear which sentence refer to the Notation
Reference, and which sentences refer to the other parts of the docs.
Agreed.
... I _really_ think this is completely unnecessary, though. And if you
want to add full sentences to every single notation reference @ref{}, I
assume you want to do the same for every @lsr{dir,snippet}, every
@internalsref{}, etc ?
No, not really. My only concern -- since you asked for general principles
-- is that there shouldn't be a rule to preclude explanation where it is
desirable. This will be the case, I imagine, with references to some
complicated function in an altogether general section, or in other cases
where the reference in its barest form is less than obvious. In many cases,
I agree that an extra description will be fluff and should be avoided.
Mats, you're the yardstick for efficient NR use. What do you think of
the compact vs. full sentence form of @seealso ? I don't want to
approve any change that makes the NR harder to use for knowledgeable
users, and IMO this is one such change.
How do you define a knowledgeable user in this respect? One who is
knowledgeable in using the docs will know to look for links in the seealso
sections, and I can't see how it would make it more difficult to use it
with an extra pointer or two (like Remember to bring the towel from your
hotel room) -- and one as knowledgeable about LP as Mats probably won't
need those links in any case :)
sorry, the question wasn't for me, so I'll shut up.
Eyolf
--
Life, like beer, is merely borrowed.
-- Don Reed
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: chattiness in @seealso
Eyolf Østrem wrote:
On 15.11.2007 (16:19), Graham Percival wrote:
... I _really_ think this is completely unnecessary, though. And if you
want to add full sentences to every single notation reference @ref{}, I
assume you want to do the same for every @lsr{dir,snippet}, every
@internalsref{}, etc ?
No, not really. My only concern -- since you asked for general principles
-- is that there shouldn't be a rule to preclude explanation where it is
desirable.
That's why I proposed #3 -- short explanations could be added if needed,
but most of the time you wouldn't need any explanation. To take the
current examples, if you're looking at Durations and see a link to
writing rests (or simply rests, which is what we should have there),
I don't think there's any question about why it might be useful.
Also, remember that this is the format inside the @seealso -- not about
having links in the main doc section.
Cheers,
- Graham
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: lp with korean/utf8 lambda dvipdfmx
Unfortunately, this is impossible because lilypond-book invokes latex only but, I need it to run lambda, so the mess showed up with the no files output-error only! Indeed, the use of `latex' is hard-coded currently. While lambda is a rather dead end, users might become interested in using XeTeX. This is worth a bug report IMHO. In my case, a latex-document built with hlatex (based on EUC-KR/KS-encoding) must be compiled into PDF in to steps: You might try my CJK package for standard LaTeX instead... Are there any options then for lilypond to invoke lambda? How would the example utf-8.ly in collated-files have been compiled, if it's used with latex? The CJK package comes with UTF-8 support. On TeXLive, some standard Korean fonts (taken from an older version of HLaTeX) have been provided both for KS encoding and UTF-8 (using virtual fonts for that). Werner ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Space on the left end of each line
This seems like the sort of thing there should be an easy tweak for, but I'm not finding the right properties to change, I guess. I'm setting a bunch of plainchant stuff in more or less modern notation, so it uses modern note heads and spacing rules and five lines, but still doesn't have a time signature or key signature and the clef is only printed on the first line. However, since the notes start in immediately on subsequent lines, the lyrics (which are centred on each note head) sometimes hang off the left end of the staff. When I have a stanza mark or something, then it *really* hangs off the end. So I'd like to allow a fixed-width space at the beginning of the line before the notes start rendering. I say fixed-width because I've tried a bunch of things involving adding an invisible note at the beginning of the line, but since there are a different number of notes on each line, this makes a variable-width space and the result looks very ragged. Ideally this fixed-width space would be configurable, but I'd settle for an invisible clef sign (i.e. a space the same width as the clef sign on the first line). But I couldn't figure out how to do that either. I'm using LP 2.10.0 at the moment, but I'm happy to upgrade again if the answer is to be found in a later version. -- -=-Don [EMAIL PROTECTED]http://www.blahedo.org/-=- How do I love thee? My accumulator overflows. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Space on the left end of each line
Hi Don, I'd like to allow a fixed-width space at the beginning of the line before the notes start rendering. Have you thought about adding this value to the 'X-extent of the first note? e.g., \once \override NoteColumn #'X-extent = #'(-20 . 1) It's not ideal (there'll be a lot of manual tweaking required), but it would work (I think...). Hope this helps, Kieren. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
