Re: GSoC 2020 update, June 15

[Han-Wen Nienhuys]

On Tue, Jun 16, 2020 at 9:06 AM Werner LEMBERG <wl@gnu.org> wrote:
>
> >> 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...

They're putting the metadata in separate files? Given that TTF/OTF
have generic embedded tables, that is .. not the brightest idea. Maybe
we can just standardize on an embedded table ("ZIP " or something)
that holds a zip file with all files we want access to?

Isn't Smufl a standard proposed by the Dorico folks? We could try to
agree on a mechanism with them?

-- 
Han-Wen Nienhuys - hanwenn@gmail.com - http://www.xs4all.nl/~hanwen