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
PATCHES - Countdown for June 16th
Hello, Here is the current patch countdown list. The next countdown will be on June 18th. A list of all merge requests can be found here: https://gitlab.com/lilypond/lilypond/-/merge_requests?sort=label_priority Push: !168 Doc: improve NR 3.4.2 skipTypesetting subsec. - Valentin Villenave https://gitlab.com/lilypond/lilypond/-/merge_requests/168 !154 Inline MIDI templates into input/regression/midi/GNUmakefile - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/154 !151 Remove sponsors from webpage - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/151 !149 Augment predicate documentation, fix primary/secondary distinction - David Kastrup https://gitlab.com/lilypond/lilypond/-/merge_requests/149 !125 Drop lily-git - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/125 Countdown: !166 parser: use %api.pure instead of deprecated %pure-parser - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/166 !165 Website post-processing: Reindent to < 80 cols - Michael Käppler https://gitlab.com/lilypond/lilypond/-/merge_requests/165 !162 Remove unused file python/safeeval.py - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/162 !159 Spanner::fast_substitute_grob_array: fix int/vsize confusion - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/159 !158 Various Scheme cleanups - David Kastrup https://gitlab.com/lilypond/lilypond/-/merge_requests/158 !156 Disable Perl's hash randomization - Jonas Hahnfeld https://gitlab.com/lilypond/lilypond/-/merge_requests/156 !152 Make Transform more visible to Scheme - David Kastrup https://gitlab.com/lilypond/lilypond/-/merge_requests/152 !148 Fixes for release build with GUB - Jonas Hahnfeld https://gitlab.com/lilypond/lilypond/-/merge_requests/148 !147 Avoid scm_append_x for property values - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/147 !145 Add PDF bookmark support & multi-level TOC outline ability. - Valentin Villenave https://gitlab.com/lilypond/lilypond/-/merge_requests/145 !99 Use common pitchnames and glyphs alist for non-standard notations - Valentin Villenave https://gitlab.com/lilypond/lilypond/-/merge_requests/99 Review: !161 bracketify-stencil: refuse to add brackets to empty stencil - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/161 !157 Janitorial work: fix/update/add copyright headers. - Valentin Villenave https://gitlab.com/lilypond/lilypond/-/merge_requests/157 New: !167 Cast away type warning for Paper_column::rank - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/167 !164 Use cp to create out/ files from source - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/164 !138 footnote engraver fixes - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/138 Waiting: !155 Make CI test one file without GS API - Jonas Hahnfeld https://gitlab.com/lilypond/lilypond/-/merge_requests/155 *** Regards, James
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
