I have run into what may be an "ugly" issue, but I thought I'd post here
first.
If you have a group of notes beamed across staves, you sometimes get an
ugly beam slope.
\version "2.25.2"
\score {
\new PianoStaff <<
\new Staff = "upper" {
\v
On 06.07.2018 01:02, Noeck wrote:
Is this an ugly-type bug?
I’d say yes. Your graphic is cropped too much, because if the right tie
were a lot shorter, I’d be totally fine with this, but they’re pretty
much the same length (see attachment).
Best, Simon
Hi,
I encountered an ugly tie. What can I do to make the tie more
symmetrical (other than extra-offset or \shape - or should I just use
those in combination with \alterBroken)?
It occurs when the note is tied twice (to both sides) and there is a
line break in one of the ties.
MWE:
\version
Hi All,
I just want to say that I make very heavy and extensive use of the \shapeII
function in openlilylib in my dense new complexity school scores and it
behaves perfectly. This is contrary to what Simon reports, so I am
mystified. I mention this so that the experience of Simon does not put you
Am 23.12.2016 um 11:49 schrieb Simon Albrecht:
> Maybe try \shapeII from openlilylib as well, it’s much more comfortable
> to use, though in my experience sadly it messes with system/staff
> placement in a way that makes it unusable.
Could you please elaborate a little bit on that, possible with
On 23.12.2016 11:29, Shevek wrote:
My question was specifically if there is a way to fix this behavior*without*
manually tweaking each slur. Or failing that, if this is a known bug.
It is known that the slur and tie and phrasing slur printing algorithms
aren’t very good in difficult
My question was specifically if there is a way to fix this behavior *without*
manually tweaking each slur. Or failing that, if this is a known bug.
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/Ugly-slur-with-large-leap-help-tp198395p198403.html
Sent from the User
See:
http://lilypond.org/doc/v2.18/Documentation/notation-big-page#modifying-ties-and-slurs
- Original Message -
> From: "Shevek" <saul.james.to...@gmail.com>
> To: "Lillypond Users Mailing List" <lilypond-user@gnu.org>
> Sent: Friday, December
Flipping the slur avoids the worst problems, but it's not really correct.
Ideally, it should bend dramatically underneath the stem then upwards
towards the grace note.
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/Ugly-slur-with-large-leap-help-tp198395p198401.html
ilypond-user@gnu.org>
> Sent: Friday, December 23, 2016 8:47:13 AM
> Subject: Ugly slur with large leap - help?
> I have a passage similar to the following:
>
> \version "2.18"
> \language "english"
>
> \relative c''' {
> \grace { f8( } c
bug? Is there a way to improve how it looks without manually tweaking each
slur? This figure appears a lot throughout the piece.
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/Ugly-slur-with-large-leap-help-tp198395.html
Sent from the User mailing list a
04 PM, Simon Albrecht <simon.albre...@mail.de>
> wrote:
>
>> Hi Andrew,
>>
>> On 17.01.2016 16:50, N. Andrew Walsh wrote:
>>
>>> Hi list,
>>>
>>> I ran into an issue when using what is admittedly an ugly hack for
>>> forcing F
On 26.01.2016 14:33, N. Andrew Walsh wrote:
ah, now I see why I wasn't using something like your example. Look at
what happens when the last note is raised a fourth:
\version "2.19.35"
<<
\relative c'' {
c4 d f
\override Stem.stemlet-length = #0.5
\override
Hi list,
I ran into an issue when using what is admittedly an ugly hack for forcing
French beaming, when *also* working with a voice with lyrics.
What I want, when I have (pseudo-code):
{ r8.[ e16] }
is for the rest to be roughly in the middle, with a stemlet, beamed
together
gt;>
>> I ran into an issue when using what is admittedly an ugly hack for
>> forcing French beaming,
>>
>
> French beaming is a different thing: it means that mid-beam stems only
> extend to the innermost beam, not through the last beam as per default.
>
&
. Not to say plain ugly.
Just to close this thread: my current version already looks much better.
The solution I choose was to use a4 landscape papersize/mode. Not uncommon
for quatre mains repertoire. See attachment. My Lilypond sourcecode makes
it quite easy for me to produce separate pages
Am 01.03.2015 um 02:39 schrieb Steve Lacy:
On Sat, Feb 28, 2015 at 3:11 PM, Urs Liska u...@openlilylib.org
mailto:u...@openlilylib.org wrote:
Yes, but I'd repeat that this is less LilyPond's fault than a
problem of having an amount of music that is inherently unsuitable
to be
Am 01.03.2015 um 00:07 schrieb Martin Tarenskeen:
On Sat, 28 Feb 2015, H. S. Teoh wrote:
In my experience, lilypond tends to produce better output for longer
pieces -- presumably because there's more room for adjustments to
optimize the layout. Therefore I wouldn't judge just by the first
On Sat, 28 Feb 2015, H. S. Teoh wrote:
In my experience, lilypond tends to produce better output for longer
pieces -- presumably because there's more room for adjustments to
optimize the layout. Therefore I wouldn't judge just by the first few
bars alone.
I am well aware of that. I have
Am 28.02.2015 um 20:39 schrieb Kevin Barry:
On Sat, Feb 28, 2015 at 6:47 PM, Martin Tarenskeen
m.tarensk...@zonnet.nl mailto:m.tarensk...@zonnet.nl wrote:
Having entered one line of music it occurred to me that the spacing
looks quite sub-optimal. Not to say plain ugly.
Just
looks quite sub-optimal. Not to say plain ugly.
Just to illustrate that LilyPond is great (I have produced many really
good looking scores using only minimal tweaking) but there isstill
enough room for improvement: see the attached pdf example.
The example was produced using LilyPond
Hi,
I am typesetting a simple Beethoven 4-mains. I am in the very first stage
of entering the notes - without additional tweaks to optimize the output.
Having entered one line of music it occurred to me that the spacing looks
quite sub-optimal. Not to say plain ugly.
Just to illustrate
On Sat, Feb 28, 2015 at 6:47 PM, Martin Tarenskeen m.tarensk...@zonnet.nl
wrote:
Having entered one line of music it occurred to me that the spacing looks
quite sub-optimal. Not to say plain ugly.
Just as a test, I typeset the music myself again. With 2.18.2 LilyPond
split it onto two lines
On Sat, Feb 28, 2015 at 3:11 PM, Urs Liska u...@openlilylib.org wrote:
Yes, but I'd repeat that this is less LilyPond's fault than a problem of
having an amount of music that is inherently unsuitable to be typeset
nicely on one system.
I'll have to say that I find this perspective a bit
is that sometimes
LilyPond has to decide between two evil choices and in this case the
excerpt was a little too long for one system and too short for two. The
ugly bar was caused by an extra note column in one of the four staves that
made note columns in the other three parts seem too wide (bar 4
There's *lots* of short music that would benefit greatly from
beautiful typesetting.
Short music, per se, isn't the problem.
Well, it is in case it leads to very tight typesetting. The
out-of-the-box settings of LilyPond aren't suited to that.
Have a look at code issues 2141 to 2145.
\version 2.17.96
{
a'8 ( b'4. ) r2
}
Look at the slur. It goes through stem and flag. Shouldn't it start above the
stem? Not sure...
Karol
attachment: slur.png___
lilypond-user mailing list
lilypond-user@gnu.org
2013/12/3 Karol Majewski karo...@wp.pl:
\version 2.17.96
{
a'8 ( b'4. ) r2
}
Look at the slur. It goes through stem and flag. Shouldn't it start above the
stem? Not sure..
Imo this is ugly, but i'm not sure how it should look like...
Janek
Am 03.12.2013 10:30, schrieb Janek Warchoł:
2013/12/3 Karol Majewski karo...@wp.pl:
\version 2.17.96
{
a'8 ( b'4. ) r2
}
Look at the slur. It goes through stem and flag. Shouldn't it start above the
stem? Not sure..
Imo this is ugly, but i'm not sure how it should look like...
Janek
I
On Tue, 3 Dec 2013, Urs Liska wrote:
Am 03.12.2013 10:30, schrieb Janek Warchoł:
2013/12/3 Karol Majewski karo...@wp.pl:
\version 2.17.96
{
a'8 ( b'4. ) r2
}
Look at the slur. It goes through stem and flag. Shouldn't it start above
the stem? Not sure..
Imo this is ugly, but i'm
and flag. Shouldn't it start above
the stem? Not sure..
Imo this is ugly, but i'm not sure how it should look like...
Janek
I don't _know_ either, but I think to become acceptable it would definitely
need more horizontal space between.
Don't know if it is a good solution, but would
Elaine Gould gives the following answer:
When outer notes have opposite directions, move the slur at the stem end
towards the noteheads so it does not tilt contrary to the direction of the
pitches.
attachment: SP_A1251.jpg___
lilypond-user mailing
Am 03.12.2013 11:49, schrieb Karol Majewski:
Elaine Gould gives the following answer:
When outer notes have opposite directions, move the slur at the stem end
towards the noteheads so it does not tilt contrary to the direction of the
pitches.
But this example doesn't have the flag, which
On Dec 3, 2013 5:56 AM, Urs Liska u...@openlilylib.org wrote:
Am 03.12.2013 11:49, schrieb Karol Majewski:
Elaine Gould gives the following answer:
When outer notes have opposite directions, move the slur at the stem end
towards the noteheads so it does not tilt contrary to the direction of
But this example doesn't have the flag, which is the problematic issue
here.
Alternately, couldn't the stem of the B go up instead of down
I would prefer slur down to avoid the flag and connect from note head to
the stem.
___
lilypond-user mailing
Several things can be made.
#*# One. Put the slur down.
http://lilypond.org/doc/v2.12/Documentation/user/lilypond/Curves.html#Slurs
Still works in 2.17 as well.
\version 2.17.96
{
\slurDown
a'8( b'4.) r2
}
[image: Imágenes integradas 2]
#*# Two. Put a silent note.
I just use a random scale
Thanks for the suggestion Peter, it indeed works very well!
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/Two-possible-ugly-bugs-tp152672p153211.html
Sent from the User mailing list archive at Nabble.com.
___
lilypond-user
Maybe this can be helpful to you or anyone else. I was just reminded
when working on a solution for another issue involving beams, that
beams.positions are one of the most useful settings.
Here it is in relation to your example:
{
\override Beam.concaveness = #+inf.0
a8[ r] e8[ r] a,8[ r]
-possible-ugly-bugs-tp152672p152764.html
Sent from the User mailing list archive at Nabble.com.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
- Original Message -
From: Gilberto Agostinho gilbertohasn...@gmail.com
To: lilypond-user@gnu.org
Sent: Monday, October 21, 2013 4:16 PM
Subject: Re: Two possible ugly bugs
Hi all,
Did anyone check these two bugs I described? Should I report them to the
Issue Tracker or not? And just
Hi all,
Here are two possible little bugs (of type ugly) that do not look well IMO.
If you give me green light, I would happily add them to our Issue Tracker
myself.
1) Some ugly positioning when using \pitchedTrill:
\version 2.17.28
\markup {Everything is fine here}
{
\pitchedTrill d'8
I'm a percussionist and I've played from parts that behave like the examples
Gilberto has given. I agree that the default behaviour of LP is a bit ugly,
and when shrunk down onto a part I imagine it would cause a few raised
eyebrows from my percussion colleagues! His proposed suggestions would
.nabble.com/ugly-bar-line-when-changing-line-count-tp152072p152275.html
Sent from the User mailing list archive at Nabble.com.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Eluze, thank you for all your replies and for adding the request, I really
appreciate it.
Take care,
Gilberto
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/ugly-bar-line-when-changing-line-count-tp152072p152279.html
Sent from the User mailing list archive
at the attached code to see how to:
http://lilypond.1069038.n5.nabble.com/file/n152154/test4.png test4.ly
http://lilypond.1069038.n5.nabble.com/file/n152154/test4.ly
Eluze
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/ugly-bar-line-when-changing-line-count-tp152072p152154
.nabble.com/ugly-bar-line-when-changing-line-count-tp152072p152207.html
Sent from the User mailing list archive at Nabble.com.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
in context:
http://lilypond.1069038.n5.nabble.com/ugly-bar-line-when-changing-line-count-tp152072p152213.html
Sent from the User mailing list archive at Nabble.com.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman
in this case. I am basically
arguing that LP should behave like this and that *out of the box*, due to
what are the standards of notation IMO.
Thanks once again for your replies.
Take care,
Gilberto
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/ugly-bar-line-when-changing
in the documentation of
changing line-count there involves a change in between bar lines, thus not
showing this problem we discuss here:
http://lilypond.org/doc/v2.17/Documentation/a8/lily-ef95c0bf.png
Also, when a change time signatures happens at the same place, things really
get ugly. The code below
and the notes with the new number
of lines.
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/ugly-bar-line-when-changing-line-count-tp152072p152122.html
Sent from the User mailing list archive at Nabble.com.
___
lilypond-user
Hello all,
I found what can possible be an ugly issue regarding the bar lines when
changing the staff line-count. I might be wrong on this one, but shouldn't
the first bar line in the example below cover the whole 5 lines?
\version 2.17.28
\relative c'' {
f4 d g, e |
\stopStaff
Gilberto Agostinho-3 wrote
I found what can possible be an ugly issue regarding the bar lines when
changing the staff line-count. I might be wrong on this one, but shouldn't
the first bar line in the example below cover the whole 5 lines?
Any thoughts on this?
that's probably arbitrary
\relative c'' { a2.^ok ( b4 c1 ) }
\new Staff \relative c'' { a2^ugly as sin ~ ( a4 ~ a16 b8. c1 ) }
\new Staff \relative c'' { \slurDown a2^better ~ ( a4 ~ a16 b8. c1 ) }
hjh
--
James Harkins /// dewdrop world
jamshar...@dewdrop-world.net
http://www.dewdrop-world.net
Come said the Muse,
Sing me
In the following, to look correctly positioned, the final A in the bar
needs to be moved slightly to the right relative to the notes in the
other voice each side of it. I tried moving the note to the right using
\override NoteColumn #'force-hshift, but that didn't move the note. What
can I
2012/5/24 Nick Payne nick.pa...@internode.on.net:
In the following, to look correctly positioned, the final A in the bar needs
to be moved slightly to the right relative to the notes in the other voice
each side of it. I tried moving the note to the right using \override
NoteColumn
Nick Payne wrote:
In the following, to look correctly positioned, the final A in the bar
needs to be moved slightly to the right relative to the notes in the
other voice each side of it.
Boy, that's a tough situation. Personally, I would not call your
example ugly. The note heads
On Thu, May 24, 2012 at 9:48 AM, Nick Payne nick.pa...@internode.on.net wrote:
In the following, to look correctly positioned, the final A in the bar needs
to be moved slightly to the right relative to the notes in the other voice
each side of it. I tried moving the note to the right using
Marek Klein
0918 610 720
http://gregoriana.sk
2012/5/24 Nick Payne nick.pa...@internode.on.net
In the following, to look correctly positioned, the final A in the bar
needs to be moved slightly to the right relative to the notes in the other
voice each side of it. I tried moving the note to
On Thu, May 24, 2012 at 8:23 PM, Marek Klein ma...@gregoriana.sk wrote:
Maybe it is proportional notation what you are looking for?
I don't think so. using proportional notation doesn't fix the lack
of optical spacing between notes in different voices issue. The a is
still visually closer to c
example ugly. The note heads, for example, are perfectly spaced. I
understand that you don't like the closeness of the stems, but if you
move that note over, it's going to disturb the proportionality of the
note heads, and I'm guessing it's going to look worse. Have you
considered stretching
Hello list,
I made a quick fix for the makeOctaves function from
http://lsr.dsi.unimi.it/LSR/Item?id=445
Since 2.15.x notes may appear as single NoteEvents *not* wrapped in an
EventChord, I added a check for 'NoteEvent and did a map on EventChord
elements.
This is an ugly solution, because
elements.
This is an ugly solution, because EventChords are octaved twice.
But it works for the moment.
If my googling was wrong and there is a better solution around, a hint
is appreciated.
Cheers, Jan-Peter
--snip--
\version 2.15.31
#(define (with-octave-up m octave)
(let* ((old
eluze eluzew at gmail.com writes:
hi Laszlo
i think the nesting is the cause of this uglyness (and 2.12.3 ws more
tolerant against this).
rearranging could look like this:
\score {
\context ChordNames = chordsU \chordsU
\context Staff = cStaffU
\tempo 4 = 72
Hi lilypond folks,
lilypond-2.14.2 has some serious bugs regarding to chords engraving. The
attached .ly [1] did not have those ugly artifacts when I rendered it to pdf
using lilypond-2.12.3 (see [2]); now lilypond-2.14.2 renders those ugliness
there (see [3]). How to get rid of them (to achieve
hi Laszlo
i think the nesting is the cause of this uglyness (and 2.12.3 ws more
tolerant against this).
rearranging could look like this:
\score {
\context ChordNames = chordsU \chordsU
\context Staff = cStaffU
\tempo 4 = 72
\context Voice = cStaffU \staffU
Hi,
while tweaking hairpins I often use a high zoomed display (Ubuntu 10.04,
Adobe Reader 9 with 6400 %). So I noticed that the hairpins are printed
terraced (using ragged-right = ##f). The markup with draw-line seems to be
much better.
This ugly output disappears, if I switch to ragged-right
PDF Creator is correctly interpreting the .ps output of lilypond, but
Scribus can't import it whithout mistakes...
I think the problem doesn't come from Lilypond, but from Scribus's
interpretation of Postscripts...
François
___
lilypond-user mailing
You're right, I can import pdfs. But it's more difficult to optimize the
size of the picture: you have to specify in lilypond the exact size of the
musicsheet in order to avoid blank spaces.
___
lilypond-user mailing list
lilypond-user@gnu.org
I would like to import musicsheets in Scribus. The only way I found is
export a .png file with Lilypond, and import it in Scribus. But I think that
a .ps importation would be a better solution: less space and better quality.
I put in attachment an exemple of a .ps output (converted in .png by
I tried to use the .ps output, but it's not so good as the .pdf one. It's the
same thing under Windows XP or Ubuntu 7.10.
Do you have any solutions ?
François
___
lilypond-user mailing list
lilypond-user@gnu.org
François Labadens wrote:
I tried to use the .ps output, but it's not so good as the .pdf one. It's the
same thing under Windows XP or Ubuntu 7.10.
Do you have any solutions ?
It does look pretty grainy by itself, but it's used to produce a great
looking pdf, so it shouldn't be a major worry.
It's been my understanding that most viewers and applications will
render a .ps file by way of a low resolution bitmap 'preview', so as not
to clog RAM while you're working on files. When you go to print or
export the file, the .ps file is rendered at whatever resolution you
specify in your
If you clarify what you mean by ugly, it's easier to comment on your
problems.
Do you mean fussy-looking or do you mean that certain symbols are
missing or replaced
by something else? Also, what kind of applications do you use when
viewing/printing the PS file.
The Postscript output
2007/12/18, Risto Vääräniemi [EMAIL PROTECTED]:
Please, see
http://lists.gnu.org/archive/html/bug-lilypond/2007-12/msg00153.html for a
temporary solution.
I have copied the eight type1\*.pfa files (24Kb each) to
c:\windows\fonts directory. Now accented characters are properly
viewed but the
) were fine and I tested even the Spanish n with
tilde (don't know its name) and it was OK. Funny.
-Risto
--
View this message in context:
http://www.nabble.com/Ugly-fonts-in-2.11.36-tp14377193p14395592.html
Sent from the Gnu - Lilypond - User mailing list archive at Nabble.com
I'm win. XP user, and recently upgrade from 2.11.34 to 2.11.36. and for my
surprise the fonts are totally changed in this version; from the very nice
Century; to an horrendous Arial or maybe Courier font in the time signatures,
the text all, and lyrics. Is this a new font to be used with LP? Is
2007/12/17, Cesar Penagos [EMAIL PROTECTED]:
I'm win. XP user, and recently upgrade from 2.11.34 to 2.11.36. and for my
surprise the fonts are totally changed in this version; from the very nice
Century; to an horrendous Arial or maybe Courier font in the time
signatures, the text all, and
/fonttivirhe_36_better.png A sample of
fixed .36 score
Please, see
http://lists.gnu.org/archive/html/bug-lilypond/2007-12/msg00153.html for a
temporary solution.
-Risto
--
View this message in context:
http://www.nabble.com/Ugly-fonts-in-2.11.36-tp14377193p14384528.html
Sent from the Gnu - Lilypond - User
hi Dniele!
please post some code and it will be easier to help you!
regards
bainos
Daniele Degano ha scritto:
hi, im new to the program and i was having some difficulty. i switched time
signatures in my piece, and the program put a bar in the wrong place (ie, it
didnt count properly). its a
hi, im new to the program and i was having some difficulty. i switched time
signatures in my piece, and the program put a bar in the wrong place (ie, it
didnt count properly). its a bit of a vague description, and i would not mind
submitting code if anyone were interested. thanks!
Hi again,
I´m still searching for a way to solve this problem. Is there anyone
who has an idea how to tweak lilypond?
Dominic
2007/3/15, Dominic Neumann [EMAIL PROTECTED]:
okay, sorry for not posting an example. It´s not that easy to find a
simple one, because in the simple situations there´s
Dominic-
My apologies for not having seen the previous thread, but
the following changes to your code appear (to me) to resolve
the clash...
Stan
On Jul 12, 2007, at 2:02 PM, Dominic Neumann wrote:
Hi again,
I´m still searching for a way to solve this problem. Is there anyone
who has an
2007/7/12, Dominic Neumann [EMAIL PROTECTED]:
Hi again,
Hi Dominic,
I´m still searching for a way to solve this problem. Is there anyone
who has an idea how to tweak lilypond?
I tried the snippet you posted, and as you can see the result doesn't
look ugly at all.
Have you tried
2007/7/12, Stan Sanderson [EMAIL PROTECTED]:
Valentin, I get the output from Dominic's code which he complains about:
(LP 2.10.25)
Yes, I can see that, but it doesn't collide here on 2.11.27 (linux32).
This might have been fixed with the new spacing code or something,
which is why I asked
This is how it looks in LP 2.11.27.
No collisions! :)
2007/7/12, Valentin Villenave [EMAIL PROTECTED]:
2007/7/12, Stan Sanderson [EMAIL PROTECTED]:
Valentin, I get the output from Dominic's code which he complains about:
(LP 2.10.25)
Yes, I can see that, but it doesn't collide here on
I too would like to know how to fix this.
Thanks,
Joe
On 22/04/07, Dominic Neumann [EMAIL PROTECTED] wrote:
Hi,
I´m trying to typeset songs with different verses. When the refrain
comes before the verses, the stanza numbers don´t get enough place.
They are printed right onto the last
okay, sorry for not posting an example. It´s not that easy to find a
simple one, because in the simple situations there´s no problem with
the brackets. I already included the tipp for question 3 and it works
good.
There´s a problem with the collision of the bracket numbers and the chordnames.
It is much easier to answer questions like these if you include an example
(short but complete so it can be ran directly through LilyPond)
of the LilyPond code that you used. Then anybody on the mailing list
who has an idea can quickly test it. Now, I would need to spend maybe
10 minutes to first
Hi,
when using volta brackets together with chordnames it doesnt look good to me.
There are three problems:
1.) The font of the bracket numbers (1., 2., ...) doesnt look good. I
want it to be the same font as the one that is used for chordnames. In
addition the baseline of the chordnames should
. Why?
Apologies in advance -- I'm not going to be much help!
Number one: check section 6.7.4 of the manual under 'Manual Repeats'.
If you manually specify the repeat (I agree, it's an ugly way to do
it) you can use a markup to specify the volta text, and change the
font using a markup. I can't
Hi,
2007/3/12, Cameron Horsburgh [EMAIL PROTECTED]:
Apologies in advance -- I'm not going to be much help!
Number one: check section 6.7.4 of the manual under 'Manual Repeats'.
If you manually specify the repeat (I agree, it's an ugly way to do
it) you can use a markup to specify the volta
Richard Schoeller [EMAIL PROTECTED] wrote: Aaron,I just looked this with 2.6.4. The Hebrew lyrics do seem to come outmore squished together than the English. I was able to defeat this byusing: wow someone else doing hebrew lilypond on linux non the less!!I actually never fiddled with fonts
Hi all, I notated a song with lyrics which are crunched together. The code is below. I gather most of you won't be able to read the hebrew, but I would guess the same behaviour happens sometimes with english. The original song has all the eight notes and sixteenth notes with flags. While this
On 23-Jan-06, at 9:24 AM, Aaron Mehl wrote:
I notated a song with lyrics which are crunched together.
Please read section 7.3.7.1 in the 2.7 manual.
Cheers,
- Graham
___
lilypond-user mailing list
lilypond-user@gnu.org
Aaron,
I just looked this with 2.6.4. The Hebrew lyrics do seem to come out
more squished together than the English. I was able to defeat this by
using:
\override Score.SeparationItem #'padding = #1
Otherwise, the ordering all seems OK. However, since most of the lyrics
are a nigun I
When I generate a PDF-file with
lilypond input.ly
the title is set in a really ugly font. What's wrong here?
mfg ar
--
E-Learning in der Schule:
http://www.dbg-metzingen.de/Menschen/Lehrer/Q-T/Rittershofer/E-Learning/
___
lilypond-user mailing
LilyPond version?
Operating system?
What package did you install (or did you compile it yourself)?
(Please reply to the mailing list)
/Mats
Andreas Rittershofer wrote:
When I generate a PDF-file with
lilypond input.ly
the title is set in a really ugly font. What's wrong here?
mfg ar
lilypond-commands in a tex file and process this file,
everything is ok.
The ugly font only occurs in diret lilypond output.
mfg ar
(Please reply to the mailing list)
/Mats
Andreas Rittershofer wrote:
When I generate a PDF-file with
lilypond input.ly
the title is set
Am Freitag, den 01.07.2005, 11:13 +0200 schrieb Mats Bengtsson:
See http://lists.gnu.org/archive/html/lilypond-user/2005-05/msg00207.html
I already have these fonts, that is not the problem.
However, you may want to try the new stable version 2.6.0,
which is available i a package that
is a typewriter font with very bad kerning.
When I include lilypond-commands in a tex file and process this file,
everything is ok.
The ugly font only occurs in diret lilypond output.
mfg ar
(Please reply to the mailing list)
/Mats
Andreas Rittershofer wrote:
When I generate a PDF-file
1 - 100 of 117 matches
Mail list logo
