Re: GSoC 2020 update, June 15
On Wed, Jun 17, 2020 at 5:26 AM Owen Lamb wrote: > > On Tue, Jun 16, 2020 at 12:16 AM Han-Wen Nienhuys wrote: >> >> On Tue, Jun 16, 2020 at 9:06 AM Werner LEMBERG wrote: >> >> [...] Now we have external >> > metadata files again – not a single one, but a bunch of them... >> >> They're putting the metadata in separate files? > > > If they are, I'm not aware of it. The specification only mentions one > metadata file, [font name]-metadata.json. I guess you mean "they are using only one separate json file", but to me that is still one file too many. -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: GSoC 2020 update, June 15
On 6/16/2020 10:26 PM, Owen Lamb wrote: I wasn't sure what to say as to my "affiliation" with LilyPond and/or GSoC I've also had that feeling when interacting with other entities on behalf of the LilyPond. This has happened maybe twice. In the past, I've said something like "I am a volunteer doing research and testing for the GNU LilyPond project (lilypond.org, sheet music engraving software) and I'm working on [insert topic here.]" -- Karlin High Missouri, USA
Re: GSoC 2020 update, June 15
On Tue, Jun 16, 2020 at 12:16 AM Han-Wen Nienhuys wrote: > On Tue, Jun 16, 2020 at 9:06 AM Werner LEMBERG wrote: [...] Now we have external > > metadata files again – not a single one, but a bunch of them... > > They're putting the metadata in separate files? If they are, I'm not aware of it. The specification only mentions one metadata file, [font name]-metadata.json. There are a few other JSON files mentioned, but they are only reference files for SMuFL in general, which are not expected to be packaged with any fonts. On Tue, Jun 16, 2020 at 12:20 AM Urs Liska wrote: > If it fits into what they (this is also the www music notation > community group (https://www.w3.org/community/music-notation/)) see fit > for the way forward it is certainly possible to talk with them. > I just sent a message to the list with questions, but again it looks like there will be a delay. There was an option to sign up as a member, but I wasn't sure what to say as to my "affiliation" with LilyPond and/or GSoC... Thanks, Owen
Re: GSoC 2020 update, June 15
Am Dienstag, den 16.06.2020, 09:16 +0200 schrieb Han-Wen Nienhuys: > Isn't Smufl a standard proposed by the Dorico folks? Yes and no. Daniel Spreadbury spearheaded the effort while Dorico was developed. But it was originally conceived as an open standard. > We could try to > > agree on a mechanism with them? If it fits into what they (this is also the www music notation community group (https://www.w3.org/community/music-notation/)) see fit for the way forward it is certainly possible to talk with them. Urs
Re: GSoC 2020 update, June 15
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 - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: GSoC 2020 update, June 15
On Tue, Jun 16, 2020 at 12:00 AM Owen Lamb 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. -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: GSoC 2020 update, June 15
>> 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
Re: GSoC 2020 update, June 15
On Mon, Jun 15, 2020 at 4:00 PM Owen Lamb 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. > > 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
GSoC 2020 update, June 15
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. It appears that the HarfBuzz library, already a LilyPond dependence thanks to Pango, can read an OT font's table of features. I sent a help request to the HarfBuzz mailing list, but it appears not to have gone through yet, since I'm not a member of the list. Now that the weekend's over and my message still hasn't appeared on the HarfBuzz archive, I've joined the list and sent the message again. 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!) 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. (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, Owen
