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.
By default, FreeType 2.12.1 prefers to move the middle stems of
characters like 'B' and 'e' downwards, which is ugly. By applying a
tiny tweak to the "hstem" commands for such stems we can persuade
FreeType to move them upwards instead. This wasn't a problem when we
were using FontForge because FontForge didn't use proper stem hints on
the baseline.
The weight-changing code in adjust_weight() depended on the direction
that outlines were drawn in, so when I changed the direction to match
that required by CFF, it started lightening the font when it should have
been boldening it. A lot of swapping "next" and "prev" has corrected
that.
The magic numbers -21 and -20 shouldn't be scaled when the width of the
characters changes. The easiest way to fix this is to switch to
calculating the hints in actual font units. Only now of course that
will get bold fonts wrong...
I think I added it because a lot of mathematical operators (like '+')
have their bottom edge there. But such operators don't really need
their bottom edges aligned: it's much more important that they should
have their proper shapes and should have their centre lines aligned.
This only slightly improves the rendering of '+' in FreeType 2.12.1:
it's still asymmetric but the asymmetry is in a better direction.
Moreover, some glyphs with descenders like "section" are substantially
improved.
This gets me to the milestone where the new version isn't uniformly
worse than the old one when rendered by FreeType at 10.5 ppem (the
worst size I've found).
The big problem I still have is that letters with three horizontal
stems (like 'B') get their middle stem rounded down in this version
and up in 002.009. I think this is because FontForge generates and
edge hint and not a stem hint at the bottom of the character, which
also makes bottom stems rather fuzzy. This version gives sharper
stems, but the characters all end up looking top-heavy.
If we're imitating a CRT character generator, obviously we should
process pixels line-by-line, not column-by-column. But that means
writing "for (y ...)" before "for (x ...)" which isn't the instinctive
way I did it.
So now that's corrected and the Y loops are outside the X loops, which
should make any debugging output easier to follow. This has been
confirmed not to change FreeType rendering at 10.5 ppem.
Type 1 fonts (and by extension CFF fonts) are required to have their
outer contours go counter-clockwise. Bedstead has always generated
outlines clockwise and depended on FontForge to correct them. Now
they're generated counter-clockwise as is proper, which will be fine
until I decide I want TrueType outlines instead.
This makes no difference to FreeType's rendering at either 20 ppem or
10.5 ppem
Now there's a select_hints() function that decides what hints should
be emitted, and emit_hints() just handles putting those hints into a
charstring. I hope this will make each function reasonably simple.
Importantly, it means that select_hints() can be called twice, once
for horizontal stems and once for vertical ones.
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.
