These are the remaining characters that Unicode calls "WITH CEDILLA" but
that the standard (and code charts) say should actually have a comma
below by default.
The Unicode code charts and all the fonts I have conveniently to hand
are agreed that the cedilla should be attached to the letter, usually
to the left leg. So now it is in Bedstead as well. This also allows
the body of the letter to return to its normal shape.
If I'm going to insist that U+0162 and U+0163 really have cedillas, I
should have their unambiguously comma-below versions, U+021A and
U+021B, as well.
According to Unicode 16.0.0 (chapter 7), U+0327 COMBINING CEDILLA is
ambiguous. It can mean an actual cedilla, but it can also mean a
comma below. This also applies to precomposed characters containing
it. Unicode recommends default forms for various letters and in
particular says that for D and T (upper- and lower-case) the comma
form should be the default.
However, Unicode now has a separate U+021A LATIN CAPITAL LETTER T WITH
COMMA BELOW and recommends its use for Romanian. So I think the
recommendation to render U+0162 LATIN CAPITAL LETTER T WITH CEDILLA with
a comma below is no longer applicable.
I have now updated Bedstead so that U+1E10 LATIN CAPITAL LETTER D WITH
CEDILLA is treated as having a comma below instead. In practice, this
just means that it's unaffected by 'cv96'
All references to capital letters above apply equally to the
corresponding small letters.
The OpenType spec (version 1.9.1) says, "The FeatureRecord array
should be sorted alphabetically by feature tag." Bedstead was instead
emitting them in the order in which they appeared in the gsub_features
array, which was determined by the order the lookups need to occur in.
In particular, the 'cvXX' lookups need to occur after the 'ssXX'
lookups so as to override them properly.
Fixing this required some care to keep all the indices straight, but I
think I've managed it.
This means that now each possible variant of a character covered by a
'cvXX' feature has a human-readable name. I don't know of anything
that uses these, so they're somewhat untested.
Bedstead's various glottal-stop characters were originally based on
its question mark, because that character looks a bit like a question
mark without a dot. However, while adding a Character Variant feature
for question marks I noticed that the glottal stop and question mark
in the Unicode code charts didn't match, which was why I left the
glottal stop out of that feature.
I've now also looked at the official IPA charts from the International
Phonetic Association, and it's clear that the glottal stop does not in
general match the question mark. In particular, the join between the
rounded section and the stem is often smooth in a question mark but is
always a right angle in the glottal stop. I've thus re-designed
Bedstead's glyphs to follow this pattern. I've also shortened the
crossbar on the glottal stop derivatives that have them, since that
seems to better match DejaVu Sans, which is the sans-serif font
preferred by the IPA.
This seems appropriate for something that wants to treat these as ASCII
glyphs with their ambiguous semantics.
This uses the existing apostrophe.curly, and also adds grave.curly (an
alias for quotereversed) and bar.broken (an alias for brokenbar). Of
course there are also 'cvXX' features to enable each one individually as
well.
Unicode takes the position that U+0027 APOSTROPHE is always a straight
apostrophe and is you want a curly one you should use U+2019 RIGHT
SINGLE QUOTATION MARK (or U+02BC MODIFIER LETTER APOSTROPHE but let's
not get into that here). Bedstead generally follows that, putting the
SAA5050 straight apostrophe at U+0027 and the SAA5055 curly one at
U+2019.
Older character standards, though, conflated those two and treated the
difference between them as one of font design. In particular, ETS 300
706: May 1997, "Enhanced Teletext specification" treats position 2/7 as
being the same character in all national sub-sets of the Latin G0
primary set. When coverting Teletext data to Unicode, ZVBI maps 2/7 to
U+0027 whichever national sub-set is in use.
This means that to faithfully display Teletext data in the way that an
SAA5051/2 would, Bedstead needs to interpret U+0027 as a curly
apostrophe. I have accomplished this by adding a new "apostrophe.curly"
alias and including that in the 'ss01' and 'ss02' Stylistic Sets. It
also, of course, gains a new Character Variant feature, 'cv07', so that
you can turn the curly apostrophe on and off independently.
This does cause me to wonder whether there should be a stylistic set to
map U+0020..U+007E onto the SAA5055 glyphs.
This collides with the small lower-case 't' of 'cv84' at U+0163 LATIN
SMALL LETTER T WITH CEDILLA, but I think all the combinations work. I
do currently have both "uni0163.small.angular" and
"uni0163.angular.small" to ensure that you can apply each stylistic
set with the opposing character variant. Maybe with more careful
interleaving I could get away with only one of those.
The indentation wasn't always correct, and made the C code ugly. I've
now found "xmllint --format", which does a better job, so I think it's
quite reasonable to stop trying to do it myself.
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.
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.
