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.
"circleplus" is the AGLFN name, but it was called "uni2259" in
Bedstead 002.000 and 002.001, so the old name should stay for
compatibility, for instance with existing PostScript files.
The consequence of this is to narrow the diagonal strokes. They go
from being 6% wider than horizontal and vertical strokes to being 0.4%
wider. I like the consistency, but it also has a practical advantage:
at round pixel sizes the daigonal edges no longer pass through pixel
centres. This means that we're no longer at the mercy of rasterizer
tie-breaking rules so (for instance) Ghostscripts rasterizations are
symmetric now.
Since the shape of diagonal lines on a real SAA5050 is determined by
both edges of a clock whose duty cycle is only specified as being
between 0.4 and 0.6, I claim this is still within the tolerances of
the original.
