[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Unicode accidentals vs. Markup accidentals
From: |
Valentin Petzel |
Subject: |
Re: Unicode accidentals vs. Markup accidentals |
Date: |
Mon, 16 Jan 2023 11:12:56 +0100 |
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 particularly easy to
work with nor particularly powerful. The design choice of having all markups
be separated by space requires a lot of \concat. This does show that lilypond
was not mainly conceived as a typesetting program, but as a notation program.
Now, the problem we have here is as already discussed that Lilypond does by
default use a font that does not provide these glyphs. A simple solution could
be using a different font. MuseScore provides a font "Edwin", which is a fork
of the font used by Lilypond with a few added symbols. The team of Dorico does
provide an OFL font "Academico", which reproduces the same typeface, and
provides a few added symbols. The downsides of this is that these fonts simply
use the accidental glyphs from MuseScore’s notation font Leland and Dorico’s
notation font Bravura. This means they do not optically match the font that
well and they most certainly do not match Lilypond’s notation glyphs.
If you can live with such a thing, changing the text font to Dorico’s
Academico will produce quite nice results.
On the other hand to make life easier and code easier to read you may alwas
define your own markup commands like this:
#(define-markup-command (tsharp layout props) ()
(interpret-markup layout props (markup #:raise 0.8 #:fontsize -3 #:sharp)))
#(define-markup-command (tflat layout props) ()
(interpret-markup layout props (markup #:raise 0.4 #:fontsize -1.7 #:flat)))
#(define-markup-command (tnatural layout props) ()
(interpret-markup layout props (markup #:raise 0.67 #:fontsize -2.5
#:natural)))
#(define-markup-command (with-sharp layout props m) (markup?)
(interpret-markup layout props (markup #:concat (m #:hspace 0.15
#:tsharp))))
#(define-markup-command (with-flat layout props m) (markup?)
(interpret-markup layout props (markup #:concat (m #:hspace 0.2 #:tflat))))
#(define-markup-command (with-natural layout props m) (markup?)
(interpret-markup layout props (markup #:concat (m #:hspace 0.2
#:tnatural))))
#(define-markup-command (with-sharp-between layout props m1 m2) (markup?
markup?)
(interpret-markup layout props (markup #:concat (m1 #:hspace 0.15 #:tsharp
m2))))
#(define-markup-command (with-flat-between layout props m1 m2) (markup? markup?)
(interpret-markup layout props (markup #:concat (m1 #:hspace 0.2 #:tflat
m2))))
#(define-markup-command (with-natural-between layout props m1 m2) (markup?
markup?)
(interpret-markup layout props (markup #:concat (m1 #:hspace 0.2 #:tnatural
m2))))
\markup { A C with a \tsharp can be written \with-sharp-between C ,
a C with a \tnatural can be written \with-natural C and
a C with a \tflat can be written \with-flat-between C . }
Also while Lilypond will not automatically replace Unicode characters, you can
tell it to do so manually:
\new Staff {
\override TextScript.before-line-breaking =
#(lambda (grob)
(ly:grob-set-property! grob 'text
(markup #:replace
`(("♭" . ,#{ \markup{\hspace #0.2 \tflat}
#})
("♯" . ,#{ \markup{\hspace #0.15
\tsharp} #})
("♮" . ,#{ \markup{\hspace #0.2
\tnatural} #}))
(ly:grob-property grob 'text))))
c'1^"B♭"
c'1^"C♯"
c'1^"D♮"
}
Cheers,
Valentin
Am Montag, 16. Jänner 2023, 07:52:50 CET schrieb 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
> characters within the Unicode spec? That seems like a pretty reasonable
> suggestion to me...
>
> I also don't think it's unreasonable to suggest that the default typography
> should look good. I hope we can agree that the output on staves 1 & 2 is
> significantly worse than the output on staff 3 (attached picture if it
> doesn't display inline for you).
> [image: image.png]
> Staves 1&2 are Unicode and default markup glyphs as in my original post
> (compiled on Windows). To get staff 3 the following is required:
>
> \new Staff {
> c'1^\markup\concat\vcenter { B \hspace #0.2 \fontsize #-1.5 \flat }
> c'1^\markup\concat\vcenter { C \hspace #0.1 \fontsize #-2 \sharp }
> c'1^\markup\concat\vcenter { D \hspace #0.2 \fontsize #-1.5 \natural }
> }
>
> IMO Staff 3 should be the default output, not something that requires so
> much tweaking.
>
> On Sun, Jan 15, 2023 at 9:56 PM Werner LEMBERG <wl@gnu.org> wrote:
> > > 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 that
> > selects a fallback font – and it is more or less unpredictable which
> > fallback is actually used due to the way how FontConfig works. If you
> > want LilyPond glyphs you have to explicitly select them.
> >
> > In general, I strongly suggest that you *always* select the correct
> > font for text rendering to assure that your document stays portable
> > and can be reliably compiled on other systems.
> >
> > > and the default size/alignment of the glyphs within text markup
> > > should not require adjustment to look correct.
> >
> > How do you want to adjust the size in an automated way? Just think of
> > using Times New Roman together with Courier, as shown in the image –
> > what size should the LilyPond glyphs have? And the default
> > positioning is not too bad, as demonstrated in the other image.
> >
> > ```
> > \markup { "foo" \number "♭♯♮" "bar" }
> > ```
> >
> > Werner
signature.asc
Description: This is a digitally signed message part.
- Re: Unicode accidentals vs. Markup accidentals, (continued)
- Re: Unicode accidentals vs. Markup accidentals, Saul Tobin, 2023/01/16
- Re: Unicode accidentals vs. Markup accidentals, Werner LEMBERG, 2023/01/16
- Re: Unicode accidentals vs. Markup accidentals, Valentin Petzel, 2023/01/16
- Re: Unicode accidentals vs. Markup accidentals,Re: Unicode accidentals vs. Markup accidentals, Werner LEMBERG, 2023/01/16
- Re: Unicode accidentals vs. Markup accidentals,Re: Unicode accidentals vs. Markup accidentals, Mark Knoop, 2023/01/16
- Re: Unicode accidentals vs. Markup accidentals, Re: Unicode accidentals vs. Markup accidentals, Jean Abou Samra, 2023/01/16
- Re: Unicode accidentals vs. Markup accidentals, Werner LEMBERG, 2023/01/16
- Re: Unicode accidentals vs. Markup accidentals,Re: Unicode accidentals vs. Markup accidentals, Kieren MacMillan, 2023/01/16
- Re: Unicode accidentals vs. Markup accidentals,Re: Unicode accidentals vs. Markup accidentals, Jean Abou Samra, 2023/01/16
- Re: Unicode accidentals vs. Markup accidentals, Kieren MacMillan, 2023/01/16
- Re: Unicode accidentals vs. Markup accidentals,
Valentin Petzel <=
- Re: Unicode accidentals vs. Markup accidentals, David Wright, 2023/01/16