Here's a patch for the accordion push symbol.
This looks fine.
It would have been simpler if I had just drawn two straight lines:
draw z1
-- z2;
draw z3
-- z2;
This would seem to be allowed by the instructions in README, but I
get the sense that mf2tp1 really doesn't
This is probably overkill. FontForge is quite good in doing this for
you, provided the intersections are well defined. `fill' is necessary
because you can't exactly control the direction of the outline by
using `penstroke'.
But if I change from penstroke to fill, using zkr to go along one
Am 20.10.2010 09:50, schrieb Werner LEMBERG:
This is probably overkill. FontForge is quite good in doing this for
you, provided the intersections are well defined. `fill' is necessary
because you can't exactly control the direction of the outline by
using `penstroke'.
But if I change
+ ... {dir (180 - loopangle)}z7e{dir (180 - loopangle)}
This is too much :-) The following
+ ... z7e{dir (180 - loopangle)}
is sufficient. A new patch attached (to preserve tabs for dull mail
programs).
Werner
--- feta-scripts.mf.old 2010-10-17
Am 18.09.2010 22:21, schrieb n.putt...@gmail.com:
[...]
I think the only sane method would be to use a scheme engraver, since
you could acknowledge interesting grobs and make typesetting decisions
for the TabNoteHead based on the grobs present at a particular timestep.
Done.
This doesn't
Hi, folks,
why does LyricText #'font-series default to #'bold-narrow?
First, it's counterintuitive to me to have a bold narrow font as the
most important thing to read in a piece; it's just too black-ish.
Condensed seems fine for lyrics, but bold?
Second, it's defined for nearly no font, in
On 10/20/10 1:59 AM, Werner LEMBERG w...@gnu.org wrote:
+ ... {dir (180 - loopangle)}z7e{dir (180 - loopangle)}
This is too much :-) The following
+ ... z7e{dir (180 - loopangle)}
is sufficient. A new patch attached (to preserve tabs for dull mail
Hi Alexander,
CC-ing to the bug list just in case.
On Wed, Oct 20, 2010 at 2:39 PM, Alexander Kobel n...@a-kobel.de wrote:
why does LyricText #'font-series default to #'bold-narrow?
First, it's counterintuitive to me to have a bold narrow font as the most
important thing to read in a piece;
why does LyricText #'font-series default to #'bold-narrow?
This looks like an oversight. The change is from 2004 where TeX has
been still used as the output device.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
LGTM.
Carl
http://codereview.appspot.com/2401042/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Hello.
see
Customizing fretboard fret diagrams
Documentation/snippets/customizing-fretboard-fret-diagrams.ly
lines 74 -- 81:
doctitle = Customizing fretboard fret diagrams
} % begin verbatim
\include predefined-guitar-fretboards.ly
\storePredefinedDiagram #default-fret-table \chordmode { c' } %
Yes, please do. It's probably my mistake.
Thanks,
Carl
On 10/20/10 9:59 AM, Francisco Vila paconet@gmail.com wrote:
Hello.
see
Customizing fretboard fret diagrams
Documentation/snippets/customizing-fretboard-fret-diagrams.ly
lines 74 -- 81:
doctitle = Customizing fretboard fret
Hi all,
I'm currently working on automatic cue clefs (i.e. \cueDuring in different
clefs than the containing voice, e.g. using a violin or flute cue inside the
cello part).
My current state is up at rietveld at:
http://codereview.appspot.com/2588042
As the cue clefs should not override the
These are just some things that I noticed.
2.1.1 Entering Lyrics.
Lyrics are entered in a special input mode, which can be introduced by
the keyword \lyricmode, or by using \addlyrics or \lyricsto. In this mode…
Which mode? This has bugged me for a while, and since changes are being
James
Many thanks for your comments. At first glance they all seem
pertinent. I'll have a look at fixing them up tomorrow.
I'm actually dealing with TODOs dotted around the file in no
particular order, so there is no high-water mark for the changes
I've made. You could read and comment
Reviewers: ,
Message:
Greetings everybody,
this user-friendly modification has been discussed for a while but
nothing concrete had been done so far. Therefore I took the liberty of
proposing a very simple patch, since this modification is something I
really really need (well, not me, but
On Wed, Oct 20, 2010 at 7:20 PM, Trevor Daniels t.dani...@treda.co.uk wrote:
Many thanks for your comments. At first glance they all seem pertinent.
I'll have a look at fixing them up tomorrow.
Hi Trevor,
I've taken the liberty to apply James' suggestions myself:
New patchset uploaded
Ian
http://codereview.appspot.com/2219044/diff/10001/scm/lily.scm
File scm/lily.scm (right):
http://codereview.appspot.com/2219044/diff/10001/scm/lily.scm#newcode231
scm/lily.scm:231: (_ module (ice-9 curried-definitions) not in Guile
1.8\n)
Change --verbose
OK to remove offending line even when using Guile V1.8.7?
Ian
http://codereview.appspot.com/2219044/diff/15001/scm/lily.scm
File scm/lily.scm (right):
http://codereview.appspot.com/2219044/diff/15001/scm/lily.scm#newcode271
scm/lily.scm:271: (debug-enable 'debug)
This causes a deprecation
Hi Ian,
I will test your patch shortly.
Thanks,
Patrick
http://codereview.appspot.com/2219044/diff/15001/scm/lily.scm
File scm/lily.scm (right):
http://codereview.appspot.com/2219044/diff/15001/scm/lily.scm#newcode231
scm/lily.scm:231: (_ Guile 1.8\n)
Okay, I can live with this. :)
Hi Ian,
I just tested your patch.
In addition to the small tweak that is needed (see my comment below), it
seems that the `(use-modules (ice-9 curried-definitions))' statement
does not carry over to display-lily.scm. I am a bit puzzled by this.
This is the error message, in context:
;;;
I like this idea as a way to get the functionality you want in the short
term. But I don't like it for the long term. I think the long-term
syntax needs to be
\language foobar
so that we don't have a separate keyword for each language. As you
point out, that will require a parser change.
In
On Wed, Oct 20, 2010 at 10:30:17AM -0600, Carl Sorensen wrote:
On 10/20/10 9:59 AM, Francisco Vila paconet@gmail.com wrote:
doctitle = Customizing fretboard fret diagrams
} % begin verbatim
\include predefined-guitar-fretboards.ly
\storePredefinedDiagram #default-fret-table
In the documentation, there is an example how to convert a texinfo
file to a newer version:
convert-ly --from=... --to=... --no-version *.itely
A similar command can be used for lilypond-book input files:
convert-ly --from=... --to=... --no-version *.tex
What I consider problematic is
On Thu, Oct 21, 2010 at 6:06 AM, Werner LEMBERG w...@gnu.org wrote:
What I consider problematic is that syntax changes aren't restricted to
lilypond
environments.
This is useful for updating the docs -- we *want* it to change text
like to change the direction of the slur, use
Apparently GUB (from about a year ago) no longer works on 10.3.9.
It's quite possible that this was broken in the change that made it
work on 10.5.
http://code.google.com/p/lilypond/issues/detail?id=1295
I have no clue how to fix the errors. I'm quite willing to apply test
patches and upload
To sum up: Keywords like `orientation' are far too frequent in
normal text to be handled without protection if convert-ly is
applied to lilypond-book (or texinfo) input.
I'm fine with this being a command-line option to convert-ly.
Actually, this could even be the default -- as long as
27 matches
Mail list logo
