I thought repeat marks might be useful, and ended up doing a few others.
The repeat marks and clefs are based on the assumption that a five-line
stave fills the character cell and that you're using the clefs in their
most common position.
The OpenType spec isn't entirely confident here, but it seems to think
that name ID 16 is unnecessary if it's identical to 1, and it makes
sense to me that 16/17 should go together as a pair just like 1/2 do.
Without then, the feature doesn't work, and more surprisingly
FontForge puts the description of the feature into string ID 0, which
is meant to be the copyright notice.
On browsers that support Web fonts, it seems silly to still be using
images for displaying font samples. So I've tried to translate the
samples into HTML. The result is a bit of a mess, but it roughly works.
The images are still there, and the stylesheet tries to arrange that
they get used where appropriate, and that speech synthesizers don't try
to read the samples.
Emitting a separate "AlternateSubs2" line for each target doesn't work
properly, so we make a second pass over the alternates for the current
glyph, constructing a single "AlternateSubs2" line afer doing all the
"Substitution2"s.
The "separated graphics" flag is now in the "flags" field, rather than
in the character data, and the bits specifying which cells are painted
are now contiguous. Also the MOS flag is now called MOS6, to go with
MOS4. This makes the specification of the ZVBI code points more
complex, but cleans up the Unicode ones, which I think is appropriate.
On the way, I found that 'palt' was being applied to 4-cell mosaic
graphics and fixed that.
The shapes of the 4-cell mosaic graphics are based on an alternative
history in which Teletext adopted 4-cell graphics. It's obviously
reasonable that such a world would still have separated graphics, so
let's have them.
This makes me thing that the method I've used for flagging separated
graphics is silly, but that's a story for another commit.
While Unicode 13 added code points for 6-cell mosaic graphics, it
didn't specify any way to select separated vs contiguous graphics.
This differs fron ZVBI, which used differect code points for separated
and contiguous glyphs. This means that separated graphics must be a
matter of style, which is consistent with the way that they're
selected by a control character in Teletext.
In OpenType, implement this as a stylistic set, 'ss16', that replaces
the contiguous glyphs with their separated counterparts. I'm
reserving 'ss14' for the 4-cell equivalent.
There are Unicode code points for most Latin small capital letters, so
we may as well make our existing designs for them available under those
code points. The glyphs generated by the 'smcp' and 'c2sc' lookups are
now aliases for the canonical Unicode versions.
Now that we can have aliases, we can arrange that 'smcp' applied to
"a", and 'c2sc' applied to "A" give differently-named glyphs that have
the same appearance. This means that something attempting to generate
Unicode from PostScript will be able to properly distinguish them. It
also means that the SC flag can be removed and we can stop making
assumptions about case-mapping of glyph names.
This is done by making the new glyph contain only a reference to the
old one. While it's possible to have multiple Unicode code points
reference the same glyph, that's rarely what you want because it's
useful to be able to map back from a glyph name to a code point, and
obviously that requires that the glyph have different names when
accessed through different code points.
It was getting complicated to ensure that everywhere that needed a
glyph name correctly generated them: simpler to have the preprocessor
generate them once.
Now rather than linearly searching the list of glyphs, dolookup() can
do a binary search on a list of glyph names. This is faster, but the
code is currently very ugly.
This should have no effect on the OTF output, but it ensures that all
characters are properly encoded in BDF. It also corrects a technical
invalidity in our SFD files.
A typical Web browser support Web Fonts these days, so there's no need
to use an image for the purpose. The other images remain for now since
they're not really representing text.
