CG section 5 (Documentation work) and doc scripts

[Greg]

I have made some improvements to the Contributors' Guide: section 5
(Documentation work) and attach two patches.

Attached patch 0001 corrects some capitalisation of 'Git' and 'HTML'
(c.f.
[http://www.lilypond.org/doc/v2.19/Documentation/source/Documentation/contributor/other-text-concerns]).

Attached patch 0002 improves
[http://www.lilypond.org/doc/v2.19/Documentation/source/Documentation/contributor/scripts-to-test-the-documentation],
particularly with regard to the build/ subdirectory.

Being new to editing the docs, I have also noticed a couple of problems
with scripts/auxiliar/doc-section.sh and scripts/auxiliar/cg-section.sh.

If you run doc-section.sh without lilypond-book having been built under
the build/ subdirectory, the script fails. Perhaps the script could test
for the presence of an installed version of lilypond-book (version 2.19)
and use this instead if a copy is not available in build/. It is of
course possible to alter LILYPOND_BOOK, which could instead be mentioned
in the docs.

There is also a problem with cg-section.sh compared with doc-section.sh.
If cg-section.sh is run without the build/ and build/tempdocs/
subdirectories, the script fails with mkdir errors. However,
doc-section.sh does have better checking for missing subdirectories. It
would be helpful if cg-section.sh could check for missing subdirectories
and create them as necessary.

Thanks,
Greg.


0001-Doc-CG-5-Documentation-work-capitalisation-of-Git-an.patch
Description: Binary data


0002-Doc-CG-5.7.1-Documentation-work-esp.-build-subdirect.patch
Description: Binary data
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: note head extents and event procedures (tabstaff)

[Thomas Morley]

2015-12-22 20:24 GMT+01:00 Steve Fullerton :
>  I wasn't very clear in my first post. I've included an example this time.
>
> I am taking over the bendAfter stencil and drawing something else in its
> place. However the 'width' calculation in the code below doesn't account for
> double digit fret numbers. I think it is returning the width of a music
> note, not the width of a tab note. Changing ly:note-head to ly:tab-note-head
> doesn't work either.
>
> I have a couple of questions.
>
> 1. How do you work out the position of the right side of the tab note head
> so I can position my markup correctly?
>
> 2. Is there a better way to do this or is taking over a stencil the right
> way to do this? In other words, what is the best way to draw stuff to the
> left or right of a tab note?
>
> I am only concerned about TabStaff here so if the solution doesn't work for
> Staff it is not a problem.
>
> Thanks for your help.


Hi Steve,

I never worked with bendAfter before, so it took some time to get a
bit familiar with it _and_ because it's so weird:

(1) BendAfter is ignored by the spacing-engine! Is this really intended?
Switch to `test-stil' in the code at the end of this mail to test.
(2) It's behaviour is buggy if ledger-lines come into play, see the
attached untweaked png

code for it:

\version "2.19.32"

{
  e''4..\2\bendAfter #1
  a''4..\2\bendAfter #1
}

Thus, cc-ing bug-list.


Nevertheless in most cases translating the newly created stencil by
the car of the original-X-extent will work:

\version "2.18.2"

psBendArrow = #"
  0.1 setlinewidth
  0.0 -0.75 moveto
  0.0 -0.75 0.2 -0.75 0.4 0 curveto
  0.4 0.9 lineto
  stroke
  0.4 1.0 moveto
  0.1 0.5 lineto
  0.7 0.5 lineto
  closepath fill
  "

stil =
#(lambda (grob) (grob-interpret-markup grob (markup #:postscript psBendArrow)))

test-stil =
#(lambda (grob) (grob-interpret-markup grob "xx"))

foo =
\override BendAfter.after-line-breaking =
  #(lambda (grob)
 (ly:grob-set-property! grob 'stencil
   (ly:stencil-translate-axis
  ;; nb, settings for BendAfter doesn't affect spacing!
  ;; switch to `test-stil' to watch this
  (stil grob)
  ;(test-stil grob)
  (car (ly:grob-property grob 'X-extent))
  X)))

mus = {
  e''4\2\bendAfter #1
  a''4\2\bendAfter #1
}

\score {
  <<
\new Staff \mus
\new TabStaff \mus
  >>
  \layout {
\foo
\context {
  \TabStaff
  \tabFullNotation
}
  }
}


Cheers,
  Harm
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Review of chapter 4 of NR (spacing.itely)

[Jean-Charles Malahieude]

Le 22/12/2015 11:00, Federico Bruni a écrit :


h) 4.6.1 Displaying spacing

"Note that:

@multitable {1 staff-space} {staff-size)/4 * (25.4/72.27) mm}

@item 1 point
@tab = (25.4/72.27) mm

@item 1 staff-space
@tab = (@code{staff-size})/4 pts
@item
@tab = (@code{staff-size})/4 * (25.4/72.27) mm

