[Top][All Lists]

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

Re: Planned font-related changes

From: Jean Abou Samra
Subject: Re: Planned font-related changes
Date: Sat, 15 Apr 2023 01:16:12 +0200
User-agent: Evolution 3.46.4 (3.46.4-1.fc37)

A little update on this:

Le mercredi 05 avril 2023 à 02:29 +0200, Jean Abou Samra a écrit :
> As a follow-up to 
> [](
>  I thought it might be helpful for reviewers to explain how the somewhat 
> numerous changes I am submitting and preparing around fonts are organized and 
> interrelate.  
> There are several independent fronts:
> 1. Improving the part of the code that takes an alist chain and
> chooses the basic selection method for the font: simplifying,
> decoupling font families and font sizes. Basically,
> [!1888](
> [!1917](
> has an important follow-up (renaming 'feta to 'music) that was
> left out of !1888 because it was already large/complex enough.

This is completed now.

> 2. Make Pango font selection more flexible. The first step is
> [!1911](
> It depends on !1888, but only because there would otherwise
> be annoying merge conflicts; logically speaking, it is independent.
> There will be a second patch in this series to fix
> [#6539](

That second patch is 
[!1933]( Now 
follow-ups planned at the moment.

> 3. Improve how LilyPond searches for music fonts in the file system.
> Goals are issues [#6485](
> and [#6486](
> A prerequisite is 
> [!1903](
> There will be one or two more patches after that.

Actually there will be three patches or more. 
[!1938]( is a 
prerequisite that I submitted independently because it sounded trivial to do 
but actually revealed a Pango bug that has to be worked around in a non-trivial 

After this, I expect two more MRs:

- One to use a separate FcConfig for Emmentaler, to fix #6485,
- One to also use Fontconfig for Open_type_fonts, making their selection the 
same as Pango fonts, which should address #6486. It will make using custom 
music fonts possible with `#(ly:font-config-add-directory "/path/to/fonts")` 
just like you can already do with text fonts.

Possibly one more MR to add a command-line option for adding font directories, 
similar to `-I`.

> 4. Get rid of the font-encoding property to simplify the internals. This is
> [](
> [!1914]( is
> a prerequisite.

This turned out a bit harder than I expected, but should still be feasible. I 
plan to submit an MR when 
[!1940]( (which 
partly touches the same snippets) is close to ~"Patch::push".

> I have more ideas, mostly speculative; this is what is relatively settled at 
> the moment.

I have started looking a bit into merging Owen's GSoC work on SMuFL from 3 
years ago (which led to 
[!1944]( It's not 
super easy; I don't know yet if I'm ready to put in that work.

I'm also looking into using pangocairo for text rendering in the Cairo backend, 
which would be simpler than the current hand-coded integration with FreeType. 
I'm not sure yet whether this can be done efficiently without breaking the PS 
backend, though. It's also not quite clear to me if we can completely replace 
FreeType. We'll still need it in the foreseeable future for the PS backend, as 
we need it to get, e.g., PS font names, but pangocairo uses HarfBuzz, 
apparently sidestepping FreeType entirely. It seems that HarfBuzz has its own 
(more minimal?) API for operations like getting the outline of a glyph, which 
we could potentially use for skylines, and then the day we remove the PS 
backend, we wouldn't need FreeType anymore. Not sure if HarfBuzz is less 
desirable than FreeType for this task for whatever reason.


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

reply via email to

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