Not cities, but capital versions of some letters we already had in
lower-case for IPA. Specifically:
U+0186 LATIN CAPITAL LETTER OPEN O
U+0189 LATIN CAPITAL LETTER AFRICAN D
U+0190 LATIN CAPITAL LETTER OPEN E
U+0196 LATIN CAPITAL LETTER IOTA
U+01B2 LATIN CAPITAL LETTER V WITH HOOK
Between them, Hyperglot thinks this gains us useful coverage of
languages with a few tens of millions of speakers, which seems like good
value to me.
The all also have small caps, and in the case of the African D all the
capital-D variants.
The International Phonetic Association's preferred sans-serif font
doesn't give this character a serif at the top left, so Bedstead
shouldn't either. Also the bottom-left corner of the letter is subtly
curved, so I've rounded off that corner a bit as well. The result is
more like the IPA's ideal and also easier to design a capital version
of.
Now all of the caps and small caps have a central peak four pixels
above the baseline, and all of the lower-case have a central peak
three pixels above the baseline. The outer arms vary as necessary to
accommodate accents and for small caps.
Hyperglot says these are needed for Welsh, and they're trivial to
draw.
There seems to be some confusion around the proper shape for small-cap
W in Bedstead; I should investigate this in more detail.
When generating hints for a symmetric glyph like 'v', it's helpful if
the hits are symmetric because that means that the hinted bitmap is
also likely to be symmetric. This is particularly visible on
Microsoft Windows where the version of 'v' before this patch ended up
horribly distorted when rendered at 20 ppem in Bedstead Condensed. To
try to avoid such horrors, we now select hints starting at the outside
edges of the character and working inwards, instead of going from left
to right or top to bottom. This means that where hints conflict,
we'll tend to choose the ones towards the outside edge of the
character, rather than towards the top or left.
This changes the hinting for 50 glyphs, but all in ways that look
superficially reasonable.
For more complicated characters we probably still want to think about
hint substitution, but that still scares me.
C23 marks asctime() as deprecated and it seems polite to keep up with
that. Using strftime() isn't noticeably more complicated: the "%c"
specifier does what we want and we don't get a spurious newline that
we have to remove again.
Microsoft Windows 11 pays some attention to counter hints, and the
results are disastrous. Specifically, at awkward ppem, characters
with counter hints end up one pixel smaller that characters without
them. That makes the counters the same size, and puts every
horizontal stem squarely on a pixel, but means that cap height is all
wobbly, which looks horrible. Additionally, some characters ('2' and
'3', at least) end up grossly distorted, with the top of the character
either stretched way above the character cell or squashed down to the
centre line.
Turning off the counter hints solves these problems. Windows does
then draw the 'B' with its centre-line below the centre rather than
above it, but that's not a regression from 002.009. As far as I can
tell, FreeType 2.12.1 ignores counter hints entirely. At least, the
output of ftlint at 11 ppem is the same before and after this change.
Vertical counter hints survive. They're also ignored by FreeType
2.12.1 (as are all vertical stem hints), but they seem to have a
broadly positive effect in Windows.
Rather than mucking about with errno, we can just take advantage of the
fact that on overflow, strtoull() is specified to return ULLONG_MAX,
which is guaranteed to be (much) bigger than the maximum
SOURCE_DATE_EPOCH that we can cope with. So our usual range check can
cope with overflow as well.
This seems to be necessary for the font viewer in MS Windows 11 to
consider the font to be valid. The semantics of this field are not
documented in the OpenType spec, but the Apple TrueType spec does at
least give an example. I've roughly followed Apple's example, putting
together the full name, version number, and build date that we already
have to hand and include in the font. Between them those should
uniquely identify reasonable builds of Bedstead fonts without adding
extra complexity or non-reproducibility.
I've never been comfortable with constructing or editing commit
messages that will appear under someone else's name, but on the other
hand I don't want to be forced either to use someone else's message
untouched or to remove their name from the "Author" field. Allowing
myself to make clearly-marked edits seems to be a good compromise, and
square brackets are a common way of marking edits and editorial
comments.
Now we don't make any assumption about being on a POSIX system, and
instead have our own implementation of gmtime(). This turns out to be
shorter than the comment explaining why the previous code was more or
less valid.
While I'm in the area, also fail if the year is after 9999, since
asctime() causes undefined behaviour in those cases.
That's a real cedilla, and hence gets the SAA5054 angular form. It's
also the last Latin letter with a cedilla that isn't blocked by
something else. At least, until Unicode adds a new one.
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.
