TTX doesn't actually care what order we emit tables in: it will always
put them into the recommended order. So I've made the order something
that works correctly and that doesn't look too silly in TTX's console
output.
And explain in excruciating detail why it's safe. It's only actually
safe on systems (like POSIX ones) where time_t is an integer type, but
I think that's good enough for me.
If set, it is used to set the "created" and "modified" fields in the
OpenType 'head' table. This means that builds of Bedstead can be
reproducible.
The current code just casts the "long long" interpretation of the
environment variable into a time_t. This is potentially undefined
behaviour, because time_t might be a signed integer type smaller than
"long long". But I can't find a way to properly range-check it. Even
in POSIX, where time_t is required to be an integer type, there
doesn't seem to be a constant that specifies its range.
These are generated from the glyph bitmap by a similar
pattern-matching arrangement that generates the outline. Then, like
emit_path(), there's an emit_hints() that turns them into valid
charstrings. The handling of overlapping hints could be cleverer: at
the moment we emit the leftmost-possible set of hints, but we collect
a histogram of where hints are needed so could instead emit the most
useful. Or even try to do hint substitution.
This makes the Bedstead Web page at 90% zoom much prettier than
before, but it's not as good as the FontForge auto-hinter managed.
Edge hints and counter hints will probably help.
Stringifying it from a C token may have been more compact, but it was
also quite confusing because those really weren't C identifiers and
everywhere else XML appears in strings.
This pulls the conditional that works out how to render a glyph into
it's own function, doglyph(), that also handles indirecting through
aliases. Later maybe we'll properly use subroutines to share the
charstrings for aliased glyphs.
bedstead.c outputs an utterly minimal TTX file containing no tables, and
TTX compiles it into a similarly minimal OTF. Which Ghostscript then
complains about.
FontForge is an impressive application, but it's not well-suited to
being part of a mechanical font-production pipeline. The SFD format is
weird and rather difficult to generate, and FontForge imposes rather
more of its own opinions on the output than I'd like.
TTX is a lower-level format, and while it's a little bit weird, most of
it's weirdness comes from being a faithful representation of the
structure of an OpenType font. Ideally I'd like something a little
higher-level, but a format that's too low-level is much easier to work
with than one that's too high-level. The obvious alternative is UFO,
which is very popular but looks like being a pain to generate from plain
C.
Looking to the future, I like the idea of a variable version of
Bedstead, and neither SFD nor UFO seems to support that very well. In
UFO's case, it seems that the convention is to create UFOs at various
points in the design space and then have a tool interpolate between
them, which seems wrong when they're all procedurally generated from the
same source. TTX will allow me to directly generate the variation
tables, if I can understand how they work.
