[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GSoC 2020 update, June 15

From: Han-Wen Nienhuys
Subject: Re: GSoC 2020 update, June 15
Date: Tue, 16 Jun 2020 09:16:26 +0200

On Tue, Jun 16, 2020 at 9:06 AM Werner LEMBERG <> 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 - -

reply via email to

[Prev in Thread] Current Thread [Next in Thread]