Re: GSoC 2017

[Urs Liska]

Am 06.03.2017 um 17:32 schrieb tisimst:
> On Mon, Mar 6, 2017 at 1:42 AM, ul [via Lilypond] <
> address@hidden> wrote:
>
>>
>> Am 06.03.2017 um 07:44 schrieb Werner LEMBERG:
>>>>> Not yet :-)  I can only second what Urs said.
>>>> I think we (i.e. Abraham and you) should give Matthew some more
>>>> concrete pointers on where to start investigating.
>>> Can you send him our e-mail conversation regarding this topic?
>>> Currently, I'm abroad, not having time to do that by myself.
>> I'll see what is there - probably it's at least partially in German.
>>
>>>>> BTW, where are the current instructions to install a font compliant
>>>>> to the SMuFL layout?
>>>> What context are you talking about here?
>>> This context:
>>>
>>>   http://lilypondblog.org/2014/01/smufl-fonts-in-lilypond/
>>>
>>> I don't know whether this is still up to date.
>> Oh, me neither.
>> Joram?
>>
> While I think this background info is helpful, I don't believe it's really
> relevant beyond seeing which SMuFL glyphs are being substituted for the
> LilyPond ones.
>
> Here's what I see needing to happen to make SMuFL _really_ work with
> LilyPond:
>
> 1. Full revamp of LilyPond's glyph naming scheme so it coincides with SMuFL
> glyph names. The Metafont files would need to be adjusted for this.
> 2. Refactor LilyPond's glyph metadata subtables into the external SMuFL
> font metadata file (thankfully there are many similarities here...)
> 3. Refactoring everywhere a glyph or the embedded metadata (LILY, LILC,
> LILF subtables) is called (thankfully, they are all called by name and not
> code point so they're easy to search for) to use the SMuFL glyph names.
> 4. Provide a mechanism to load a _single_ 3rd-party font file since I think
> most SMuFL font designers will not take the effort to create optically
> sized ones like Emmentaler. Now, SMuFL does include a dedicated set of
> codepoints for the case where the user has a smaller staff next to the
> normal sized one so the smaller staff's glyphs _are_ optically sized, but
> no application that I know of (including Dorico) utilizes this at yet. It's
> not a bad approach since an engraver isn't likely to have more than two
> staff sizes in the same score, but I'm not sure it's the _right_ approach.
> I like LilyPond's idea of this better.

Of course it is good to have optical sizes - even if the vast majority
of LilyPond users may not even be aware of it. And it's not depending on
the number of different sizes in a score but already on a single staff
size. If you want to engrave a pocket score requiring very small staves
it's obviously better to have optical sizes that aren't simply scaled down.
So we should definitely use the optical sizes equally when font handling
is done by SMuFL, but (as you say) should be prepared that more or less
any other font won't have it. (None of your fonts have it, Abraham,
isn't it?).

> 5. (Optional) Create the "_Text.otf" version of the font files. They are
> intended to make including music glyphs in text easier, but I don't see any
> reason LilyPond would need to create these files.
>
>>> For LilyPond there *are* of course no such instructions yet, and
>>>> otherwise you can install them like regular fonts, it's then up to
>>>> the notation application to properly use it.
>>> Well, yes.  But music fonts are handled specially in lilypond...
> They are, but SMuFL is similar enough that it should be a fairly
> straightforward transition. I have to believe that Daniel Spreadbury
> borrowed a lot of ideas from the LilyPond handles fonts. The nice thing
> about SMuFL is that there are dedicated locations on all operating systems
> (Mac, Win, Linux) where the files are expected to be located, as explained
> in the SMuFL gitbook[1], so there should be no problem pointing to them.
> SMuFL fonts are installed in the system font folder just like any normal
> text font.

Here's a caveat (but I'm not sure if that relates to the GSoC project).
Some time ago I worked on a modified system to load the notation font
from system installed fonts too, which would substantially reduce the
amount of housekeeping when using alternative notation fonts. But I got
stuck at a well-meant but nasty behaviour of fontconfig that made it
basically impossible: fontconfig *always* returns a reference to a font.
This sounds good but is a real problem with notation fonts.

The idea behind that behaviour is that when an application requests a
font it *needs* a font, and when a particular font isn't installed in
the system there has to be a fallback font. The problem is that with
notation fonts it is totally unclear what an appropriate replacement
font is. What I wanted (and what is necessary) would be the information
that a requested font (e.g. LilyJAZZ) isn't available - then LilyPond
could explicitly fall back to Emmentaler. But instead fontconfig insists
on giving back *something*, so when LilyJAZZ isn't installed you may end
up with a score trying to typeset the noteheads with Comic Sans or Times
New Roman.

I think the implication for GSoC is: If we don't find a solution to fix
this issue (maybe fontconfig has been updated in the meantime, or we can
convince the developers to do something about it) we will probably have
to load the SMuFL fonts from the LilyPond installation directory just
like we do now.

Best
Urs

>
> Those are just some thoughts to keep the conversation going.
>
> Best,
> Abraham
>
> [1] https://w3c.github.io/smufl/gitbook/
>
>
>
>
> --
> View this message in context: 
> http://lilypond.1069038.n5.nabble.com/GSoC-2017-tp200631p200794.html
> Sent from the Dev mailing list archive at Nabble.com.
> _______________________________________________
> lilypond-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/lilypond-devel

-- 
address@hidden
https://openlilylib.org
http://lilypondblog.org