Re: Default font for the web site

[Paul Morris]

> On Mar 2, 2016, at 6:08 PM, Simon Albrecht  wrote:
> 
>  made me think that we 
> really should specify a default font for our web site. 

I think specifying a default font is probably a good idea.  This raises a 
couple of related issues in addition to which font to specify.

We could either (A) rely on users having the font installed in their OS or (B) 
provide the font as a “web font”[1] (in compressed WOFF format[2]) that gets 
downloaded and used by the browser when someone visits the site.  

(A) OS-installed fonts
Often this approach means using one of a handful of “web safe fonts”[3] that 
are more likely to be installed.  However, as wikipedia says "most linux 
distributions don't include these fonts by default” and I’m not sure whether or 
not these fonts would be suitable for a free software project like LilyPond.  
We could specify a font like “TeX Gyre Schola” but it will only be used if a 
user has it installed.  Another wrinkle is that it is possible to specify more 
than one font so that there’s a primary font and one or more fallback fonts...

(B) web fonts
This approach gives us more control, assuring that the same font is used 
everywhere and the site looks the same regardless of the OS or what fonts users 
have installed.  The trade-off is that there is more to download when the user 
visits the site, so the first page loaded from the site is a little slower, but 
I’m not sure whether this difference would be noticeable or not.  The TeX Gyre 
fonts are available in WOFF format.[4]

[1] https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face
[2] https://developer.mozilla.org/en-US/docs/Web/Guide/WOFF
[3] https://en.wikipedia.org/wiki/Web_typography#Web-safe_fonts
[4] 
http://www.fontsquirrel.com/fonts/list/find_fonts?q[term]=Tex+Gyre&q[search_check]=Y


Another question is whether to use a serif or a sans-serif font.  There is a 
debate about whether serif or sans-serif is easier to read on screens/websites. 
 (Keeping the current serif style is the path of least resistance, of course.)

-Paul



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

Broken link on GSOC page

[Paul Morris]

On the LilyPond GSOC page: 
http://lilypond.org/google-summer-of-code.html

Under "Improve default beam positioning” the link to "section 2.2 here” goes to:
http://icking-music-archive.org/lists/sottisier/sottieng.pdf

Which no longer exists, because as it says here:
http://icking-music-archive.org/lists/sottisier/sottisier.html

that document has been moved here:
http://imslp.org/wiki/Repository_of_Music-Notation_Mistakes_%28Coulon,_Jean-Pierre%29

So a broken link to fix...

-Paul


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

Re: \markup \sans ... does not always give sans-serif output in svgs in 2.19.36

[Paul Morris]

Hi James,

> On Feb 17, 2016, at 6:26 AM, James Lowe  wrote:
> 
> Without pretending to understand any of the past history of the reasons we 
> changed the font defaults I think the problem was (and I am sure I will be 
> corrected) that the results on all the different OSes - where Century 
> Schoolbook may or may not be installed would result in unexpected results, 
> along with some 'cyrillic' considerations, so I think it seemed to make it a 
> better idea to define this via aliases.

Using the aliases is fine, but when creating svg files it is possible to 
specify a generic font-family instead of a particular font (or in addition to 
it, in case the particular font is not available).  So when producing svg files 
we could specify a generic font-family when the user asks for that (\markup 
\sans …) even if the user has not specified a particular font. 

> As to saying 'LilyPond Serif' vs just 'Serif', isn't that just semantics if 
> it is all an 'alias' anyway?

“serif” “sans-serif” and “monospace” are officially defined as meaningful 
values for the font-family property for svg files.  They tell an svg renderer 
(like a web browser) to “use a font of this type when displaying this svg 
image”.[1]  

“LilyPond Serif” and friends mean nothing to an svg renderer because they are 
neither fonts nor generic font families that they understand.

So my suggestion is that LilyPond should be smart enough to use “serif” in an 
svg file rather than “LilyPond Serif” when no particular font has been set by 
the user.  (Same for “sans-serif” and “monospace” for “LilyPond Sans Serif” and 
“LilyPond Monospace”.)  

Hope that clarifies things.


[1] Links to svg specification / documentation:

http://www.w3.org/TR/SVG11/text.html#FontFamilyProperty
http://www.w3.org/TR/2008/REC-CSS2-20080411/fonts.html#font-specification
http://www.w3.org/TR/2008/REC-CSS2-20080411/fonts.html#generic-font-families


The following generic families are defined: 'serif', 'sans-serif', 'cursive', 
'fantasy', and 'monospace'. Please see the section on generic font families for 
descriptions of these families. Generic font family names are keywords, and 
therefore must not be quoted.
Authors are encouraged to offer a generic font family as a last alternative, 
for improved robustness.



> Here are the core check-ins (in case we have already discussed what you are 
> asking on dev or bug - if only at a programmatic level that I am not 
> competent enough to understand).
> 
> e.g
> 
> https://code.google.com/archive/p/lilypond/issues/4441
> https://codereview.appspot.com/241340043/

Thanks.  I took a look.  My sense is that what I am talking about would need to 
happen in the svg backend code, but I’m just making a more or less educated 
guess.


> I did go round the houses with the devs on this when trying to help the patch 
> submitted with the documentation. No one seemed to express concerns about the 
> alias part - but of course that doesn't mean it cannot be an enhancement.

Ok, I'd still say it’s a regression since 2.18 produces svg files that better 
reflect user input than 2.19, but I’ll take an enhancement.  :-)

Thanks,
-Paul



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

Re: \markup \sans ... does not always give sans-serif output in svgs in 2.19.36

[Paul Morris]

> On Feb 16, 2016, at 4:17 PM, James Lowe  wrote:
> 
> From usage:
> 
> http://lilypond.org/doc/v2.19/Documentation/usage-big-page#advanced-command-line-options-for-lilypond
>  
> 
> Note for backend svg output: LilyPond’s default fonts (LilyPond Serif, 
> LilyPond Sans Serif and LilyPond Monospace) are just local font aliases. 
> Therefore, when using the backend svg command you must explicitly define the 
> default fonts in your source file;
> 
Thanks James, I hadn’t seen that explanation and workaround.

It still seems like it would be better if these local aliases didn’t make it 
into the svg files by default (when fonts are not user specified).  Seems like 
LilyPond's svg backend code could simply substitute:

“serif” for “LilyPond Serif”
“sans-serif” for “LilyPond Sans Serif”
“monospace” for “LilyPond Monospace”

That would produce svgs that had valid defaults and met expectations, svgs like 
those produced by 2.18.

(Well, instead of “serif” in 2.18 you would get "Century Schoolbook L” but I 
think “serif” is the better default.  Or we could specify both a specific font 
and a generic fallback like "TeX Gyre Schola, serif”.  That’s an option with 
the svg font-family property.)

So this seems like a regression to me, or at least a good feature request.

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

Re: Noteheads slightly too large

[Paul Morris]

Hi Pierre,

> On Feb 10, 2016, at 4:08 AM, Pierre Perol-Schneider 
>  wrote:
> 
> Finally, after all types of trials, using 'stencil-scale is definitely the 
> best workaround to reach an acceptable note head output:
> 
> #(set-global-staff-size 180)  %% <= below scales and offsets were set at 
> #(set-global-staff-size 300) and controlled at zoom #2000 
> #(set-default-paper-size "a4" 'landscape)
> 
> \layout {
>   indent = 0
>   \context {
> \Staff
> \omit Clef
> \omit TimeSignature
>   }
> }
> 
> \relative {
>   \override NoteHead.stencil = 
> #(lambda (grob) (ly:stencil-scale (ly:note-head::print grob) 0.980  
> 0.924))
>   \override NoteHead.extra-offset = #'(0 . -.001)
>   d'4*1/2 f2*1/4 a1*1/8 c\breve*1/16 e\longa*1/32 
> }

Looks good!  Nice to have a workaround for this until the font itself is 
adjusted (assuming it will be).

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

Re: Exporting fonts as outlines in SVG (was: \markup \sans ... does not always give sans-serif output in svgs in 2.19.36)

[Paul Morris]

> On Feb 13, 2016, at 4:05 PM, Urs Liska  wrote:
> 
> would it be possible to (optionally) export text fonts as outlines in the SVG?

This would be a nice option to have at some point, but I can’t speak to 
feasibility / amount of effort entailed.

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

Re: Noteheads slightly too large

[Paul Morris]

> On Feb 14, 2016, at 10:11 AM, David Kastrup  wrote:
> 
> Your image only shows notes between staff lines.  However, a reduction
> in notehead size will mainly make notes _on_ staff lines look too small
> and/or unsymmetric so the image is not really useful for judging
> potential _downsides_ of that change.  Can you do a more complete image,
> including ledger lines and larger note values (half, semibreve, breve,
> longa)?

Maybe also include an example with some note heads that are colored so you can 
see better how they overlap with the staff lines?  i.e. with 

\override NoteHead.color = #blue

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

Re: \markup \sans ... does not always give sans-serif output in svgs in 2.19.36

[Paul Morris]

Looking closer at the SVG files produced...  In 2.18 we have this:

   some text 


And when I manually edit the 2.19 svg file so it has font-family="sans-serif” 
then that fixes it and the text appears as sans-serif.  Elsewhere in the svg 
files I see that:

2.18 svg has:  font-family="Century Schoolbook L”
2.19 svg has:  font-family="LilyPond Serif"

From this thread:
http://lists.gnu.org/archive/html/lilypond-devel/2015-06/msg00175.html

and this commit:
http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=28f58ecc2271956e9377dc61e5135ce3ade4abbd

we see that “LilyPond Sans Serif” and “LilyPond Serif” are aliases.  So it 
appears that the code that produces the svgs is including the alias names for 
“font-family" rather than what the alias refers to (e.g. “sans-serif” or 
"Century Schoolbook L”).

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

\markup \sans ... does not always give sans-serif output in svgs in 2.19.36

[Paul Morris]

\version “2.18.2"
\markup \sans {"This is sans-serif in svg output everywhere I view it."}


