On Mon, Jun 15, 2020 at 4:00 PM Owen Lamb <[email protected]> wrote: > > Hi all, > > Apologies for the lateness of this update. Last week was mostly research > into stylistic alternates and how to support OpenType features in a SMuFL > font, so not much was done in the way of code changes aside from creating a > proof-of-concept stylistic alternate mapping. >
The update may be formally late, but you had conversation on the list last week, so I don't see any problem. <snip> > > So, my game plan for this week is as follows: while I correspond with > HarfBuzz, I will generate a JSON file for Emmentaler. Then, I will have > open-type-font.cc try to load a font's JSON file, and if that fails its > GSUB table, into some sort of Scheme object (perhaps an alist?), which can > then be read (or written--who knows if a user might want to mess with font > metadata!) by LilyPond. I will probably need to create another > font-specific Scheme alist so that specific font features, such as > ligatures, alternates, or style sets, can be turned on or off at any point, > telling HarfBuzz (or whatever glyph-replacing method we go with) which of > them to use at any given moment. I think that you should use a hash table, rather than an alist. As I understand it, you'll be creating it once, and accessing it many times. The extra computation to create a hash table will be repaid many times over in the lookup. > > (A SMuFL font's metadata file also includes settings such as staff line > thickness, etc. for drawing primitives in their correct proportions, so > I'll eventually need to make LilyPond respect those as well. But one step > at a time!) > > Once again, if you have any worries/suggestions, please let me know. I plan > to send my next update on time, on Friday. > Thanks for your good work. I'm excited to see this happening! Carl
