Re: GSoC Follow-Up

[Urs Liska]

Hi Ed,


Am 01.03.2018 um 05:01 schrieb Kieren MacMillan:
> Hi Ed,
>
> > I’d love to hear everyone’s opinions about doing a project with stylesheets, 
> > which seems to be the project I plan on applying with.  What would everyone 
> > want to see in the project?

I think I can piggy-back on Kieren's post to add some thoughts:

> Here are some thoughts (stream-of-consciousness):
>
> 1. I want to be able to arbitrarily mix and match styles, in any order, without 
> triggering conflicts and other problems. Currently in Lilypond, depending on 
> which order you set the global font size versus load a stylesheet, initial 
> settings can get overwritten/lost for what seems like no good reason. 
> Obviously, there has to be some sort of determination of precedence — I'm 
> assuming [like CSS] it would be cascading, and last-applied-wins.

One thing that may be challenging on a conceptual and implementational 
level is how to address and include style sheets.
I think we will want to have both public, shared, and local stylesheet 
"repositories".

A "style sheet repository" will have to have one fundamental property 
(presumably the "house" part of "house style"), with all the defining 
subcomponents (e.g. paper, score set-up, etc.) enclosed. I assume that 
the loading functions will look up that root directory and find their 
way down from there.
What I mean is, you could have local repositories (e.g. "client-1", 
"client-2"), then you could have repositories shared in a project and 
hosted on some Git servers, and finally I hope we'll have a 
community-maintained public library. Finally there may be components 
built into LilyPond itself.

We will need a reliable way to address any of these, "mixing and 
matching" without issues.

> 2. I would like graceful fallback options (cf. CSS font-family lists), so that 
> sharing stylesheets isn't a nightmare (e.g., if the person you share with is 
> lacking the font you call for). Currently in Lilypond, the fallback situation — 
> especially font-related — borders on catastrophic.

I've once worked on font handling, back in 2015, after Abraham added the 
possibility to use alternative notation fonts. Unfortunately I tried to 
fix two things at once, and one of these didn't work (for external 
reasons), with the result that none of it was actually integrated. I 
have just pushed a few of my local branches from then: 
dev/urs/font-selection, dev/urs/font-exists, and dev/urs/font-handling. 
You may have a look at these, but it may not be too much fun. As said 
they are quite old, and it didn't work to simply rebase them on the 
current master, so I didn't bother making that work.

I'm telling this because it might be useful to reconsider these things 
or at least some of them and include them in a project.

The first thing I tried (and IIRC actually succeeded with) is making it 
possible to load notation and text fonts individually instead of all at 
once. So you could, for example in a base file of a style sheet, load a 
set of fonts, and later in a user document change, say, only the sans 
font, without resetting all the other, text and notation, fonts.
I think this worked out quite well, and this would probably be a huge 
step regarding Kieren's with 1) above.

The second thing, which I should really have tackled independently, was 
trying to enable LilyPond to use notation fonts that are installed as 
system fonts (rather than loading it from its own installation directory).
IIRC I actually made this work - but only "work for me", for an annoying 
reason I had no control over, namely fontconfig's failure to fail.
If you ask fontconfig for a certain font it will *always* return a font 
and won't notify you if it didn't find the requested font. At least this 
was the case in 2015, maybe (hopefully) this has changed by now. This 
means if you ask fontconfig for "Adobe Garamond Pro" and this isn't 
installed it might return Times New Roman instead, or whatever it 
consideres the best match. More inconveniently, the fallback font may be 
different on another user's installation.
So my approach was to ask for a given notation font and fall back to 
Emmentaler if it isn't found. But instead fontconfig *did* return a 
font, but if "LilyJAZZ" isn't installed it could return you Arial 
instead. So the idea of an automatic fallback may make some use in 
*text* fonts but definitely not with *notation* fonts.

Llooking into this matter (maybe also by asking fontconfig for 
improvements or workarounds) is probably optional but might be a really 
useful enhancement to the project idea.

> 3. Naturally, Lilypond should use the new system "100% natively" (which is why 
> you’re on board), not as some sort of add-on that requires an additional library (e.g., 
> OLL).

But if there's anything in OLL that may be useful or required (from 
oll-core or the notation-fonts package) this can very well be moved into 
LilyPond as part of the project - if it meets the expectations of the 
reviewers community, of course.

Best
Urs

> That's it for now. If I think of anything else, I'll send another response.
>
> Best,
> Kieren.
> ________________________________
>
> Kieren MacMillan, composer
> ‣ website: www.kierenmacmillan.info
> ‣ email: address@hidden
>
>
> _______________________________________________
> lilypond-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/lilypond-devel