Consider "sites/all/fonts" folder support, or Libraries API support with Fonts sub-folder

Well, properly setting up a local font requires some user input, hence the GUI; but it indeed becomes tedious to repeat the same operation for multiple subdomains in a multisite installation.

However, there's a dilemma - either we somehow save related user input (CSS family names, weights) globally along the fonts themselves (and then any subdomain can modify global values and break the rest), or some user input still needs to be done for each subdomain.

A potential way out could be making something out of #1537748: Handle local fonts better with Features.

At a risk of taking this off-topic, I'd also like to note another potential solution for heavy users of local fonts would be a submodule for FontServ; that would take care of file format conversion, too.

Drave Robber is right that this is more complicated than just putting the files on the server. We'd either need to have a separate form to fill out all the metadata or put that in a text file and read it from there. Either way, this would be a lot of work, and it wouldn't make the process much easier. Also, local fonts isn't generally something you should be doing a lot, since it introduces both speed (dedicated font hosts are faster) and licensing (most web-licensed fonts are already hosted somewhere) issues. So if you're using so many local fonts that it takes a long time to upload them, you should probably look into hosted font alternatives. Because of all of that, I'm marking this as "won't fix."

That said, if someone wants to do some sort of bulk local font interface in a separate project, I'm happy to help explain the APIs beyond the documentation. I just don't think it's worth putting in the main project.

Also, FontServ haven't responded to my inquiry about maintenance status of the project, so I'll be looking into what can be done about #1537748: Handle local fonts better with Features.