Question about the header structure of the very first page of the score
Hello, in Italy it's very common to have a printed score with the very first page formatted as this image shows: https://www.stretta-music.com/media/images/712/776712_detail-00.jpg Basically, it is a sequence of fields, all horizontally centered, following this order, from top to bottom: 1) composer 2) title 3) subtitle 4) subsubtitle 5) (optional) copyright How can I obtain the same structure in LilyPond? Note that all the fields have different fonts (and font-sizes) The title + subtitle + subsubtitle structure of LP would be enough but I also need to place the name of the composer at the top of the page. Thanks for your help! P
Re: reducing size of an element
Hello Leonid, Do \override Staff.TimeSignature.font-size = #-2 (or any other number). If you want it to apply to all Staves you can also to \overrider Score.etc Cheers, Valentin Am Dienstag, 23. November 2021, 01:40:13 CET schrieb Leonid Hrabovsky: > Hi everyone, who may instruct me on how to reduce the size of > timesig.neomensural94 grob (Notation pg. 454) if it is possible? > > > *Леонід - Leonid* signature.asc Description: This is a digitally signed message part.
reducing size of an element
Hi everyone, who may instruct me on how to reduce the size of timesig.neomensural94 grob (Notation pg. 454) if it is possible? *Леонід - Leonid*
Re: Unwanted space around cautionary accidental
Hello Jean, About the difference in horizontal skylines: As regular accidentals get be parenthesized and cautionary accidentals can be unparenthesized I think it is still legitimate to let behave AccidentalCautionary behave the same way. According to the source flats and double flats get a bit more padding to the right, but I don’t actually find any difference between these two. Cheers, Valentin Am Dienstag, 23. November 2021, 00:33:09 CET schrieb Jean Abou Samra: > Le 23/11/2021 à 00:05, Valentin Petzel a écrit : > > Accidental and AccidentalCautionary grob definitions differ in three ways, > > the Accidental grob has these three additional properties: > > > > (extra-spacing-width . (-0.2 . 0.0)) > > (horizontal-skylines . ,(ly:make-unpure-pure-container > > ly:accidental-interface::horizontal-skylines)) (vertical-skylines . > > ,grob::unpure-vertical-skylines-from-stencil) > > > > I know no good reason why these properties should differ, as the only > > difference between these grobs should be that AccidentalCautionary has > > parenthesize set to #t by default. > The difference in horizontal-skylines is expected, > I believe. Accidental has some adjustments specific to > certain glyphs (flats and double flats). This is not > relevant for AccidentalCautionary because the parentheses > 'hide' the outline of the glyph from the horizontal > point of view. > > However, the differences in extra-spacing-width and > vertical-skylines are clearly not expected as far > as I can see. Good catch; I suggest to submit a patch. > > (Homework for me: figure out why accidentals' skylines > need be unpure??) > > Best, > Jean signature.asc Description: This is a digitally signed message part.
Re: Unwanted space around cautionary accidental
Hello Harm,
I tested it with 2.19.45 version, this is why I added "(at least)" in my
previous post. I don't know if the same behavior occurs in older versions...
Second, comparing the two NoteColumns in your example I notice a
> different positioning of the accent in y-axis direction, but no
> remarkable space changes between it and the cautionary accidental. Do
> I miss something?
>
You are right: given that the cautionary accident introduced extra unwanted
space, I assumed therefore that this extra-vertical space was made by some
invisible horizontal extent of the cautionary accidental, but the effective
unwanted space is between the accent and the notehead.
Though, the suggested override for vertical-skylines doesn't solve it
> completely, see the ouput of:
>
> {
> %\override Staff.AccidentalPlacement.right-padding = 0.25 %% default
> 0.15
> \override AccidentalCautionary.vertical-skylines =
> #grob::unpure-vertical-skylines-from-stencil
> <>-\tweak extra-offset #'(-1 . 8.5) _\markup \draw-line #'(10 . 0)
> c'''!-> s c'''?->
> }
>
>
Thank you very much!
Best,
P
Re: Unwanted space around cautionary accidental
Am Mo., 22. Nov. 2021 um 23:29 Uhr schrieb Paolo Prete :
>
> Hello,
>
> Please, have a look at this:
>
> { c'''!-> s c'''?-> }
>
> From (at least) 2.19.45 on it adds an unwanted space between the cautionary
> accidental and the ">" script. Any Idea of how to fix this without tweaking?
>
> Thanks!
> P
Hi Paolo,
I don't see any changed behaviour while comparing 2.18.2., 2.22.1 and
2.23.3, maybe some versions of 2.19.x did different...
Second, comparing the two NoteColumns in your example I notice a
different positioning of the accent in y-axis direction, but no
remarkable space changes between it and the cautionary accidental. Do
I miss something?
That said I would prefer do have the same vertical space in both
NoteColumns between the accent and the NoteHead, I _think_ there would
be enough room for it.
Though, the suggested override for vertical-skylines doesn't solve it
completely, see the ouput of:
{
%\override Staff.AccidentalPlacement.right-padding = 0.25 %% default 0.15
\override AccidentalCautionary.vertical-skylines =
#grob::unpure-vertical-skylines-from-stencil
<>-\tweak extra-offset #'(-1 . 8.5) _\markup \draw-line #'(10 . 0)
c'''!-> s c'''?->
}
Adding the commented override for right-padding does.
Cheers,
Harm
Re: Unwanted space around cautionary accidental
Great! Thanks! On Tue, Nov 23, 2021 at 12:05 AM Valentin Petzel wrote: > Accidental and AccidentalCautionary grob definitions differ in three ways, > the Accidental grob has these three additional properties: > > (extra-spacing-width . (-0.2 . 0.0)) > (horizontal-skylines . ,(ly:make-unpure-pure-container > ly:accidental-interface::horizontal-skylines)) > (vertical-skylines . ,grob::unpure-vertical-skylines-from-stencil) > > I know no good reason why these properties should differ, as the only > difference between these grobs should be that AccidentalCautionary has > parenthesize set to #t by default. > > Anyway, since AccidentalCautionary is missing the property to calculate > vertical skylines from stencil it will do so only from extent, which gives > you higher skylines and thus also more required space. > > Your problem is solved by doing > \override AccidentalCautionary.vertical-skylines = > #grob::unpure-vertical-skylines-from-stencil > > Cheers, > Valentin
Re: Unwanted space around cautionary accidental
Hello Jean, I’m working on submitting a patch. Should I add a regtest for this issue? If so, does it suffice to create a new regtest ly file for this? Valentin Am Dienstag, 23. November 2021, 00:33:09 CET schrieb Jean Abou Samra: > Le 23/11/2021 à 00:05, Valentin Petzel a écrit : > > Accidental and AccidentalCautionary grob definitions differ in three ways, > > the Accidental grob has these three additional properties: > > > > (extra-spacing-width . (-0.2 . 0.0)) > > (horizontal-skylines . ,(ly:make-unpure-pure-container > > ly:accidental-interface::horizontal-skylines)) (vertical-skylines . > > ,grob::unpure-vertical-skylines-from-stencil) > > > > I know no good reason why these properties should differ, as the only > > difference between these grobs should be that AccidentalCautionary has > > parenthesize set to #t by default. > The difference in horizontal-skylines is expected, > I believe. Accidental has some adjustments specific to > certain glyphs (flats and double flats). This is not > relevant for AccidentalCautionary because the parentheses > 'hide' the outline of the glyph from the horizontal > point of view. > > However, the differences in extra-spacing-width and > vertical-skylines are clearly not expected as far > as I can see. Good catch; I suggest to submit a patch. > > (Homework for me: figure out why accidentals' skylines > need be unpure??) > > Best, > Jean signature.asc Description: This is a digitally signed message part.
Re: Unwanted space around cautionary accidental
Le 23/11/2021 à 00:05, Valentin Petzel a écrit : Accidental and AccidentalCautionary grob definitions differ in three ways, the Accidental grob has these three additional properties: (extra-spacing-width . (-0.2 . 0.0)) (horizontal-skylines . ,(ly:make-unpure-pure-container ly:accidental-interface::horizontal-skylines)) (vertical-skylines . ,grob::unpure-vertical-skylines-from-stencil) I know no good reason why these properties should differ, as the only difference between these grobs should be that AccidentalCautionary has parenthesize set to #t by default. The difference in horizontal-skylines is expected, I believe. Accidental has some adjustments specific to certain glyphs (flats and double flats). This is not relevant for AccidentalCautionary because the parentheses 'hide' the outline of the glyph from the horizontal point of view. However, the differences in extra-spacing-width and vertical-skylines are clearly not expected as far as I can see. Good catch; I suggest to submit a patch. (Homework for me: figure out why accidentals' skylines need be unpure??) Best, Jean
Re: Check if a font is currently installed
Hello Paolo, If you want to do this for any font you’ll have no other option but to basically do what font-config does, and that is to try to estimate how distant two font names are. I would be very useful if we could get font-config to give us the actual distance. Cheers, Valentin Am Dienstag, 23. November 2021, 00:15:37 CET schrieb Paolo Prete: > Hello Valentin, > > >From what I understand, your procedure relies on the convention that the > > name of the font file has to be very similar to the descriptive name of the > font; unfortunately, this adds unsafety to the procedure I wrote before > (which is already unsafe), even if it shortens that procedure a bit. > I think that the only way to have a reliable check is to parse the > configured name. > An additional C++ helper function, wrapped by Scheme, is highly useful IMHO > (and maybe it should require few lines of additional code), but I wonder as > well if a solution can be found for the last stable versions of LilyPond > too. I have to meditate about it... > > Best, > Paolo > > On Mon, Nov 22, 2021 at 11:31 PM Valentin Petzel wrote: > > Hello Paolo, > > > > This behaviour actually comes from font-config and not from Lilypond. It > > is > > somewhat sensible, since we want to be able to specify a font intuitively > > and > > not by some set identifier. > > > > One hacky way to get what you want if you are checking for very specific > > fonts > > could be this, which would be checking the font file for some string we’d > > expect to find in it. > > > > Cheers, > > Valentin signature.asc Description: This is a digitally signed message part.
Re: Check if a font is currently installed
Hello Valentin, >From what I understand, your procedure relies on the convention that the name of the font file has to be very similar to the descriptive name of the font; unfortunately, this adds unsafety to the procedure I wrote before (which is already unsafe), even if it shortens that procedure a bit. I think that the only way to have a reliable check is to parse the configured name. An additional C++ helper function, wrapped by Scheme, is highly useful IMHO (and maybe it should require few lines of additional code), but I wonder as well if a solution can be found for the last stable versions of LilyPond too. I have to meditate about it... Best, Paolo On Mon, Nov 22, 2021 at 11:31 PM Valentin Petzel wrote: > Hello Paolo, > > This behaviour actually comes from font-config and not from Lilypond. It > is > somewhat sensible, since we want to be able to specify a font intuitively > and > not by some set identifier. > > One hacky way to get what you want if you are checking for very specific > fonts > could be this, which would be checking the font file for some string we’d > expect to find in it. > > Cheers, > Valentin
Re: Check if a font is currently installed
> On 22 Nov 2021, at 23:31, Valentin Petzel wrote: > > Hello Paolo, > > This behaviour actually comes from font-config and not from Lilypond. It is > somewhat sensible, since we want to be able to specify a font intuitively and > not by some set identifier. Somewhat sensible… but someone should teach Fontconfig some manners… aikebah@Rajah Trial % fc-match "Clearface Gothic LT Std" ClearfaceGothicLTStd-Roman.otf: "Clearface Gothic LT Std" "55 Roman" aikebah@Rajah Trial % fc-match "Clearface Gothic LT" Verdana.ttf: "Verdana" "Regular" I would consider "Clearface Gothic LT Std” a MUCH better match than Verdana, but fontconfig disagrees So I can also perfectly see the sense in Paolo’s quest for checking if the selected font appears to be what he attempted to configure. > > One hacky way to get what you want if you are checking for very specific > fonts > could be this, which would be checking the font file for some string we’d > expect to find in it. > > Cheers, > Valentin
Re: Unwanted space around cautionary accidental
Accidental and AccidentalCautionary grob definitions differ in three ways, the Accidental grob has these three additional properties: (extra-spacing-width . (-0.2 . 0.0)) (horizontal-skylines . ,(ly:make-unpure-pure-container ly:accidental-interface::horizontal-skylines)) (vertical-skylines . ,grob::unpure-vertical-skylines-from-stencil) I know no good reason why these properties should differ, as the only difference between these grobs should be that AccidentalCautionary has parenthesize set to #t by default. Anyway, since AccidentalCautionary is missing the property to calculate vertical skylines from stencil it will do so only from extent, which gives you higher skylines and thus also more required space. Your problem is solved by doing \override AccidentalCautionary.vertical-skylines = #grob::unpure-vertical-skylines-from-stencil Cheers, Valentin signature.asc Description: This is a digitally signed message part.
Re: Check if a font is currently installed
Hello Paolo, This behaviour actually comes from font-config and not from Lilypond. It is somewhat sensible, since we want to be able to specify a font intuitively and not by some set identifier. One hacky way to get what you want if you are checking for very specific fonts could be this, which would be checking the font file for some string we’d expect to find in it. Cheers, Valentin#(define path1 (ly:font-config-get-font-file "TeX Gyre Schola")) #(define path2 (ly:font-config-get-font-file "nonsense")) #(define (read-line port) (define (iterator prev) (let ((char (read-char port))) (if (or (eof-object? char) (equal? char #\nl)) (if (and (eof-object? char) (null? prev)) 'eof prev) (iterator (cons char prev) (let ((rev-list (iterator '( (if (equal? rev-list 'eof) 'eof (list->string (reverse rev-list) #(define (file-contains? path expr) (define (iterator port) (let ((line (read-line port))) (if (equal? line 'eof) #f (if (string-contains line expr) #t (iterator port) (iterator (open-input-file path))) #(display (file-contains? path1 "TeXGyreSchola")) #(display (file-contains? path2 "nonsense")) signature.asc Description: This is a digitally signed message part.
Unwanted space around cautionary accidental
Hello,
Please, have a look at this:
{ c'''!-> s c'''?-> }
>From (at least) 2.19.45 on it adds an unwanted space between the cautionary
accidental and the ">" script. Any Idea of how to fix this without tweaking?
Thanks!
P
Re: Check if a font is currently installed
Hello Valentin, I looked at the src code as well. I don't see an easy way to by-pass the problem, given that ly:font-config-get-font-file is bound to a C++ code that can't be dynamically overridden. In addition, The procedure explained in http://lilypond.org/doc/v2.21/Documentation/notation/fonts#single-entry-fonts even if it does work, it appears a bit misleading to me, because it requires to set the font-name attribute with a string which doesn't represent the name of the font, because it can include the style attributes as well. IMHO, replacing: \override #'(font-name . "Bitstream Vera Sans, sans-serif, Oblique Bold") with \override #'(font-formatted-class . "Bitstream Vera Sans, sans-serif, Oblique Bold") Would be more appropriate (maybe there are better strings than "font-formatted-class", but you get the idea). However, I can image that this would be not a trivial change to the current API. In any case, given a string that represents the class of the font (name + other attributes), I can't find a function that can parse this string and consequently finds the associated font-file. In fact #(ly:font-config-get-font-file str) accepts only the name of the font. Then, until we find a way to A) parse the complete string AND B) check if the corresponding font is really found, when I want to set fonts for my score I can only do the following procedure, which is long, unsafe and laborious: 1) I choose a font with some system fonts viewer, then check if it is included in the list obtained with -dshow-available-fonts (this is laborious: it would be better to have a sort of "font viewer" already bound to LilyPond) 2) I Inspect the properties of the chosen font with the above command, so to manually create a string that represents it (i.e: "Bitstream Vera Sans, sans-serif, Oblique Bold") and then set font-name with that string (this is unsafe, because there's not a way to check if the font is installed) 3) Get the file of the font with ly:font-config-get-font-file, and then feed a function like \checkFontFile font-name font-file-name (see the snippet below): this is tedious but necessary too, because if we compile a score on a different OS than the original one, it can raise a warning if the font is not found. And this is error-prone too: for example, for "Liberation Sans, Italic", I got the LiberationSansNarrow-Regular.ttf file, which can be misleading. If we solve at least the above A and B problems, the procedure is much simplified. Please let me know if you have any idea about it, or an alternative. It would be really useful to have a proper way to manage these things. Best, Paolo %% checkFontFile = #(define-scheme-function (parser location fontName fontFile) (string? string?) (let ((warning (not (string-contains (ly:font-config-get-font-file fontName) fontFile (if warning (begin (display "\nwarning: font '") (display fontFile) (display "' not found!\n") ) ) )) %% On Sun, Nov 21, 2021 at 9:32 PM Valentin Petzel wrote: > Hello Paolo, > > After looking into this it seems like this is intended behaviour for font- > config. Basically this does not perform an exact match, but calculates > some > distance and returns the font with best distance. Maybe it would be > somehow > possible to get that distance and decide upon it? > > Cheers, > Valentin > > Am Sonntag, 21. November 2021, 21:06:15 CET schrieb Paolo Prete: > > Thank you Valentin, a fix for this would be very useful. > > Best, > > Paolo > > > > On Sun, Nov 21, 2021 at 8:52 PM Valentin Petzel > wrote: > > > Hello Paolo, > > > > > > Theoretically it should be enough to check if > > > #(ly:font-config-get-font-file > > > font-name) is false, but at least on my system this returns just some > > > arbitrary but fixed font file if the font is not found. It should > > > definitely > > > not behave this way, gotta look into this. > > > > > > Cheers, > > > Valentin
Re: Box around MeasureCounter
On 2021-11-22 11:24 am, Rajesh Baskar wrote:
I had another question. The MeasureCounter boxify function does not
work if we change the staff to Rhythmic staff.
You need to scope the grob to the appropriate context. \boxifying
something within Staff only affects Staff. If you need it to work for
RhythmicStaff, just be more specific:
\new Voice {
\boxify RhythmicStaff.MeasureCounter
...
}
%% ...or... %%
\new RhythmicStaff
\with { \boxify MeasureCounter }
{ ... }
%% ...or... %%
\layout {
\context {
\RhythmicStaff
\boxify MeasureCounter
}
}
-- Aaron Hill
Re: Box around MeasureCounter
From: lilypond-user
on behalf of Rajesh Baskar
Date: Monday, November 22, 2021 at 12:45 PM
To: Aaron Hill
Cc: "lilypond-user@gnu.org"
Subject: Re: Box around MeasureCounter
Aaron,
I had another question. The MeasureCounter boxify function does not work if we
change the staff to Rhythmic staff.
It works perfectly if you add the Meeasure_counter_engraver and \boxify
MeasureCounter for the RhythmicStaff
\version "2.22.0"
boxify =
#(define-music-function
(grob-path) (key-list?)
(define proc (grob-transformer 'stencil
(lambda (grob orig) (grob-interpret-markup grob #{
\markup \override #'(box-padding . 0.25)
\override #'(thickness . 2)
\box \stencil #orig #}
#{ \override $grob-path . stencil = #proc #})
\include "english.ly" \header {tagline = "" }
\score {\new RhythmicStaff {
\override Score.SpacingSpanner.strict-note-spacing = ##t
\set Score.proportionalNotationDuration = #(ly:make-moment 1/4)
\set Staff.midiInstrument = #"Grand Piano"
\key c \major \numericTimeSignature
\time 4/4
\clef treble
\startMeasureCount
\hideNotes b2 c
\unHideNotes a c'4 g
\stopMeasureCount
\bar "||"}
\layout {
\context {
\RhythmicStaff Here is the change
\consists Measure_counter_engraver
\boxify MeasureCounter
}
}
\midi { \tempo 4 =92}
}
Re: Box around MeasureCounter
Aaron,
I had another question. The MeasureCounter boxify function does not work
if we change the staff to Rhythmic staff.
\version "2.22.0"
boxify =
#(define-music-function
(grob-path) (key-list?)
(define proc (grob-transformer 'stencil
(lambda (grob orig) (grob-interpret-markup grob #{
\markup \override #'(box-padding . 0.25)
\override #'(thickness . 2)
\box \stencil #orig #}
#{ \override $grob-path . stencil = #proc #})
\include "english.ly" \header {tagline = "" }
\score {\new RhythmicStaff {
\override Score.SpacingSpanner.strict-note-spacing = ##t
\set Score.proportionalNotationDuration = #(ly:make-moment 1/4)
\set Staff.midiInstrument = #"Grand Piano"
\key c \major \numericTimeSignature
\time 4/4
\clef treble
\startMeasureCount
\hideNotes b2 c
\unHideNotes a c'4 g
\stopMeasureCount
\bar "||"}
\layout {
\context {
\Staff
\consists Measure_counter_engraver
\boxify MeasureCounter
}
}
\midi { \tempo 4 =92}
}
On 11/18/2021 11:43 AM, Rajesh Baskar wrote:
Aaron,
Thank you so much, this worked perfectly.
On 11/17/2021 7:50 PM, Aaron Hill wrote:
\version "2.20.0"
boxify =
#(define-music-function
(grob-path) (key-list?)
(define proc (grob-transformer 'stencil
(lambda (grob orig) (grob-interpret-markup grob #{
\markup \override #'(box-padding . 0.25)
\override #'(thickness . 2)
\box \stencil #orig #}
#{ \override $grob-path . stencil = #proc #})
\new Staff
\with {
\consists Measure_counter_engraver
\boxify MeasureCounter
}
{
\boxify Staff.Clef
\startMeasureCount
fis'4 g'8 a' \once \boxify Accidental bes'2 cis''4 d''2.
\stopMeasureCount
}
Re: DynamicTextSpanner.style
Thanks Jean! JM > Le 22 nov. 2021 à 14:13, Jean Abou Samra a écrit : > > Le 22/11/2021 à 14:01, Jacques Menu a écrit : >> Hello folks, >> >> I can’t find the list of all possible values for DynamicTextSpanner.style in >> the LP internals reference. >> Where is it to be found? >> >> Thanks! >> >> JM > > > Hi Jacques, > > Possible styles are usually documented in interfaces. In this case, it's in > the line-interface: > > http://lilypond.org/doc/v2.23/Documentation/internals/line_002dinterface > > There is also more user-level documentation of line styles: > > http://lilypond.org/doc/v2.22/Documentation/notation/line-styles > > Cheers, > Jean
Re: DynamicTextSpanner.style
Le 22/11/2021 à 14:01, Jacques Menu a écrit : Hello folks, I can’t find the list of all possible values for DynamicTextSpanner.style in the LP internals reference. Where is it to be found? Thanks! JM Hi Jacques, Possible styles are usually documented in interfaces. In this case, it's in the line-interface: http://lilypond.org/doc/v2.23/Documentation/internals/line_002dinterface There is also more user-level documentation of line styles: http://lilypond.org/doc/v2.22/Documentation/notation/line-styles Cheers, Jean
DynamicTextSpanner.style
Hello folks, I can’t find the list of all possible values for DynamicTextSpanner.style in the LP internals reference. Where is it to be found? Thanks! JM
