Re: GSoC 2020 update, June 15

[Werner LEMBERG]

>> Rather late in the week, I also came to the realization that, in
>> order to support *any* SMuFL font's optional features, I'll also
>> have to read its metadata JSON file if it has one, before
>> defaulting to its OpenType features if it doesn't.  (Thanks,
>> Werner, for guiding me through that business!)
> 
> if we're doing JSON anyway, you might want see if you can migrate
> the existing Scheme based table to JSON too.  The Scheme format is
> convenient because we already have a Scheme parser, but JSON is more
> fitting to the task.

Well, if we are going the JSON route with external metadata files I
think it isn't necessary to add LilyPond-specific SFNT tables (like
'LILY') to the font at all.  We can simply add one or more JSON files
that hold the LilyPond metadata.

I must admit that I'm not happy how the SMuFL people have solved the
problem.  It was always inconvenient in former times that, for
example, Type 1 fonts have to be accompanied with external metrics
files (ditto for TeX fonts), and it was a relieve for everyone that
TrueType (and OpenType) didn't need that.  Now we have external
metadata files again – not a single one, but a bunch of them...

As far as I can see, it is not possible at all to create
SMuFL-compliant OpenType fonts that hold all the data that is
contained in the JSON files.  If this my assumption is correct I
wonder whether it makes sense at all to add more OpenType support to
Emmentaler than the bare minimum to make it usable in a text
environment.


    Werner