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.
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.
Instead, pass the destination filename to the bdf.ps program and have it
open the file itself. This avoids capturing Ghostscript's own
diagnostics in the output file.
A technique only slightly spoiled by the fact that nothing flags
obsolete characters yet, so it's actually marking every alias instead.
Still, it puts a nice diagonal bar across the affected characters
telling you to use a different one, which looks nice but may
obliterate the character rather _too_ effectively.
[ from email ]
One thing I wanted to query was the ZVBI mosaic graphics codepoints at
0xEE00 to 0xEE7F. The ZVBI code says (in lang.c):
" Table 47 G1 Block Mosaic is not representable
* in Unicode, translated to private code U+EE00 ... U+EE7F.
* (contiguous form has bit 5 set, separate form cleared)."
My reading of this is that the separated forms should therefore sit at
0xEE00-0xEE1F and 0xEE40-0xEE5F, with the contiguous forms at 0xEE20-0xEE3F
and 0xEE60-0xEE7F. This is indeed what the teletext1/2/4 fonts commonly
seen in teletext recoveries do; see for example
https://al.zerostem.io/~al/teletext/bbc1/1996-12-28-0008.1/100.html.
Bedstead maps these the opposite way around, however, and if you swap it in
on the linked page, all the contiguous and separated mosaics will swap
places.
I hadn't noticed that they're included in the Symbols For Legacy
Computing Supplement as well. Apparently they were part of the Sharp
MZ character set.
I've removed the Turkish code pages because I don't have letters with
breves yet. And I've removed the Latin-2 code pages because I haven't
come up with a good way to distinguish accented upper- and lower-case
'S'.
I don't think Bedstead has enough coverage of these ranges to consider
them to be "functional":
47: Dingbats
62: Alphabetic Presentation Forms
68: Halfwidth and Fullwidth Forms
69: Specials
88: Musical Symbols + Byzantine + Ancient Greek
89: Mathematical Alphanumeric Symbols
Having a way to specify that the half-brackets extend upwards but not
leftwards avoids all the rendering problems they were previously
suffering from. And I've spotted the VT100 scan-line characters,
which should be extended to the left but not upwards. Since the
middle scan-line is unified with a line-drawing character, they really
need to extend leftwards for symmetry, but extending scan-line 1
upwards would be a disaster.
So now there are two flags, JOIN_U and JOIN_L, to specify joining in
each direction. I've renamed the both-directions flag as JOIN,
because it's not just specific to line-drawing any more. I might
eventually want a JOIN_D to suppress hinting of the bottom edge of the
character, but I need to do some testing first.
It doesn't work quite properly: some characters hit the left side of the
character cell, so I might want to separate the joins-leftward and
joins-upward flags.
In XLFD terms, Bedstead is a "character cell" font, where every
character fits entirely within its cell (defined by advance width,
ascent, and descent). Bedstead Bold maintained this because it
thickened into the unused column to the left of each character.
However, combining the new continuous line-drawing with emboldening led
to bold line-drawing characters that extended beyond their character
cell. This led FontForge to make the SPACING property of the BDF file
"M" (for monospace) rather the "C".
This commit simply clips the X co-ordinate of points in a bolded
character at zero. That's safe because line-drawing characters are
guaranteed not to be doing anything diagonal in the left-most column.
This is slightly ugly, in that the bold characters aren't quite so
algorithmically derived from the non-bold ones, but in most cases
there'll be another line-drawing character to the left anyway.
This is done my duplicating the top row of pixels upwards and the left
column leftwards. This is analogous to what MDA and other IBMish
adaptors do to expand eight-pixel wide characters to nine pixels on screen.
