Re: Unicode accidentals vs. Markup accidentals

2023-01-16 Thread David Wright
On Sun 15 Jan 2023 at 22:52:50 (-0800), Saul Tobin wrote: > Lilypond ships with a text font as well as a music font. I agree that I > suspect that currently Lilypond's text font does not actually define these > Unicode music characters, so it falls back on the OS to find them. Why not > just add

Re: Unicode accidentals vs. Markup accidentals,Re: Unicode accidentals vs. Markup accidentals

2023-01-16 Thread Jean Abou Samra
Le 16/01/2023 à 16:57, Kieren MacMillan a écrit : Hi all, In any case, please submit this to the LSR! I was *just* going to look at this to see if it could be improved viz-a-viz Jean’s suggestion that callbacks using after-line-breaking are often better done with grob-transformer. [Yes, I

Re: Unicode accidentals vs. Markup accidentals

2023-01-16 Thread Werner LEMBERG
>>> Is there a possibility to register this or a similar function globally >>> so that all markup strings can use it? > > It is the same mechanism, and add-text-replacements! answers > Werner’s question. Thanks. I only did a quick index search for 'replace' in the NR, and there was no hit.

Re: Unicode accidentals vs. Markup accidentals,Re: Unicode accidentals vs. Markup accidentals

2023-01-16 Thread Kieren MacMillan
Hi all, > In any case, please submit this to the LSR! I was *just* going to look at this to see if it could be improved viz-a-viz Jean’s suggestion that callbacks using after-line-breaking are often better done with grob-transformer. [Yes, I know this is *before*-line-breaking…] If so, that

Re: Unicode accidentals vs. Markup accidentals, Re: Unicode accidentals vs. Markup accidentals

2023-01-16 Thread Jean Abou Samra
> Le 16 janv. 2023 à 15:07, Mark Knoop a écrit : > >  > At 12:51 on 16 Jan 2023, Werner LEMBERG wrote: >>> \new Staff { >>> \override TextScript.before-line-breaking = >>> #(lambda (grob) >>> (ly:grob-set-property! grob 'text >>>(markup #:replace >>>

Re: Unicode accidentals vs. Markup accidentals,Re: Unicode accidentals vs. Markup accidentals

2023-01-16 Thread Mark Knoop
At 12:51 on 16 Jan 2023, Werner LEMBERG wrote: >> \new Staff { >> \override TextScript.before-line-breaking = >> #(lambda (grob) >> (ly:grob-set-property! grob 'text >> (markup #:replace >> `(("♭" . ,#{ \markup{ \tflat} #})

Re: Unicode accidentals vs. Markup accidentals,Re: Unicode accidentals vs. Markup accidentals

2023-01-16 Thread Werner LEMBERG
> I quite like this, but incorporating this into my previous code I > found going down TWO steps to be optically more pleasing. OK :-) > \new Staff { > \override TextScript.before-line-breaking = > #(lambda (grob) > (ly:grob-set-property! grob 'text >

Re: Unicode accidentals vs. Markup accidentals

2023-01-16 Thread Kieren MacMillan
Hi Werner, > I rather suggest the following > > ``` > F = \markup { \smaller \number ♭ } > S = \markup { \smaller \number ♯ } > N = \markup { \smaller \number ♮ } > > \new Staff { > c'1^\markup \concat { B \F } > c'1^\markup \concat { C \S } > c'1^\markup \concat { D \N } > } > ``` > > If

Re: Unicode accidentals vs. Markup accidentals

2023-01-16 Thread Valentin Petzel
Hello Werner, I quite like this, but incorporating this into my previous code I found going down TWO steps to be optically more pleasing. This probably because the \number accidentals are designed for use with with numbers, which are slightly higher than regular text and very bold faced. So in

Re: Unicode accidentals vs. Markup accidentals

2023-01-16 Thread Valentin Petzel
Hello Saul, I do not find this much surprising at all. Yes, Lilypond could do lots of automagic, automatically replacing such signs by the respective music font version. But it does not and rather gives you (the user) the control and the responsibility. But typesetting in Lilypond is neither

Re: Unicode accidentals vs. Markup accidentals

2023-01-16 Thread Werner LEMBERG
> Lilypond ships with a text font as well as a music font. I agree > that I suspect that currently Lilypond's text font does not actually > define these Unicode music characters, so it falls back on the OS to > find them. Why not just add copies of Emmentaler glyphs to the > Lilypond text fonts

Re: Unicode accidentals vs. Markup accidentals

2023-01-15 Thread Saul Tobin
Lilypond ships with a text font as well as a music font. I agree that I suspect that currently Lilypond's text font does not actually define these Unicode music characters, so it falls back on the OS to find them. Why not just add copies of Emmentaler glyphs to the Lilypond text fonts for

Re: Unicode accidentals vs. Markup accidentals

2023-01-15 Thread Werner LEMBERG
> IMO Lilypond should render musical Unicode characters using the same > font as the music itself, No, it should not. If you select font 'foo' for text rendering, everything should come from that font. If a certain character is not in 'foo', it is the FontConfig library rather than LilyPond

Re: Unicode accidentals vs. Markup accidentals

2023-01-15 Thread Saul Tobin
IMO Lilypond should render musical Unicode characters using the same font as the music itself, and the default size/alignment of the glyphs within text markup should not require adjustment to look correct. On Sun, Jan 15, 2023 at 4:07 AM William Rehwinkel < will...@williamrehwinkel.net> wrote: >

Re: Unicode accidentals vs. Markup accidentals

2023-01-15 Thread William Rehwinkel
Dear Saul, I don't see why this would be surprising... as you said it's the difference of using the unicode symbol from the text font (such as unicode symbol https://www.compart.com/en/unicode/U+266D for a flat) for an accidental and pasting in the lilypond musical font symbol for that

Unicode accidentals vs. Markup accidentals

2023-01-14 Thread Saul Tobin
Surprisingly, typing the Unicode characters for accidental symbols does not produce the same font output as using the markup commands: << \new Staff { c'1^"B♭" c'1^"C♯" c'1^"D♮" } \new Staff { c'1^\markup { B \flat } c'1^\markup { C \sharp } c'1^\markup { D \natural