Re: faster lilypond rendering
On Wednesday 15 February 2006 06.28, Richard Schoeller wrote: I'd like to weigh in on this one. My experience is totally contrary to the way this discussion has gone. The actual entry and correction of the music is a trivial small part of the time I spend working with Lilypond. I spend much more time in adjusting the tweaks, especially the choice of line breaks, page breaks and the locations of rehearsal marks. This activity has much more requirement to actually render the whole document. And it takes forever on my 700Mhz PII! So, cutting out processing of sections of music is of little use. I'm really looking for faster rendering in general. Then it could maybe be a good idea to only render one or two pages at a time, and skip the rest. BTW, some watching of the process leads me to think that one of the biggest performance sinks is conversion to PDF. Sounds very strange. However, if ps-pdf conversion does take forever, then you can always use the --ps switch to lilypond (which skips the pdf generation phase). -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
modern-cautionary
I'm not getting a cautionary naturalization on the lower A - and it sure would be nice to have! In other instances where the notes are in the same octave it works fine. #(set-accidental-style 'modern-cautionary) f''4 g''8 aes''8 a'4 d''4 Running XP and version 2.6.4-5 Arthur -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 267.15.8/260 - Release Date: 2006/02/14 ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: faster lilypond rendering
Hello Richard, As a different data point you can compare to to explain the kind of performance (or lack thereof) you get: I produce a 70 pages conductor's score in less than half an hour (and this is a *very* conservative estimate) on a two years old PC. True, it has 2GB of memory, but other than that, it is to be considered a fairly old beast by today's standards. Regards, Darius. Richard Schoeller wrote: I'd like to weigh in on this one. My experience is totally contrary to the way this discussion has gone. The actual entry and correction of the music is a trivial small part of the time I spend working with Lilypond. I spend much more time in adjusting the tweaks, especially the choice of line breaks, page breaks and the locations of rehearsal marks. This activity has much more requirement to actually render the whole document. And it takes forever on my 700Mhz PII! So, cutting out processing of sections of music is of little use. I'm really looking for faster rendering in general. BTW, some watching of the process leads me to think that one of the biggest performance sinks is conversion to PDF. I think that performance may be a non-linear function of the number of pages. The final phase of rendering a 28 page conductor's score takes hours. This is much more than twice as long as other scores that are approximately half the length. It is also much, much longer than it takes to get to the prompt about starting the PDF conversion. FWIW, this could be caused by or at least exacerbated by poor memory usage in the conversion phase. If the PS to PDF conversion loads the whole document into memory at once, this could all be the result of swap thrashing. The above is all in 2.6.4-1. I haven't gone to 2.7 yet, though some of the new features look tempting. Dick On Tue, 2006-02-14 at 13:31 -0800, Ben Fisher wrote: Thanks for the suggestions. Skipping corrected music looks like the most helpful option. It is a cool and useful idea to skip music. (altough the way to do seems a little awkward.) -Ben ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: faster lilypond rendering
Quoting Erik Sandberg [EMAIL PROTECTED]: ... BTW, some watching of the process leads me to think that one of the biggest performance sinks is conversion to PDF. Sounds very strange. However, if ps-pdf conversion does take forever, then you can always use the --ps switch to lilypond (which skips the pdf generation phase). Unfortunately, that's not true on Windows, where it seems that GSView is unable to handle Postscript files from LilyPond, no matter what ghostscript version you use. See the mailing list archives for more information. /Mats ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: modern-cautionary
Works fine with 2.6.5 on Windows. Fred I'm not getting a cautionary naturalization on the lower A - and it sure would be nice to have! In other instances where the notes are in the same octave it works fine. #(set-accidental-style 'modern-cautionary) f''4 g''8 aes''8 a'4 d''4 Running XP and version 2.6.4-5 Arthur ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: modern-cautionary
Hi Art!
At least for WinXP v2.7.33-3 it works fine using
\score {
\new Staff {
#(set-accidental-style 'modern-cautionary)
f''4 g''8 aes''8 a'4 d''4
}
}
If there is no other reason to neglect I would recommend to update.
Kind regards,
Thies Albrecht
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: white text on black background
While waiting for a knowledgeable reply on this list, which never came, I managed to find a solution. The helpful volunteers who answer questions on this mailing list are happy that you managed to find a solution. It took a fair amount of experimenting to get it right, principally given the utterly sparse documentation about \filled-box and \with-color notably regarding the form and semantics of their arguments. The helpful volunteer who manages the documentation (i.e. me) will be happy to receive patches and detailed descriptions of what to add to the docs. I know a lot less about \filled-box and \with-color than you do. (Hmm, in hindsight I can see how I may have sounded inappreciative, sorry, I guess I was just steaming off for seeing every other post getting a reply and mine a deafening silence as they say.) All that the manual (version 2.6.6) says about \filled-box is: \filled-box xext (pair of numbers) yext (pair of numbers) blot (number) Draw a box with rounded corners of dimensions xext and yext. I suggest completing this as follows. \filled-box xext (pair of numbers) yext (pair of numbers) blot (number) Draw a box with possibly rounded corners of dimensions xext and yext, where the first number of xext is the horizontal offset of the left side of the box, the second number of xext is the horizontal offset of the right side, the first number of yext is the vertical offset of the bottom side, and the second number of yext is the vertical offset of the top side. All offsets are in staff spaces and relative to the current position. Positive offsets are rightwards and upwards, negative offsets are leftwards and downwards. The blot is the roundness of the box corners, namely the diameter in staff spaces of the circle corresponding to the curve made by each corner, and should not exceed half the size of the width or height of the box, which one is smaller. Naturally a value of zero represents sharp corners. Example: \filled-box #'(-.3 . 1.8) #'(-.3 . 1.8) #0 ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: faster lilypond rendering
Mats Bengtsson wrote: Quoting Erik Sandberg [EMAIL PROTECTED]: ... BTW, some watching of the process leads me to think that one of the biggest performance sinks is conversion to PDF. Sounds very strange. However, if ps-pdf conversion does take forever, then you can always use the --ps switch to lilypond (which skips the pdf generation phase). Unfortunately, that's not true on Windows, where it seems that GSView is unable to handle Postscript files from LilyPond, no matter what ghostscript version you use. See the mailing list archives for more information. Did someone submit a bugreport? FWIW, GS 8.54 groks lilypond PS output without complaints when using -dSTRICT -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
volta brackets not 'closing'
Folks,
In the first part of a tune I'm doing, I want to have a repeat volta (2)
with 2 alternatives.
Like:
\repeat volta 2 {
\grg f4. _\markup { transition } ( f4. )
\hdblg g4. ( g4. )
\dblA A4. ( A4. )
f8 e8 f8 \dbld d4 e8 \break
\grg f4. ( f4. )
\hdblg g4. ( g4. )
e8 A8 e8 A8 f8 e8
}
\alternative {
{f8 e8 c8 \grg f4.}
{f4 e4 c4 \grg f4. (f4.) \bar || \break }
}
When I do it this way, the 2nd volta bracket doesn't 'close'
(no vertical line on the right edge).
In the second alternative, if I replace
\bar || with
\bar |.
Then it 'closes'. Is this normal behaviour?
Also: in this tune, all of the parts have 8 bars
and are either repeated or written out in full - except for
one part - it has 8 bars but is only to be played once over.
I want to indicate an 'end of part' by doing a ' \bar || '
at the end, but this doesn't get picked up somehow - lilypond
just displays a single bar line at the end of this part.
Thoughts?
Regards,
Stu.
--
Stuart Lowe | Toronto, CAN | key ID on keyserver | Skype stuart.lowe
Fedora Core release 4 (Stentz) GNU/Linux kernel 2.6.11-1.1369_FC4 on i686
localhost3.localdomain
13:13:00 up 12 days, 2:37, 6 users, load average: 0.47, 0.66, 0.88
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: symphonic, continuos movements, percussion, midi
Mats Bengtsson mats.bengtsson at ee.kth.se writes:
Quoting alexandre reche e silva recheesilva at yahoo.com.br:
I still need help because of a strange side effect: using /mark to
titling adds a empty staff at the top of the others?!?! (This is really
embarrassing. Imagine. An uninvited blank top staff...).
If you include short but complete example .ly file that illustrates
this problem, it will be much easier for us to tell what mistake you do.
/Mats
Peace and Health in Jesus Christ
Well, the task of reduce a symphonic piece to a short but complete example
was finally done. Nevertheless, the ensemble was reduced to flute and oboe
only, and just the first section was quoted bellow (because I don't know yet
how to attach a .ly file to this post). You will witness the strange effect of
a ghost staff (probably a side effect from self-teaching ;)
%{
It would be interesting to criticise any other aspect of the labour too -- just
for newbies' didact purposes involving tabbing, spacing, line breaking,
structural format,hierarchy... (The editor used is jedit.)
I insist on this because we newbies have problems with possibilities of such
openness allowed by lily language. From this point of view, orthography and
semantic rules will help as well as syntax.
Someone said limitations are highly creative. We are not interested in
martial rules, but instead, in the art of writing,e.g., to put together, to
compound: to compose. We hear that a program well structured (I mean, well
wrote) demand less work.
The software is growing fast and maybe there is no spot for that.
But, it would be interesting also to think in a task front to show some
blueprints to lily writing expanding the manual section (3.1 in version 2.4.5)
'Suggestions for writing LilyPond files'.
As some editors use to respond to certain languages --
in terms of tabbing and highlighting --
we (non programmers programming because want to see music) could be
encouraged to observe some points:
* open braces (or whatever) and after that break line and give a tab (or
three spaces to be more economic, visually speaking) just to make the
block easier to see and to understand better the code;
* make this recursively if one nests grub inside grub;
(* remember that this is usable for long sentences)
* global stuffs remains at the top of the file;
* do not repeat information along the files;
* give more spaces between groups of notes to differentiate them from
notes inside the group;
* ...
What I am trying to depict (almost overloading my English) is that some
conventions on this way help people to:
- question less and precise more;
- see better the whole picture;
- help lily (and ourselves) to understand our files;
- migrate from front-end environments;
- help bug tracking (who knows? :)
- ...
In spite this is the adequate occasion or not, I want to thank you anyway by the
opportunity to comment (and indent) this ideas, present daily in our thoughts
while dealing with lilypond -- in some autodidact mode. Thanks to \Mats,
Graham, Han-Wen and of course Pedro Kröger: the responsible for introduce me to
the app.
%}
%The Flute file:
%==
\version 2.4.5
\include header.ly
#(ly:set-point-and-click 'line-column )
fluteINotes = \relative c'' {
\set Staff.instrument = #2 Flautas
\set Staff.instr = #fl
\set Staff.midiInstrument = #flute
%1 I - This is my beloved Son, in whom I am well
pleased.
\tempo 4 = 116 b'4~\fp\( b8 b)-\!\mf r2 |
\time 2/4 R2 |
\time 5/4 b cis4~\fp\( b cis8 b cis)-\!\f r4 r2 |
\time 4/4 R1 |
%5
R1 |
\time 2/4 R2 |
\time 4/4 R1 |
R1 |
ais b8 r8 r8 fis' g- r2 |
%10
r4 cis16 b d ais e'8~ ais e'2~ |
ais e'2. r4 |
r2 ais,16\mf cis e gis r4 |
R1 |
r2 r4 ais16 gis fis e- |
%15
\time 2/4 R2 |
\time 4/4 R1 |
R1 |
b'16 ais fis b, r4 r2 |
cis'16 b gis cis, r4 r2 |
%20
R1 |
b cis16 ais b gis ais8~ gis ais2.~ |
gis ais r4 |
r4 cis d16- b cis-. ais b-. b cis( b' cis8-) b, cis-. ais' b(
[gis ais)] |
ais, b r8 r4 r2 |
%25
R1 |
d'16\f cis ais d,~ d2. |
cis'16 b gis cis,~ cis2.~ |
\time 2/4 cis2~ |
\time 4/4 cis2\ r2\! |
%30
d e16\mf e fis fis gis\fp fis gis\ \repeat unfold 12 fis gis |
\repeat unfold 15 fis gis fis gis\ff\! |
R1 |
R1 |
ais b16\mp \repeat unfold 7 ais b \repeat unfold 8 gis ais |
%35
R1 |
ais b16\p \repeat unfold 15 ais b |
\repeat unfold 16 b cis |
\repeat unfold 8 ais b \repeat unfold 4gis ais \repeat unfold 4fis gis|
R1 |
%40
ais, b16 ais b ais b8~ ais b ais b-. gis ais16 gis ais
gis ais8-. fis gis r8 |
\time 2/4 R2 |
\time 4/4 R1 |
R1 |
cis' d16\ \repeat unfold 7cis d cis d\f\! cis d\\repeat unfold 2
cis d \repeat unfold 4 cis d |
%45
\repeat unfold 15 cis d cis d\! |
R1 |
R1 |
R1 |
R1 |
%50
R1 |
R1 |
R1 \bar
Re: white text on black background
Quoting Marius Amado Alves [EMAIL PROTECTED]: ... All that the manual (version 2.6.6) says about \filled-box is: \filled-box xext (pair of numbers) yext (pair of numbers) blot (number) Draw a box with rounded corners of dimensions xext and yext. I suggest completing this as follows. \filled-box xext (pair of numbers) yext (pair of numbers) blot (number) Draw a box with possibly rounded corners of dimensions xext and yext, where the first number of xext is the horizontal offset of the left side of the box, the second number of xext is the horizontal offset of the right side, the first number of yext is the vertical offset of the bottom side, and the second number of yext is the vertical offset of the top side. All offsets are in staff spaces and relative to the current position. Positive offsets are rightwards and upwards, negative offsets are leftwards and downwards. The blot is the roundness of the box corners, namely the diameter in staff spaces of the circle corresponding to the curve made by each corner, and should not exceed half the size of the width or height of the box, which one is smaller. Naturally a value of zero represents sharp corners. Example: \filled-box #'(-.3 . 1.8) #'(-.3 . 1.8) #0 I'd rather propose to say something like: \filled-box xext (pair of numbers) yext (pair of numbers) blot (number) Draw a box with rounded corners of dimensions xext and yext, where blot is the roundness of the box corners. Example: \filled-box #'(-.3 . 1.8) #'(-.3 . 1.8) #0 which gives a box extending horizontally from -0.3 to 1.8 and vertically from -0.3 up to 1.8, with sharp corners. Which is shorter and, at least in my opinion, just as informative. Every single distance related parameter in LilyPond is specified in units of staff spaces, so that information cannot be repeated everywhere! /Mats ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
impossible layout
I'm getting some odd results. I'm setting a medium sized score (arrangement of Mars from The Planets for large brass ensemble). When processing the score at some font sizes I get impossible output. Impossible in that LilyPond tries to put a system break on a page. The result is that I see just the very tip-top of the second system (as little as two staff lines above the bottem edge of the paper). There is obviously room for only one system per page. Details: Not all of the parts have the information entered yet. At some font sizes this strange behavior disappears. Lily v2.7.34 (recent CVS) Question: Do I need to send a *.ly input file or the PDF for inspection? -David ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: faster lilypond rendering
I produce a 70 pages conductor's score in less than half an hour (and this is a *very* conservative estimate) on a two years old PC. True, it has 2GB of memory, but other than that, it is to be considered a fairly old beast by today's standards. ... And it takes forever on my 700Mhz PII! So, cutting out processing of sections of music is of little use. I'm really looking for faster rendering in general... The final phase of rendering a 28 page conductor's score takes hours. This is much more than twice as long as other scores that are approximately half the length. ... FWIW, this could be caused by or at least exacerbated by poor memory usage in the conversion phase. If the PS to PDF conversion loads the whole document into memory at once, this could all be the result of swap thrashing. A two-year-old PC with 2G ram is not going to be at all equivalent to a 700 Mhz PII, no matter how much ram is being used. As suggested, the small amount of memory is probably the culprit. It may be helpful to look through the manual or the list archives for how to disable the point-and-click feature, which adds information to almost all of the symbols. I seem to recall a thread or three discussing this, and if you are able to disable the point-and-click, you will probably get faster ps-pdf conversion (and faster processing in general). Josiah ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: volta brackets not 'closing'
Quoting Stuart Lowe [EMAIL PROTECTED]:
Folks,
In the first part of a tune I'm doing, I want to have a repeat volta (2)
with 2 alternatives.
Like:
\repeat volta 2 {
\grg f4. _\markup { transition } ( f4. )
\hdblg g4. ( g4. )
\dblA A4. ( A4. )
f8 e8 f8 \dbld d4 e8 \break
\grg f4. ( f4. )
\hdblg g4. ( g4. )
e8 A8 e8 A8 f8 e8
}
\alternative {
{f8 e8 c8 \grg f4.}
{f4 e4 c4 \grg f4. (f4.) \bar || \break }
}
When I do it this way, the 2nd volta bracket doesn't 'close'
(no vertical line on the right edge).
In the second alternative, if I replace
\bar || with
\bar |.
Then it 'closes'. Is this normal behaviour?
At least it's the intended behaviour. I'm not sure how
well-investigated it was or if anybody even remembers why it's done
this way, though. It's been like this in LilyPond
for several years.
Also: in this tune, all of the parts have 8 bars
and are either repeated or written out in full - except for
one part - it has 8 bars but is only to be played once over.
I want to indicate an 'end of part' by doing a ' \bar || '
at the end, but this doesn't get picked up somehow - lilypond
just displays a single bar line at the end of this part.
Hard to say without having seen your code.
/Mats
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: faster lilypond rendering
Citerar Mats Bengtsson [EMAIL PROTECTED]: Quoting Erik Sandberg [EMAIL PROTECTED]: ... BTW, some watching of the process leads me to think that one of the biggest performance sinks is conversion to PDF. Sounds very strange. However, if ps-pdf conversion does take forever, then you can always use the --ps switch to lilypond (which skips the pdf generation phase). Unfortunately, that's not true on Windows, where it seems that GSView is unable to handle Postscript files from LilyPond, no matter what ghostscript version you use. See the mailing list archives for more information. Hm, then maybe -b svg can be used instead. That does however require a decent SVG viewing program. Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: white text on black background
On 15-Feb-06, at 11:36 AM, Mats Bengtsson wrote: Quoting Marius Amado Alves [EMAIL PROTECTED]: \filled-box xext (pair of numbers) yext (pair of numbers) blot (number) Draw a box with rounded corners of dimensions xext and yext. I'd rather propose to say something like: \filled-box xext (pair of numbers) yext (pair of numbers) blot (number) Draw a box with rounded corners of dimensions xext and yext, where blot is the roundness of the box corners. Example: \filled-box #'(-.3 . 1.8) #'(-.3 . 1.8) #0 which gives a box extending horizontally from -0.3 to 1.8 and vertically from -0.3 up to 1.8, with sharp corners. Which is shorter and, at least in my opinion, just as informative. I'd change the ending from , with sharp corners to , with corners formed from a circle of diameter 0 (ie sharp corners). Other than that, I agree that the same information is conveyed in fewer words. I'll update the docs. Every single distance related parameter in LilyPond is specified in units of staff spaces, so that information cannot be repeated everywhere! I agree... but I'm not certain that we define units of staff space anyway. I'm looking for a good place right now. Cheers, - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: impossible layout
David Bobroff wrote: I'm getting some odd results. I'm setting a medium sized score (arrangement of Mars from The Planets for large brass ensemble). When processing the score at some font sizes I get impossible output. Impossible in that LilyPond tries to put a system break on a page. The result is that I see just the very tip-top of the second system (as little as two staff lines above the bottem edge of the paper). There is obviously room for only one system per page. Details: Not all of the parts have the information entered yet. At some font sizes this strange behavior disappears. Lily v2.7.34 (recent CVS) Question: Do I need to send a *.ly input file or the PDF for inspection? yes. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: faster lilypond rendering
Josiah, You got to this response before I could. If the problem is swap thrashing, then having 8x the memory to handle a score that is 3x the pages should be plenty. I had already disabled point-and-click. It helped. The idea of using the PS output for proofing and going to PDF only when I have it right makes some sense. I'll have to fiddle with my makefiles to distinguish the targets. But it should help. Thanks for the suggestion. It still would be nice if ps2pdf would actually manage its memory a bit more subtly. Converting a page, writing to the file and then returning that space to the heap before starting the next page would be nice. Dick On Wed, 2006-02-15 at 12:35 -0800, D Josiah Boothby wrote: I produce a 70 pages conductor's score in less than half an hour (and this is a *very* conservative estimate) on a two years old PC. True, it has 2GB of memory, but other than that, it is to be considered a fairly old beast by today's standards. ... And it takes forever on my 700Mhz PII! So, cutting out processing of sections of music is of little use. I'm really looking for faster rendering in general... The final phase of rendering a 28 page conductor's score takes hours. This is much more than twice as long as other scores that are approximately half the length. ... FWIW, this could be caused by or at least exacerbated by poor memory usage in the conversion phase. If the PS to PDF conversion loads the whole document into memory at once, this could all be the result of swap thrashing. A two-year-old PC with 2G ram is not going to be at all equivalent to a 700 Mhz PII, no matter how much ram is being used. As suggested, the small amount of memory is probably the culprit. It may be helpful to look through the manual or the list archives for how to disable the point-and-click feature, which adds information to almost all of the symbols. I seem to recall a thread or three discussing this, and if you are able to disable the point-and-click, you will probably get faster ps-pdf conversion (and faster processing in general). Josiah -- Dick Schoeller mailto:[EMAIL PROTECTED] http://schoeller.hsd1.ma.comcast.net/ 781.449.5476 ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Fonts for Dynamics messed up during printing?
Yeah, I found an earlier post to this group linked through the web talking about Preview not handling embedded fonts very well. I resorted to using Aacrobat and it seems to work fine. On a side note, I could only get the error to manifest when printed on certain printers. It's quite possible viewers would also suffer although I haven't found one that does. Lilypond-book is ok except I don't want to run my thesis through yet another process to create the few figures that I use. I did use lilypond-book with dummy tex files that just had a figure in them so I could get lilypond-book to produce .ps files that encapsulate just the music and not a full page as lilypond proper does. I found that a bit annoying and so I switched to pdf cropping in preview and hence my problem. On Tue, Feb 14, 2006 at 05:55:57PM -0800, Graham Percival wrote: On 14-Feb-06, at 1:53 PM, Edwin Vane wrote: So I have a line of music that I typeset with Lilypond. Because I only want that line, I extracted it from the full page output using Preview (I'm on Mac OS X.3.9). I then include the line as a figure in a latex document I run pdflatex on. I suggest lilypond-book for this. Lilypond code directly in latex documents -- what could be better? :) Before I spend time hunting the problem down, has anybody else heard of this or have any suggestions as to where to start looking for the problem? I can't help, but I can confirm this behavior here (10.3.9). I don't know enough about fonts and pdf to investigate, but I can't successfully extract pages from a large document using Preview. I'm pretty certain this is Preview's fault, though; the lilypond pdf prints beautifully if I only print certain pages. (instead of Preview - print as pdf - print resulting pdf) Cheers, - Graham -- Edwin Vane MMath Candidate Computer Graphics Lab School of Computer Science University of Waterloo ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
