simon-git: gonville (main): Simon Tatham

Sat Oct 28 11:34:12 BST 2023

TL;DR:
  606c285 New helper function, Curve.compute_nib_bounds.
  4ec6d4f New SMuFL-compatible output mode.

Repository:     https://git.tartarus.org/simon/gonville.git
On the web:     https://git.tartarus.org/?p=simon/gonville.git
Branch updated: main
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2023-10-28 11:34:12

commit 606c28552565082a9fbec9af6442ff79f19e0feb
web diff https://git.tartarus.org/?p=simon/gonville.git;a=commitdiff;h=606c28552565082a9fbec9af6442ff79f19e0feb;hp=0c75385d2992fd18b43ecf277a4a0bcaaf954b51
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Oct 28 10:49:10 2023 +0100

    New helper function, Curve.compute_nib_bounds.

    This allows me to query a point on the curve and determine not just
    the logical position there, but the bounding box of the pen nib when
    it reaches that point of the curve. Useful for computing the bounds of
    the actual ink at points on the curve, which I'm going to need for
    font metrics in the upcoming SMuFL output mode.

 curves.py | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

commit 4ec6d4f3b2cc85f31e03811aa3d55457e1e43d94
web diff https://git.tartarus.org/?p=simon/gonville.git;a=commitdiff;h=4ec6d4f3b2cc85f31e03811aa3d55457e1e43d94;hp=606c28552565082a9fbec9af6442ff79f19e0feb
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Oct 28 11:01:49 2023 +0100

    New SMuFL-compatible output mode.

    This change adds a new version of the Gonville font files,
    compliant (at least in a 'first draft' initial sort of way) with the
    'Standard Music Font Layout' or 'SMuFL' specification, so that any
    SMuFL-supporting scoring application can use Gonville.

      https://w3c.github.io/smufl/latest/

    The new mode works a lot like the existing Lilypond mode, in that it
    has a big table of Gonville's internal names for glyphs, the desired
    encoding and glyph name in the output font, and information about
    where the origin wants to be. But it's a lot simpler, because SMuFL
    doesn't want any of Lilypond's extra metadata tables, so we _only_
    specify the glyph's real origin, and not extra stuff for the LILC
    table.

    In SMuFL, the primary lookup clients will use is the Unicode code
    point. (SMuFL is basically a standardised mapping of the Unicode
    private use area for music scoring applications to agree on.) The
    glyph names are taken from the SMuFL spec, but I only expect them to
    be used mnemonically, e.g. when looking things up in Fontforge, or
    searching for the relevant record in the source table.

    SMuFL has totally different ideas about where glyph origins ought to
    go compared to Lilypond, so I had to rework a lot of the origin
    specifications, and even define a bunch of extra context variables in
    font.py for the purposes of smuflglyphlist pulling them out and using
    them. (For example, many ornaments with vertical slashes through them
    want to be registered so that the baseline would be at the bottom of
    the glyph if it _didn't_ have the slash. This required the new
    compute_nib_bounds function to work out.)

    SMuFL also has no truck with Lilypond's idea of having variants of the
    font that change the glyph shapes subtly with size. (Neither does
    Gonville, of course; it only pretended to for the sake of not
    confusing Lilypond.) So we can write a single gonville-smufl.otf which
    has the simple font name 'Gonville'.

    A lot of credit for this work must go to Rodrigo Vilar, who developed
    a downstream Python script to take the Lilypond-compatible version of
    Gonville and re-encode it for SMuFL compliance. This commit doesn't
    include any of that script's actual code, but constructing the
    'smuflglyphlist' array was made much easier by the machine-readable
    mapping table in that script. (Although I've done my own editing pass
    over the results, so the new font won't exactly match the previous
    downstream GonvilleSmufl.)

    SMuFL is a big specification, and describes a lot of glyphs that
    Gonville doesn't include. I don't think it's a realistic project for
    me to add all the rest in one go, but I hope that as people begin to
    adopt this font, they'll find out which missing glyphs are important,
    and let me know.

    Once this has had some testing, I'll mention it in README.dev and on
    the web page. For the moment, I'm just committing this to the source
    repo, and I'll pass the resulting files on to people who can do
    initial testing.

 .gitignore |   3 +
 Buildscr   |   8 ++
 font.py    |  50 ++++++++++++-
 glyphs.py  | 243 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 301 insertions(+), 3 deletions(-)