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.
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.
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.
"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.
