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.
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.
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.
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.
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.
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.
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.
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.
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.
Apparently I didn't know about chained comparisons when I wrote this
code, so I didn't take the opportunity to write '0 <= x < limit'.
Also, removed the wildcard import from tkinter, replacing it with
explicit references to the things needed. There weren't that many of
them, so I think the 'import *' didn't gain much.
Apparently I was incredibly lazy at some point in the past and forgot
to say what the problem was when the paste data couldn't be matched
against the regex.
Previously the editor just expected to find it in your cwd. Now by
default it looks in the same directory as its own script, which means
you can run it from some other directory.
Also, I've provided a command-line option to override the default, in
case you keep the executable somewhere else again.
