Table 22-5 in Unicode 15.0 lists a number of mathematical operators
that have been disunified from punctuation characters because in some
fonts they might look different or because they otherwise need
different handling. In some cases Bedstead only had a glyph for one
of the two characters. Now we have both in all cases. Here's what
happened in each case:
U+002D HYPHEN vs U+2122 MINUS SIGN: both already present and
different.
U+003F SOLIDUS vs U+2215 DIVISION SLASH: U+003F copied as U+2215.
U+005C REVERSE SOLIDUS vs U+2216 SET MINUS: U+005C copied as U+2216.
U+002A ASTERISK vs U+2217 ASTERISK OPERATOR: U+002A copied as U+2217.
U+25E6 WHITE BULLET vs U+2218 RING OPERATOR: new U+25E6 designed based
on U+2022 BULLET. It's identical to U+25AB WHITE SMALL SQUARE but I
think that's reasonable. Bullets represent a font's preference and
are likely to be identical to some geometric shape.
U+007C VERTICAL LINE vs U+2223 DIVIDES: both already present and
identical.
U+2016 DOUBLE VERTICAL LINE vs U+2225 PARALLEL TO: both already
present and identical.
U+003A COLON vs U+2236 RATIO: new U+2236 drawn one pixel higher than
U+003A.
U+007E TILDE vs U+223C TILDE OPERATOR: both already present and
different.
U+00B7 MIDDLE DOT vs U+22C5 DOT OPERATOR: U+00B7 copied as U+22C5.
Specifically halfwidth forms of characters where we already have
ambiguous versions. Bedstead is intrinsically a half-width font, so
the halfwidth forms should look the same as the ambiguous ones.
BQN wants U+27E8 MATHEMATICAL LEFT ANGLE BRACKET and U+27E9
MATHEMATICAL RIGHT ANGLE BRACKET in addition to the usual three kinds
of bracket and less-than and greater-than signs. I've come up with a
design that is at least visually distinct from all the others and
might be argued to be consistent with the way we represent oblique
lines in other characters (e.g. capital A).
I'mk a bit torn between this design and one that makes the circle the
height of a capital O, but this one is more consistent with out other
circles and jots.
There are several glyphs in Bedstead that are not encoded at standard
Unicode code points. In most cases this is because they're font
variants of other glyphs, and in one case it's a character that's
simply not in Unicode ("oldsheqel"). These can be accessed using
OpenType features or by glyph name, but not all applications make
those available or easy to use. Giving all the glyphs code points
makes them usable (albeit with some ugliness) in pretty much any
application.
The code points I've used are in the "Reserved for font hacks" range
in the ConScript Unicode Registry, which should minimise their chances
of colliding with other useful things.
Bedstead is now so large that Ghostscript 10.00.0 insists on subsetting
it (and telling us it's doing so) anyway.
This reverts commit 8371e8afb823e2e383e8a6cfcf0c7fc75907a674.
Ordinary roman typefaces make the diagonal of an N thick and the
vertical strokes thin, so I think it's entirely legitimate for the
diagonal to be the member that gets doubled even if that looks a bit
odd. That finally gets me the full double-struck alphabet.
One of these is used by BQN, but obviously if I'm going to have one I
should have all four.
According to Unicode document L2/07-004, "Proposal to add Medievalist
and Iranianist punctuation characters to the UCS", "The ideally formed
QUINE CORNER (U+231C-U+231F) has equal-length sides and sit at cap
height and on the baseline". I've tried to implement that here.
Specifically:
U+2E17 DOUBLE OBLIQUE HYPHEN
U+2E1A HYPHEN WITH DIAERESIS
U+2E1B TILDE WITH RING ABOVE
U+2E1E TILDE WITH DOT ABOVE
U+2E1F TILDE WITH DOT BELOW
U+2E22 TOP LEFT HALF BRACKET
U+2E23 TOP RIGHT HALF BRACKET
U+2E24 BOTTOM LEFT HALF BRACKET
U+2E25 BOTTOM RIGHT HALF BRACKET
U+2E32 TURNED COMMA
U+2E35 TURNED SEMICOLON
U+2E39 TOP HALF SECTION SIGN
U+2E55 LEFT SQUARE BRACKET WITH STROKE
U+2E56 RIGHT SQUARE BRACKET WITH STROKE
U+2E57 LEFT SQUARE BRACKET WITH DOUBLE STROKE
U+2E58 RIGHT SQUARE BRACKET WITH DOUBLE STROKE
U+2E59 TOP HALF LEFT PARENTHESIS
U+2E5A TOP HALF RIGHT PARENTHESIS
U+2E5B BOTTOM HALF LEFT PARENTHESIS
U+2E5C BOTTOM HALF RIGHT PARENTHESIS
U+2E5D OBLIQUE HYPHEN
This makes the masked object the same height as the containing
heading, which avoids the dark bars above and below it when on a
brighter display than mine.
The new title is a fade from a (manipulated) photo of the word
"Bedstead" displayed by my Beeb on a CRT monitor into the title text in
Bedstead Extended. The other visible tweak is to increase the left
margin so that the headings have some clearance from the left edge of
the window. At the same time, I've set the other margins explicitly to
the 8px that Firefox and Chromium use by default.
Generated from a photo using this command:
convert IMGP8893.JPG -crop 3200x1150+0+720 -scale 22.5%x25% \
-modulate 150,80 -quality 80 -strip titlebg.jpg
The correct underline position is (in my opinion) in the lowest pixel
of the character cell, in line with the descender of the "g". This is
where the BBC Micro's cursor is by default.
It turns out that there are two ways to specify the underline
position: Type 1 fonts and AFM files specify the centre of the line,
while the OpenType 'post' table specifies the top edge ("for
historical reasons"). Experimentation demonstrates that FontForge's
"UnderlinePosition" uses the Type 1 definition and converts it to the
OpenType version as necessary.
"make all" shouldn't depend on things that aren't in the source
distribution, and now it doesn't. The images that are only used for the
Web site are now generated by a separate "all-web" target. I'm not sure
this is the right long-term approach, but it's good enough for now.
A couple of reasons. Firstly, being hosted externally it was an
unnecessary privacy leak. I could have included it in the
distribution (and thus hosted it myself), but it would have perversely
been the least free thing in there.
Secondly, its colours jarred with the rest of the page. If the button
were free, I could adjust its colours to match the rest of the page,
but it's not and changing its colours isn't allowed. I did wonder
about playing games with CSS filters, but that would be complicated
and not really in keeping with the spirit of the licence.
Given both of those, removing it seems like the simplest approach.
