Re: Markup wrap at the end of the line
I agree that when a long markup stretches the measure at the end of a line, it suggests that there may be better ways of laying out the line breaks. Perhaps there should be a penalty for stretched measures due to markup in Lilypond's line breaking algorithm? Saul On Sat, Mar 16, 2019, 6:34 PM Andrew Bernard wrote: > Hi edes, > > Well, if absolute line breaking is not important in your score, you could > always put a break in front of the bar with the long text. In terms of > engraving, which to me is all about clarity for musicians to read, you > don't see many examples of this, as it is indeed hard to read a note then > read the next line for rest of the directive and then start the next line. > I'd be looking at better ways of laying out. Or you could perhaps just > stack the long instruction vertically with several lines in a column. If > you are doing this on a page break it would not be good, I think! > > Sorry, not the specific answer to your question. > > Andrew > > > On Sun, 17 Mar 2019 at 03:04, edes wrote: > >> >> a related but different question: how can i make a markup wrap at the end >> of the line? >> >> ___ > lilypond-user mailing list > lilypond-user@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-user > ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Markup wrap at the end of the line
Hi edes, Look at LSR 829. This is exactly your case, and what I was saying, The line break is such that the very long text is all on one line. I believe this is the conventional way to handle this. Andrew ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Markup wrap at the end of the line
Hi edes, Well, if absolute line breaking is not important in your score, you could always put a break in front of the bar with the long text. In terms of engraving, which to me is all about clarity for musicians to read, you don't see many examples of this, as it is indeed hard to read a note then read the next line for rest of the directive and then start the next line. I'd be looking at better ways of laying out. Or you could perhaps just stack the long instruction vertically with several lines in a column. If you are doing this on a page break it would not be good, I think! Sorry, not the specific answer to your question. Andrew On Sun, 17 Mar 2019 at 03:04, edes wrote: > > a related but different question: how can i make a markup wrap at the end > of the line? > > ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Edition engraver verbosity
I am now using edition-engraver and page-layout. I am overwhelmed by the sheer brilliance of this code. Thanks Jan-Peter and Urs and others! Is there an option to switch off the 'trying...' messages and on on? It's annoying when using gvim and make as it just causes one to have to quit 'more' and so on because of long pages of output, for no real need. If there is a verbose switch, could you let me know? If not, can I put one in? Andrew ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Snippet: Using arbitrary markup with LyricHyphen
On 3/16/19, Aaron Hill wrote: > So, what I ended up doing was rewriting the LyricHyphen stencil > procedure to use an actual hyphen glyph rather than try to draw > something. And in the noble pursuit of generalization, the following > approach supports *any* arbitrary markup. Nice! I’ve tried to make it compatible with 2.18, so that I could post it on the LSR: http://lsr.di.unimi.it/LSR/Item?id=1090 V. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Snippet: Using arbitrary markup with LyricHyphen
On Mar 16, 2019, at 6:30 AM, Aaron Hill wrote: > This whole thing started as a way to automate setting the properties of > LyricHyphen based on the current LyricText font. In my use case, I am > preparing music for projection, which requires larger font sizes than typical > for print. The default values for things like length, thickness, and height > are not suitable and require manual tweaking. > > What I wanted is a way to measure the size of an actual hyphen in a font and > have LyricHyphen's default stencil procedure draw a box accordingly. > However, when using ly:stencil-extent against a simple glyph, the results did > not reflect only the ink but also included spacing/kerning information for > the glyph. Depending on the font, the effective width of a hyphen might be > larger than it actually appears. The resulting LyricHyphen does not line up > with nor properly mimic a real hyphen. > > Now, even if I could solve the detail with glyph outlines and get the right > dimensions, there is still a problem that Lyric_hyphen::print uses a rounded > box with a hard-coded corner radius for its stencil. In my case, the radius > was too small compared to the actual hyphen in the font I was using, so it > looks too "sharp". > > So, what I ended up doing was rewriting the LyricHyphen stencil procedure to > use an actual hyphen glyph rather than try to draw something. And in the > noble pursuit of generalization, the following approach supports *any* > arbitrary markup. I’ve been wanting this for quite a while. Thanks for sharing!! David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Need help with Lily Pond File
Am Sa., 16. März 2019 um 13:52 Uhr schrieb Andrew Bernard : > There's a convention on this list to just post Minimal Working Exmaples > (MWE), to make it possible for people to help, rather than full scores. > Making an MWEW instead of posting a huge chunk is a valuable exercise because > I find nine times out of ten it helps you isolate and solve the problem by > yourself anyway. And this piece is for sure under copyright in many countries... Cheers, Harm ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Markup wrap at the end of the line
el 2019-03-15 a las 09:44 Urs Liska escribió:
> Markups can't flow beyond the end of a score (horizontally) and widen
> the score if necessary:
>
> \version "2.19.82"
>
> {
>c'1 -"This is a long text that widens the score because it can't
> protrude." c'1
> }
>
> Is there a possibility to override this behaviour so that the score is
> just spaced naturally and the markup just goes as long as it needs?
a related but different question: how can i make a markup wrap at the end
of the line?
i have a longish markup on a note (like "poco a poco rallentando blah blah
blah)" and when it's on the last bar of a line, the measure is
unacceptably stretched.
i think to remember i once saw how to allow breakable markups, but i
either imagined it or it's somewhere i can't find...
--
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Need help with Lily Pond File
HI Yerko, and welcome. Can I make the politest suggestion? People on the list always object when I say how I think things should be done, but this file is illegible and unwieldy, with very, very long lines, making it a really hard slog to help you. A good practice is to have each bar on one line. This is so much easier to read. There are no serious errors in your file, just little things, like \italics instead oif \italic, and slight misuse fo markup. Would you kindly make your file clean and legible and I'd be happy to point out a few things. Use a tool like Frescobaldi and just go through the errors one by one starting at the top. Frescobaldi makes this process easy. There's a convention on this list to just post Minimal Working Exmaples (MWE), to make it possible for people to help, rather than full scores. Making an MWEW instead of posting a huge chunk is a valuable exercise because I find nine times out of ten it helps you isolate and solve the problem by yourself anyway. Andrew ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Snippet: Using arbitrary markup with LyricHyphen
This whole thing started as a way to automate setting the properties of
LyricHyphen based on the current LyricText font. In my use case, I am
preparing music for projection, which requires larger font sizes than
typical for print. The default values for things like length,
thickness, and height are not suitable and require manual tweaking.
What I wanted is a way to measure the size of an actual hyphen in a font
and have LyricHyphen's default stencil procedure draw a box accordingly.
However, when using ly:stencil-extent against a simple glyph, the
results did not reflect only the ink but also included spacing/kerning
information for the glyph. Depending on the font, the effective width
of a hyphen might be larger than it actually appears. The resulting
LyricHyphen does not line up with nor properly mimic a real hyphen.
Now, even if I could solve the detail with glyph outlines and get the
right dimensions, there is still a problem that Lyric_hyphen::print uses
a rounded box with a hard-coded corner radius for its stencil. In my
case, the radius was too small compared to the actual hyphen in the font
I was using, so it looks too "sharp".
So, what I ended up doing was rewriting the LyricHyphen stencil
procedure to use an actual hyphen glyph rather than try to draw
something. And in the noble pursuit of generalization, the following
approach supports *any* arbitrary markup.
\version "2.19.82"
#(define (lyric-hyphen-text-stencil grob)
"Draws a LyricHyphen using an arbitrary text markup."
(define (span-point side common dir)
(let ((iv (ly:generic-bound-extent side common)))
(if (interval-empty? iv)
(ly:grob-relative-coordinate side common X)
(interval-bound iv dir
(define (get-text-stencil grob)
(let* ((orig (ly:grob-original grob))
(into (ly:spanner-broken-into orig)))
(grob-interpret-markup
(ly:spanner-bound (if (null? into) orig (first into)) LEFT)
(ly:grob-property grob 'text "-"
(let* ((left-bound (ly:spanner-bound grob LEFT))
(right-bound (ly:spanner-bound grob RIGHT))
(common (ly:grob-common-refpoint left-bound right-bound X))
(left-span (span-point left-bound common RIGHT))
(right-span (span-point right-bound common LEFT))
(span-length (- right-span left-span))
(padding (ly:grob-property grob 'padding 0.1))
(minimum-length (ly:grob-property grob 'minimum-length 0.3))
(usable-length (- span-length
(if (zero? (ly:item-break-dir left-bound)) padding 0)
(if (zero? (ly:item-break-dir right-bound)) padding 0
(if (< usable-length minimum-length) '()
(let* ((dash-sten (get-text-stencil grob))
(dash-extent (ly:stencil-extent dash-sten X))
(dash-length (min (interval-length dash-extent)
usable-length))
(scaled-sten (ly:stencil-scale
(ly:stencil-translate-axis
dash-sten (- (interval-start dash-extent)) X)
(/ dash-length (interval-length dash-extent)) 1))
(dash-period (max (ly:grob-property grob 'dash-period
1.0) dash-length))
(dash-count (1+ (floor (/ (- usable-length dash-length)
dash-period
(extra (- usable-length dash-length (* (- dash-count 1)
dash-period)))
(offset (+ (- left-span (ly:grob-relative-coordinate grob
common X))
(if (zero? (ly:item-break-dir left-bound))
padding 0)
(/ extra 2
(apply ly:stencil-add (map (lambda (n)
(ly:stencil-translate-axis scaled-sten (+ offset (* n
dash-period)) X))
(iota dash-count)))
\paper { indent = 0 ragged-right = ##f }
{ \omit Staff.TimeSignature
\repeat unfold 3 { b'4. 8 4 4 | 8 8 8 8 2 \break }
r2 b'2~ \break 1~ \break 2 2
}
\addlyrics {
\override LyricHyphen.dash-period = #5
\override LyricHyphen.padding = #0.2
\override LyricHyphen.stencil = #lyric-hyphen-text-stencil
Lo -- rem ip -- sum do -- lor sit a -- met.
\override LyricHyphen.text = #"\xe2\x80\x93" % U+2013
\override LyricText.font-series = #'bold
Lo -- rem ip -- sum do -- lor sit a -- met.
\override LyricHyphen.text = \markup
\circle \with-color #red #"\xe2\x99\xa5" % U+2665
\override LyricText.font-size = #3
Lo -- rem ip -- sum do -- lor sit a -- met.
\override LyricHyphen.text = \markup
\scale #'(3 . 1) \with-color #blue #"\xe2\x89\x8b" % U+224B
\override LyricText.font-size = #6
Break -- ing
}
NOTE: While this procedure is largely based on Lyric_hyphen::print, it
is not an exact copy. For instance, it omits the special handling of
whiteout, since \whiteout is a markup command which should in theory
serve an equivalent role. There is an edge case* that I could not
determine how to trigger, so I skipped its handling. Lastly, I chose to
compute dash count
Re: The Guide to getting Point and Click going with Gvim under Ubuntu 18
Hello All, I do once more apologize for my silly mistake about apparmor. As repentance, I have looked into all the issues Federico mention and solved the issue. In short, you have to create an apparmor profile for lilypond-wrapper.guile (it's not very hard to do - there are utilties to assist.) I'll get all my thoughts in order and take down notes on how to do this, and update the Guide I wrote. Here I was claiming it all worked fine and it turns out I had disabled the profile for evince and forgotten about it. I think I deserve a punishment. Perhaps I should be Transported to Australia for Life. Hold on, I am in Australia. :-) Anyway, issue solved. Andrew ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: The Guide to getting Point and Click going with Gvim under Ubuntu 18
Hi David, I made a mistake here - total lack of comprehension on my part. Not taking the time to study the format of the apparmor profile files, I misunderstood that the '#" in the '#include' was a comment character that had to be removed to activate the line. The comment character is '#' but '#include' is a single unit. Indeed the standard usr.bin.evince contains: #include and has no need of modification. My apologies for misleading readers - I am a complete idiot! The curious thing is that on my system where the '#' is removed the file appears to be included and works just fine, so maybe that's a peculiarity of the grammar? Or maybe I am totally mixed up. Thanks for pointing this out. Andrew On Sat, 16 Mar 2019 at 14:17, David Wright wrote: > On Sat 16 Mar 2019 at 00:31:16 (+1100), Andrew Bernard wrote: > > Hi Federico, > > > > Well, the '#' issue was a simple typo, not a vast conceptual error. > > > > I developed this on my pristine Ubuntu 18.10 and it all works swimmingly. > > Then I don't understand why you were altering the line at all. > AFAICT both Ubuntu's and Debian's /etc/apparmor.d/usr.bin.evince > files will include the local/usr.bin.evince file automatically. > Editing /etc/apparmor.d/usr.bin.evince is only needed for making > major changes to the configuration. > > Cheers, > David. > ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
