subject:"music font"

Re: What music font packaging/selection experience do we want?

2023-04-21 Thread Jean Abou Samra




> Le 21 avr. 2023 à 15:18, Jean Abou Samra  a écrit :
> 
> The idea is that rather than putting all the .otf file in one directory, you 
> make one subdirectory per font. Cf. the bit about recursive searching.


By the way, this is what we’re heading toward with SMuFL anyway. It doesn’t 
specify the file name of the JSON metadata file, so it needs to be the only 
JSON file in its directory.

Re: What music font packaging/selection experience do we want?

2023-04-21 Thread Werner LEMBERG

> Now to the second approach, which I prefer.  [...]

Me too.  All your suggestions are sound, thanks.


Werner

Re: What music font packaging/selection experience do we want?

2023-04-21 Thread Jean Abou Samra




> Le 21 avr. 2023 à 14:48, Wols Lists  a écrit :
> Just to add to bikeshed colours, please DON'T call it "stylesheet". Call it 
> the same name as the font, or something like that.
> If I've got a bunch of custom fonts I use, I just want to dump them in a 
> directory and forget about them. If they all store their metrics in a file 
> called "stylesheet.ily" they'll get thoroughly confused.


The idea is that rather than putting all the .otf file in one directory, you 
make one subdirectory per font. Cf. the bit about recursive searching.


> Indeed, it would be nice to be able to add a top-level command to lilypond 
> that adds this directory to the list of directories searched for fonts by 
> default. Dunno how easy that's for you to implement, but it would make life 
> damn simple for users :-)


That’s exactly what the linked MR does, the command being

#(ly:font-config-add-directory "/home/me/…/")

Re: What music font packaging/selection experience do we want?

2023-04-21 Thread Wols Lists


On 21/04/2023 12:03, Kieren MacMillan wrote:

If, next to the .otf font file, a file called stylesheet.ily (or another 
bikeshed color) is found, it is read and defines the style parameters. Because 
we want to be able to apply it both globally and locally to one 
score/bookpart/book, we take it in the form of a \layout block. To do that, we 
read stylesheet.ily with ly:parse-string-expression. That is, in exactly the 
same way as the content of #{ ... #} is read. For the stylesheet.ily writer, 
this means that the file is written as a single \layout block (plus perhaps a 
\version statement).

If in the future we support SMuFL, we'll also read the JSON metadata and 
synthetize a layout from it, then use it in the same way. stylesheet.ily would 
continue to be supported and could be used to define styles that SMuFL doesn't 
allow.

How modular and adaptable will that be? In a robust stylesheet system, there 
would be “inheritance”, “cascading”, etc., rather than the “include and 
overwrite” that happens with [ad-hoc] stylesheets now.

Just to add to bikeshed colours, please DON'T call it "stylesheet". Call 
it the same name as the font, or something like that.


If I've got a bunch of custom fonts I use, I just want to dump them in a 
directory and forget about them. If they all store their metrics in a 
file called "stylesheet.ily" they'll get thoroughly confused.


Indeed, it would be nice to be able to add a top-level command to 
lilypond that adds this directory to the list of directories searched 
for fonts by default. Dunno how easy that's for you to implement, but it 
would make life damn simple for users :-)


Cheers,
Wol

Re: What music font packaging/selection experience do we want?

2023-04-21 Thread Jean Abou Samra

Le vendredi 21 avril 2023 à 07:03 -0400, Kieren MacMillan a écrit :

> How modular and adaptable will that be? In a robust stylesheet system, there 
> would be “inheritance”, “cascading”, etc., rather than the “include and 
> overwrite” that happens with [ad-hoc] stylesheets now.

"Inheritance" is a form of "overwrite", isn't it? ;-)

You are right that this all begs questions about stylesheets. However, this 
proposed system is little different from what LilyPond currently does, and as 
such I don't think it would hamper the design of a refined stylesheet system.

It would be essentially equivalent to adding a `\layout` block with settings 
for the font wherever you put a `\paper { fonts.music = "..." }`. (Except that 
`\layout` isn't allowed in `\book`, but I hope to make this mechanism work 
nevertheless, until we can make `\layout` work there.)

