Re: GSoC 2020: Shape-note notehead encoding

[Owen Lamb]

On Mon, Jul 20, 2020 at 8:25 PM Werner LEMBERG <wl@gnu.org> wrote:

>
> > [...] This will allow other programs to throw an error when, e.g.,
> > noteShapeKeystoneBlack isn't found in the font, notifying the user
> > that something's wrong.  If the correct styleset is used, the
> > program will correctly display every notehead in that style.  This
> > would probably require documentation so that Emmentaler users know
> > that the alternate styles are there in the first place.
>
> OK.  Are you going to implement the style sets as TrueType features,
> too?
>

Yes, I'm planning to do that as well.


> > A third solution is to request that the Funk and Walter systems be
> > encoded in SMuFL separately from the main set.  But of course that's
> > a tall order, and on top of that we'd force Emmentaler users to wait
> > until their program of choice updates to the new version of SMuFL,
> > if it ever does.
>
> Maybe it makes sense that you discuss that with the SMuFL people...
>

Yes--I'm hesitant to ask for completely new sets of glyphs, since our
Aiken/Thin/Funk/Walker sets are much more like stylesets than anything
else, but I definitely want to ask about particular glyphs we have that
they don't. SMuFL needs to define the following:

   - Whole noteheads separately from half noteheads (SMuFL only
   distinguishes between white, black, and doubleWhole),
   - A mirrored/reversed diamond-shaped notehead, and
   - Having moon (doFunk), arrowhead (reFunk), triangleRound (tiFunk),
   keystone (doWalker), quarterMoon (reWalker), and isoscelesTriangle
   (tiWalker) shapes in both left and right directions instead of in just one.

Are there any corpuses (corpori?) of shape-note repertoire that I can cite
for my proposal (perhaps what was once used to determine our own set)?

Thanks,
Owen