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.
This is roughly equivalent to moving rising edges one subpixel later,
thinning vertical and horizontal lines by one pixel. The actual shift
is slightly smaller to ensure that the points of "0" etc don't end up
crossing over themselves.
This requires choosing a CSS weight for the non-bold versions. I've
gone for 500, matching what we use in the OS/2 table. CSS's default
(and "normal") weight is 400, but the matching rules mean that you'll
get 500 if there isn't a 400 available.
Unlike other weights, "Bold" can be represented in the normal TTF
Family/Subfamily structure, so it should be put there. To avoid making
the single printf call for LangName unbearably complex, I've split it
into two, one for the case where the typographic family/subfamily names
(16/17) differ from the basic ones, and one for when they don't.
By having short names for the co-ordinates of the points we're
considering, we can make the conditions easier to read, which will
help as the conditions become more complex.
It now records how it wants to move each point and them actually moves
the points in a second pass. This avoids a problem where moving one
point would cause the loop not to correctly recognise the types of
adjacent points in the path. This in particular affected glyphs with
sharp upper corners (like &) with weights >= 50.
It's necessary to build the glyph complement, and I think the source
distribution should include everything necessary to build the binaries
in it. It doesn't need to include things that are only used for the
Web site, though.