You could achieve modularity for font stylesheets using `\include` inside the 
`stylesheet.ily` file, but I don't expect use cases. If there is something in a 
font stylesheet that also needs to be shared with something else, it sounds 
like something that's not intrinsically related to the font and shouldn't be 
part of a font stylesheet in the first place. For example: if you create a font 
that reproduces editions from publisher Foo from the XVIIth century, the 
thickness of stems sounds like something that should be part of the font 
stylesheet, but I think spacing overrides should be kept in a more general 
stylesheet that both sets that font and makes other settings to look exactly 
like what you're reproducing.


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

Re: What music font packaging/selection experience do we want?

2023-04-21 Thread Kieren MacMillan

Hi Jean,

> For those who haven't followed the (long) story, this MR basically lets 
> LilyPond search for music fonts in the same way as it searches for text 
> fonts. It thus makes it possible to make music fonts found with 
> ly:font-config-add-font or ly:font-config-add-directory, in contrast to the 
> current approach where you have to drop them into directories that are 
> normally supposed to be internal to LilyPond (and therefore re-add them with 
> every new LilyPond version). This lays the internal foundation for a better 
> user experience of using alternative music fonts.

As someone who (a) uses alternative music fonts for almost everything and (b) 
upgrades often, this is a welcome MR. Thank you!

> Now, from the user point of view, the question is how we want to organize the 
> UX of using an alternative music font:
>   • Download the font: from where? Are some alternative fonts 
> preinstalled with our official binaries? This would deserve a thread of its 
> own and I won't discuss it here.
>   • Install the font: how?
>   • Use the font in a .ly file: how?
> For (3), the basic way to select a music font is
> \paper {
>   fonts.music = "whatever"
> }
> 
> The main issue is that this only switches the glyphs themselves. However, to 
> look good, there are also other style adjustments to make in order to match 
> the font, like the thickness of stems and staff lines, etc. We want to have a 
> way to select a font and make those adjustments automatically at the same 
> time.

How does this discussion intersect with our/my long-ongoing discussion around 
stylesheets in general? As with SMuFL support, I think it's probably desirable 
to keep broader stylesheet mechanism(s) in mind.

> Now to the second approach, which I prefer.
> In this approach, \paper { fonts.music = "foo" } remains the syntax to select 
> an alternative music font.

I prefer this, too.

> If, next to the .otf font file, a file called stylesheet.ily (or another 
> bikeshed color) is found, it is read and defines the style parameters. 
> Because we want to be able to apply it both globally and locally to one 
> score/bookpart/book, we take it in the form of a \layout block. To do that, 
> we read stylesheet.ily with ly:parse-string-expression. That is, in exactly 
> the same way as the content of #{ ... #} is read. For the stylesheet.ily 
> writer, this means that the file is written as a single \layout block (plus 
> perhaps a \version statement).
> 
> If in the future we support SMuFL, we'll also read the JSON metadata and 
> synthetize a layout from it, then use it in the same way. stylesheet.ily 
> would continue to be supported and could be used to define styles that SMuFL 
> doesn't allow.

How modular and adaptable will that be? In a robust stylesheet system, there 
would be “inheritance”, “cascading”, etc., rather than the “include and 
overwrite” that happens with [ad-hoc] stylesheets now.

> For this reason, I lean towards a -dfont-path option, similar to -I but for 
> font directories, and scanned recursively.
> 
> The downside, of course, is that we'll need to wait until a Frescobaldi 
> update implements a graphical way to add font directories, like include 
> directories, for this become a really seamless experience. (I would be 
> willing to contribute that in Frescobaldi.)

There are lots of things we get in Lilypond that don’t show up in Frescobaldi 
for a while, so this is a trivial “downside”.

Thanks,
Kieren.
__

My work day may look different than your work day. Please do not feel obligated 
to read or respond to this email outside of your normal working hours.

What music font packaging/selection experience do we want?

2023-04-21 Thread Jean Abou Samra

Hi,

