Bar lines on single staff line system

Between 2.17.0 and 2.17.1 the behaviour of single staffline systems changed. The earlier behaviour had no barline; the latter has one. Images showing this are attached. I can't decide whether this is a positive change or not. Happy to bisect if necessary. What does everyone else think? --

Re: Bar lines on single staff line system

2013/4/5 Phil Holmes : > Between 2.17.0 and 2.17.1 the behaviour of single staffline systems changed. > The earlier behaviour had no barline; the latter has one. Images showing > this are attached. I can't decide whether this is a positive change or not. > Happy to bisect if necessary. What does

Re: Bar lines on single staff line system

2013/4/5 Janek Warchoł : > 2013/4/5 Phil Holmes : >> Between 2.17.0 and 2.17.1 the behaviour of single staffline systems changed. >> The earlier behaviour had no barline; the latter has one. Images showing >> this are attached. I can't decide whether this is a positive change or not. >> Happy to

Re: Bar lines on single staff line system

>> Between 2.17.0 and 2.17.1 the behaviour of single staffline systems >> changed. The earlier behaviour had no barline; the latter has one. >> Images showing this are attached. I can't decide whether this is a >> positive change or not. Happy to bisect if necessary. What does >> everyone else

Snippet broken in 2.17.14

The snippet http://lilypond.org/doc/v2.17/Documentation/snippets/contexts-and-engravers#contexts-and-engravers-engravers-one_002dby_002done no longer produces sensible output. It was broken by http://code.google.com/p/lilypond/issues/detail?id=3225 See attached images from current unstable do

Re: Snippet broken in 2.17.14

2013/4/5 Phil Holmes > The snippet http://lilypond.org/doc/v2.17/**Documentation/snippets/** > contexts-and-engravers#**contexts-and-engravers-** > engravers-one_002dby_002done

Update essay to correct display of articulations (issue 8412044)

Reviewers: , Message: Please review - simple change to the essay to account for the changed way to remove articulations. Description: Update essay to correct display of articulations Please review this at https://codereview.appspot.com/8412044/ Affected files: M Documentation/essay/engraving

Re: X-aligning on Y-parent - ?? advice needed

2013/4/4 Janek Warchoł : > Hi Han-Wen, > > On Thu, Apr 4, 2013 at 10:48 AM, Han-Wen Nienhuys wrote: >> I think this is because these are texts that are attached to multimeasure >> rests. The multi measure rest is the Y parent of the text. IIRC, the texts >> are implemented as spanners, >> so their

Re: X-aligning on Y-parent - ?? advice needed

They have to be spanners - if the mm rest is broken across a linebreak, the text should be too. On Thu, Apr 4, 2013 at 7:01 PM, Janek Warchoł wrote: > Hi Han-Wen, > > On Thu, Apr 4, 2013 at 10:48 AM, Han-Wen Nienhuys > wrote: > > I think this is because these are texts that are attached to mult

Re: X-aligning on Y-parent - ?? advice needed

On 5 April 2013 17:47, Janek Warchoł wrote: Regardless of it being a spanner, i've tried to find where > MultiMeasureRestText's (and MultiMeasureRestNumber's) Xparent is set, > but without sucsess. I thought that maybe it happens in line 240 of > paper-column-engraver, but apparently not. Span

Re: Removes outside-staff-priority from dynamic-related objects in Dynamic context (issue 7655045)

On 2013/03/30 05:07:46, mike7 wrote: > On 2013/03/27 21:50:02, janek wrote: > > ... until Mike changed side-position-interface::y-aligned-side() so that > now below-staff text scripts now sit on top of the Dynamics reference > line ?! > Could you send an example of the text scripts doing this

Patch countdown postponed until April 6th (AM GMT)

Sorry for the inconvenience and short notice. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: X-aligning on Y-parent - ?? advice needed

Hi, 2013/4/5 Han-Wen Nienhuys : > > On Thu, Apr 4, 2013 at 7:01 PM, Janek Warchoł > wrote: >> It is obvious that MultiMeasureRest itself should be a spanner, but >> its number is just a text, an item with a fixed width. Why should it >> be a spanner? > > They have to be spanners - if the mm rest

suggestion: change OctavateEight name to ClefTransposition - opinions?

Hi, The name "OctavateEight" doesn't have any sense - it doesn't show that this grob is related to the clef, and anyway the clef can be "transposed" by any amount, not just an octave. I suggest to rename this grob to ClefTransposition or something similar (since this is not strictly transposition,

Re: Lilypond case-insensitivity (was: shall we rename X-offset)

Hi, 2013/3/25 Eluze : > janek.lilypond wrote >> I think that such functions would greatly help users who struggle with >> case-sensitivity, … > > … and other spelling problems (is it color or colour? etc.) +1 > the problem is that LilyPond doesn't provide a full list of all > > keywords > comman

did you know...

that there are at least *four* engraving mistakes in one of examples featured on our website? http://www.lilypond.org/ly-examples/bach-bwv610.png also, there are two mistakes in the "logo-like" image on front page. ouch. Janek ___ lilypond-devel mailin

Re: Bar lines on single staff line system

intended change by 6f4893fa86378aa4a637eedbde5efc4680efa5bf see http://code.google.com/p/lilypond/issues/detail?id=2762 2013/4/5 Phil Holmes : > Between 2.17.0 and 2.17.1 the behaviour of single staffline systems changed. > The earlier behaviour had no barline; the latter has one. Images showing

Re: point-and-click in SVG

On Thu, Apr 04, 2013 at 07:05:03AM +0200, Jan Nieuwenhuizen wrote: > Graham Percival writes: > > > This is because output-svg.scm's > > (grob-cause ...) > > is called *before* drawing the path of the notehead, and SVG has > > no z-index. > > What if you have grob-cause set a grob-cause for the

Re: suggestion: change OctavateEight name to ClefTransposition - opinions?

Am 05.04.2013 23:02, schrieb Janek Warchoł: Hi, The name "OctavateEight" doesn't have any sense - it doesn't show that this grob is related to the clef, and anyway the clef can be "transposed" by any amount, not just an octave. I suggest to rename this grob to ClefTransposition or something simi

Re: suggestion: change OctavateEight name to ClefTransposition - opinions?

Just a thought: LilyPond allows for any number, not just "8," so doesn't ClefTransposition actually make more sense? -David - Original Message - From: "Marc Hohl" To: lilypond-devel@gnu.org Sent: Saturday, April 6, 2013 6:35:56 AM Subject: Re: suggestion: change OctavateEight name to C