@end multitable
"

The first line within @multitable block is not rendered. What is meant for?



If I'm not mistaken, it fixes the wideness of the columns: you first 
determine the largest you would need for each of them ("1 staff-space" 
for the first). This will position the tab accordingly. Look how the = 
are vertically aligned on the three lines.


Cheers,
Jean-Charles


___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Review of chapter 4 of NR (spacing.itely)

[Federico Bruni]

Il giorno sab 19 dic 2015 alle 18:11, Carl Sorensen 
 ha scritto:

Very nice work, Federico.


On 12/18/15 10:57 AM, "Federico Bruni"  wrote:



b) 4.3.1 Line breaking
"Note that manually forced line breaks have to be added in parallel
with the music:"
What means "in parallel" here? The example following this sentence 
does

not show "parallel breaks", there's only one \break in one voice.
If the purpose is suggesting the use of \break in each voice, the
example
does not match this purpose.

What I'm getting wrong?


 I think that the example is demonstrating that you can add breaks in 
a

music expression that contains only breaks and spacing information, as
long as that expression is in parallel with the music.

I use this feature often in my scores; I create a spacing variable and
actually add it in a parallel context in a Staff.

I agree that it is poorly worded and needs to be fixed.


Well, if I read it again, it's not that bad.
I would link to the snippet "Using an extra voice for breaks" some 
lines below that sentence, which describes perfectly that use of \break.



I add the last (and final) three points of my report:

g) 4.5.5 Proportional notation
"The spacing is bad because the evenly spaced notes of the bottom staff 
do not stretch uniformly. Classical engravings include very few complex 
triplets and so classical engraving rules can generate this type of 
result."


The second sentence is not very clear to me.
Which type of result?
Shouldn't say tuplets instead of triplets?


h) 4.6.1 Displaying spacing

"Note that:

@multitable {1 staff-space} {staff-size)/4 * (25.4/72.27) mm}

@item 1 point
@tab = (25.4/72.27) mm

@item 1 staff-space
@tab = (@code{staff-size})/4 pts
@item
@tab = (@code{staff-size})/4 * (25.4/72.27) mm

@end multitable
"

The first line within @multitable block is not rendered. What is meant 
for?



i) 4.6.1 Displaying spacing

"The pairs (a,b) are intervals, where a is the lower edge and b the 
upper edge of the interval."


It's not clear which pairs it's referring to.





___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Doc: CG 2.1 LilyDev minor corrections

[James Lowe]

Greg,

On 21/12/15 18:15, Greg wrote:
> I have made some minor corrections to the Contributors' Guide – 2.1
> LilyDev. A patch file is attached.
>
> This is my first patch so please let me know if there is anything else I
> should do.
>
> Thanks,
> Greg.
>
>
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-lilypond

Thank you.

Ticket created at:
https://sourceforge.net/rest/p/testlilyissues/issues/4705/

and the patch has now been put into the test/review process.

I'll include you on the Rietveld ticket (referenced in the issue but
owned by myself) so you can see if anyone has any corrections or
questions. If there are any corrections, you can send me the corrected
patch and I'll continue to manage it for you.

-- 
James

---

B8F4 5395 CBE2 ED37 7513 B075 FF32 5682 A84B D8BE

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Review of chapter 4 of NR (spacing.itely)

[Federico Bruni]

Il giorno mar 22 dic 2015 alle 11:00, Federico Bruni 
 ha scritto:

g) 4.5.5 Proportional notation
"The spacing is bad because the evenly spaced notes of the bottom 
staff do not stretch uniformly. Classical engravings include very few 
complex triplets and so classical engraving rules can generate this 
type of result."


The second sentence is not very clear to me.
Which type of result?
Shouldn't say tuplets instead of triplets?


IIUC the problem arises with longer tuplets, as in the 5-tuplet of the 
example.
As classical engravings include very few complex (and long) tuplets, 
this kind of problem is not taken into account by classical engraving 
rules.





___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Segfault when using \lookup?

[Ophir Lifshitz]

Hello all,

I am trying to insert a few unencoded (but named) glyphs from an OpenType
font (i.e., glyphs not associated with a codepoint in the cmap table). I
haven't yet figured out if it's possible — if you know how, please tell me!

I ran lilypond 2.19.31 on the following example while investigating:

{ b'^\markup { \lookup #"a" } }


and the result was:

GNU LilyPond 2.19.31
Processing `foo.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...Segmentation fault: 11


When I changed #"a" to #"foobar" it compiled successfully.

After a bit of debugging, the dynamic cast seems to return null in
stencil-integral.cc
here
.
Is it possible the case where fm is Pango_font instead of
Modified_font_metric is not handled? Is this a particularly straightforward
fix, or are more extensive modifications necessary?

Thanks,
Ophir
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond