Turn on the ForceBold flag for bold fonts

As far as I can tell, FreeType ignores it, but I may as well turn it
on in case something pays attention.

Slightly ugly hack to bias middle stems upwards

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.

Fix vertical stem hints on bold condensed fonts

The weight needed to be adjusted to allow for the change in width.

Correct bold outlines

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.

Fix left and right edge hints at non-default widths

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...

Quell a few compiler warnings

Remove glyph footprint comment from XML output

It was only there for debugging and isn't generally helpful.

An idea about version numbers

Support cntrmask and hintmask operators in editor

Skip XML comments when reading charstrings in editor

Emit cntrmask operators

Counter-mask support in select_hints()

It detects evenly-spaced runs of at least three stems, which is a
surprisingly fiddly thing to code.

Use self-explanatory constants to specify alignment zones

This adds ALEFHEIGHT for the height of Hebrew letters.

Remove lower alignment zone at +1 pixel

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.

More-or-less functional edge hints

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.

Support for edge hints in select_hints()

Which demonstrated plenty of bugs in the code generating them.
Currently edge hints only appear in a helpful comment.

Process pixels in raster order

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.

Reverse (almost) all the paths

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

Switch hhints loop in emit_hints() so it counts forwards

Now that it only touches the input array once, it's much simpler to do
the y-axis inversion there.

Some infrastructure towards edge hints

There are places to record them now, but they're ignored by
select_hints() and emit_hints().

Separate selecting usable hints from emitting them

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.

Change version number so pre-release fonts are distinguishable

Correct baseline of BDF fonts

Pass --no-recalc-timestamp to TTX

Without that, it updates the "modified" field in the 'head' table,
which makes builds unreproducible.

Emit OpenType tables in a more logical order

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.

Update Web page for new generation procedure

Correct cap height in font headers

Put version number in glyph complement PDF

Now that we've got the version number in a constant, this is
convenient.

Extract version number from C file, not nonexistent SFD

Correct ordering of stem hints

The spec for Type 2 charstrings requires that all hstem hints must
occur before all vstem hints.

Ignore stem hints in editor

Though it would be neat if it could display them.

Add .DELETE_ON_ERROR target to Makefile

That ensures that output files of a rule get properly deleted if the
recipe fails, which is almost always correct.

Make the processing of SOURCE_DATE_EPOCH safe

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.

Support SOURCE_DATE_EPOCH

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.

Generate stem hints

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.

Use my own, officially assigned, achVendID

The assignment is recorded at
<https://learn.microsoft.com/en-gb/typography/vendors/>.

This branch is destined to be the next major version of Bedstead, so
it's a sensible place to make this change.

Constants for 'OS/2' achVendID and XLFD/BDF FOUNDRY

Have a defined constant for the family name "Bedstead"

All occurrences of the name in the OTF and BDF files are now derived
from that definition so that they can conveniently be changed together.

Very rough but apparently functional 'palt' support

Change TTXI etc macros to take XML tag name as a string

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.

Skeleton of GPOS support

Put single substitutions in the GSUB table

'aalt' feature implemented via TTX

Beginnings of 'GSUB' generation: a table of the lookups we need

This is now used to generate the 'name' entries for stylistic sets.

Clean up trailing whitespace in bedstead.c

Record proper left sidebearings in 'hmtx' table

That change was more invasive than I was expecting.

Move function declarations after structure declarations

Update editor to read Type 2 charstrings (in source form)

Now the editor displays something useful again.

Update comment on compare_glyphs_by_ffid()

It's not necessary any more, but it does seem to make the output file
smaller so it can stay for now.

Note that TTX overrides hhea.numberOfHMetrics

Adjust indentation of CFF XML

It's not perfect, but it's prettier.

Remove extraglyphs variable that's no longer needed

Don't emit unnecessary CFF DICT entries

In several cases, Bedstead uses the defaults, so there's no need to
mention them.

Remove newlines from charstrings in TTX output

This does make the file rather wide, but I think it also makes it
easier to find what you're looking for.

Create a subroutine for each aliased glyph

So both the original name and any aliases can then call the subroutine
instead.

Correct charstring stack accounting in emit_contour()

The first point doesn't count because it gets an rmoveto rather than an
rlineto.

Make aliases work again, inefficiently

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.

Put the charstring cursor in a local variable

Combine successive rlineto operators

In a Type 2 charstring, an rlineto operator can take up to 24 pairs of
co-ordinates, so most contours need only one rmoveto and one rlineto.

Don't emit first point of a contour twice

Type 2 charstrings implicitly close each contour with a line, so there's
no need for us to explicitly do so.

Emit 'CFF ' and 'hmtx' tables for TTX (mostly)

The left sidebearings in 'hmtx' are not set yet, and there are (of
course) no hints, but the glyphs are the right shapes.

cmap fixup

Generate 'post' table for TTX

Generate 'cmap' table for TTX

TTX currently refuses to compile it, but I suspect that's because the
font still has no glyphs.

Generate 'name' table for TTX

Macros for the common TTX pattern <foo value='bar'/>

That makes things a little less verbose.

Generate 'OS/2' table for TTX

Use constants for ascent, descent, etc

This way there won't be quite so many magic numbers in the font metrics.

Generate 'maxp' table for TTX

Generate 'hhea' table for TTX

Generate 'head' table for TTX

Minimal infrastructure for going via TTX rather than SFD

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.

Wibblings about version numbers

Fontmap is required by .bdf.ps files

Add DEFAULT_CHAR to BDF

Also sort properties into the order they appear in the XLFD spec.

Correct weight and width names in BDF

They shouldn't have leading spaces.

Add FACE_NAME property to BDF

Add FONT_VERSION property to BDF

Switch build system to generating BDF via PostScript

As far as I can see, the new BDF files are now as good as the
FontForge-generated ones.

Add support for choosing font size and weight in BDF generation

More BDF properties and a proper XLFD name

Rough Makefile bits for new BDF generation

Add rough support for generating BDF without FontForge

This is extremely silly, but it's actually quite functional and
surprisingly compact.  bedstead.c gains the ability to generate a
PostScript file that emits a BDF file rendering each glyph into an image
and then dumping the image in hex.

I still need to get the font metadata right, which is my main reason for
wanting to get away from FontForge, but that shouldn't be difficult.
And the Makefile needs to be updated to make this work properly.  But
the bitmaps are coming out correctly.

Use EXIT_SUCCESS and EXIT_FAILURE

This is a bit of C pedantry.  POSIX requires that an exit status of
zero is success and non-zero is failure, but the C standard says no
such thing.  Instead it provides EXIT_SUCCESS and EXIT_FAILURE.  Since
Bedstead aspires to work on non-POSIX systems, it should use the
defined constants.  Also removing magic numbers is a good thing.

Make it safe to call fullname_to_fontname() twice

Another capital esszett link

Map the .notdef character at U+F1FF

It should be the DEFAULT_CHAR in BDF, but that needs it to have an
encoding.  U+2395 APL FUNCTIONAL SYMBOL QUAD happens to look
identical, but I don't think I should rely on that.

Correct Wdieresis small-cap

Wdieresis.sc is obviously wrong: a capital shouldn't have an 'smcp'
mapping.  A 'c2sc' mapping for that character would also be wrong
because it's already squashed to fit under its accent.  On the other
hand, there should be a wdieresis.sc that maps to the upper-case,
because the characters are slightly different.

Wdieresis.sc is retained as a compatibility alias (for Wdieresis),
just in case.

SAA5050 reverse-engineering links

Add headings in NOTES

Move dot in Ldot and corresponding small cap leftwards

It should be centred between the uprights of the Ls, and that makes it
so.  Sadly, it's not possible to do the same for the lower-case.

Also add a relevant link to NOTES.

Some thoughts on UnitsPerEm

Explicitly set OS2Vendor to 'PfEd'

That's the default value that FontForge uses.  I'd like to change it,
but fontconfig makes it available to applications as "foundry" and I
somehow ended up with Emacs recording that in its configuration.  So if
I'm going to make that change I think it should go with a major version
bump.

But at least I can make sure it doesn't change unexpectedly and give
myself somewhere to make the change when it comes.

Stop dopalt() reading off the end of the character bitmap

Spotted by GCC -Warray-bounds.

Update editor to emit the new style of character bitmap

Switch to using string constants for character bitmaps

Future versions of C are likely to make octal integer constants
obsolescent.  Switching to something non-obsolete seems wise, and also
using octal character constants saves eight characters per line that I
can use for other things.

I did consider just using one character per row, but I think that might
be a little too hard to read.

Tidy up Creative-Commons-related verbiage in HACKING

Specifically, "declaration" is not a usual noun for CC0, and "Creative
Commons" isn't usually followed by "Corporation".

Add some SPDX-License-Identifier headers

In places where they don't get in the way.

Make co-ordinate systems more sensible

The SAA5050 character images appear at the bottom-right corner of the
character cell, with a blank pixel to the top and the left.  This can
be seen if you put am alphanumeric character and a mosaic graphics
character side-by-side, since mosaic graphics characters fill the
entire character cell.

However, when I first made Bedstead, I put the character images in the
top-right corner, and the co-ordinate system matched that.  When I
fixed this in 2013 (commit 7bea0c6fadc35de50ea08eb184d4b15a7b411ef3),
I just did it by adjusting the final transformation of the vector
co-ordinates, leaving all the internal co-ordinate systems intact.
This was visible when I added mosaic graphics, which had to be offset
by one pixel to compensate.

Now I've finally corrected the problem somewhat properly.  Pixel
co-ordinates count from (0,0) in the top-left corner of the character
cell.  Vector co-ordinates count from (0,0) in the bottom-left corner
and are offset to the baseline on emission.  The conversion between
the two forms is still weirdly spread all over the place though.

Update version to 002.009

This release is just to give the Debian build a more sensible base to
work from.