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.
The code predated the introduction of bold variants, so it was
significantly incorrect. Also it appears that some software uses the
PANOSE classification to distinguish monospaced fonts. After careful
study of the specification, I think all the variants of Bedstead can
be classified as text fonts, so I've removed the code that described
some variants as decorative. Then I did some calculations and a lot
of playing around with GeoGebra to work out which parts of the design
space give which values of Stroke Variation, Letterform, and Midline.
At least Noto Sans and Noto Sans Symbols2 think that EM SPACE should
be the same width as mosaic graphics characters, and I think we could
do with a space that doesn't get changed by 'palt'.
I'm a bit uncertain about this because I currently think these glyphs
shouldn't be in Bedstead at all. They're not based on any real system
or standard, so they don't really have any good reason to be here.
But here they are nonetheless, at least until Bedstead 003.000. So
while I don't really want to encourage their use, I think gratuitously
leaving them difficult to use will just annoy anyone who actually has
a use for them and they thus deserve encodings.
That is, not generating aliases at all, becuase that's simpler and
actually makes the OTF file smaller. Which makes me wonder if all
aliases should be done the same way, leaving FontForge to
automatically factor out common bits.
All the *.sep6 glyphs are now aliases for their proper Unicode 16
names. And the 6-cell mosaic graphics are now in the section for
glyphs from real character generators, because that's what they are.
A character can't both be an alias and have its own bitmap data, so we
may as well overlap them. Wrapping them in a union doesn't require any
changes to the syntax of the glyphs array because C allows for
incomplete bracketing of initialisers. Because the union doesn't have a
name, its members can be accessed as though they're members of the
containing struct, which means that accesses to them don't need to
change.
There is a new flag to mark a glyph as an alias since "alias_of == NULL"
no longer works, and a corresponding change to the ALIAS() macro.
This saves about 20K of bedstead's data segment on a 64-bit system,
which is kind of silly but it's satisfying nonetheless.
FontForge has opinions about what order glyphs in an OpenType font
should appear in, at least some of them being mandated by the OpenType
spec (for instance that .notdef must by glyph 0). When outputting an
OpenType font, FontForge re-orders it in accordance with these opinions.
I expect that this will be a problem if I want to emit a table that
FontForge doesn't understand, since it won't be able to correct the
glyph indexes in that table. Thus I've added code to re-order the
glyphs in Bedstead such that FontForge won't re-order them. This should
mean that bedstead.c can safely use the glyph indexes that it generates
without worrying that FontForge might change them.
I don't think FontForge minds what order unencoded glyphs appear in, but
I've defined them to be in strcmp() order of glyph name so that they're
at least somewhat stable. Before this, they were in the same order as
in the source file.
Bedstead claims to be written in ISO C. ISO C allows "int" to be only
16 bits wide, which is a bit of a problem. In fact, it's not much of
a problem because Bedstead mostly deals in small numbers. The main
exception is Unicode code points, which can exceed 16 bits.
To hopefully fix this, Bedstead now mostly uses "long" for Unicode
code points. The main exception is in the gklph table where that
seems a bit profligate on 64-bit systems so I've used int_least32_t
instead.
The fiddliest bits of this are around uses of printf(), which cares
whether it's being passed an "int" or a "long".
This is untested on an actual 16-bit system, but at least on a 64-bit
system it continues to produce correct results.
Specifically this changes the comments on IPA characters to refer to
them in lower-case even though the official names of these characters
are upper-case. I did this because it was annoying not being able to
tell the case of a letter from its comment.
In addition to their obviously distinctive national characters, the
SAA5051 and SAA5052 also change the shape of some standard characters
compared to the SAA5050. I had spotted some of these, but noticed
several more when using an actual SAA5051 in my Acorn System 3. The
unusual characters are apparently much easier to spot on screen than
in a datasheet.
Now, I think, we actually have the correct characters for each of
these chips. In many cases, they're the same as one another, and in
those cases I've aliased the glyphs.
The small-caps and 'rtlm' lookups now come before the stylistic sets.
This is appropriate because the former make changes to the semantics
of characters and so should take priority over mere stylistic changes.
'palt' comes last because it can only reasonably be applied to the
actual glyphs being rendered.
Almost no new glyphs, because the existing accented caps glyphs are
themselves small. I'm not quite sure which glyphs small caps need to
be visually distinct from, so for now I won't worry about that.
I liked the approach I took with 'rtlm' of putting variant glyphs next
to the standard ones in the glyph array. So I've tried doing the same
with small caps. Each small cap appears at least twice. For ones with
real Unicode code points, the 'c2sc' version is an alias for the native
one. For small caps without Unicode code points, the 'c2sc' version is
the actual small cap glyph. In either case, the 'smcp' version is an
alias for the 'c2sc' one. This is a change from the previous setup,
where the 'c2sc' version was an alias for the 'smcp' one instead. I've
swapped them because the small cap glyph is generally based on the full
cap, so putting them together seems sensible.
As far as I can tell, the "GaspTable" line that I put in the SFD file
has never actually worked. I don't think I want it to anyway: even
when the source pixels line up precisely with the display pixels, it's
still worth having anti-aliasing on the diagonal lines. And of course
none of this would work properly for any width other than the default
one.
So overall, it doesn't work, and if it did I'd want it to stop. So
let's remove it.
These are characters that have the Bidi_Mirroring_Glyph but don't
appear in the OpenType Mirroring Pairs List (OMPL). In a couple of
cases, these are listed by Unicode as "best fit" and I think I should
actually redraw the tildes the other way around.
