I realised that VAR2 can be a parameter to the various CVXX macros
instead. This makes the existing code a little more complicated, but
will make the code for the three-way choice of capital D less
confusing.
The macro names are getting worse, and will definitely need to be
rationalised at some point, bit the structure is getting better.
I was accidentally emitting a separate <AlternateSubst> element for
each base character, which worked but was unnecessary. A single
<AlternateSubst> for the whole lookup will make for a smaller font
file and probably faster lookups as well.
The inverted and reversed question-mark characters should obviously
change shape along with the normal one, so now they do. This
conveniently tests the 'cvXX'/'ssXX' interaction without getting
tangled up with small caps as well.
Based on the different shapes of the glyphs in the Unicode code charts,
I've decided that glottal stops should not change their shapes along
with question marks, and should perhaps be different shapes entirely.
In general, we want each Stylistic Set to be constructed out of a
collection of Character Variants. At the moment, this is fairly
simple, but if I start putting variants of more characters into these
features (for example, adding questiondown.open to go with
question.open), it will get awkward keeping them in sync. But the two
kinds of lookup want different XML, so they can't just be copied
as-is.
One approach would be to have a C data structure that gets used to
generate both sets of lookups, but an alternative is to extend the
existing pre-processor magic to use X macros to construct the two
lookups. This is what I've done.
At the moment, this is just using the existing macros that generate
XML, but driving them from another set of macros, one for each
Character Variant feature. The Stylistic Sets then invoke all the
macros for the Character Variants they include.
There are a couple of open problems. One is the (single, so far) case
where there are two variants of a character, namely 'D'. This should
be dealt with by paramaterising the variant macro, but I've not got
around to that yet. The other is that the macro names are largely
horrible.
The features that generate the variant ocircumflex and ccedilla glyphs
are now treated a being variants of lower-case 'o' and cedilla
respectively. Unlike the SAA5051/2 variants, we don't yet have
variants of their base glyphs. Indeed, for the lower-case 'o' we
probably never will, because the variant is "larger accented versions"
so the unaccented version wouldn't change.
I haven't done anything about the weird SAA5054 ugrave because I'm not
sure there's any real design principle behind it.
I've also added a comment explaining the numbering of 'cvXX' features.
The idea of these is that each one allows for choosing between different
variants of a single character (or set of closely-related characters).
This allows for deciding that you want (for instance) the angular
SAA5054 "ccedilla", but not its weird conjoined "ugrave".
This seems like a good way to handle chips like the SN74S262 where some
samples seem to vary in a single character from others, as well as more
generally for making the variant glyphs easily accessible for purposes
other than precise emulation.
At the moment, each feature only provides alternatives for a single
character, but now that we have a mechanism for it, that might change.
TTX is quite capable of inferring the lookup type from the type of the
main child element of <Lookup>. This should allow for specifying
different kinds of lookup using literal XML.
These substitutions are not generated from the glyphs table, but are
specified statically. Rather than taking a table and transforming it
into XML with C, we could just put the static XML in a string, which
is much simpler. To avoid excessive simplicity, the string is
generated by a pile of preprocessor macros.
This causes no change to the output OTFs.
These are just emitted after the standard AlternateSets, and because
of how TTX works, they end up overriding the standard ones. This
seems a bit dodgy to me, so I might try to do better later.
I just got an SAA5054 (date code 8510) and the character it has at 5/13
is different from the one in the datasheet. The real one lacks the
pixel in the bottom right corner, so it's more like a Ugrave than a
ugrave. However, it would be weird for a character set to include the
capital but not the lower case, and the corresponding character set in
ETS 300 706: May 1997 (the French option in table 36) is obviously
lower-case. So I think it's semantically lower-case, whatever it looks
like.
As for the thing I was intending to check, yes the accent does join onto
the letter.
This means that users of this stylesheet can use declarations like
"font-variant: styleset(saa5051)" to request a particular stylistic set.
The separated graphics sets, 'ss14' and 'ss16', are not covered by this
because new applications should use the proper Unicode code points for
separated graphics instead.
The old approach was that each stylistic set had a distinct glyph-name
suffix, the same way that small caps or right-to-left mirrored glyphs
did. This meant that when several chips used the same alternative
glyph, there needed to be a separate alias for each chip. This was
slightly awkward for just the SAA5051 and SAA5052, but I'd like to add
coverage for the SN74S262 and SN74S263, and those share some of the
same glyphs as well.
So now those stylistic sets have an explicit list of which variant
glyphs they include, and my plan is that each variant glyph will have
a single canonical name. They'll still have to keep the existing
names for compatibility. Indeed, for now that's what they're using
because that makes checking the output easier.
No change to the resulting font, though the lookups do end up in a
different order in the TTX file.
Every feature must have a scripts list, but "suffix" is only one way
you might select lookups to generate. Putting it at the end makes it
easier to leave it out. Indeed, our existing 'aalt' lookup omits it.
This causes no change to the generated fonts.
ISO C doesn't guarantee that the execution character set is ASCII, or
anything like it. Bedstead tries to require only ISO C, but it used
strcmp() to sort glyph names and so the output depended on the sort
order of characters. Moreover, the code for finding variants of
characters required that '.' have a lower value than any other
character that appeared in glyph names.
To avoid this dependency, we now have a table that assigns values to
each character that can appear in glyph names, and a strcmp-compatible
function that compares two strings after mapping through that table.
This means that our sort order is explicitly specified in the code,
and also provides a convenient place to catch unusual characters in
glyph names.
This change has no effect on the output TTX files (at least on an ASCII
system). All remaining uses of strcmp() are testing solely for
equality.
The corresponding members of struct vec are signed, as are most of the
arguments passed to the functions, so it's silly that the parameters
themselves are unsigned. This takes the number of warnings under
clang -Weverything down from 126 to 30.
This doesn't cause any change to the output TTX files.
[ from email ]
2. Regular unicode characters: a few additions, mostly to fill out
compatibility with Teletext character set ranges that were otherwise
almost-complete (which is basically everything except Arabic at this point)
per this reference page: https://al.zerostem.io/~al/ttcharset/[al.zerostem.io]
Some of the cyrillic additions are a bit dubious, but hopefully close enough
to pass.
