Re: GSoC 2017

[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.
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.

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.