\version “2.19.36"
\markup \sans {"This is _not_ sans-serif in svg output in firefox, chromium, or 
mac os preview."}



However, strangely, the 2.19 svg does have sans-serif text in inkscape and the 
frescobaldi svg viewer.

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

Re: Noteheads slightly too large

[Paul Morris]

Hi Pierre,

> On Feb 9, 2016, at 4:30 PM, Pierre Perol-Schneider 
>  wrote:
> 
> Some thoughts regarding the use of ly:stencil-scale:
> 1. the command seems to have a side effect on the stem attachment (or 
> probably no effect on the note head extents - tested on a W8 OS)
> 2. applying it on all note heads suppose that all glyphs have the same scale 
> defects (which is not the case, see my example with the harmonic style).
> 
> So here's my attempt to get something liable to all note head styles.
> Unfortunately I did note find any direct procedure to get the 'default style 
> ( '() do not work):

Well, I was only intending that code for testing purposes.  Looks like you’ve 
got a good start on something for actual use.

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

Re: Noteheads slightly too large

[Paul Morris]

> On Feb 9, 2016, at 10:12 AM, tisimst  wrote:
> 
> Although microscopic, I can confirm this is true at the font level (at
> least at the default printed 20pt size, I didn't check the other optical
> variants). Relative to a 1000-em unit staff height (which is what the fonts
> are designed to, center of bottom staff line to center of top staff line),
> here are the dimensions causing the problem you are seeing:
> 
> staff-space = 250-em
> staff line thickness = 25-em (i.e., 0.1 staff-space)
> solid notehead height = 276-em
> 
> Now, here's the discrepancy. The distance between the bottom of a staff
> line to the top of the next staff line up, is 250+25 = 275-em. That means
> that there is an overall difference in size of 1-em unit (at the 20pt
> printed size, this equates to 1/50pt = 0.00028in = 0.0071mm difference). In
> other words, we are technically splitting hairs with this, but nonetheless,
> it is a difference. The solid notehead is "too large" by 1/100pt on either
> side.

Interesting...  Here’s some code for experimenting with this.  It scales 
notehead stencils. A scaling of 250/276 should make the solid notes equal to 
one staff-space.  (Or should it be 275/276 to make it the "distance between the 
bottom of a staff line to the top of the next staff line up”?)

-Paul


\version "2.19.36"

example = \relative {
  c' d e f g a b c
}

{
  \example
}

{
  \override NoteHead.stencil =
  #(lambda (grob)
 (ly:stencil-scale
  (ly:note-head::print grob)
  250/276  250/276))

  \example
}




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

Re: lily-git.tcl not fully ready to run on LilyDev 4

[Paul Morris]

Hi Federico,

> On Dec 1, 2015, at 10:56 AM, Federico Bruni  wrote:
> 
> Thanks for the reminder. I probably forgot it when working on this:
> https://github.com/fedelibre/LilyDev/pull/4
> 
> I'll add it tomorrow

That’s great, thanks!
-Paul
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

lily-git.tcl not fully ready to run on LilyDev 4

[Paul Morris]

In CG 2.2, under “Where to get lily-git" it reads:

  If you are using LilyDev (see LilyDev) then lily-git should already be 
installed and ready to run.


But it seems that this is not the case with LilyDev 4.  At least not when I 
tried it today.  Not a big problem since as it goes on to say:

  If this is not the case you can easily turn it on by adding the following 
line in ~/.bashrc:
  # add lily-git to the PATH
  PATH=$LILYPOND_GIT/scripts/auxiliar:"${PATH}"


This worked fine, but it would be better not to have to take this extra step, 
for those using lily-git.tcl

-Paul


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

Re: Docs: inconsistency about ly:context-pushpop-property

[Paul Morris]

> On Oct 18, 2015, at 4:21 AM, David Kastrup  wrote:
> 
> It does a "\temporary \override".  Well spotted.

Thanks for clarifying that and for pointing out the other similar updates that 
are needed.  Improving the doc strings would definitely help matters.

-Paul


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

Docs: inconsistency about ly:context-pushpop-property

[Paul Morris]

The docs appear to be inconsistent about ly:context-pushpop-property.  Does it 
do a \temporary \override or just an \override ?

-Paul

_

ly:context-pushpop-property

do a \temporary \override or a \revert on a grob property

http://www.lilypond.org/doc/v2.19/Documentation/extending/context-evaluation

_

Function: ly:context-pushpop-property context grob eltprop val

Do a single \override or \revert operation in context. The grob definition grob 
is extended with eltprop (if val is specified) or reverted (if unspecified).

http://lilypond.org/doc/v2.19/Documentation/internals/scheme-functions




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

Re: New issue: Add StaffAxis context type

[Paul Morris]

This is a nice addition! I'm not opposed to "StaffAxis" either, but here's 
another suggestion to consider: "StaffRow".

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

error with scripts/auxiliar/update-with-convert-ly.sh on LilyDev3

[Paul Morris]

Running 
scripts/auxiliar/update-with-convert-ly.sh
in LilyDev3 results in the following error:

make: *** No rule to make target `python-modules'.  Stop.
xargs: ./out/bin/convert-ly: No such file or directory
xargs: ./out/bin/convert-ly: No such file or directory

Keith noted that:
"Looking at the first few lines of update-with-convert-ly, it looks
like it expects you to have defined the build directory as BUILD_DIR
where most other scripts expect LILYPOND_BUILD_DIR.”

A workaround is to run:
export BUILD_DIR=$LILYPOND_BUILD_DIR

Two possible ways to fix:
- add BUILD_DIR as an environmental variable in LilyDev
- edit the script to use LILYPOND_BUILD_DIR

See message below for more details.

Thanks,
-Paul


> Begin forwarded message:
> 
> From: David Kastrup 
> Subject: Re: add stencil-whiteout-outline function (issue 236480043 by 
> paulwmor...@gmail.com)
> Date: June 2, 2015 at 2:58:12 AM EDT
> To: "Keith OHara" 
> Cc: paulwmor...@gmail.com, lilypond-de...@gnu.org
> 
> "Keith OHara"  writes:
> 
>> On Mon, 01 Jun 2015 19:29:41 -0700,  wrote:
>> 
>>> scripts/auxiliar/update-with-convert-ly.sh
>>> I get this:
>>> 
>>> make: *** No rule to make target `python-modules'.  Stop.
>>> xargs: ./out/bin/convert-ly: No such file or directory
>>> xargs: ./out/bin/convert-ly: No such file or directory
>>> 
>>> I'm running LilyDev3 in a virtual machine.  (Feeling like I'm in over my
>>> head with this one.)
>> 
>> Looking at the first few lines of update-with-convert-ly, it looks
>> like it expects you to have defined the build directory as BUILD_DIR
>> where most other scripts expect LILYPOND_BUILD_DIR.
> 
> Probably an oversight and worth fixing.  I use this script only in-place
> so might have escaped this trap.
> 
> Doing the (really slow) git log --pickaxe-regex -S '[^_]BUILD_DIR'
> discovers only instances of BUILD_DIR in the docs, used in example
> scripts or recipes that set it themselves first.
> 
> convert-ly has been created using BUILD_DIR from the start.
> 
>>> export BUILD_DIR=$LILYPOND_BUILD_DIR
> 
> Well, that would be a first aid measure.
> 
> -- 
> David Kastrup
> 
> ___
> lilypond-devel mailing list
> lilypond-de...@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

Re: fixcc.py and astyle dependency problem on LilyDev

[Paul Morris]

Federico Bruni wrote
> We depend on Debian repositories.
> Current stable has 2.01:
> https://packages.debian.org/search?keywords=astyle
> 
> Next stable should have 2.04 (now in testing).
> The quick solution is using the apt pinning to install the package from
> testing. You may also try to just install the deb from debian.org website.
> Or upgrade all the system to testing (it is actually very stable).

Hi Federico,

Ok, I'll look into installing astyle 2.04.  

fixpy.cc will still need to be updated to work with 2.04 since it currently
only accepts 2.02.  In fixpy.cc I see there's the line:

  REQUIRED_ASTYLE_VERSION = "Artistic Style Version 2.02"

Should I simply edit that to say 2.04 ?  Can we assume that it will still
work as expected with the newer version?

Thanks,
-Paul



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/fixcc-py-and-astyle-dependency-problem-on-LilyDev-tp173644p173654.html
Sent from the Bugs mailing list archive at Nabble.com.

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

fixcc.py and astyle dependency problem on LilyDev

[Paul Morris]

Greetings all, In the current LilyDev [0] when I try to run fixcc.py on a file 
[1] I get this error:

  Error: we require Artistic Style Version 2.02
  Sorry, no higher or lower versions allowed

It seems that astyle 2.01 is installed in LilyDev, and 2.01 is the only version 
available via apt-get or the synaptic package manager.  The oldest version 
available from the astyle website is 2.03 [2].

Possible solutions: install astyle 2.02 in LilyDev by default, or revise 
fixcc.py so it works with astyle 2.01.

-Paul

[0] http://lilypond.org/doc/v2.19/Documentation/contributor/lilydev 

[1] http://lilypond.org/doc/v2.19/Documentation/contributor/indentation 

[2] http://sourceforge.net/projects/astyle/files/astyle/ 


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

Re: Make defining new contexts simpler with better \alias functionality

[Paul Morris]

Colin Campbell-8 wrote
> Done, Paul:
> 
> Issue 4326
> : 
> Enhancement: simplify accepting a new custom context like an existing 
> context

Thanks Colin!
-Paul



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Make-defining-new-contexts-simpler-with-better-alias-functionality-tp172723p173271.html
Sent from the Bugs mailing list archive at Nabble.com.

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

Re: Make defining new contexts simpler with better \alias functionality

[Paul Morris]

