Am 06.03.2017 um 17:32 schrieb tisimst: > 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.
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 > lilypond-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-devel -- u...@openlilylib.org https://openlilylib.org http://lilypondblog.org _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
