GeezerVison

Nice one! I cannot really review the content, but do you know how cff-parts of the ttc behaves, e.g. #20870?

(Also, out of curiosity but maybe also usefulness, it may be nice to have some info-level logging of the conversion process.)

Do you think the overall strategy of parsing TTC, dumping TTF to the font cache is a good idea?

I guess that directly handling TTC is "better", but if the option is to not be able to handle TTC, this is for sure a very worthwhile approach!

I think it can be worth a user release note as users now can do things that they couldn't do earlier (and may not realize that otherwise).

Haven't checked the technical details of the approach, but if that can be made to work this may be one of the easier ways forward (we can always remove that later once "real" ttc support comes in, similarly to @oscargus' point above).

I cannot really review the content, but do you know how cff-parts of the ttc behaves, e.g. #20870?

As far as I can tell, the cff-tables are correctly extracted. The created TTF file, e.g. for Apple SD Gothic Neo, is valid in the font preview and font forge without warnings. However, the example from #20870 still doesn't work, probably failing in the pdf/ps backend.

it may be nice to have some info-level logging of the conversion process.

Good point, I will add that.

I was just looking at how to write this functionality! This is very brute force, we do currently support ttc, but only pick out the first font.

If users upgrade to a version that includes this change, it will only become effective once the font cache is rebuilt.

we have a version number on the font cache for exactly this reason (well in case we change the format, but close enough).

tacaswell@b143647 is a stack of changes that will find all of the fonts in a ttc and passes all but 1 test (which I think identifies that there is a bigger set of bugs in the way fonts + mathtext are being used....they are just not raising). This is on top of #20740 so won't cleanly cherry-pick to main. As @anntzer predicted, the hard part was not the c++ work, but in threading through the information that we have to identify fonts by (path, index) rather than just path. I took the "just break things" approach, not sure if we want to make a new internal API that we use everywere and leave the public API only half right, just accept the on-off breaking change, do terrible things and subsclass str (i'm only mostly joking), or make a new set of APIs with new names and deprecate the old ones (that is probably the best option).

The code is very ambiguous about treating FontEntry, FontProperty, str (that is a family name), str (that is a fontspec), str (that is the absolute path to a file) as "font" in the codebase so doing some refactoring to clarify that would also be good.

On a bit more consideration, adding public API to re-generate the font cache and install it in the correct global state would be good, however I am not sure that it is trivial to do reliably because we make a FontManager singleton and then expose its methods as module attributes.

We could replace those with free functions that then call the right methods, but I'm sure at least one of our users is trying to walk back up to the instance from the method, but that is probably an acceptable thing to break with no warning.

@sauerburger Sorry for high-jacking you PR with only marginally related side-tracks.

FWIW in mplcairo I specifically recognize when you pass a path that ends with #0/#1/... (hash-and-a-number) and reparse these as font indices into a ttc file (https://github.com/matplotlib/mplcairo#font-formats-and-features). Probably not the greatest API, but one that I came up with to support this in a backend without changing anything to core. Note that I likewise do something for selecting OpenType features (also documented at the link above); it's probably worth taking that use case into account if we're going to define a new cleaner API.

FWIW in mplcairo I specifically recognize when you pass a path that ends with #0/#1/... (hash-and-a-number)

I thought of doing fame:N as the pattern and decided to go with the tuples instead.

@sauerburger is this waiting on us, or on you? I've moved to draft, but feel free to move back if we should review.

Thanks for this PR; I'm going to close as it should be superseded by #30334.