Safari badly misdisplays Bedstead in proportional mode. This is
caused by a bug in WebKit, and I haven't found an acceptable
workaround. Thus, I think the best thing to do is to turn off
proportional spacing on the Web page entirely. I think it looks nice,
but even I'll admit that it's a little too tight, and I know others
prefer the monospaced version.
Also, I can't think of a way that a real chip anything like the
SAA5050 could produce proportionally-spaced text. It's fundamentally
based on getting fed character data at a constant 1 MHz. There's no
way it can ask for a character early because the previous one was
narrow.
It's more compact and works just as well. In fact, I think it might
work better on browsers that support background-image but not
background-size. On such browsers the entire rule will be ignored,
which is what I want. If the background image can't appear at
precisely the correct size, it shouldn't appear at all.
Of course, ideally on a browser that fails to display the background,
the title also wouldn't fade out to the left. I wonder if there's a
sensible way to achieve that.
The "sizes" attribute on the icon <links> wasn't allowed by XHTML 1.0
Strict, so I've removed the DOCTYPE for that. Meanwhile HTML 5
doesn't want you declaring a <meta http-equiv="content-type">
specifying XHTML, so I've removed that as well. So now it's
XML-syntax HTML 5, which seems sensible to me even if other people
don't like XML.
HTML doesn't allow <div> inside <h1>. I found before that using a
<span> caused the background not to work. That seems to be down to CSS2
section 10.6.1, describing inline, non-replaced elements: "The height of
the content area should be based on the font, but this specification
does not specify how."
Happily, we can just define this particular <span> to be a block
element, so that it behaves like a <div> even though it's a <span>.
That works fine, and because we're only using it to get a well-defined
content area it doesn't matter if it's ineffective when the stylesheet
is missing.
The W3C HTML 5 checker objects to my use of "–" and I can't see
any reason why I should use it. The page is unashamedly in UTF-8, so
there's not much benefit to singling out this one character for special
treatment.
The page is still officially in XHTML 1.0 Strict at the moment, but I
might want to change that, which is why I'm paying attention to an
HTML 5 checker.
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.
