Issue #612 presents a patch
http://codereview.appspot.com/28134
which apparently hasn't been applied since the snippet given in the
bug report still produces the same output with 2.13.1...
Was this intentional or an oversight?
Werner
___
lil
> Issue #612 presents a patch
>
> http://codereview.appspot.com/28134
>
> which apparently hasn't been applied since the snippet given in the
> bug report still produces the same output with 2.13.1...
>
> Was this intentional or an oversight?
Since this is one of the most serious elementary
>> Since this is one of the most serious elementary typesetting bugs
>> which lilypond exposes, and which can easily happen in any piano
>> score, I vote for quick inclusion.
>
> Well, Joe had a lot of comments for Chris, and I can't find a
> follow-up patch, so I think we should wait until we hea
> The problem IIRC is that the solution I had suggested to Chris
> wasn't acceptable (with good reason) to Han-Wen. Chris
> understandably doesn't seem too keen on throwing his work away and
> starting again with another idea of mine.
Hmm. There is no such comment in the bug tracker, which is
u
> I'm still intending to follow up on it at some point, but I don't
> see myself having much available time until August.
Thanks. IMHO, this kind of bugs which are quite serious IMHO should
get a special tag in the bug tracker, perhaps something like
`priority'. BTW, I'm currently not aware of
>> IMHO, this kind of bugs which are quite serious IMHO should
>> get a special tag in the bug tracker, perhaps something like
>> `priority'.
>
> I don't know if they're as visible as #612, but I find #379 and
> #427 personally aggravating. I think those two bugs currently
> prevent LilyPond from
>> In other words, some makefile hacking is needed, which I would
>> probably need to delegate.
I agree.
> I doubt that the regtests compile without warnings,
Correct. Some of them are even expected to emit warning or error messages.
> and I'm not certain that we have enough Frogs to eat all t
> The new option, -dwarning-as-error, does *not* turn every warning into
> an error. It only turns specific warnings (that don't exist without
> this patch) into errors.
Then the name is indeed too generic and should be temporarily renamed
to something more specific until the code has been impro
> I've also attached 2 png's to demonstrate the difference: the first
> one (current.png) was compiled with the current autochange.scm and
> the second one (revised.png) was compiled with my revised patch.
> You can look at the test file below to see how it is set up.
The results looks fine for m
>> Anyway, I think that it would make a lot more sense if the staff
>> were determined by the "average" pitch of the chord.
>
> I don't think so. The purpose of staff changes is to avoid help
> lines.
Perhaps it makes sense to provide different `modes', depending on the
purpose.
Werner
> Would it be technically feasible/possible to establish a system of
> "anchors" instead?
This would be indeed a great feature!
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
> Instead of documenting this in the IR, maybe it would be better to
> write a section in the CG about how to find a grob's parent, the
> parent's parent, etc. with GDB?
Hmm. Any chance to have this in Scheme?
Werner
___
lilypond-devel mailing l
> Here's one way of doing it (from within a music block).
Very nice! Perhaps this can be wrapped into an even more convenient
function so that a user just have to say, for example,
\getAncestry { }
at the place where grobs have to be manipulated.
Definitely very useful stuff!
Werner
>> Thanks for adding this to the snippets. Maybe I'll post a better
>> explanation later. Anyway, wouldn't it be better to add this to the
>> font?
>
> For a single vertical line, I suspect this would be overkill –
> Unless we officialy include it alongside the other articulation
> marks. Werner
> I reformatted the output (slightly) to minimize duplicates. Do you
> prefer this version or the earlier one?
The more compact solution is the better one. A minor nit: Please
start the output with a newline: I get this on the TTY:
Interpretation der Musik...
Vorverarbeitung der grafischen
> I've uploaded the patch for review at
> http://codereview.appspot.com/97119
Since I don't understand the code at all, I've only a minor comment:
Please use two spaces after a full stop in documentation strings for
consistence.
Thanks for your hard work!
Werner
_
>> Thanks, Neil. My editor does confusing things with tabs.
Then use a different editor.
>> I hate them.
I dislike them, too, but there are many editors which handle them just
fine. I don't see a problem here.
Werner
___
lilypond-devel mailing
>> Please use two spaces after a full stop in documentation strings for
>> consistence.
>
> Since this is incorrect typographical practice,
It really depends. IIRC, the Chicaco manual of style recommended
this.
> and Lilypond prides itself on beautiful typography, I'm surprised
> this is the s
> "The view at CMOS is that there is no reason for two spaces after a
> period in published work."
Ok, whatever :-) Look up references to TeX and LaTeX for more on this
topic.
> However, the PDF (e.g., the NR) *appears* to preserve double-space
> sentence separations — where (e.g., some
> specif
>> Indeed, I just see that @frenchspacing is only used for French and
>> Japanese (the latter only partially). It should be activated for all
>> languages except, perhaps, English. Note that I don't care what you
>> native speakers actually decide for English
>
> Excellent! Then I nominate @fre
>> Then I nominate @frenchspacing (i.e., single-spaced sentences) be
>> used for the English docs, consistent with the overwhelming
>> majority of modern English typographic style guides and practice...
>> Seconder? Opposed? Abstentions?
>
> Don't we want to be following the GNU Coding Standards?
> - What is a good name for the new articulation?
I suggest `vertical stroke'. At least this seems to be the name
referred to in the literature for the staccato-like symbol which
Mozart uses.
> - What should be the precise shape (width/height ratio)? Currently I
> use height = 1 staff_space and
> Some cyrillic glyphs in Century Schoolbook L font (and in
> TeXGyreSchola too) are ugly: they have strong difference from font
> "Shkolnaya" which described by Soviet standard GOST 3489.23-71 and
> from some Schoolbook TrueType/OpenType fonts:
> http://www.ljplus.ru/img4/s/h/shoorick/compare_sch
> Duh, I tracked down the problem; sorry for the delay, I would have
> solved it earlier if I wasn't an idiot or with more complete make
> logs, as I didn't got this failure on my machine, probably because
> of the typical order make compiles Lily docs on it.
It still fails for me on my GNU/Linux
>> For Mozart, the stroke should perhaps a bit shorter -- maybe two
>> different symbols?
>
> Attached are two samples for long and short strokes with varying
> width. The long strokes have height = staff_space, the shorter ones
> height = 0.8*staff_space (is that a reasonable choice?). Each fil
>> Additionately, maybe it would be nice to increase the >relative<
>> thickness of the stroke on smaller staff sizes as it's described in
>> NR 4.2.1 for the Feta font. Otherwise the line will look too thin
>> at smaller staff sizes, I think.
>
> Ah, interesting point. I have no clue, though, h
>> It still fails for me on my GNU/Linux box (using git e306bf5d from
>> today, checked out cleanly in a separate directory with `git
>> clone'). The first documentation file processed is snippets.tely,
>> then followed by notation.tely which aborts since identifiers.tely
>> is missing.
>>
>> Some
> I really hope I got it right in the commit I just pushed to master
> and lilypond/translation.
It works now, thanks.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Is there a difference between \pad-around and \pad-markup? Reading
the documentation and looking at the examples, I can't see any. In
case there are differences, this should be documented. Otherwise I
suggest to mark one of the two commands as deprecated.
Werner
[git 17492869]
In notation-big-page.html, the output of the snippet which documents
\wordwrap-field is broken: It only shows the `title' field; the
`description' field is completely missing.
Werner
___
lilypond-devel mailing list
lilypond-devel@g
[git 17492869]
The \eyeglasses example image in notation-big-page.html is apparently
cut off at the right. This probably indicates that the bounding box
of this glyph has incorrect values.
Werner
___
lilypond-devel mailing list
lilypond-devel@g
> I prefer to keep pad-around since it is more descriptive.
OK.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
> I experimented a little bit with one possible solution, but I don't
> know how practical the rest of you will find it. For each parser
> variable, it is possible to define a separate "default" value. The
> existing variable would be initialized to the default value, and it
> would be reset to
>> What about resetting all such variables automatically at the
>> beginning of a new \score block?
>
> Awesome! How?
No idea! :-)
Han-Wen?
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilyp
Carl,
can you modify yyout2grammar.py to avoid overlong lines? For example,
it currently generates
206 music_function_chord_body: music_function_identifier_musicless_prefix
EXPECT_MUSIC function_arglist_nonmusic chord_body_element
207 | music_function_identifier_m
For longer pieces, lilypond takes ages for the `preprocessing
graphical elements' stage. For the novice, it might appear that
lilypond hangs. Any chance to add a progress indicator, for example,
giving the ratio between the total number of grobs and the grobs
already processed?
Werner
__
The documentation of the new `after-title-spacing' property and its
siblings is missing. Additionally, there are no regression tests
showing those parameters in action.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.g
>> Any chance to add a progress indicator, for example, giving the
>> ratio between the total number of grobs and the grobs already
>> processed?
>
> What could be done is having a progress indicator showing the number
> grob/property combinations that were computed.
OK. Even a rotating dash wo
> IIUC, one interesting advantage of this is that scheme symbols
> have less restrictions than parser identifiers:
>
> \anchor #'m.32
> \anchor #'flute2-entrance
Mhmm, this is not something we should advertize loudly...
Werner
___
lilypond-deve
>> > IIUC, one interesting advantage of this is that scheme symbols
>> > have less restrictions than parser identifiers:
>> >
>> > \anchor #'m.32
>> > \anchor #'flute2-entrance
>>
>> Mhmm, this is not something we should advertize loudly...
>
> Why not?
I believe it confuses users that Scheme code
> Looking at an example from Ted Ross (see attached png), I'm
> thinking that Dot_column_engraver may be better suited in the
> Voice context than in the Staff context.
Good idea.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
htt
> It's only for some exotic tweaks that you might want to change the
> fraction to something else than the default 15/16...
Hmm. Section 1.2.6 in notation.pdf says that 3/4 is the default value
for \afterGrace. A documentation bug?
Werner
___
[You should use bug-lilyp...@gnu.org -- lilypond-...@gnu.org doesn't
work IIRC!]
> A clue for our brave developers: The attached image made from
>
> \stemDown c4 c\longa
>
> shows that the skyline mechanism does not consider the longa' stem
> worth to be skylined.
This is not a clue, this i
>> becomes @qq{}
>
> One small concern: produces double-quotes, whereas our texinfo
> @q{} produces single quotes. I don't think it's a big deal, but
> it might confuse somebody down the road.
Read it again, Graham :-)
Werner
___
lilypond-de
In notation.pdf, section 1.8.3, `Single entry fonts', the `Charter'
font is used. However, on my GNU/Linux platform, I have both bitmap
and outline Charter fonts installed. Specifying `Charter' only
selects the bitmap variant which is of course rejected by lilypond.
What about changing the font
> On my Fedora 11 box, I get
>
> $ fc-match "Bitstream Charter"
> bchr.pfa: "Bitstream Charter" "Regular"
Good.
> [lily...@freemousse master]$ fc-match "Charter"
> DejaVuSans.ttf: "DejaVu Sans" "Book"
OK, this means that `Charter' alone even fails on your platform
(because you apparently don't
> Here are my results (Arch Linux):
>
> $ fc-match "Bitstream Charter"
> c0648bt_.pfb: "Bitstream Charter" "Regular"
>
> $ fc-match "Charter"
> charR12.pcf.gz: "Charter" "Regular"
I get exactly the same, BTW, with my openSuSE 11.1.
Werner
Folks,
assume that I've compiled lilypond from scratch, say, two weeks ago,
together with the full documentation. Is it OK nowadays to say
git pull
make all
to *really* have a good build? For example, I see that there are no
makefile rules which handle changes to configure.in or aclocal.
[git b6e82e5a from today]
Joe,
since documentation of your changes is not yet available, I have to
ask directly: What's the new method for providing proper distances
between the header, the body, and the footer of a page? If I do it
the old way (this is, I just run a new lilypond binary on my
[git 2eee8fa8 from today]
Does ancient music work correctly -- I mean `correctly' to the extent
of the limited support we have? Looking at the headword of section
2.8 (Ancient notation), I see that the very last note clashes with the
final double barline. Additionally, if I change the \paper se
> \break doesn't always work where you'd expect; this is because the
> divisiones are breath marks not barlines. So doing "\finalis \break"
> doesn't always work. In fact, the VaticanaVoice context defaults to
> 4/4 time-signature, even though this is meaningless in Gregorian
> Chant. So "\finalis
> I'm not sure what's going on here, Werner, but something which might
> improve matters would be to use barlines for divisiones instead of
> breathing signs: since Joe's fixed the spacing problems associated
> with empty barlines, it should be possible to reinstate barAlways =
> ##t together with
> As for the example I posted, I did say it was a quick test; to
> implement this change properly will involve amending
> engraver-init.ly as well as gregorian.ly (following a careful check
> that it doesn't cause any problems elsewhere).
Yes. Please do so :-)
Werner
>> For example, I see that there are no makefile rules which handle
>> changes to configure.in or aclocal.m4...[1]
>
> Should we ever have one?
IMHO yes.
> I'm not sure this is a good idea, because AFAIK make can't rerun
> configure with all the options the user could wish, so configure
> (and
> Are there any guidelines LilyPond adheres to for creating bounding
> boxes?
No.
> For example, when I adjusted the bbox for the \eyeglasses markup
> command, I _underestimated_ the bbox. Should I have slightly
> _overestimated_ instead? Attached is a PNG displaying the bbox.
I think overesti
>> What's the new method for providing proper distances between the
>> header, the body, and the footer of a page? If I do it the old way
>> (this is, I just run a new lilypond binary on my score) the footer
>> line gets always attached to the body without any vertical space
>> inbetween,
>
> You
> One has to keep in mind that Metafont does not permit more than 16
> different heights per font (something like that, I don't remember
> the exact details).
Yes, this problem already bites us. I'll add a bug tracker item which
suggests to split the Metafont output into even smaller units, say,
>> configure.in has been modified! Please rerun `autogen.sh',
>> then `make all' again.
>
> Done.
Thanks.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
> I'll add a bug tracker item which suggests to split the Metafont
> output into even smaller units, say, 16 glyphs per subfont, to
> circumvent the problem. It's basically a logistic change which can
> be done even with minimal knowledge of the Metafont language --
> perhaps this is something fo
> The overlap between "Ecce panis" and "Allegro" is due to a bug (that
> you and Werner have already found) regarding rehearsal marks not
> being counted in the spacing problem.
You haven't fixed this, right?
Werner
___
lilypond-devel mailing lis
> if you can explain me what should I do, I would try to make it.
OK. However, it seems to be more complicated than thougth at a first
glance. Anyway, here a rough outline how it could be done.
1. Metafont is called for those fonts:
feta11.mf, feta13.mf, ...,
feta-braces-a.mf, feta-
>
>> feta-eindelijk
>> feta-toevallig
>> feta-arrow
>> feta-puntje
>> feta-bolletjes
>> feta-schrift
>> feta-banier
>> feta-klef
>> feta-timesig
>> feta-pendaal
>> feta-haak
>> feta-accordion
>
> I've always wished those were in English.
> Pushed to git.
Thanks a lot!
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
>> Regarding your "Top" context: why do you override VerticalAxisGroup
>> #'Y-extent = ##f? This is likely to confuse the layout algorithm
>> even after the bug I mentioned is fixed.
>
> This was necessary for the old vertical layout engine -- at least it
> served me well since a few years. I'l
> feta-pendaalfeta-pedal
Perhaps feta-pedalsigns?
> feta-accordion feta-accordion
feta-accordionsigns?
> feta-timesigfeta-timesig
feta-timesignatures?
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu
>> However, there are still formatting problems, as given in the
>> example below. See attached image.
>
> Is your git up to date? With 38a4db2d15f4 (my last commit) and
> 16d16717f3 (current HEAD), I get the attached output.
Oops, my mistake! Sorry for the noise. Everything's fine now.
Thank
[git d4310174]
Consider this snippet:
\new Staff {
<< { s1^"Foobar"
s1 }
{ R1
R1^\fermataMarkup }
>>
}
As can be seen in the attached image, the text markup gets a higher
`inside' priority than the fermata. I think this is wrong, since in
most cases there i
> So, if I am understanding correctly, LilyPond currently uses the
> same dimensions for both the "metrics" box and the "bounding" box
> for each glyph. This is why the longa glyph, for example, is
> cropped in the EPS/PNG output. Is this true?
I think so. On the other hand, we need an exact bb
>> I'll add a bug tracker item which suggests to split the Metafont
>> output into even smaller units, say, 16 glyphs per subfont, to
>> circumvent the problem.
>
> This is red herring. The metrics for feta are computed by parsing the
> metafont .log file. The .TFM files are unused, because of
[about Makefiles]
> Don't waste your time understanding them, as their timelife is now
> known to be very limited.
Are you sure that SCons is the right choice? What about cmake?
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
htt
> FWIW, I used to think that this would be a very important feature;
> now I'm not so sure. There are certainly a few cases (eg. slurs,
> hairpins, treble clefs) where having more accurate outlines would
> help.
It would also help in improved positioning of accidentals.
> But the list is fairly
>> As can be seen in the attached image, the text markup gets a higher
>> `inside' priority than the fermata. I think this is wrong, since
>> in most cases there is nothing between a rest and the fermata above
>> it. BTW, this problem doesn't happen if you replace the rests with
>> notes in the
>> However, we need a mechanism to improve the more critical cases.
>
> Maybe attaching some "ghost characters" without actual content to
> the glyphs might be possible, where the total outline is determined
> by overlaying all the bounding boxes?
This is a very nice idea! For example, the
>> That patch changed the grob type from TextScript (?) to
>> MultiMeasureText, so
>
> The grob type hasn't changed: if you add a markup to a multi-bar
> rest, the function `script-to-mmrest-text' converts the ScriptEvent
> to a MultiMeasureTextEvent.
>
>> yes, it changed the priority, from what I
> I think that the two boxes
>
> 11
> 11
>222++222
>2 11 2
>222++222
> 11
> 11
>
> should suffice for most practical purposes...
Maybe. This is something which should be tested as soon as someone is
going to write support for it
Folks,
I've just seen this change in a recent commit:
+...@seealso
+
+Installed Files:
+...@file{lily/parser.yy}
IMHO, this is not correct: lily/parser.yy does *not* get installed at
all! Either we introduce a special macro which points to the source
tarball, or we omit references lik
> Grr, it doesn't work so well, though: This will not work in the
> first measure of a line or immediately after a time signature
> change!
What about attaching a markup text consisting of \hspace only,
together with \textLengthOn?
Werner
___
li
[git 17e68b85]
`make doc' fails with
...
convert annotated-demo.svg out-www/annotated-demo.png
convert: Must specify image size `/tmp/magick-XXqtAIPz'.
convert: missing an image filename `out-www/annotated-demo.png'.
make[3]: *** [out-www/annotated-demo.png] Error 1
This is `convert'
[git dd442f49]
This simple input
\relative {
\repeat unfold 31 { c'1 r r r r r r r }
}
makes the vertical layout overflow instead of properly filling two
pages. If you slightly increase the repeat factor, the lowest staves
even fall off the bottom of the page.
Werner
<>__
[git dd442f49]
There is a horizontal offset bug if a markup is attached to a skip.
Look at this small example:
\paper {
ragged-right = ##f
}
foo = {
s1
\time 7/8 s8*7^"foobar"
\time 10/8
}
bar = {
R1
R8*7
}
<<
\context Staff = "foo" \foo
\context
[Sorry if this has already been dealt with; I'm abroad, with no access
to the internet.]
This change
+ convert -depth 8 \
-alpha Off \
-background white \
-layers flatten \
-trim \
+repage \
$<
>> Any idea how to fix my issue?
>
> Change MultiMeasureRestText #'outside-staff-priority so it's lower
> than TextScript #'outside-staff-priority.
OK.
>> Shall this be added to the bug tracker as a regression?
>
> I don't think so; we just need to agree on a more appropriate value
> than the c
>> It seems that (a) either `convert' or the file has some problems
>> (but inkscape loads it without problems) and (b) that it has been
>> forgotten to add a PNG version of this file.
>
> As for (b), I wanted to add png versions:
> http://lists.gnu.org/archive/html/lilypond-devel/2009-08/msg00730.
>> Basically, I agree, but the case of SVG is quite problematic since it
>> relies on external fonts at certain locations. In particular,
>> `annotated-demo.svg'
>
> We don't use annotated-demo.svg.
Well, but due to the generic SVG->PNG rule in GNUmakefile it is
converted anyway, and this conver
>> Hmm. I currently can't imagine a situation where a value > 0 is
>> needed, so I vote to remove the setting of #'outside-staff-priority
>> for MultiMeasureRestText -- however, I'm not sure whether this has any
>> influence to issue #495 (this looks rather unrelated to
>> #'outside-staff-priorit
> This effect seems to be a consequence of ragged-right = ##f together
> with a second bar containing a single note (or space). When the
> second bar is stretched to fill the line the note gets displaced
> almost to the centre of the bar. This simpler example shows the
> same effect:
>
> \paper
> Additionally, it seems that some `convert' versions are buggy.
> Look, for example, at the attached image, created with version
> 6.4.3. For testing, I've manually issued the current Makefile rule
>
> convert -depth 8 \
> -alpha Off \
> -background white \
> -la
> This patch adds scripts.lvide and scripts.rvide glyphs to the
> parmesan font:
>
>http://codereview.appspot.com/110073
>
> An example is attached.
>
> Okay to apply?
I've never seen these symbols, and I've seen a lot of scores...
What's your source?
Werner
From: Patrick McCarty
Subject: Re: [git 17e68b85] make error in documentation
Date: Mon, 24 Aug 2009 13:02:11 -0700
> On Mon, Aug 24, 2009 at 7:12 AM, Werner LEMBERG wrote:
>>
>>> Additionally, it seems that some `convert' versions are buggy.
>>> Look, for example
> A while ago we had that discussion about a user wanting two vertical
> lines on each side of the breve instead of one. I have now prepared
> a patch for our font, which adds such a "noteheads.sM1double" glyph:
> http://codereview.appspot.com/109075
> This patch also defines a notehead style '
> I would argue against introducing this complication. Positioning
> spacer rests differently to notes of the same duration does not seem
> a good idea.
Well, my example shows that it actually uses a *different* position
compared to the full rest -- if we follow your suggestion, this is a
real bu
>> > After all, it is very easy to place the markup where you want it by
>> > simply using two spacer notes:
>> >
>> > foo = {
>> > s1
>> > \time 7/8 s8^"foobar" s8*6
>> > \time 10/8
>> > }
>>
>> OK, I haven't thought of that solution, thanks. This should perhaps
>> be added to the documentat
> Both the note and the spacer in the second bar are positioned in
> roughly the centre of the bar, although interestingly not quite in
> identical positions. I don't know why they differ slightly, but you
> see my point.
Here's another example -- it's yours slightly extended -- which
probably sh
The files
Documentation/topdocs/AUTHORS.info
Documentation/topdocs/INSTALL.info
Documentation/topdocs/README.info
Documentation/topdocs/lilypond-changes.info
aren't removed if you say `make distclean'.
Werner
___
lil
> Werner, does the conversion from SVG->PNG work for you now? I'll add
> a configure rule soon if this does solve the problem.
It's better (see attached image) but not really good -- inkscape still
produces better results.
Werner
<>___
lilypond-d
> It's better (see attached image) but not really good
BTW, I've tested with ImageMagick 6.5.5-2, with librsvg version
2.22.3.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
>> It's better (see attached image) but not really good -- inkscape still
>> produces better results.
>
> What was wrong with that image? Looks fine to me, and that's what
> I see from my own conversion.
Attached is the inkscape rendering. Note how the green and blue box
are now synchronized co
Can someone please tell me the commands (lilypond and gs, I assume,
with *all* options) to convert a LY file to PNG and to PDF, as used
for the notation reference? The full set of options to lilypond isn't
shown in the log file...
Werner
___
lil
>> After all, it is very easy to place the markup where you want it by
>> simply using two spacer notes:
>>
>> foo = {
>> s1
>> \time 7/8 s8^"foobar" s8*6
>> \time 10/8
>> }
>
> OK, I haven't thought of that solution, thanks. This should perhaps
> be added to the documentation.
There is a s
> I assume that "needed" and "unneeded" aren't actually
> contradictions... or maybe they are, and that's why the internal
> error is printed.
They are contradictions, thus the internal error. It's a rounding
issue in FontForge.
> Executable based on sources from 00:29 GMT 29-Apr-2008.
> Libra
101 - 200 of 3522 matches
Mail list logo