I have this on my list of things to work on, but I don't know when I'll be
able to get to it (and there are some other LilyPond items that I'd like to
work on first).  So can someone add a tracker issue for this?  (I'd add it
myself but I don't have those privileges.)  Here's a suggested title:

"Enhancement: simplify accepting a new custom context like an existing
context"

and then just a link to this discussion thread would suffice, especially the
message with David's proof of concept code here:
http://lists.gnu.org/archive/html/bug-lilypond/2015-03/msg00022.html

Thanks,
-Paul



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Make-defining-new-contexts-simpler-with-better-alias-functionality-tp172723p173224.html
Sent from the Bugs mailing list archive at Nabble.com.

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

Re: LP website : right column has strange look in other langage than english

[Paul Morris]

Schneidy wrote
> Please check the right column on the website, e.g. here :
> http://lilypond.org/index.fr.html
> compared to : http://lilypond.org/index.html

Yes, see also: 
http://lists.gnu.org/archive/html/lilypond-devel/2015-03/msg00112.html

Once the files for other languages are updated by the translators all will
be well.  (I don't think we need a tracker issue for this? But I leave that
up to the bug squad.)

Cheers,
-Paul



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/LP-website-right-column-has-strange-look-in-other-langage-than-english-tp173117p173119.html
Sent from the Bugs mailing list archive at Nabble.com.

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

Re: Make defining new contexts simpler with better \alias functionality

[Paul Morris]

David Kastrup wrote
> You are thinking too complicated.
> 
> \score {
>   <<
> \new myVoice { c' d' e' f' }
> \new myOtherVoice { e' f' g' a' }
>   >>
> 
>   \accept-like Voice myVoice
>   \accept-like Voice myOtherVoice
>   \layout {
> \context {
>   \Voice
>   \name myVoice
>   \alias Voice
>   \override NoteHead.color = #blue
> \context {
>   \Voice
>   \name myOtherVoice
>   \alias Voice
>   \override NoteHead.color = #green
> }
>   }
> }

Nice! That solves that. 
-Paul




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Make-defining-new-contexts-simpler-with-better-alias-functionality-tp172723p172823.html
Sent from the Bugs mailing list archive at Nabble.com.

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

Re: Make defining new contexts simpler with better \alias functionality

[Paul Morris]

I thought of another limit case: trying to create more than one custom
context inside a single score block, as follows, will result in more than
one typeset score:

\score {
  <<
\new myVoice { c' d' e' f' }
\new myOtherVoice { e' f' g' a' }
  >>

  \accept-like Voice myVoice \layout {
\context {
  \Voice
  \name myVoice
  \alias Voice
  \override NoteHead.color = #blue
}
  }
  \accept-like Voice myOtherVoice \layout {
\context {
  \Voice
  \name myOtherVoice
  \alias Voice
  \override NoteHead.color = #green
}
  }
}


One way around this would be to edit the function to work as follows,
accepting an alist as the first argument.  

\score {
  <<
\new myVoice { c' d' e' f' }
\new myOtherVoice { e' f' g' a' }
  >>

  \accept-like #'((Voice . myVoice) (Voice . myOtherVoice)) \layout {
\context {
  \Voice
  \name myVoice
  \alias Voice
  \override NoteHead.color = #blue
}
\context {
  \Voice
  \name myOtherVoice
  \alias Voice
  \override NoteHead.color = #green
}
  }
}

That's less elegant as the user has to switch into scheme to supply the
first argument.

-Paul



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Make-defining-new-contexts-simpler-with-better-alias-functionality-tp172723p172810.html
Sent from the Bugs mailing list archive at Nabble.com.

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

Re: Make defining new contexts simpler with better \alias functionality

[Paul Morris]

David Kastrup wrote
> Actually, that kind of usage only works outside of \score.
> 
> If you write
> \score {
>   ...
>   \layout { \context { \Voice \name myVoice } }
>   \accept-like Voice myVoice \layout { }
> }
> 
> Then you get _two_ typeset scores.  One without the \accept properties
> in place, and one without the context definition.
> 
> But your proposal would not really fare better: an \accept-like-layout
> command in that position would not really have a way of getting at the
> previous score-specific layout definition.

Ah, ok, good catch.  So for score specific contexts the following usage is
needed.

\score {
  \new myVoice { c' d' e' f' }
  
  \accept-like Voice myVoice \layout {
\context {
  \Voice
  \name myVoice
  \alias Voice
  \override NoteHead.color = #blue
}
  }
}

So it's probably best to just recommend that as the way to do it in all
cases.

-Paul



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Make-defining-new-contexts-simpler-with-better-alias-functionality-tp172723p172806.html
Sent from the Bugs mailing list archive at Nabble.com.

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

Re: Make defining new contexts simpler with better \alias functionality

[Paul Morris]

David Kastrup wrote
> An extra command seems like bikeshedding when you can just write
> 
> \accept-like Voice myVoice \layout { }
> 
> instead.

Good point!  Lets just go with that.

What should the function be named?  How about "\accept-context-like" ?  I
haven't come up with anything better.

Also, where would this go in the code base?  If you like I can work up a
patch with documentation for the manuals, but I don't know what file to add
it to.

-Paul



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Make-defining-new-contexts-simpler-with-better-alias-functionality-tp172723p172785.html
Sent from the Bugs mailing list archive at Nabble.com.

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

Re: Make defining new contexts simpler with better \alias functionality

[Paul Morris]

Paul Morris wrote
> (The only possible down side I see is that users may find it strange to
> supply an output definition as a function argument, but I don't know of a
> way around that.)

Well, here's one possible way.
-Paul

\version "2.19.16"

accept-like =
#(define-scheme-function (parser location old new out)
   (symbol? symbol? ly:output-def?)
   (for-each
(lambda (p)
  (let* ((sym (car p))
 (def (cdr p))
 (acc (ly:context-def-lookup def 'accepts)))
(if (and (memq old acc) (not (memq new acc)))
(ly:output-def-set-variable! out sym
  (ly:context-def-modify
   def
   (ly:make-context-mod
`((accepts ,new
(ly:output-find-context-def out))
   out)

accept-like-layout =
#(define-scheme-function (parser location old new)
   (symbol? symbol?)
   #{ \accept-like $old $new \layout { } #})

accept-like-midi =
#(define-scheme-function (parser location old new)
   (symbol? symbol?)
   #{ \accept-like $old $new \midi { } #})

%%

\layout {
  \context {
\Voice
\name myVoice
\alias Voice
\override NoteHead.color = #blue
  }
}

\accept-like-layout Voice myVoice

\midi {
  \context {
\Voice
\name myVoice
\alias Voice
  }
}

\accept-like-midi Voice myVoice

\score {
  \new myVoice { c'1 }
  \layout {}
  \midi {}
}



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Make-defining-new-contexts-simpler-with-better-alias-functionality-tp172723p172760.html
Sent from the Bugs mailing list archive at Nabble.com.

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

Re: Make defining new contexts simpler with better \alias functionality

[Paul Morris]

David Kastrup wrote
> That does not work since contexts have no notion of what other contexts
> may accept them and \denies does not maintain a list of its own but just
> removes material from the \accepts lines.  If an alias is to be accepted
> in lieu of an actual context, there is no way to dial back the
> acceptance.

Ah I see, yes if contexts have no "denies" list then this won't work.  


David Kastrup wrote
> I think it would make more sense to have a command that will walk
> through an output definition and make the required changes, like
> 
> \accept-like Voice myVoice
> \layout {
>   \context {
> \Voice
> \name "myVoice"
> ...
>   }
> }
> 
> That does not require new internals and is pretty straightforward to
> write as a scheme function taking two symbols and an output definition
> as arguments and returning an output definition.

That makes sense to me.  It gets the job done without having to change the
internals.  Setting up the default contexts is a different kind of task than
a user copying and modifying one of them.  So this may be the best way to
provide for the latter.  Thanks for weighing in on this and for providing
the proof of concept.

(The only possible down side I see is that users may find it strange to
supply an output definition as a function argument, but I don't know of a
way around that.)

-Paul







--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Make-defining-new-contexts-simpler-with-better-alias-functionality-tp172723p172743.html
Sent from the Bugs mailing list archive at Nabble.com.

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

Make defining new contexts simpler with better \alias functionality

[Paul Morris]

This is not a bug but an enhancement idea.

Make defining new contexts simpler with better \alias functionality.

Use \alias for determining what contexts accept other contexts (and not just 
for allowing commands accepted in one context to be used in another context).

Jim Long:

“...it would be nice, if it is practical, for "Higher" contexts to decide to 
accept "Lower" contexts based on context name (\ChordNames) as well as on alias 
(\alias ChordNames).

A would accept C because A accepts B, and C is explicitly 
declared as an alias of B.  Therefore, A would accept B and all 
aliases of B.”

Paul Morris: 

"Most of the time if we want commands that work in X to work in Y (by using 
\alias X), we also want Y to be accepted wherever X is accepted.

So when Z is determining whether to accept a new context Y... have it first 
check Y's name, and if the name is unknown (not in its "accepts" list) then 
have it check Y's alias (\alias X).  If the alias X is in the "accepts" list, 
then Z would accept Y. 

In rare cases where we didn't want these things coupled (where we wanted 
commands from X to work in Y, but we didn't want Y to be accepted wherever X is 
accepted), then we could use \denies and \accepts to define exactly where we 
want Y to be accepted or denied.

This would really simplify the process of creating custom contexts, especially 
in the common case of wanting a modified version of an existing context that 
works everywhere it does.”

See full discussion thread here:
http://lists.gnu.org/archive/html/lilypond-user/2015-02/msg00684.html



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

Update guile version dependency info in docs from "1.8.2 or newer" to "1.8.2"

[Paul Morris]

In the docs, update dependency info from guile “(1.8.2 or newer)” to just 
“(1.8.2)” until guile 2.0 support is stable.  As reported on the user list here:

http://lilypond.1069038.n5.nabble.com/Kubuntu-GCC-compile-with-guile-2-td169498.html
 



I did a cursory web search and found these two instances. There may be others.

http://lilypond.org/doc/v2.18/Documentation/topdocs/INSTALL#requirements-for-running-lilypond
 


http://lilypond.org/doc/v2.19/Documentation/contributor-big-page#requirements-for-running-lilypond
 


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

Re: barcheck failure with partial in middle of piece

[Paul Morris]

David Kastrup wrote
> More like you are expecting too much from |.  A bar check will check
> that you are at the end of a bar.  Putting it in parallel with \partial
> does not make all that much sense since \partial explicitly demands
> _not_ to be at the end of a bar.
> 
> At any rate, I found some branch in my repository that appears to change
> the behavior to the one you'd have preferred in this case.  Probably the
> patch did not work in the particular case I had in mind or had some
> logical fallacy in it or failed some other test.
> 
> Since it at least seems to cause more expected behavior in your usage,
> I've put it to review as
> 
> Tracker issue: 4056
> (http://code.google.com/p/lilypond/issues/detail?id=4056)
> Rietveld issue: 119610044 (http://codereview.appspot.com/119610044)
> Issue description:
>   Let \partial in mid-piece work via a finalization hookThat
>   allows all other processing to complete before measurePosition is
>   adjusted.  In particular, this avoids problems when multiple
>   parallel  contexts invoke \partial and/or bar checks.  Also
>   contains commit:  Regtest for \partial in mid-piece

Thanks David!  Glad you already had a solution for this on the drawing
board.  Talk about turnaround time.  I knew you were good, but anticipating
and solving issues before they are reported is taking it to another level. 
:-)  Thanks also for making \partial work mid-piece in the first place.

Abraham, thanks for the pointer to your workaround.

Having looked into this some more, it seems that (one place) where I went
wrong was assuming that I needed to have matching \partial commands in each
parallel context, when it seems that a \partial only needs to be in one of
them.  If that's correct, would it be worth adding something about this to
the docs?  Although maybe that wouldn't be needed after David's new patch?

http://lilypond.org/doc/v2.19/Documentation/notation/displaying-rhythms#upbeats

-Paul




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/barcheck-failure-with-partial-in-middle-of-piece-tp165402p165417.html
Sent from the Bugs mailing list archive at Nabble.com.

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

barcheck failure with partial in middle of piece

[Paul Morris]

I'm getting an unexpected barcheck failure when using partial in the middle
of a piece.  In the minimal example below, if you comment out the chords the
first barcheck succeeds, but with the chords included it fails.  (Also the
beaming in that first measure is off.)  

Not sure if this is a bug or if I'm expecting too much from \partial.  In
2.18 there was a warning for using \partial after the start of a piece, but
not in 2.19.

(Actual use case: in fiddle tunes where the A and B parts are each repeated,
and there's a line \break before the start of the B part...  the pickup
notes for the B part should be notated at the beginning of the B part,
rather than at the end of the A part, to easily see them when repeating back
to the start of the B part.  Hence the use of partial in the middle of a
piece.)

Cheers,
-Paul


\version "2.19.11"

melodyOne = \relative {
  \time 6/8
  a'8 a a a a a | % this barcheck fails when chords are present
  \partial 8
  d8 |
  c8 c c c c c |
}

chordsOne = \chordmode {
  \time 6/8
  a2. |
  \partial 8
  s8 |
  a2. |
}

\score {
  <<
\new ChordNames { \chordsOne }
\new Staff { \melodyOne }
  >>
}



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/barcheck-failure-with-partial-in-middle-of-piece-tp165402.html
Sent from the Bugs mailing list archive at Nabble.com.

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

Dots are shifted to avoid non-existent ledger lines (with custom ledger line positions)

[Paul Morris]

Here's an obscure one: when ledger line positions have been overridden, the 
positions of dots on dotted notes are still shifted to avoid ledger lines that 
are no longer there.  They don't seem to be shifted based on actual ledger line 
positions.

-Paul


\version "2.18.2"

greenNote =  \once \override NoteHead.color = #green

\markup { Dots are shifted to avoid non-existent ledger lines (see green 
notes). }

\new Staff \with {
  \override StaffSymbol.line-positions = #'(-4 0 4)
  \override StaffSymbol.ledger-positions = #'(-4 0 4)
}
\relative f' {
  \time 12/4
  c,4. d e
  \greenNote f
  g a b
  \greenNote c
  g''
  \greenNote a
  b c d
  \greenNote e
  f g
}

\markup { Dots are not being shifted based on actual ledger line positions.}

\new Staff \with {
  \override StaffSymbol.ledger-positions = #'(-3 -1 1 3 5)
}
\relative f' {
  c, d e f g a b c
}

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

Docs: "Line length" page and "line-width" property

[Paul Morris]

In the Notation Reference, this page[1] is called "Line length" but the 
property that it covers (among others) is called "line-width."  Seems like it 
would be better if the title of the page was "Line width" for greater 
consistency.

[1] http://lilypond.org/doc/v2.19/Documentation/notation/line-length

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

Re: LSR search results: title text doesn't match links or images

[Paul Morris]

Schneidy wrote
> Should be fixed now.
> 
> ~Pierre

Hi Pierre, 
Wow that was fast!  Thanks!
-Paul



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/LSR-search-results-title-text-doesn-t-match-links-or-images-tp161698p161709.html
Sent from the Bugs mailing list archive at Nabble.com.

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

LSR search results: title text doesn't match links or images

[Paul Morris]

Hello,  

There seems to be something odd going on with LSR search results.  When I do
a search for "title:defining" 
http://lsr.di.unimi.it/LSR/Search?q=title%3Adefining

I get these three results:

  Display bracket with only one staff in a system [0.14286]
  Dynamics custom text spanner postfix [0.14286]
  Percent repeat counters for piano music [0.14286]

None of which have "defining" in the title.  However, clicking on the links
takes me to these snippets that do:

  Defining predefined fretboards for other instruments 
  http://lsr.di.unimi.it/LSR/Item?id=578

  Defining an engraver in Scheme: ambitus engraver
  http://lsr.di.unimi.it/LSR/Item?id=805

  Defining a Custom Staff Context
  http://lsr.di.unimi.it/LSR/Item?id=882

And then I notice that the images in the search results are from these 3
"defining" snippets.  So in the list of results the images as well as the
links do not correspond with the titles.  

I'm seeing a similar pattern with other searches too, not just with
"title:defining".  Does anyone else see this?

-Paul



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/LSR-search-results-title-text-doesn-t-match-links-or-images-tp161698.html
Sent from the Bugs mailing list archive at Nabble.com.

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

Re: page-break-permission = ##f doesn't work for the final manual \pageBreak

[Paul Morris]

Paul Morris wrote
> Hmmm...  one way to look at this is that the docs here:
> http://lilypond.org/doc/v2.18/Documentation/notation/explicit-breaks
> 
> give the impression that LilyPond has a mode that will _only_ insert
> breaks where there are explicit break commands (***and nowhere else***). 
> But is that actually the case?  The following leads you to think there is
> such a "manual break only" mode:
> 
> "When line-break-permission is overridden to false, Lily will insert line
> breaks at explicit \break commands ***and nowhere else***. When
> page-break-permission is overridden to false, Lily will insert page breaks
> at explicit \pageBreak commands ***and nowhere else***."
> 
> 
> But what it says at the top of that page is a little different:
> 
> "Lily sometimes rejects explicit \break and \pageBreak commands. There are
> two commands to override this behavior:"
> 
> If that is the more accurate account of what these commands do, then they
> don't really prevent automatic breaks from being inserted.  They just
> prevent explicit breaks from being ignored/rejected.  If that's the case
> then I think the next part should be revised like this:
> 
> "When line-break-permission is overridden to false, Lily will _always_
> insert line breaks at explicit \break commands. When page-break-permission
> is overridden to false, Lily will _always_ insert page breaks at explicit
> \pageBreak commands."

I withdraw this suggestion, given the evidence in the other thread (that I
started about the example on this page).

But that evidence further confirms to me that what I'm seeing here is indeed
a bug, since it looks like no automatic page breaks should be inserted at
all when page-break-permission is ##f (regardless of ragged-bottom or
ragged-last-bottom settings).

As David Kastrup suggested on the user list this issue is probably related:
https://code.google.com/p/lilypond/issues/detail?id=3281

-Paul



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/page-break-permission-f-doesn-t-work-for-the-final-manual-pageBreak-tp159763p159852.html
Sent from the Bugs mailing list archive at Nabble.com.

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

Re: Docs: example for line-break-permission and page-break-permission

[Paul Morris]

Trevor Daniels wrote
> However, I'm not sure that the change proposed by Paul is correct.
> I think the current wording is correct.
> 
> Try this, and you'll see the long line runs off the right side of the
> page.
> No line break is inserted to prevent it; only the manual ones are
> actioned.

I tried this and I see what you mean.  Also this for testing pagebreak:

\paper {
  indent = #0
  ragged-right = ##t
  ragged-bottom = ##t
}

music = \relative c'' { c8 c c c c c c c }

\score {
  \new Staff {
\repeat unfold 110 { \music } 
  }
  \layout {
\context {
  \Score
  \override NonMusicalPaperColumn.page-break-permission = ##f
}
  }
}

No auto page breaks were inserted, the music was compressed onto one page,
and I got these:
warning: cannot fit music on page: overflow is 27.591750
warning: compressing music to fit

So I think Trevor is right that this is an accurate statement:

"When line-break-permission is overridden to false, Lily will insert line
breaks at explicit \break commands and nowhere else. When
page-break-permission is overridden to false, Lily will insert page breaks
at explicit \pageBreak commands and nowhere else."

(And if that's the case then it convinces me that what I reported in the
other thread is indeed a bug.)

That means that this statement is potentially misleading:

"Lily sometimes rejects explicit \break and \pageBreak commands. There are
two commands to override this behavior:"

If these commands prevent automatic breaks, then that is different from, and
unrelated to, preventing rejecting explicit breaks.

So I like James' suggestion for a more thorough explanation that would
remove this ambiguity.


Trevor Daniels wrote
> Yes.  I'd remove the pagebreak from this example (since its effect is not
> clear in the docs anyway); use a smaller example showing a line break
> being
> inserted and being suppressed; and simply say page-break-permission
> works the same way.  I'd also give the music variable a full bar of notes
> rather than half a bar so the repeat counts correspond with the number
> of bars in the lines.

This makes sense to me.  Here's a smaller and more focused example:

% default output
\repeat unfold 10 { c'4 c' c' c' } 

% automatic line breaks suppressed
\score {
  \new Staff {
\repeat unfold 10 { c'4 c' c' c' } 
  }
  \layout {
\context {
  \Score
  \override NonMusicalPaperColumn.line-break-permission = ##f
}
  }
}

Maybe a clearer name for these commands would have been:

  automatic-line-breaks = ##f
  automatic-page-breaks = ##f

-Paul





--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Docs-example-for-line-break-permission-and-page-break-permission-tp159803p159851.html
Sent from the Bugs mailing list archive at Nabble.com.

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

Re: page-break-permission = ##f doesn't work for the final manual \pageBreak

[Paul Morris]

On Feb 24, 2014, at 3:38 PM, Federico Bruni  wrote:

> No, my fault: you should change the value of ragged-last-bottom:
> 
> \paper {
>   ragged-last-bottom = ##f
> }

Ah, ok, thanks.  Glad to know there's already a way to achieve this.


> If the point of setting page-break-permission = ##f is to "insert page
> breaks at explicit \pageBreak commands and nowhere else" as the docs say...
> and yet there is an easily reproducible case where breaks are always
> inserted where there is no explicit \pageBreak, despite the presence of an
> explicit \pageBreak where the break should go, and would go if there were
> more music after it...  I'd call that a bug.
> 
> I assume that fixing this would entail improving \pageBreak so it works even
> when there is no object following it? (i.e. when it is the last command in
> the input)
> 
> 
> You should ask a comment from a developer, but I don't think that this 
> request makes sense. Also because of ragged-last-bottom, which already fixes 
> this case.

Hmmm...  one way to look at this is that the docs here:
http://lilypond.org/doc/v2.18/Documentation/notation/explicit-breaks

give the impression that LilyPond has a mode that will _only_ insert breaks 
where there are explicit break commands (***and nowhere else***).  But is that 
actually the case?  The following leads you to think there is such a "manual 
break only" mode:

"When line-break-permission is overridden to false, Lily will insert line 
breaks at explicit \break commands ***and nowhere else***. When 
page-break-permission is overridden to false, Lily will insert page breaks at 
explicit \pageBreak commands ***and nowhere else***."


But what it says at the top of that page is a little different:

"Lily sometimes rejects explicit \break and \pageBreak commands. There are two 
commands to override this behavior:"

If that is the more accurate account of what these commands do, then they don't 
really prevent automatic breaks from being inserted.  They just prevent 
explicit breaks from being ignored/rejected.  If that's the case then I think 
the next part should be revised like this:

"When line-break-permission is overridden to false, Lily will _always_ insert 
line breaks at explicit \break commands. When page-break-permission is 
overridden to false, Lily will _always_ insert page breaks at explicit 
\pageBreak commands."


Thanks for your help and for considering this.  I've started another thread 
about the example.

Cheers,
-Paul

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

Docs: example for line-break-permission and page-break-permission

[Paul Morris]

The example given here: 
http://lilypond.org/doc/v2.18/Documentation/notation/explicit-breaks

is not so good since the output is actually the same when you comment out the 
commands that it is intended to illustrate: 

% \override NonMusicalPaperColumn.line-break-permission = ##f 
% \override NonMusicalPaperColumn.page-break-permission = ##f 

(It is a good demonstration of ragged-bottom and ragged-right, however.)  To 
improve it the number of measures on some of the lines and the number of lines 
per page would need to be increased so that they are large enough to trigger an 
automatic line break or page break if these commands were not present.   

Below is a suggested revision that does a better job of illustrating the 
effects of those two commands.   

Thanks,
-Paul

% 
\version "2.18.0"
\paper { 
  indent = #0 
  ragged-right = ##t 
  ragged-bottom = ##t 
} 

music = \relative c'' { c8 c c c } 

\score { 
  \new Staff { 
\repeat unfold 2 { \music } \break 
\repeat unfold 2 { \music } \break 
\repeat unfold 4 { \music } \break 
\repeat unfold 6 { \music } \break 
\repeat unfold 8 { \music } \break 
\repeat unfold 10 { \music } \break 
\repeat unfold 12 { \music } \break 
\repeat unfold 14 { \music } \break 
\repeat unfold 12 { \music } \break 
\repeat unfold 10 { \music } \break 
\repeat unfold 8 { \music } \break 
\repeat unfold 6 { \music } \break 
\repeat unfold 4 { \music } \break 
\repeat unfold 2 { \music } \break 
\repeat unfold 2 { \music } \pageBreak 
\repeat unfold 2 { \music } 
  } 
  \layout { 
\context { 
  \Score 
  \override NonMusicalPaperColumn.line-break-permission = ##f 
  \override NonMusicalPaperColumn.page-break-permission = ##f 
} 
  } 
} 
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: page-break-permission = ##f doesn't work for the final manual \pageBreak

[Paul Morris]

Here's a revision of that example[1] that does a better job of illustrating
the effects of those two commands.  
-Paul

[1] http://lilypond.org/doc/v2.18/Documentation/notation/explicit-breaks


\paper {
  indent = #0
  ragged-right = ##t
  ragged-bottom = ##t
}

music = \relative c'' { c8 c c c }

\score {
  \new Staff {
\repeat unfold 2 { \music } \break
\repeat unfold 2 { \music } \break
\repeat unfold 4 { \music } \break
\repeat unfold 6 { \music } \break
\repeat unfold 8 { \music } \break
\repeat unfold 10 { \music } \break
\repeat unfold 12 { \music } \break
\repeat unfold 14 { \music } \break
\repeat unfold 12 { \music } \break
\repeat unfold 10 { \music } \break
\repeat unfold 8 { \music } \break
\repeat unfold 6 { \music } \break
\repeat unfold 4 { \music } \break
\repeat unfold 2 { \music } \break
\repeat unfold 2 { \music } \pageBreak
\repeat unfold 2 { \music }
  }
  \layout {
\context {
  \Score
  \override NonMusicalPaperColumn.line-break-permission = ##f
  \override NonMusicalPaperColumn.page-break-permission = ##f
}
  }
}



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/page-break-permission-f-doesn-t-work-for-the-final-manual-pageBreak-tp159763p159791.html
Sent from the Bugs mailing list archive at Nabble.com.

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

Re: page-break-permission = ##f doesn't work for the final manual \pageBreak

[Paul Morris]

Federico Bruni-5 wrote
> I'm not sure if it's really a bug. On 2.16.2 the same happens.
> I guess that pageBreaks needs an object afterwards, otherwise it doesn't
> make sense. You can use an empty \markup to work around the problem:

That's a helpful workaround (thanks!), although you end up with an extra
blank page that you don't really want. So I'd say the need for such a
workaround indicates an area for improvement (if not a bug).  

If the point of setting page-break-permission = ##f is to "insert page
breaks at explicit \pageBreak commands and nowhere else" as the docs say... 
and yet there is an easily reproducible case where breaks are always
inserted where there is no explicit \pageBreak, despite the presence of an
explicit \pageBreak where the break should go, and would go if there were
more music after it...  I'd call that a bug.  

I assume that fixing this would entail improving \pageBreak so it works even
when there is no object following it? (i.e. when it is the last command in
the input)

If this is a "won't fix" then I'd suggest that that part of the docs should
be edited to be more accurate, maybe to indicate this is a "known issue" or
something like that.


Speaking of the docs for this, the example given here:
http://lilypond.org/doc/v2.18/Documentation/notation/explicit-breaks

is not so good since the output is actually the same when you comment out
the commands that it is intended to illustrate:

% \override NonMusicalPaperColumn.line-break-permission = ##f
% \override NonMusicalPaperColumn.page-break-permission = ##f

(It is a good demonstration of ragged-bottom and ragged-right, however.)  To
improve it the number of measures on some of the lines and the number of
lines per page would need to be increased so that they are large enough to
trigger an automatic line break or page break if these commands were not
present.  

Thanks for considering,
-Paul



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/page-break-permission-f-doesn-t-work-for-the-final-manual-pageBreak-tp159763p159789.html
Sent from the Bugs mailing list archive at Nabble.com.

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

Re: [LSR v2.18] Work in progress (in short)

[Paul Morris]

Thomas Morley-2 wrote
>> I just have a question about snippets that have _not_ been approved yet,
>> either because they required an LSR upgrade or for some other reason. 
>> Will
>> these survive the upgrade process without being lost?
> 
> Yes.
> They will be added through the web-interface after the LSR runs the new
> version.
> At least, we did so last time.
> Ofcourse you could download the tarball, too. As kind of backup.

Ok, Thanks!  Maybe I will download a backup copy just for good measure.

-Paul



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/LSR-v2-18-Work-in-progress-in-short-tp159733p159782.html
Sent from the Bugs mailing list archive at Nabble.com.

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

Re: [LSR v2.18] Work in progress (in short)

[Paul Morris]

Hello Pierre,

Many many thanks for all your work upgrading the LSR!  I know it must be a
huge effort of time and energy. The upgrade was definitely needed.

I just have a question about snippets that have _not_ been approved yet,
either because they required an LSR upgrade or for some other reason.  Will
these survive the upgrade process without being lost?  

There are several of these I've contributed in this category.  Here is one
of them, for example:

Dashed individual staff lines [needs LSR upgrade]
http://lsr.di.unimi.it/LSR/Item?u=1&id=880 

Thanks again,
-Paul



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/LSR-v2-18-Work-in-progress-in-short-tp159733p159765.html
Sent from the Bugs mailing list archive at Nabble.com.

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

page-break-permission = ##f doesn't work for the final manual \pageBreak

[Paul Morris]

When using

  \override NonMusicalPaperColumn.page-break-permission = ##f 

if the music doesn't easily fit on the last page (i.e. it needs to be 
vertically compressed to fit), then the final manual \pageBreak is ignored and 
an automatic page break occurs that causes the music to spill over onto an 
additional page.  See the three examples below.

The docs say: "When page-break-permission is overridden to false, Lily will 
insert page breaks at explicit \pageBreak commands and nowhere else."  
http://lilypond.org/doc/v2.18/Documentation/notation/explicit-breaks
 
-Paul


%% EXAMPLE 1
\version "2.18.0"

\layout {
  \override NonMusicalPaperColumn.page-break-permission = ##f
}

music = \relative f' {
  e1 c c c c c c c c c c c c c c c c c c c c c
  c c c c c c c c c c c c c c c c c c c c c c f
}

\score { \music }
\score { \music }
\score { \music }
\score { \music }
\pageBreak

\score { \music }
\score { \music }
\score { \music }
\score { \music }
\pageBreak



%% EXAMPLE 2
\version "2.18.0"

\layout {
  \override NonMusicalPaperColumn.page-break-permission = ##f
}

music = \relative f' {
  e1 c c c c c c c c c c c c c c c c c c c c c
  c c c c c c c c c c c c c c c c c c c c c c c
  c1 c c c c c c c c c c c c c c c c c c c c c
  c c c c c c c c c c c c c c c c c c c c c c c
  c1 c c c c c c c c c c c c c c c c c c c c c
  c c c c c c c c c c c c c c c c c c c c c c c
  c1 c c c c c c c c c c c c c c c c c c c c c
  c c c c c c c c c c c c c c c c c c c c c c f
}

\score { \music }
\pageBreak
\score { \music }
\pageBreak



%% EXAMPLE 3
\version "2.18.0"

\layout {
  \override NonMusicalPaperColumn.page-break-permission = ##f
}

music = \relative f' {
  e1 c c c c c c c c c c c c c c c c c c c c c
  c c c c c c c c c c c c c c c c c c c c c c c
  c1 c c c c c c c c c c c c c c c c c c c c c
  c c c c c c c c c c c c c c c c c c c c c c c
  c1 c c c c c c c c c c c c c c c c c c c c c
  c c c c c c c c c c c c c c c c c c c c c c c
  c1 c c c c c c c c c c c c c c c c c c c c c
  c c c c c c c c c c c c c c c c c c c c c c f
  \pageBreak
  e1 c c c c c c c c c c c c c c c c c c c c c
  c c c c c c c c c c c c c c c c c c c c c c c
  c1 c c c c c c c c c c c c c c c c c c c c c
  c c c c c c c c c c c c c c c c c c c c c c c
  c1 c c c c c c c c c c c c c c c c c c c c c
  c c c c c c c c c c c c c c c c c c c c c c c
  c1 c c c c c c c c c c c c c c c c c c c c c
  c c c c c c c c c c c c c c c c c c c c c c f
  \pageBreak
}

\score { \music }

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

Re: Web site manual search defaulting to 2.17

[Paul Morris]

Phil Holmes-2 wrote
> There's not much point restricting the search to 2.18 documents unless
> Google has indexed them.

Google's pretty quick with indexing so I thought I'd check their progress. 
Searched for:
site:lilypond.org/doc/v2.18

54 pages of results (10 per page, and seems to include some translated
pages).  
"about 5,120 results" 
"...we have omitted some entries very similar to the 531 already displayed."


Compare that with a search for:
site:lilypond.org/doc/v2.17

66 pages of results (10 per page)
"about 7,770 results"
"...we have omitted some entries very similar to the 660 already displayed."

So that's roughly 80% at this point (531 / 660).  
(That's assuming that the number of web pages in /v2.18/ and /v2.17/ are
similar.)

--
Paul Morris



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Web-site-manual-search-defaulting-to-2-17-tp158320p158479.html
Sent from the Bugs mailing list archive at Nabble.com.

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

Re: Bar number on odd bars does not work on new release?

[Paul Morris]

Looks like the following works.  I just added a second argument to the lambda
expression. It is just ignored, but it prevents the error.
(n) -> (n x)

HTH,
-Paul

\version "2.18.0"

\layout { 
  \context { 
\Score 
barNumberVisibility = #all-bar-numbers-visible 
barNumberVisibility = #(lambda (n x) (= (modulo n 2) 1))
\override BarNumber.break-visibility = #all-visible 
} } 

\new Staff { 
  \bar "" 
  \repeat unfold 8 { c'2 c' } 
}




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Bar-number-on-odd-bars-does-not-work-on-new-release-tp157263p158179.html
Sent from the Bugs mailing list archive at Nabble.com.

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

Re: docs: #' no longer needed with \tag, \removeWithTag, \keepWithTag

[Paul Morris]

David Kastrup wrote
> One reason that has not been done is that the names of context and grob
> properties are under our control.
> 
> Tags are under user control.
> 
> You can write
> 
> \tag #'violin1
> 
> but you cannot write
> 
> \tag violin1
> 
> since "violin1" does not obey the syntax for what LilyPond considers a
> "word".

Ok, I see.  That makes sense.  Thanks for explaining.

If you're only using one or two tags here or there it doesn't make a big
difference.  However, I was just creating some piano music with fingerings
on almost every other note, and tagging each fingering so that I could also
render the music without them.  I found it to be a lot easier to type and
read without the #' when I was entering that many tags.  So I was really
glad that I stumbled upon this new possibility.

FWIW, I do think it would be nice to somehow let users know about this new
syntax, as an option, with a disclaimer about not using numbers, etc.  But
I'm not sure what's the best way to do that.  Maybe it's better to just keep
it as it is for now, especially with 2.18 right around the corner and other
things taking priority.  I'm happy to leave it in the capable hands of the
dev team.

(Just curious... Is the idea to eventually make \tag violin1 work, and then
update the docs at that point?)

Thanks again for the explanation,
-Paul





--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/docs-no-longer-needed-with-tag-removeWithTag-keepWithTag-tp156200p156207.html
Sent from the Bugs mailing list archive at Nabble.com.

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

docs: #' no longer needed with \tag, \removeWithTag, \keepWithTag

[Paul Morris]

In 2.17 you no longer need to use #' with \tag, \removeWithTag, or 
\keepWithTag.  This is a helpful simplification but it is not yet reflected in 
the docs.[1]  For example:

  \tag #'aa  % old way
  \tag aa % new way

Dotted lists work too:

Instead of:
  \removeWithTag #'aa 
  \removeWithTag #'bb
  \removeWithTag #'cc
  \tag #'aa \tag #'bb \tag #'cc { g1 }

or:
  \removeWithTag #'(aa bb cc)
  \tag #'(aa bb cc) { g1 }

you can now just do this:
  \removeWithTag aa.bb.cc
  \tag aa.bb.cc { g1 }

I think it's also worth adding \tag to this list on the changes page[2]:
  Several commands now accept symbol lists (conveniently entered as 
dot-separated 
  words) for various kinds of arguments. These include ‘\accidentalStyle’, 
  ‘\alterBroken’, ‘\footnote’, ‘\hide’, ‘\omit’, ‘\overrideProperty’, ‘\shape’, 
  and ‘\tweak’.

[1] 
http://lilypond.org/doc/v2.17/Documentation/notation/different-editions-from-one-source#using-tags
[2] http://lilypond.org/doc/v2.17/Documentation/changes/index.html
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: make-connected-path-stencil should not hard-code the path origin at (0 0)

[Paul Morris]

> Paul Morris wrote:
> Currently the function "make-connected-path-stencil"[1] does not allow you to 
> specify the starting point (origin) of the path, but arbitrarily hard-codes 
> it 
> as (0 0).  This makes the function less flexible for no good reason. 

Hello bug squad,

I'd like to withdraw this proposal.  Having thought about it some more, I think 
it would be better to have a new function that combines the benefits of both 
(A) the make-connected-path-stencil function and (B) using ly:make-stencil with 
a path expression.  Namely:

(A)
- automatically calculate stencil extents
- allow scaling of the stencil

(B)
- allow use of all possible path commands, both relative and absolute:  
   lineto rlineto curveto rcurveto moveto rmoveto closepath
- allow "unconnected" paths with multiple segments 
  (i.e. allow (r)moveto in the middle of the path expression)
- allow use of different cap and join styles

So with some work I've written a function that can actually do all this 
(drawing on the make-connected-path-stencil code and the path code itself from 
output-svg.scm).  I would like to contribute it to LilyPond, but I suppose I 
should look at the contributors guide on how to proceed.

Maybe I will send what I've got to the developer list to see if there's even 
interest in including this.  (Although it looks like they are in the middle of 
the 2.18 release, and there's no rush on this...)

Thanks,
-Paul

P.S. Here are snippets demonstrating each of these current ways to make a path 
stencil:
http://lsr.dsi.unimi.it/LSR/Item?id=623
http://lsr.dsi.unimi.it/LSR/Item?id=891
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: make-connected-path-stencil should not hard-code the path origin at (0 0)

[Paul Morris]

Paul Morris wrote
> A proposed revision making this change is in the attached file.

Looks like the attachment did not make it through, so pasting it inline
below.  (Also, I only sent one email, but it looks like it posted twice for
some reason...)

-Paul

\version "2.17.29"

% Most of this code is just copied verbatim from stencil.scm 
% as dependencies of the main function
% the changes proposed are in the "revised-make-connected-path-stencil" 
% function below starting at line 72

#(define (line-part-min-max x1 x2)
  (list (min x1 x2) (max x1 x2)))

#(define (bezier-part-min-max x1 x2 x3 x4)
  ((lambda (x) (list (reduce min 1 x) (reduce max -1 x)))
   (map
(lambda (x)
  (+ (* x1 (expt (- 1 x) 3))
 (+ (* 3 (* x2 (* (expt (- 1 x) 2) x)))
(+ (* 3 (* x3 (* (- 1 x) (expt x 2
   (* x4 (expt x 3))
(if (< (+ (expt x2 2) (+ (expt x3 2) (* x1 x4)))
   (+ (* x1 x3) (+ (* x2 x4) (* x2 x3
(list 0.0 1.0)
(filter
 (lambda (x) (and (>= x 0) (<= x 1)))
 (append
  (list 0.0 1.0)
  (map (lambda (op)
 (if (not (eqv? 0.0
(exact->inexact (- (+ x1 (* 3 x3)) (+ x4 (*
3 x2))
 ;; Zeros of the bezier curve
 (/ (+ (- x1 (* 2 x2))
   (op x3
   (sqrt (- (+ (expt x2 2)
   (+ (expt x3 2) (* x1 x4)))
(+ (* x1 x3)
   (+ (* x2 x4) (* x2 x3)))
(- (+ x1 (* 3 x3)) (+ x4 (* 3 x2
 ;; Apply L'hopital's rule to get the zeros if 0/0
 (* (op 0 1)
(/ (/ (- x4 x3) 2)
   (sqrt (- (+ (* x2 x2)
   (+ (* x3 x3) (* x1 x4)))
(+ (* x1 x3)
   (+ (* x2 x4) (* x2 x3)
   (list + -

#(define (bezier-min-max x1 y1 x2 y2 x3 y3 x4 y4)
  (map (lambda (x)
 (apply bezier-part-min-max x))
   `((,x1 ,x2 ,x3 ,x4) (,y1 ,y2 ,y3 ,y4

#(define (line-min-max x1 y1 x2 y2)
  (map (lambda (x)
 (apply line-part-min-max x))
   `((,x1 ,x2) (,y1 ,y2

#(define (path-min-max origin pointlist)
  ((lambda (x)
 (list
  (reduce min +inf.0 (map caar x))
  (reduce max -inf.0 (map cadar x))
  (reduce min +inf.0 (map caadr x))
  (reduce max -inf.0 (map cadadr x
   (map (lambda (x)
  (if (= (length x) 8)
  (apply bezier-min-max x)
  (apply line-min-max x)))
(map (lambda (x y)
   (append (list (cadr (reverse x)) (car (reverse x))) y))
 (append (list origin)
 (reverse (cdr (reverse pointlist pointlist


% to make it possible to specify the origin of the path, 
% rather than having it hard-coded at (0 0), some suggested changes 
% have been made to the function below:

#(define (revised-make-connected-path-stencil pointlist thickness
x-scale y-scale connect fill)
  "Make a connected path described by the list @var{pointlist}, with
thickness @var{thickness}, and scaled by @var{x-scale} in the X direction
and @var{y-scale} in the Y direction. @var{connect} and @var{fill} are 
boolean arguments that specify if the path should be connected or filled, 
respectively. The first point in @var{pointlist} sets the origin of the
path."

  (let* ((origin (car pointlist)) ;; changed
 (boundlist (path-min-max origin (cdr pointlist))) ;; changed
 ;; modify pointlist to scale the coordinates
 (path (map (lambda (x)
  (apply
   (if (= 6 (length x))
   (lambda (x1 x2 x3 x4 x5 x6)
 (list 'curveto
   (* x1 x-scale)
   (* x2 y-scale)
   (* x3 x-scale)
   (* x4 y-scale)
   (* x5 x-scale)
   (* x6 y-scale)))
   (lambda (x1 x2)
 (list 'lineto
   (* x1 x-scale)
   (* x2 y-scale)
   )))
   x))
(cdr pointlist))) ;; changed
 (origin-scaled (list   ;; added
 (* (list-ref origin 0) x-scale);; added
 (* (list-ref origin 1) y-scale))) ;; added
 ;; a path must begin with a `moveto'
 (prepend-origin (cons (cons 'moveto origin-scaled) path))

make-connected-path-stencil should not hard-code the path origin at (0 0)

[Paul Morris]

Greetings Bug Squad,

Currently the function "make-connected-path-stencil"[1] does not allow you to 
specify the starting point (origin) of the path, but arbitrarily hard-codes it 
as (0 0).  This makes the function less flexible for no good reason. 

(Well, at least none that I can see, unless for some reason the code that 
calculates the size of the stencil depends on it, but that seems unlikely.)

I think it would make more sense for the origin to be defined by the first 
point in the "pointlist" argument.  A proposed revision making this change is 
in the attached file.  It contains a revision of this function, as found in 
stencil.scm in the LilyPond source code (including David Kastrup's recent 
improvements[2]).  The changes start at line 77.

(I suppose that if this change went forward then convert-ly would need to add a 
"(0 0)" in the appropriate place to explicitly set the path origin wherever 
this function has been used, to keep from mangling existing stencils...)

Thanks for considering,
-Paul

[1] http://lsr.dsi.unimi.it/LSR/Item?u=1&id=891
[2] http://code.google.com/p/lilypond/issues/detail?id=3624

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

make-connected-path-stencil should not hard-code the path origin at (0 0)

[Paul Morris]

Greetings Bug Squad,

Currently the function "make-connected-path-stencil"[1] does not allow you to 
specify the starting point (origin) of the path, but arbitrarily hard-codes it 
as (0 0).  This makes the function less flexible for no good reason. 

(Well, at least none that I can see, unless for some reason the code that 
calculates the size of the stencil depends on it, but that seems unlikely.)

I think it would make more sense for the origin to be defined by the first 
point in the "pointlist" argument.  A proposed revision making this change is 
in the attached file.  It contains a revision of this function, as found in 
stencil.scm in the LilyPond source code (including David Kastrup's recent 
improvements[2]).  The changes start at line 77.

(I suppose that if this change went forward then convert-ly would need to add a 
"(0 0)" in the appropriate place to explicitly set the path origin wherever 
this function has been used, to keep from mangling existing stencils...)

Thanks for considering,
-Paul

[1] http://lsr.dsi.unimi.it/LSR/Item?u=1&id=891
[2] http://code.google.com/p/lilypond/issues/detail?id=3624

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

error when making a connected path with make-connected-path-stencil

[Paul Morris]

When trying to use the function "make-connected-path-stencil" to create a 
connected path, setting "connect" to true (#t) leads to this error in the log:

Wrong type argument in position 1 (expecting empty list): closepath

-Paul

%%% EXAMPLE %%%
\version "2.17.28"

\markup \stencil
#(make-connected-path-stencil
'((0 2) (2 2))
0.1
1
1
#t ;; <-- error if "connect" is set to #t (works fine if set to #f)
#f)

%%% ERROR LOG %%%

Parsing...
[...] error: GUILE signaled an error for the expression beginning here
#
(make-connected-path-stencil
[...] error: wrong type for argument 1. Expecting stencil, found #
#(make-connected-path-stencil
Wrong type argument in position 1 (expecting empty list): closepath
[...] In procedure reverse! in expression (ly:parse-file file-name):
[...] Wrong type argument in position 1: (# . #f)


%%% 

In case it is useful, here's documentation for this function from where it is 
defined in the stencil.scm file, around line 432:

(define-public (make-connected-path-stencil pointlist thickness 
x-scale y-scale connect fill) 
  "Make a connected path described by the list @var{pointlist}, with 
thickness @var{thickness}, and scaled by @var{x-scale} in the X direction 
and @var{y-scale} in the Y direction.  @var{connect} and @var{fill} are 
boolean arguments that specify if the path should be connected or filled, 
respectively." 
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Enhancement: always print key signature grobs, even for keys with no sharps or flats

[Paul Morris]

Ralph Palmer-3 wrote
> Thanks for the email. This has been submitted as Issue 3615 :
> https://code.google.com/p/lilypond/issues/detail?id=3615

Thanks!  I've attached the illustration files to the issue.
-Paul



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Enhancement-always-print-key-signature-grobs-even-for-keys-with-no-sharps-or-flats-tp152184p152363.html
Sent from the Bugs mailing list archive at Nabble.com.

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

Re: Web/Docs: LilyPond version is not clear on docs web pages

[Paul Morris]

On May 8, 2013, at 1:57 PM, James  wrote:

> There are probably more but these are the open ones that I quickly found. I 
> am sure this has been discussed and probably tracked elsewhere if not in one 
> of these above.

I did not find this particular issue being tracked.  I looked through those you 
listed, the 42 that came up in a search for "website," and the 10 that came up 
for "label:website".  

I looked into the texi-to-html generation business a little, and it seems like 
it might just be a matter of adding @version{} in the right place in the right 
file.  Just where that would be didn't jump out at me, and maybe it's more 
complicated than that.

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

Web/Docs: LilyPond version is not clear on docs web pages

[Paul Morris]

PROBLEM

In the docs on the web it is not obvious, especially to new users, which 
version of LilyPond any given page is for.  This is particularly a problem when 
landing on a doc page directly from a web search or link.

For example, a new user does a web search that takes them directly to an old 
docs page like this:
http://lilypond.org/doc/v2.14/Documentation/notation/writing-rhythms

The only clue they have that they are not looking at the current docs is the 
"2.14" in the URL (which they will probably not notice), and the tiny text 
"This page is for LilyPond-2.14.2 (stable-branch)." that is not visible until 
you scroll all the way down a long page.  


SUGGESTION

A simple thing would be to put the version number of LilyPond somewhere at the 
top of every web page.  For example, it could go at the top of the left hand 
column.  Where it says "LilyPond - Notation Reference" it could say "LilyPond 
2.14 - Notation Reference" instead.  

To make it more obvious, you could have "LilyPond 2.14" in a larger font size 
on its own line, with "Notation Reference" on the next line.

Optionally, to take this a step further, a clear message could appear at the 
top of each page in older versions of the docs that says something like "NOTE: 
This documentation is *not* for the most recent version of LilyPond.  We 
recommend using the most recent version which is documented here."  With links 
to the current version of LilyPond and the docs.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Suggested doc revision for customizing staff positions

[Paul Morris]

Here is a suggested revision for the docs, Notation Reference 1.6.2
http://www.lilypond.org/doc/v2.17/Documentation/notation/modifying-single-staves

It adds a sentence about how to preserve the usual stem directions when 
customizing the staff.

CURRENT TEXT:

The position of each the staff lines can also be altered. The values used are 
half staff line spaces and the new position is relative to the normal center 
line. A single staff line is printed for every value entered so that the number 
of staff lines, as well as their position in the staff, can be changed with a 
single override. 

[Example]

The clef position and the position of middle C may need to be adjusted 
accordingly to fit the new lines. See Clef.



SUGGESTED REVISION:

The position of each staff line can also be altered. A list of numbers sets 
each line's position. 0 corresponds to the normal center line, and the normal 
line positions are (-4 -2 0 2 4). A single staff line is printed for every 
value entered so that the number of staff lines, as well as their position, can 
be changed with a single override. 

[Example]

To preserve typical stem directions (in the bottom half of the staff stems 
point up, in the top half they point down), align the center line (or space) of 
the customized staff with the position of the normal center line (0).  The clef 
position and the position of middle C may need to be adjusted accordingly to 
fit the new lines. See Clef.



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

Re: "legder" docs typo

[Paul Morris]

On Jan 19, 2013, at 4:31 AM, James  wrote:

> This has been fixed and checked in. It'll appear when the next version of 
> Lilypond is built (2.17.11) the website gets built at the same time.

James, Thanks for fixing this.

Regards and HTH,
-Paul
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

"legder" docs typo

[Paul Morris]

Caught a couple of typos here:

http://www.lilypond.org/doc/v2.16/Documentation/notation/modifying-single-staves

Two corrections shown between  ... 

Legder  Ledger  lines can also be made to appear inside the staff where 
custom staff lines are required. The example shows the default position of 
ledger lines when the explicit legder-position  ledger-position  is and 
is not set.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Clarifying documentation of advanced command-line options

[Paul Morris]

Here is a suggestion for clarifying the documentation of advanced command-line 
options, from a command-line beginner.

http://www.lilypond.org/doc/v2.16/Documentation/usage/command_002dline-usage#advanced-command-line-options-for-lilypond

I wanted to try SVG output, and after reading that page I was trying to use:

  lilypond -dbackend='svg

When the correct command is:

  lilypond -dbackend=svg

(I had to search and come across an old mailing list post to figure it out.)

It seems that the documentation should not show the single quote since you do 
not need it (and if you do include it things fail in rather baffling ways).  
Why not just show \svg\ rather than \'svg\ ?

This was particularly confusing because in the example given of 

  -dpoint-and-click=#f

you use exactly #f as it is shown in the table of options, which suggests that 
you would need to use exactly 'svg rather than svg.

So another suggestion is to show an example with the full text command that you 
would enter, like "lilypond -dbackend=svg"  (or at least "-dbackend=svg")

Overall, I think these kinds of examples would help the command-line 
documentation in general.  It's much easier for a beginner like myself to see 
an example of what to do than to try and decipher things like the following 
without one:

  lilypond [option]… file…

  -d[option-name]=[value],--define-default=[option-name]=[value]

Thanks for considering these.  I imagine I am not the only one making a first 
foray into the command-line with LilyPond, and these kinds of clarifications 
should help us out.

-Paul


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

Re: NoteHead X-offset, conflict with ly:grob-relative-coordinate

[Paul Morris]

On Dec 11, 2012, at 7:29 PM, Thomas Morley  
wrote:

> 2012/12/12 Paul Morris :
>> On Dec 11, 2012, at 3:32 PM, Colin Hall  wrote:
>> 
>>> On Tue, Dec 11, 2012 at 04:32:57AM +, Keith OHara wrote:
>>>> Colin Hall  gmail.com> writes:
>>>> 
>>>>> I'm going to post a link to this on the dev forum and see if we can
>>>>> identify what the bug is, and then I can create a tracker.
>>>>> 
>>>> I don't see any bug; reasoning is on -devel.
>>> 
>>> That's great, Keith, thanks.
>>> 
>>> Paul, here's a link to Keith's explanation on the lilypond-devel
>>> mailing list archive:
>>> 
>>> http://lists.gnu.org/archive/html/lilypond-devel/2012-12/msg00116.html
>>> 
>>> I believe Thomas gave you some ideas of how to obtain the engraving
>>> you wanted.
>>> 
>>> OK?
>> 
>> Hi Colin,
>> 
>> Ok, as Keith is saying, if this is how it is supposed to work then I guess 
>> it shouldn't be considered a bug.  And luckily there's another way to get 
>> the same results (thanks to Thomas for that tip).
>> 
>> I guess that means that a NoteHead's X-offset has not been designed to be a 
>> property that can be reliably overridden.  I wonder if it would be worth 
>> documenting this somehow, to keep people from trying to go down this path in 
>> the future.
>> 
>> Currently the internals page for NoteHead[1] makes it sound like X-offset is 
>> simply a number that you can easily override:
>> 
>>  X-offset (number):
>>  ly:note-head::stem-x-shift
>>  The horizontal amount that this object is moved relative to its X-parent.
>> 
>> but apparently something more complicated is going on, involving the other 
>> notes in a chord, and the function for determining their placement.
> 
> Well, quoting
> 
> NR 5.5.1 Aligning objects:
> 
> Note: Many objects have special positioning considerations which cause
> any setting of X-offset or Y-offset to be ignored or modified, even
> though the object supports the self-alignment-interface. Overriding
> the X-offset or Y-offset properties to a fixed value causes the
> respective self-alignment property to be disregarded.
> 
> http://lilypond.org/doc/v2.17/Documentation/notation/aligning-objects

Ah, ok, so that page is already documenting this.  


> But I found no hint about it in the IR

Would it make sense if under "X-offset" in the IR it said something like this?

"The horizontal amount that this object is moved relative to its X-parent.  The 
amount may be set directly or may be set to be calculated by procedures in 
order to achieve alignment with the parent object."  

(Added a borrowed sentence from the page linked above.)


>> Anyway, documenting this somehow would be my suggestion, but I don't have 
>> the knowledge to do it, and I realize that there may be higher priorities, 
>> so take it FWIW.
>> 
>> On a related note, I just added a snippet for this to the LSR[2] that uses 
>> ly:grob-translate-axis! instead of X-offset, and I could add a comment to it 
>> saying that overriding a NoteHead's X-offset does not always work, and to 
>> use ly:grob-translate-axis! instead.
>> 
>> (The snippet is not currently working in the LSR, but it works fine for me 
>> on 2.16, so I am guessing that there is a compatibility problem with 2.14.)
> 
> Will have a look at it.

Thanks.  I tried to install 2.14.2 to confirm that this was the problem, but 
was unable to install it. (Maybe it is incompatible with my OS?)


>> Thanks,
>> -Paul
>> 
>> [1] http://www.lilypond.org/doc/v2.16/Documentation/internals/notehead
>> [2] http://lsr.dsi.unimi.it/LSR/Item?u=1&id=861
>> 
>> 
>> 
>> 
>> ___
>> bug-lilypond mailing list
>> bug-lilypond@gnu.org
>> https://lists.gnu.org/mailman/listinfo/bug-lilypond
> 
> -Harm


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

Re: NoteHead X-offset, conflict with ly:grob-relative-coordinate

[Paul Morris]

On Dec 11, 2012, at 3:32 PM, Colin Hall  wrote:

> On Tue, Dec 11, 2012 at 04:32:57AM +, Keith OHara wrote:
>> Colin Hall  gmail.com> writes:
>> 
>>> I'm going to post a link to this on the dev forum and see if we can
>>> identify what the bug is, and then I can create a tracker.
>>> 
>> I don't see any bug; reasoning is on -devel.
> 
> That's great, Keith, thanks.
> 
> Paul, here's a link to Keith's explanation on the lilypond-devel
> mailing list archive:
> 
> http://lists.gnu.org/archive/html/lilypond-devel/2012-12/msg00116.html
> 
> I believe Thomas gave you some ideas of how to obtain the engraving
> you wanted.
> 
> OK?

Hi Colin, 

Ok, as Keith is saying, if this is how it is supposed to work then I guess it 
shouldn't be considered a bug.  And luckily there's another way to get the same 
results (thanks to Thomas for that tip).  

I guess that means that a NoteHead's X-offset has not been designed to be a 
property that can be reliably overridden.  I wonder if it would be worth 
documenting this somehow, to keep people from trying to go down this path in 
the future.  

Currently the internals page for NoteHead[1] makes it sound like X-offset is 
simply a number that you can easily override:

  X-offset (number):
  ly:note-head::stem-x-shift
  The horizontal amount that this object is moved relative to its X-parent.

but apparently something more complicated is going on, involving the other 
notes in a chord, and the function for determining their placement.

Anyway, documenting this somehow would be my suggestion, but I don't have the 
knowledge to do it, and I realize that there may be higher priorities, so take 
it FWIW.

On a related note, I just added a snippet for this to the LSR[2] that uses 
ly:grob-translate-axis! instead of X-offset, and I could add a comment to it 
saying that overriding a NoteHead's X-offset does not always work, and to use 
ly:grob-translate-axis! instead.  

(The snippet is not currently working in the LSR, but it works fine for me on 
2.16, so I am guessing that there is a compatibility problem with 2.14.)

Thanks,
-Paul

[1] http://www.lilypond.org/doc/v2.16/Documentation/internals/notehead
[2] http://lsr.dsi.unimi.it/LSR/Item?u=1&id=861




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

Re: NoteHead X-offset, conflict with ly:grob-relative-coordinate

[Paul Morris]

On Dec 10, 2012, at 6:37 PM, Thomas Morley  
wrote:

> 2012/12/10 Paul Morris :
>>> I'm not top posting.
>> 
>> % All the notes should be moved to the right-hand
>> % side of the stem by overriding their X-offset
>> % property, but something about the "rel-coord"
>> % variable that is set by "ly:grob-relative-coordinate"
>> % prevents this from working as it should.  After
>> % removing that variable it works fine. Setting
>> % X-extent also does not work (this is commented
>> % out below).
>> 
>> \version "2.16.1"
>> 
>> CustomNoteHeads =
>> #(lambda (grob)
>>  (let* (
>>(notecol (ly:grob-parent grob 0))
>>(rel-coord (ly:grob-relative-coordinate grob notecol 0)))
>>(set! (ly:grob-property grob 'X-offset) 1.251178 )
>> 
>>;; (set! (ly:grob-property grob 'X-extent) '(0 . 4) ))
>> )
>> 
>> \score {
>>  \new Staff
>>\with {
>>  \override NoteHead #'before-line-breaking = \CustomNoteHeads
>>}
>>{ c' d' e' f' }
>>  \layout { }
>> }
> 
> Hi Paul,
> 
> please be very careful with the code you post.
> You commented a _needed_ closing bracket.

Hi Harm,  Oh no!  I winced when I read that...  My apologies and thank you for 
your patience with my rookie mistake(s).  I'm still getting used to typical 
scheme formatting (for closing brackets), and this is twice now that I've let 
editing code after pasting it into an email get the best of me (ironically, in 
an attempt to communicate more clearly).  So no more of that, and I will make 
sure to double check in the future.


> Nevertheless, I can't explain why your code doesn't work.
> Speculating, I'd say 'X-offset and 'X-extent are the wrong properties
> with 'before-line-breaking.
> Using 'extra-spacing-width and ly:grob-translate-axis! for offset in
> X-axis seems to work:
> 
> \version "2.16.1"
> 
> CustomNoteHeads =
> #(lambda (grob)
>  (let* (
>(notecol (ly:grob-parent grob X))
>(rel-coord (ly:grob-relative-coordinate grob notecol 0)))
> 
>  (ly:grob-set-property! grob 'extra-spacing-width  '(-1 . 1))
>  (ly:grob-translate-axis! grob 1.251178  X)))
> 
> \score {
>  \new Staff
>\with {
>  \override NoteHead #'before-line-breaking = \CustomNoteHeads
>}
>{ c' d' e' f' }
>  \layout { }
> }

Thanks for the tip on these other ways to get the same results.


> But there _is_ something strange with 'X-offset in chords.
> In the examples below _none_ of the tweaks work. But if you uncomment
> the tweak for the _first_ written note of the chord they work _all_.
> 
> \version "2.16.1"
> 
> \relative c' {
><
> %\tweak  #'X-offset #1
> f
> \tweak  #'X-offset #2
> a
> \tweak  #'X-offset #3
> c
>> 
><
> %\tweak  #'X-offset #2
> a
> \tweak  #'X-offset #1
> f
> \tweak  #'X-offset #3
> c'
>> 
> }
> 
> 
> No idea why.

Well, I'm glad I haven't sounded a false alarm in my effort to help.  It did 
seem like a bug, although an obscure and probably not very consequential one.

Cheers,
-Paul


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

NoteHead X-offset, conflict with ly:grob-relative-coordinate

[Paul Morris]

> I'm not top posting.

% All the notes should be moved to the right-hand 
% side of the stem by overriding their X-offset 
% property, but something about the "rel-coord" 
% variable that is set by "ly:grob-relative-coordinate" 
% prevents this from working as it should.  After 
% removing that variable it works fine. Setting 
% X-extent also does not work (this is commented 
% out below).

\version "2.16.1"  

CustomNoteHeads =
#(lambda (grob)
  (let* (
(notecol (ly:grob-parent grob 0))
(rel-coord (ly:grob-relative-coordinate grob notecol 0)))
(set! (ly:grob-property grob 'X-offset) 1.251178 )

;; (set! (ly:grob-property grob 'X-extent) '(0 . 4) ))
)

\score {
  \new Staff
\with { 
  \override NoteHead #'before-line-breaking = \CustomNoteHeads
}
{ c' d' e' f' }
  \layout { }
}


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

Re: Difficulties with testing installation on a Mac

[Paul Morris]

Ah, thanks for your emails, I realized after trying a few other samples from the website (which returned similar errors) that I had installed an outdated version.  Where I got off track was at http://lilypond.org/web/download/macos.html  where I didn't know how to do the following:

	• 	Get the Lilypond package description by enabling the "unstable" tree in fink and executing fink selfupdate-cvs.

(It's my first time using Fink, and I've had very little unix experience)  I was using the "Fink Commander" a GUI that comes with the Fink download (as recommended by the Fink installation documentation).  Maybe it would be good to spell out how to do the above from within this app?  (for us newbies out here clinging to our mouses...)

It seems that you can enable the "unstable tree" under 
Fink Commander--->Preferences--->Fink--->Use unstable packages

Then "Lilyond-unstable" appears in the package list, but it indicates it is only vsn  2.3.12-1
Is this the up-to-date version for the Mac at this point?  Or am I still missing something?

Then when I try to "Selfupdate-cvs" (from Source menu) I get the following error:

Fink has the capability to run the CVS commands as a normal user. That has
some advantages - it uses that user's CVS settings files and allows the
package descriptions to be edited and updated without becoming root. Please
specify the user login name that should be used: [root] 

For Fink developers only: Enter your SourceForge login name to set up full
CVS access. Other users, just press return to set up anonymous read-only
access. [anonymous] 

Checking to see if we can use hard links to merge the existing tree. Please
ignore errors on the next few lines.
Now logging into the CVS server. When CVS asks you for a password, just press
return (i.e. the password is empty).
cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/fink login
Can't exec "cvs": No such file or directory at /sw/lib/perl5/Fink/Services.pm line 403.
### execution of cvs failed, exit code -1
Failed: Logging into the CVS server for anonymous read-only access failed.
At this point I don't know what to do...

(I've removed the 2.2.5 lilypond package, using Fink Commander, but haven't tried installing the 2.3.12-1 version...  I'll try jedit when I get that far...)

Thanks for the help!
Paul

PS. this probably should go to the user list and not the bug list, (?) but I'm sending it to both (since it started on bug...)



On Nov 22, 2004, at 5:16 AM, Mats Bengtsson wrote:

Paul Morris wrote:
Greetings,
I actually got it installed and tested on my mac, but with two stumbling blocks along the way... (related to the documentation / instructions)
(If this is not the correct email address for this, please forward to the appropriate one, Thanks!)
1. It wasn't clear where to save the "test.ly" file. (when following directions at: http://lilypond.org/web/download/getting-started.html) After a few tries I found that it is the user directory, ie: /hard-drive/users/username/

I guess that you are not that used to using a command window in Mac.
You should simply save it in the directory where you run the command.
I think it is possible to install jedit also on Mac. This could be a
nice option, since the lilypond mode in this text editor includes lots
of builtin help functions and also has buttons to run lilypond.


2. The following text in the test.ly file:
{
c4( c)
}

Since the latest stable version of LilyPond is 2.4, the instructions on
the getting started page have recently been modified to match that
version. If you use version 2.2, you should read the tutorial and users
manual corresponding to that particular version, as Paul already pointed
out.

/Mats


_
Music Notation Modernization Association
http://www.mnma.org
___
bug-lilypond mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Difficulties with testing installation on a Mac

[Paul Morris]

Greetings, 
I actually got it installed and tested on my mac, but with two stumbling blocks along the way...  (related to the documentation / instructions)  

(If this is not the correct email address for this, please forward to the appropriate one, Thanks!)


1. It wasn't clear where to save the "test.ly" file.  (when following directions at:  http://lilypond.org/web/download/getting-started.html)  After a few tries I found that it is the user directory, ie: /hard-drive/users/username/


2. The following text in the test.ly file:


{
c4( c)
}

 lead to the following error: 

lilypond (GNU LilyPond) 2.2.5
Running lilypond-bin...
Now processing `test.ly'
Parsing...

/Users/paul/test.ly:1:1: error: parse error:
{



/Users/paul/test.ly:2:3: warning: Braces don't match:
c4(
c)
Failed files: test.ly 


lilypond: error: LilyPond failed on input file test (exit status 1)
lilypond: warning: Running LilyPond failed. Rerun with --verbose for a trace.


So I eventually found and tried this text:

% This file has ledger lines and a slur

\score { \notes { c4-(  c4-) } }

from this page for Windows users: http://lilypond.org/web/download/windows.html

and that worked...


So, just thought I'd report these two hurdles so they might be smoothed out for other mac users in the future.  Let me know if you have any questions.

Cheers,
Paul
___
bug-lilypond mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-lilypond