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.
Well, it isn't. I think
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'll test
feta-pendaalfeta-pedal
Perhaps feta-pedalsigns?
feta-accordion feta-accordion
feta-accordionsigns?
feta-timesigfeta-timesig
feta-timesignatures?
Werner
___
lilypond-devel mailing list
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.
Thanks for
[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 is
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 bbox only
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 the
[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
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
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 can see.
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
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
___
[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
inline:
[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 Staff
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 current
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 conversion
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-priority to me)
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 \
-layers
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 pnor...@gmail.com
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 LEMBERGw...@gnu.org wrote:
Additionally, it seems that some `convert' versions are buggy.
Look, for example, at the
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 bug
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.
I think you mean added
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 sheds
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
___
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
inline:
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
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
___
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 serious drawback of
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.
Library based
Here is a patch that introduces a command line option aux-files,
which can be used (-daux-files=#f, -dno-aux-files or #(ly:set-option
'no-aux-files)) to prevent lilypond's eps backend from creating
.tex(i) and .count files:
http://codereview.appspot.com/110107
Okay to apply?
Nice
Hmm. I've seen these errors for a long time now (maybe a year and a
half), and I'm always using the latest fontforge tarball.
Testing CVS, I get similar errors, first appearing with feta11:
Interesting. I haven't seen them since a long time. Please report
this to the FontForge list. Here
While you are at it, please investigate why there are still
clipping problems during the EPS-PNG conversion. For an example,
look at the snappizzicato example image in the notation reference.
The bounding box of the generated eps files is simply obtained from
the scencil extents plus the
Here are my configuration settings for FontForge on a i586 GNU/Linux
box: [...]
--enable-double
IIRC, this option is the very one which makes the problems disappear.
Hmm. Perhaps it's better to write to the various distribution
packagers, urging them to compile FontForge with
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-priority to me)
It seems sensible to have a distinct, lower, value, but something
like 40 would place it below everything else while retaining some
future flexibility.
OK. Shall I commit this or will you do that?
Werner
___
lilypond-devel mailing list
Draft regtest and pdf output attached.
Thanks for your work!
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Jan proposed SCons [0], and after having read SCons User Manual, I
think we could make good use of it. However, SCons has severe speed
issues, which Waf [1], one of his younger (and Python-based, just
like SCons) competitors, doesn't have -- see benchmarks [2] and [3].
Please have a look at
For the record (as discussed in private email), I'm quite concerned
about waf's relative new-ness and occasional lack of development.
My preference would be to use a stable, widely used build system,
since any problems in the build system can cause a huge problem to
developers. [...]
BTW,
Let's assume I've checked out a fresh master/origin and did some
commits on top of it. How can I concatenate this commits in one to
create only one patch?
Do
git reset ...
so that non of your changes are committed (`gitk' is your friend to
find the right SHA). Then do
git commit -a
Ouch. so as soon as a LGPLv3 version of guile comes out, lilypond
can't use guile any more, because LGPLv3 is not compatible with
GPLv2... So, lilypond then has to switch to GPLv3... But then we
have a problem with freetype, which is FTL (BSD with advertising
clause, thus incompatible with
What's the reason that line breaks are by default forbidden if there
is a broken beam crossing the bar line, and that you have to set the
`breakable' flag manually to override it?
BTW, it is very unpleasant that lilypond doesn't emit any kind of
warning if it produces an overlong staff caused by
I think something like the following patch should be applied so that
the \Dynamics context supports the `to-barline' property of hairpins.
However, I haven't tested whether it has any negative side effects.
Werner
==
What's the reason that line breaks are by default forbidden if
there is a broken beam crossing the bar line, and that you have to
set the `breakable' flag manually to override it?
BTW, it is very unpleasant that lilypond doesn't emit any kind of
warning if it produces an overlong staff
I *do* suspect there's a problem with the @lilyvindex macro, though.
I doubt that since I've basically duplicated code from texinfo.tex.
On the other hand, it is possible that the standard indexing macros
don't work well for non-ASCII stuff; this would indicate a generic
problem.
But I can't
@tex
-\gdef\lilyvindex#1{\doind{vr}{\code #1}\ignorespaces}
+\gdef\lilyvindex#1{\doind{vr}{\code{#1}}\ignorespaces}
@end tex
Blush :-)
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
-\gdef\lilyvindex#1{\doind{vr}{\code #1}\ignorespaces}
+\gdef\lilyvindex#1{\doind{vr}{\code{#1}}\ignorespaces}
... and applied, thanks.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
I've added a general event class, BreakSpanEvent, as the parent
class of BreakDynamicSpanEvent since I'd eventually like to
implement commands analogous to \breakDynamicSpan for some of the
other alignment spanners (e.g., pedals and figured bass).
Awesome, thanks for your work, Neil! Just
Ping!
Werner
==
From: Werner LEMBERG w...@gnu.org
Subject: support of `to-barline' property in \Dynamics
Date: Fri, 25 Sep 2009 21:06:18 +0200 (CEST)
I think something like the following patch should be applied so
Ping!
Werner
==
From: Werner LEMBERG w...@gnu.org
Subject: Re: line breaks and broken beams
Date: Sun, 27 Sep 2009 16:08:31 +0200 (CEST)
What's the reason that line breaks are by default forbidden
Isn't the problem that beams create melismata in vocal music, and
you don't want to have a line break in the middle of a melisma?
Hmm. How often does this happen in real scores? I think that in most
circumstances good (and thus flexible) spacing is much more important,
and a user should
Would it be feasible to create new listeners/performers/contexts
purely in Scheme, by having generic enough C++
listener/performer/context factories that one can fit in everything
worth having by using Scheme?
Well, there are ongoing efforts to move more functionality from C++ to
Scheme
I'm talking about developer tools. For example, some months ago I
got the advice to use grep to browse LilyPond source code.
BTW, have you found something better?
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
I'm talking about developer tools. For example, some months ago I
got the advice to use grep to browse LilyPond source code.
BTW, have you found something better?
Eclipse is quite good at finding macro definitions etc., but it
relies on some special build configuration, i must set up first
Here is patch implementing the chord repetition shortcut that has been
discussed a few times, [...]
Wonderful!
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Though strings are valid markup objects according to the type
predicate `markup?', the parser only recognizes full_markup objects
as valid for music functions, which means it's currently impossible
to pass both strings and markups unless using Scheme.
I've posted a modest patch here,
This
OTOH, something like
{ c e g8-. c e g-^ }*2
is not doable with the q approach.
Why not?
\repeat unfold 2 { c e g8-. q-^ }
Please stop trying to overload the * operator.
Well, David has a point here IMHO: The `\repeat unfold' really is
neither elegant nor intuitive nor quickly to
The rules are already defined (albeit unsatisfactorily in my opinion):
Do whatever emacs does.
Then, for goodness' sake, why not write a small elisp program to use
Emacs in batch mode on the command line (yes, this is possible) to
format one or more files? Emacs runs on Windows too, and
Please review this patch:
http://codereview.appspot.com/152127/show
Very nice!
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
[using cc-mode for automatically formatting C++ code of lilypond]
IIRC, you mentioned this before; I think it's to do with (your)
emacs expecting a colon at the end of the macro (which isn't
strictly necessary).
D'oh. I mean semicolon of course. :)
In case we are going to automatically
I don't think that I can contribute much more to your amusement.
Wow.
I've [fortunately] never witnessed such mindless negative energy on
a mailing list to which I've been subscribed.
Guys, cool down. I think everyone of you is interested to improve
lilypond, perhaps it helps if all of
Please see #924.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
It seems that the algorithm for optimal page turning is designed for
recto and verso pages. In other words, the `first-page-number' paper
variable is also an important parameter controlling the layout.
Is this correct? However, it is mentioned nowhere.
Werner
See issue #926. This makes the Dynamics context quite useless.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
I was amused by the recent punctuation fix commit: [...]
BTW, may I remind to have TWO spaces after a full stop, exclamation
mark and question mark at the end of a sentence. This is both useful
for certain editors (like Emacs), and it helps the text-mode info
browser to break lines.
IIRC, this
BTW, may I remind to have TWO spaces after a full stop, exclamation
mark and question mark at the end of a sentence.
That is the practice I recall from my time typing others doctoral
thesi. Sadly it is not the norm for html or many modern
text-setting applications which ruthlessly trim
Graham,
is it correct that all fixes, regardless of its annoyance, get a `low
priority' in case it won't become part of the next `milestone'
release?
I consider this categorization a bit coarse, and I would like to see
at least one more level to mark bugs as `annoying' or something like
that.
If you'd entered them yourself as both Medium, or both
Low, I wouldn't have said anything.
OK.
- Low: the normal priority. Sorry, but we just don't have many bug
fixers! I favor honesty over trying to make users happy about
assigning their pet issue a higher priority flag that nobody
If you would like to change the priority between postponed, low, and
medium issues -- either raising the priority of a postponed or low
one, or lowering the priority of a low or medium one -- go ahead.
I'll eventually do that for my own bugs. However, it's basically the
job of the bugmeister
1. Severity of the Bug.
2. Probability of occurrence of the bug.
3. Difficulty of working around.
Very nice!
Of course, I'm not proposing that anybody stop fixing bugs in order
to perform this calculation. I just wanted to get the thought in
this thread in case we ever want to seriously
See issue #926. This makes the Dynamics context quite useless.
Fixed in git.
Thanks!
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Thanks to Neil, TextSpanner items are now displayed in `Dynamics'
contexts. However, this exhibits another serious annoyance, as shown
in bug issue #928.
This time, I've tagged my bug report with `medium'...
Werner
___
lilypond-devel mailing
Could someone please check issue #774 with a stable release (either
2.10 or 2.12) so that I can probably set the regression flag? At the
time of my report, I only had 2.11.13 for comparison, which is a
developer's version, and I still don't have any stable releases
installed.
Werner
Could someone please check issue #774 with a stable release (either
2.10 or 2.12) so that I can probably set the regression flag? At
the time of my report, I only had 2.11.13 for comparison, which is
a developer's version, and I still don't have any stable releases
installed.
Yes, it
Neil,
have you finished your work on fixing #305? I can vaguely remember
something into this direction ...
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Two options:
%% The second upper c octave is computed from the first c
%% i.e. the last explicite note.
\relative c' {
c e g8 c' q c r4 q
}
%% The second upper c octave is computed from the previous
%% repeated chord (q)
\relative c' {
c e g8 c' q c' r4 q
}
I'd favor the
So I'd think it would be nice to write something like
{ G4 g D // | // // | \time 3/4 G g / | D // / | // // / | }
(number of slashes corresponds with how far you have to look
backwards, in this case counting slash sequences new when they
appear) or without reslash memory
[all lilypond documentation snippets running through lilypond-book get
a horizontal offset of 3mm to the right]
I redirect this discussion to lilypond-devel.
[...] The lilypond-book option --left-padding controls this; if
not given, a default value of 3mm is used. Main reason to use have
a
1) Fix issue #628, whereby grob 'style settings (e.g., TextSpanner
#'style = #'trill) interfere with the default notehead style for
\note(-by-number);
2) Use the code from note-head::calc-glyph-name to ensure all notehead
style can be set via 'style in \note(-by-number).
Nice!
It would make life a bit easier for testers who are directly compiling
from git if the SHA1 number (perhaps the first eight digits only)
could be shown in the output of
lilypond --version
Any chance to add this?
Werner
___
lilypond-devel
Thanks to Neil, TextSpanner items are now displayed in `Dynamics'
contexts. However, this exhibits another serious annoyance, as
shown in bug issue #928.
This should be fixed now, Werner. If you can confirm, I'll close
#928.
It works, thanks!
Werner
It's part of the lilypond binary (or scheme functions) itself, not
lilypond-book.
OK.
The best solution is probably to add a new command line option
`--default-left-padding' to lilypond-book (which is then used in
the Makefile with value 0mm to override the default setting of
3mm), and
If the makefile sets it to 0mm, then what happens for longer
examples with bar numbers? Presumably somebody needs to go through
all the docs to find multi-line examples, then add
[left-padding=3mm]
to those examples.
Exactly. However, in most multi-line examples of the lilypond
Just curious: Are there (active) lilypond developers who aren't
listening to lilypond-bug?
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Do you actually expect the vertical formatting of the snippet below as
shown in the attached PDF?
Werner
==
\version 2.13.10
\paper {
ragged-last-bottom = ##f
}
\new Staff \relative {
f4 f f f |
f4 f f f
Do you actually expect the vertical formatting of the snippet below
as shown in the attached PDF?
I wouldn't say I expected it, but I can certainly explain it: it's
an inconsistent handling of two related corner cases. When a loose
line appears at the bottom of the page, we try to position
It would make life a bit easier for testers who are directly
compiling from git if the SHA1 number (perhaps the first eight
digits only) could be shown in the output of
lilypond --version
Any chance to add this?
The common way is to do something like $(shell git describe) in
the
Han-Wen,
do you remember why the dynamic signs `m' and `p' have a different
height? Ditto for essentially all other dynamic signs. At small
resolutions this looks really bad due to the PostScript hints applied
by FontForge...
Werner
___
Folks,
why can I say
\new PianoStaff \with {
\override StaffGrouper
#'between-staff-spacing #'minimum-distance = #20
} ...
but not
\new Staff \with {
\override VerticalAxisGroup
#'next-staff-spacing #'minimum-distance = #20
} ...
?
The latter gives this warning:
Is there a chance that you would consider this character for
inclusion in LilyPond 2.13?
If Werner's OK with that, I'll open a feature request on the
tracker.
Please go ahead.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
[Not tested yet the actual changes.] Is your fontforge version
compiled with --enable-double?
I use fontforge out of the box from my ubuntu distro. I don't know
how it is built.
Since you get warnings even without your changes, you haven't
--enable-double. I strongly suggest to get the
Thus, the slash of the character sticks out of the bounding box by
some amount.
This might cause problems if images are converted to, say, cropped PNG
images. You must assure somehow that the slash won't get cut off.
Everything else looks fine! BTW, I don't get any warning from my
fontforge
This might cause problems if images are converted to, say, cropped
PNG images. You must assure somehow that the slash won't get cut
off.
[...] Furthermore, if I understand your comment correctly, even
something like the coda or snappizzicato characters could have the
semi-circles that
Another nasty cutoff -- already in the PDF snippet as found in out-www
(attached for convenience) -- can be seen if you look at the output of
snippet/string-quartet-template-simple.ly
The lowest part of the system bracket is missing.
Werner
lily-6fc0ab3e-1.pdf
Description: Adobe PDF
301 - 400 of 3179 matches
Mail list logo
