Issue 156400043: Issue 4169: Line and page breaking syntactic sugar (Closed)
|
Created:
10 years, 6 months ago by Trevor Daniels Modified:
10 years, 6 months ago CC:
lilypond-devel_gnu.org Visibility:
Public. |
DescriptionIssue 4169: Line- and page-breaking syntactic sugar
Install line- and page-breaking controls and document them.
Remove now-redundant section on Explicit breaks, preserving the
snippet showing how to use an extra voice to contain break commands.
Amend indexing.
Patch Set 1 #
Total comments: 1
Patch Set 2 : Amendments as suggested by David and Janek. #
Total comments: 3
Patch Set 3 : Remove Explict breaks section #Patch Set 4 : Use \overrideProperty #
MessagesTotal messages: 21
https://codereview.appspot.com/156400043/diff/1/ly/property-init.ly File ly/property-init.ly (right): https://codereview.appspot.com/156400043/diff/1/ly/property-init.ly#newcode359 ly/property-init.ly:359: lineBreaksOn = It might be more consistent with other overrides in this file to make the commands for (re-)establishing the default settings, namely \lineBreaksOn and \pageBreaksOn, be reverts rather than overrides.
Sign in to reply to this message.
Hello, I think it may be a good idea to add "auto" prefix to these commands. They will get longer, but i think the clarification gained is worth it; we also have \autoBeamOn/Off following this convention. best, Janek
Sign in to reply to this message.
On 2014/10/19 16:58:04, dak wrote: > https://codereview.appspot.com/156400043/diff/1/ly/property-init.ly > File ly/property-init.ly (right): > > https://codereview.appspot.com/156400043/diff/1/ly/property-init.ly#newcode359 > ly/property-init.ly:359: lineBreaksOn = > It might be more consistent with other overrides in this file to make the > commands for (re-)establishing the default settings, namely \lineBreaksOn and > \pageBreaksOn, be reverts rather than overrides. done
Sign in to reply to this message.
On 2014/10/19 16:58:45, janek wrote: > Hello, > > I think it may be a good idea to add "auto" prefix to these commands. They will > get longer, but i think the clarification gained is worth it; we also have > \autoBeamOn/Off following this convention. Good thinking, especially as these commands have no effect on manual breaks. Done.
Sign in to reply to this message.
Amendments as suggested by David and Janek.
Sign in to reply to this message.
thanks, LGTM :)
Sign in to reply to this message.
On 2014/10/19 18:04:32, Trevor Daniels wrote: > On 2014/10/19 16:58:04, dak wrote: > > https://codereview.appspot.com/156400043/diff/1/ly/property-init.ly > > File ly/property-init.ly (right): > > > > https://codereview.appspot.com/156400043/diff/1/ly/property-init.ly#newcode359 > > ly/property-init.ly:359: lineBreaksOn = > > It might be more consistent with other overrides in this file to make the > > commands for (re-)establishing the default settings, namely \lineBreaksOn and > > \pageBreaksOn, be reverts rather than overrides. > > done Actually, prompted by Kieren's recent mail, it might be preferable to go back to using \override's for re-establishing the default settings, as that would permit \once to work consistently, in particular permitting \once \autoLineBreaksOn to give the line breaker one-time-step optional windows to break a line: "You may break the line here, here or here, but nowhere else." Same with perhaps more utility for line/page break combinations. What do others think? Trevor
Sign in to reply to this message.
> https://codereview.appspot.com/156400043/diff/1/ly/property-init.ly#newcode359 > > > ly/property-init.ly:359: lineBreaksOn = > using \override's for re-establishing the default settings, > What do others think? Yes, \autoLineBreaksOn is an assertive statement, so I would expect it to set the state of line-breaking with an \override, that \once would work, etc.
Sign in to reply to this message.
Looks good to me. I'm just suggesting more changes that you might want to do at the same time. https://codereview.appspot.com/156400043/diff/20001/Documentation/notation/sp... File Documentation/notation/spacing.itely (right): https://codereview.appspot.com/156400043/diff/20001/Documentation/notation/sp... Documentation/notation/spacing.itely:1769: @node Explicit breaks Probably you can eliminate this entire section. https://codereview.appspot.com/156400043/diff/20001/Documentation/notation/sp... Documentation/notation/spacing.itely:1773: commands are ignored by LilyPond. There are two commands to I am confused by the sentence above. The only time I have seen LilyPond ignore a \break is where there was no bar-line; we have \bar "" for that. Probably the manual would be better without this. https://codereview.appspot.com/156400043/diff/20001/Documentation/notation/sp... Documentation/notation/spacing.itely:1820: {using-an-extra-voice-for-breaks.ly} Maybe move this snippet up to the section you are editing on breaks?
Sign in to reply to this message.
2014-10-20 6:33 GMT+02:00 <k-ohara5a5a@oco.net>: > > https://codereview.appspot.com/156400043/diff/1/ly/property-init.ly#newcode359 >> using \override's for re-establishing the default settings, >> What do others think? > > Yes, \autoLineBreaksOn is an assertive statement, so I would expect > it to set the state of line-breaking with an \override, that \once > would work, etc. +1
Sign in to reply to this message.
On 2014/10/19 22:30:06, Trevor Daniels wrote: > Actually, prompted by Kieren's recent mail, it might be preferable to go back to > using \override's for re-establishing the default settings, as that would permit > \once to work consistently, in particular permitting \once \autoLineBreaksOn to > give the line breaker one-time-step optional windows to break a line: "You may > break the line here, here or here, but nowhere else." Same with perhaps more > utility for line/page break combinations. What do others think? Phut! I should have tried this before advocating the benefits of using \once. It doesn't work. It seems breaks must be On for at least 2 time steps to be effective. So using \autoLineBreaksOn b' b' \autoLineBreaksOff in the middle of a long sequence with Off, permits a break after the two b's, but \autoLineBreaksOn b' \autoLineBreaksOff or using \once does not permit the break, or at least the opportunity is not taken and the line runs off the right margin. So we need a \twice command ;)
Sign in to reply to this message.
On 2014/10/20 04:34:56, Keith wrote: > Looks good to me. > I'm just suggesting more changes that you might want to do at the same time. > > https://codereview.appspot.com/156400043/diff/20001/Documentation/notation/sp... > File Documentation/notation/spacing.itely (right): > > https://codereview.appspot.com/156400043/diff/20001/Documentation/notation/sp... > Documentation/notation/spacing.itely:1769: @node Explicit breaks > Probably you can eliminate this entire section. > > https://codereview.appspot.com/156400043/diff/20001/Documentation/notation/sp... > Documentation/notation/spacing.itely:1773: commands are ignored by LilyPond. > There are two commands to > I am confused by the sentence above. The only time I have seen LilyPond ignore > a \break is where there was no bar-line; we have \bar "" for that. Probably the > manual would be better without this. > > https://codereview.appspot.com/156400043/diff/20001/Documentation/notation/sp... > Documentation/notation/spacing.itely:1820: {using-an-extra-voice-for-breaks.ly} > Maybe move this snippet up to the section you are editing on breaks? Thanks Keith. I agree with all three suggestions. As they are relevant to this patch I'll incorporate them. I've decided to keep the reverts for the On predefs, since \once does not do what it says on the tin with these overrides. Leaving them as reverts means they behave as expected. New patch soon. Trevor
Sign in to reply to this message.
Remove Explict breaks section
Sign in to reply to this message.
On Tue, 21 Oct 2014 09:33:56 -0700, <tdanielsmusic@googlemail.com> wrote: > I've decided to keep the reverts for the On predefs, since \once does > not do what [the name implies] with these overrides. Yuck. The problem seems to be that the override takes effect at the first beat in a bar, after the paper-column for the previous barline has been generated, and the \once makes the override expire before the next bar. Unfortunately this also means that \override Score.NonMusicalPaperColumn.line-break-permission = #'allow R1 only has effect /after/ the R1. We have a workaround for that timing problem in \overrideProperty, and then \once works fine with autoLineBreaksOn = { \overrideProperty Score.NonMusicalPaperColumn.line-break-permission #'allow \override Score.NonMusicalPaperColumn.line-break-permission = #'allow } autoLineBreaksOff = { %?? \overrideProperty Score.NonMusicalPaperColumn.line-break-permission ##f \override Score.NonMusicalPaperColumn.line-break-permission = ##f } I put the %?? because I'm not sure whether it is more intuitive if \autoBreaksOff R1 should forbid a break before the R1, or mean "here is your last chance to break, Lily". > https://codereview.appspot.com/156400043/
Sign in to reply to this message.
On 2014/10/22 05:48:36, Keith wrote:
> On Tue, 21 Oct 2014 09:33:56 -0700, <mailto:tdanielsmusic@googlemail.com>
wrote:
>
> > I've decided to keep the reverts for the On predefs, since \once does
> > not do what [the name implies] with these overrides.
>
> Yuck. The problem seems to be that the override takes effect at the first
beat
> in a bar, after the paper-column for the previous barline has been generated,
> and the \once makes the override expire before the next bar.
>
> Unfortunately this also means that
> \override Score.NonMusicalPaperColumn.line-break-permission = #'allow
> R1
> only has effect /after/ the R1.
>
> We have a workaround for that timing problem in \overrideProperty, and then
> \once works fine with
>
> autoLineBreaksOn = {
> \overrideProperty Score.NonMusicalPaperColumn.line-break-permission #'allow
> \override Score.NonMusicalPaperColumn.line-break-permission = #'allow }
I never really got \overrideProperty. Would it cooperate with \once? Does it
only take effect once?
Sign in to reply to this message.
Thanks Keith
On 2014/10/22 05:48:36, you wrote:
> Yuck. The problem seems to be that the override takes effect at the first
beat
> in a bar, after the paper-column for the previous barline has been generated,
> and the \once makes the override expire before the next bar.
>
> Unfortunately this also means that
> \override Score.NonMusicalPaperColumn.line-break-permission = #'allow
> R1
> only has effect /after/ the R1.
>
> We have a workaround for that timing problem in \overrideProperty, and then
> \once works fine with
>
> autoLineBreaksOn = {
> \overrideProperty Score.NonMusicalPaperColumn.line-break-permission #'allow
> \override Score.NonMusicalPaperColumn.line-break-permission = #'allow }
>
> autoLineBreaksOff = {
> %?? \overrideProperty Score.NonMusicalPaperColumn.line-break-permission ##f
> \override Score.NonMusicalPaperColumn.line-break-permission = ##f }
>
That looks like the way to go. It seems \once works fine with
\overrideProperty.
> I put the %?? because I'm not sure whether it is more intuitive if
> \autoBreaksOff
> R1
> should forbid a break before the R1, or mean "here is your last chance to
break,
> Lily".
I prefer "forbid a break before the R1". That's more consistent with
\autoBreaksOn R1 permitting a break before the R1. But one drawback is that
placing
\autoBreaksOff before all music in a score gives errors: "bounds of spanner are
invalid".
That's not a problem in practice, but would require a Known issues entry.
I'll post a new patch along these lines.
Sign in to reply to this message.
On 2014/10/22 10:33:30, Trevor Daniels wrote: > Thanks Keith > > On 2014/10/22 05:48:36, you wrote: > > > We have a workaround for that timing problem in \overrideProperty, and then > > \once works fine with [line breaking] > That looks like the way to go. It seems \once works fine with > \overrideProperty. ... but only for line breaking. It seems that page breaking needs a window of opportunity to break a page that is several bars long. The number of bars required varies with the length of the music between 2 and 5 or so, but I've never seen it less than 2. So there's no chance \once will work. For consistency I'll use \overrides for both On and Off for page breaking, and add a Known issue about \once.
Sign in to reply to this message.
Use \overrideProperty
Sign in to reply to this message.
On 2014/10/22 11:20:48, Trevor Daniels wrote:
> On 2014/10/22 10:33:30, Trevor Daniels wrote:
> ... but only for line breaking. It seems that page breaking needs a window of
> opportunity to break a page that is several bars long. The number of bars
> required varies with the length of the music between 2 and 5 or so, but I've
> never seen it less than 2. So there's no chance \once will work.
Somehow I was unlucky enough to find the example that worked
{ \repeat unfold 22 b2
\autoPageBreaksOff
\repeat unfold 320 b2
\once\autoPageBreaksOn
R1
\repeat unfold 320 b2 }
I tried to figure out why LilyPond's page-breaking usually misses these
opportunities, and concluded only that LilyPond's 'constrained-breaking'
algorithm takes a strange approach.
Sign in to reply to this message.
On 2014/10/22 07:12:16, dak wrote: > I never really got \overrideProperty. Would it cooperate with \once? > Does it only take effect once? \overrideProperty uses an ApplyOutput event (as opposed to an OverrideProperty event) to change a property in grobs that *already* *exist* at the current time-step. It does not change the instructions in the context for making further grobs, so it has effect just once.
Sign in to reply to this message.
Message was sent while issue was closed.
Pushed to staging as aca2ebd202992674424bd05a8bfc7c8003a8839b Author: Trevor Daniels <t.daniels@treda.co.uk> 2014-10-22 14:23:25 Committer: Trevor Daniels <t.daniels@treda.co.uk> 2014-10-27 22:50:03 Issue 4169: Line- and page-breaking syntactic sugar Install line- and page-breaking controls and document them. Remove now-redundant section on Explicit breaks, preserving the snippet showing how to use an extra voice to contain break commands. Amend indexing. Closing ...
Sign in to reply to this message.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
