On Mon, Mar 6, 2017 at 1:42 AM, ul [via Lilypond] < ml-node+s1069038n200762...@n5.nabble.com> 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. _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