With [!1957](https://gitlab.com/lilypond/lilypond/-/merge_requests/1957) that
will soon become ready, I think it's about time to discuss how we want the “big
picture” user experience and font developer experience to be with respect to
alternative music fonts.

For those who haven't followed the (long) story, this MR basically lets
LilyPond search for music fonts in the same way as it searches for text fonts.
It thus makes it possible to make music fonts found with
`ly:font-config-add-font` or `ly:font-config-add-directory`, in contrast to the
current approach where you have to drop them into directories that are normally
supposed to be internal to LilyPond (and therefore re-add them with every new
LilyPond version). This lays the internal foundation for a better user
experience of using alternative music fonts.

While LilyPond doesn't support SMuFL right now, it's very desirable to have
that in the medium term and I think it makes sense to keep it in mind for
designing this — at least, to avoid making changes that will complicate it.

Now, from the user point of view, the question is how we want to organize the
UX of using an alternative music font:

1. Download the font: from where? Are some alternative fonts preinstalled with
our official binaries? This would deserve a thread of its own and I won't
discuss it here.

2. Install the font: how?

3. Use the font in a .ly file: how?

For (3), the basic way to select a music font is

```
\paper {
fonts.music = "whatever"
}
```

The main issue is that this only switches the glyphs themselves. However, to
look good, there are also other style adjustments to make in order to match the
font, like the thickness of stems and staff lines, etc. We want to have a way
to select a font *and* make those adjustments automatically at the same time.

I can see two approaches.

The first one is to keep doing what has been done so far: define include files.
For an example, see

[https://github.com/OpenLilyPondFonts/lilyjazz/blob/master/stylesheet/lilyjazz.ily](https://github.com/OpenLilyPondFonts/lilyjazz/blob/master/stylesheet/lilyjazz.ily)

In that perspective, the font `.otf` file can be put next to the include file,
and it can do something like

```
#(ly:font-config-add-directory (dirname (car (ly:input-file-line-char-column
(*location*)
```

which registers the directory of the include file as a font directory.

This is a workable approach. There are at least two reasons why this is
suboptimal, though.

The first reason is subjective: I would prefer if the way to select alternative
music fonts was uniform with text fonts, i.e., with `\paper { fonts.music =
"..." }`. Also, the include file would have to be `\include`d inside `\score`
blocks to make the font change local to one score. I'm not very fond of this.
See [!1929](https://gitlab.com/lilypond/lilypond/-/merge_requests/1929) for
some discussion of this practice.

The second reason is related to SMuFL. We want people to be able to take
advantage of any SMuFL font downloaded from a random place on the Internet, and
not require that every font come with a LilyPond include file to be usable with
LilyPond.

With SMuFL, there is a JSON file next to the font, which contains, among other
things, an `engravingDefaults` structure.

[https://w3c.github.io/smufl/latest/specification/engravingdefaults.html](https://w3c.github.io/smufl/latest/specification/engravingdefaults.html)

So we'll also eventually want to read that. But it's obviously much more
limited than the full range of things you can customize in LilyPond.

Now to the second approach, which I prefer.

In this approach, `\paper { fonts.music = "foo" }` remains the syntax to select
an alternative music font.

If, next to the `.otf` font file, a file called `stylesheet.ily` (or another
bikeshed color) is found, it is read and defines the style parameters. Because
we want to be able to apply it both globally and locally to one
score/bookpart/book, we take it in the form of a `\layout` block. To do that,
we read `stylesheet.ily` with `ly:parse-string-expression`. That is, in exactly
the same way as the content of `#{ ... #}` is read. For the `stylesheet.ily`
writer, this means that the file is written as a single `\layout` block (plus
perhaps a `\version` statement).

If in the future we support SMuFL, we'll also read the JSON metadata and
synthetize a layout from it, then use it in the same way. `stylesheet.ily`
would continue to be supported and could be used to define styles that SMuFL
doesn't allow.

This leaves with the question of how font files are found and where they are
installed. We don't really want users to need `#(ly:font-config-add-directory
"/home/me/...")` in every file with a custom music font.

1 2 >

1 - 100 of 105 matches

Mail list logo