Re: Default font for the web site

> 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

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

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

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

> 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 > >

Re: Noteheads slightly too large

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

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

> 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

Re: Noteheads slightly too large

> 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

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

\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

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

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

Re: Noteheads slightly too large

> 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

Re: Noteheads slightly too large

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

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

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

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

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:

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

> 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

Docs: inconsistency about ly:context-pushpop-property

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

Re: New issue: Add StaffAxis context type

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

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

fixcc.py and astyle dependency problem on LilyDev

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

Re: fixcc.py and astyle dependency problem on LilyDev

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

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

Colin Campbell-8 wrote Done, Paul: Issue 4326 lt;https://code.google.com/p/lilypond/issues/detail?id=4326gt;: Enhancement: simplify accepting a new custom context like an existing context Thanks Colin! -Paul -- View this message in context:

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

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:

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

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

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

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

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

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

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

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 {

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

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,

Make defining new contexts simpler with better \alias functionality

.” 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

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

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

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

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

barcheck failure with partial in middle of piece

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

Re: barcheck failure with partial in middle of piece

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

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

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

Docs: Line length page and line-width property

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]

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

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

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

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

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

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

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

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

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

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

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

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 }

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

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

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

On Feb 24, 2014, at 3:38 PM, Federico Bruni fedel...@gmail.com 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

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

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

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

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

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

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

Re: Web site manual search defaulting to 2.17

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

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

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 =

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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:

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

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

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

On May 8, 2013, at 1:57 PM, James pkx1...@gmail.com 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

Suggested doc revision for customizing staff positions

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

Re: legder docs typo

On Jan 19, 2013, at 4:31 AM, James pkx1...@gmail.com 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

legder docs typo

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

Clarifying documentation of advanced command-line options

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

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

On Dec 11, 2012, at 3:32 PM, Colin Hall colingh...@gmail.com wrote: On Tue, Dec 11, 2012 at 04:32:57AM +, Keith OHara wrote: Colin Hall colinghall at 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

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

On Dec 10, 2012, at 6:37 PM, Thomas Morley thomasmorle...@googlemail.com wrote: 2012/12/10 Paul Morris p...@paulwmorris.com: 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

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

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

Difficulties with testing installation on a Mac

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