SmallCaps Gap

Not "strictly" a Lilypond bug, but I thought it was worth mentioning anyway. I consider as a "bug" when you use SmallCaps in a markup, you can notice an ungly gap in the series of some sloped characters (as "WA" "VA"...). My eyes suggest the space should be reduced cause it looks a bit awkward

Re: Accidental Placement and Tie

Simon Albrecht-2 wrote > Yes, it does. Looks like > https://sourceforge.net/p/testlilyissues/issues/612/;. Thanks Simon, I should have checked on this page first! Btw, in the issue thread, it is mentioned: "A work-around is to temporarily shift to accidental style 'no-reset." I can't find any

Re: Accidental Placement and Tie

Simon Albrecht-2 wrote > It’s very easy to find in the manuals. I searched for ‘lilypond > accidentalstyle’ on the web and the first result is this page: > http://lilypond.org/doc/v2.19/Documentation/notation/displaying-pitches; > Now you hit the node for ‘Automatic accidentals’ and there you

Accidental Placement and Tie

Hi everyone, This seems like a bug to me, no? \version "2.19.81" \relative c'' { \key c \minor \override Staff.TextScript.self-alignment-X = #0 << { b1 c-"OK" \bar "||" b b-"OK" \bar "||" b ~ b-"WRONG" \bar "|." } \\ { s s s } >> } When an

Re: SmallCaps Gap

Torsten Hämmerle wrote > Off Topic:Small caps in bold used for headings are quite problematic, > anyway. Indeed, it is not very conventional... But I tried different titles and I was wondering if for film music, it wouldn't look better in small caps:

Re: SmallCaps Gap

Torsten Hämmerle wrote > This feature is rather new (doesn't work in 2.18.2 yet). > If you look a bit further down, in "Fonts explained" > http://lilypond.org/doc/v2.19/Documentation/notation/fonts.html#fonts-explained; > > , you'll find a few examples demonstrating how to use OTF old style >

Re: SmallCaps Gap

sn'ttoo good, either, but that's the price you pay for > using non-professional(and free-of-charge) fonts, I'm afraid.There's an > improvement in Av/Aw, though.All the best,Torsten Hi Torsten, could you please give me an exemple of how this works? I can't find an explanation of this in the manual.

Re: TimeSignature and magnifyStaff

Okay, I found how to trick this bug and move the TimeSignature with \override Score.TimeSignature.extra-offset = #'(1 . 0) but it still isn't very convenient! -- Sent from: http://lilypond.1069038.n5.nabble.com/Bugs-f58488.html ___ bug-lilypond

TimeSignature and magnifyStaff

Hi everyone, I found a strange bug when using the magnifyStaff tool. In this example, you can see a collusion between the clef and the time signature occurs when the lowest staff is smaller (and not otherwise). Sounds like a bug to me, what do you think? Is there a way to avoid this? \version

Re: TimeSignature and magnifyStaff

As a new LilyPond user, I never opened an issue for signaling a bug. Could someone please do it, or explain me how to proceed? Thx -- Sent from: http://lilypond.1069038.n5.nabble.com/Bugs-f58488.html ___ bug-lilypond mailing list bug-lilypond@gnu.org

Re: TimeSignature and magnifyStaff

Malte Meyn-3 wrote > I just realized that this use was not intended: The scaling of bar lines > is explicitely intended, as one can see by looking at the regtest > magnifyStaff-bar-lines.ly. Thanks for your comments on this issue. Concerning the barlines, I think it is really a mistake in this

Subdivised beams bug

Hi all, I found a small bug while using the automatic beaming function. http://lilypond.org/doc/v2.19/Documentation/notation/beams.html#setting-automatic-beam-behavior See: \relative c'' { \set subdivideBeams = ##t % Set beam sub-group length to an eighth note \set baseMoment =

Re: Subdivised beams bug

Malte Meyn-3 wrote > The result (using LilyPond 2.19.82) is exactly what I would’ve expected. > I suppose your expectation is different so what did you expect? The automatic subdivised beam is 16th instead of 8th. Here is the problem and what I would have expected: \relative c'' { \set

Re: Subdivised beams bug

Urs Liska-3 wrote > TL;DR: it's a known issue, and there's no reasonable hope to have it > fixed soon. Thank you Urs for all the explanations. I feel sorry I don't have the knowledges myself to help with the code... But LP is now my main engraving software which I start to use intensively. My

Re: Accidentals and Ledger Lines

Malte Meyn-3 wrote > Of course you could use \override instead of \once \override but of > course that’s not optimal, therefore I’m forwarding this to the bug > list. The following code shows in which cases also a neighbouring ledger > line should be shortened and where there are ledger lines

Re: allow changes of scripts by type

Hi! Is this still the method for making changes in specific scripts or does the situation has evolved since? Thanks! -- Sent from: http://lilypond.1069038.n5.nabble.com/Bugs-f58488.html ___ bug-lilypond mailing list bug-lilypond@gnu.org

Re: Stem lenght and ledger lines

Sorry I thought I posted this one in the bug report subforum... -- Sent from: http://lilypond.1069038.n5.nabble.com/Bugs-f58488.html ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond

Stem lenght and ledger lines

Quote from Gould's book: The outer stave-lines must be clearly visible; tails closer to noteheades will obscure ledger lines \version "2.19.80" \relative c' { \cadenzaOn \omit Score.TimeSignature \autoBeamOff e''8 e16 e32 a64 } You can see Lilypond does this for 8th and 16th notes,

Re: Stem lenght and ledger lines

Torsten Hämmerle wrote > This is sheer coincidence - LilyPond always (!) extends the stems to the > middle stave-line. > As soon as there are more than two flags, they obscure the ledger lines. > > Moreover, cue size note stems should not even extend to the middle > stave-line but be a

Key cancellation, position bug

Hi everyone,Just noticed a bug in the default placement of the naturals when key is changed.As you can see, the naturals aren't spaced correctly when using the bass clef.I tried \Staff.override KeyCancellation.padding = #0.2, but even with a larger padding, naturals aren't spaced

Re: Key cancellation, position bug

Code: \version "2.19.81" \new Staff { \override KeyCancellation.extra-spacing-width = #'(6.0 . -5.0) \key cis\major s1 \key ces\major s \clef bass \key ces\major s^"problem" \key cis\major s \bar "|." } -- Sent from:

Re: Key cancellation, position bug

*edit: don't mind the first line of the code, it was test purpose. -- Sent from: http://lilypond.1069038.n5.nabble.com/Bugs-f58488.html ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Key cancellation, position bug

Thomas Morley-2 wrote > For flat-cancellation:The result is an even spacing of every natural. I'd > call it a slightimprovement, but far from optimal.The gap between > first/second natural feels too wide and betweensecond/third too > tight.Sharp-cancellation is unchanged. Not perfect, but already

Re: Key cancellation, position bug

Torsten Hämmerle wrote > Hi Fox, > > This has nothing to do with the bass clef, as far as I can see (by > exchanging clefs, not changing clefs at all, or using alto clefs etc.), > but > it definitively has to do with the cancelled key signature: when > cancelling > flats, the naturals stick

Re: Compilation error, due to changes in pango

Hi all, For info, I'm using Archlinux and after making a maintenance update via pacman, I had a similar problem. LilyPond became almost unusable with pango 1.44.1-1 and I was forced to downgrade to 1.43.0.-2. Everything worked normally again after that. I'll stick with that for now but I hope a

Re: Compilation error, due to changes in pango

Werner LEMBERG wrote > Can you please tell me the librarie's .so numbers of 1.43.0 and 1.44.1 > (or 1.44.2)? > > > Werner Yes sure, but I don't know how to find that... -- Sent from: http://lilypond.1069038.n5.nabble.com/Bugs-f58488.html ___

Re: Compilation error, due to changes in pango

Werner LEMBERG wrote > The question is now what exactly causes this: > > error: invalid conversion from 'gpointer' {aka 'void*'} > to 'FT_Face' {aka 'FT_FaceRec_*'} > > during the lilypond compilation? Is this really caused by pango? Or > is this a glib issue? Could you

Re: Compilation error, due to changes in pango

I don't know if this has been reported, but I just updated pango on Arch, and the version 1:1.44.5-1 is working fine now ! -- Sent from: http://lilypond.1069038.n5.nabble.com/Bugs-f58488.html ___ bug-lilypond mailing list bug-lilypond@gnu.org

Re: magnifyStaff and key signature padding.

Schneidy wrote > Anything wrong with this suggestion? I confess I never noticed that before! But your regular output is way much better than the default one. I'll save your little script! Thanks Schneidy! -- Sent from: http://lilypond.1069038.n5.nabble.com/Bugs-f58488.html

Re: Clef change and measure length

Malte Meyn-3 wrote > I think that it depends on context: In a full score where only one > instrument has a clef change, it would look weird if all the other > instruments have the rest not centered. But in solo music, I’m not so > sure which one I would prefer. > > According to Gould

Re: Clef change and measure length

Malte Meyn-3 wrote > That example is the same in the german translation. But at p. 172 > (“Horizontale Ausrichtung von Pausen → Ganztaktige Pausen”, i. e. > “Horizontal positioning of rests → full measure rests”) she writes > something like “If the rest measure contains a clef, key signature or

Clef change and measure length

Hi all, I think this is a bug: when a clef change appears after a full measure rest, the rest is no longer centered properly in the measure. The result looks weird. See that example: \version "2.19.82" \new Staff \relative c' { c1 R-"default" \bar "||" R_"not centered" \clef bass