lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Future of the font-name property


From: Jean Abou Samra
Subject: Future of the font-name property
Date: Fri, 19 May 2023 17:57:00 +0200
User-agent: Evolution 3.48.1 (3.48.1-1.fc38)

Hi,

With 
[https://gitlab.com/lilypond/lilypond/-/merge_requests/2010](https://gitlab.com/lilypond/lilypond/-/merge_requests/2010),
 I am proposing to introduce a better alternative to the font-name property for 
overriding the font of an individual grob.

`font-name` has numerous problems that make it a confusing user interface.

It defeats commands like `\markup \bold` and overrides like `\override 
TextScript.font-series = #'bold`. If you want to change font styles while using 
`font-name`, you need to do things like

```
\markup \override #'(font-name . "Linux Libertine O") {
  Some words with
  \override #'(font-name . "Linux Libertine O Bold") one
  word in bold
}
```

instead of, with !2010,

```
\version "2.25.5"

\markup \override #'(font . ((serif . "Linux Libertine O"))) {
  Some words with \bold one word in bold
}
```

It does not work to change music fonts for music glyphs like clefs (i.e., 
fetaMusic/fetaBraces). For textual glyphs like dynamics, it sort of works, but 
the font size is off, as you can see from

```
\version "2.25.4"

{ c'\tweak font-name "emmentaler-20" ^\p }
```

When you override `font-name`, it applies to all font families. For grobs such 
as text marks, it is desirable to leave (for instance) the typewriter font 
unchanged when modifying the serif font.

Also, there is a common trap with `\override XXX.font-name = "Times New Roman"` 
where “Roman” is interpreted as a font style. The solution is a trailing comma, 
`\override XXX.font-name = "Times New Roman,"`.

`font-name` is something I would rather remove in favor of the new interface, 
which solves all of these problems. However, because of all these 
peculiarities, it is completely impossible to write a convert-ly rule for it.

What should we do here?

A. Keep it supported indefinitely. Reduce its existence in the documentation to 
a footnote.
B. Remove it. Make convert-ly emit a “not smart” message and write clear 
instructions to convert files.
C. Deprecate it now, remove it in 2.28.

Opinions?

Jean

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]