[ from email ]
2. Regular unicode characters: a few additions, mostly to fill out
compatibility with Teletext character set ranges that were otherwise
almost-complete (which is basically everything except Arabic at this point)
per this reference page: https://al.zerostem.io/~al/ttcharset/[al.zerostem.io]
Some of the cyrillic additions are a bit dubious, but hopefully close enough
to pass.
Ghostscript 10.03.1 and later disable the "makeimagedevice" operator
when running under -dSAFER. Even --permit-devices='*' isn't enough to
get it back. The release notes say that makeimagedevice has been
removed entirely, but that seems not to be correct.
Instead, pass the destination filename to the bdf.ps program and have it
open the file itself. This avoids capturing Ghostscript's own
diagnostics in the output file.
A technique only slightly spoiled by the fact that nothing flags
obsolete characters yet, so it's actually marking every alias instead.
Still, it puts a nice diagonal bar across the affected characters
telling you to use a different one, which looks nice but may
obliterate the character rather _too_ effectively.
[ from email ]
One thing I wanted to query was the ZVBI mosaic graphics codepoints at
0xEE00 to 0xEE7F. The ZVBI code says (in lang.c):
" Table 47 G1 Block Mosaic is not representable
* in Unicode, translated to private code U+EE00 ... U+EE7F.
* (contiguous form has bit 5 set, separate form cleared)."
My reading of this is that the separated forms should therefore sit at
0xEE00-0xEE1F and 0xEE40-0xEE5F, with the contiguous forms at 0xEE20-0xEE3F
and 0xEE60-0xEE7F. This is indeed what the teletext1/2/4 fonts commonly
seen in teletext recoveries do; see for example
https://al.zerostem.io/~al/teletext/bbc1/1996-12-28-0008.1/100.html.
Bedstead maps these the opposite way around, however, and if you swap it in
on the linked page, all the contiguous and separated mosaics will swap
places.
I hadn't noticed that they're included in the Symbols For Legacy
Computing Supplement as well. Apparently they were part of the Sharp
MZ character set.
I've removed the Turkish code pages because I don't have letters with
breves yet. And I've removed the Latin-2 code pages because I haven't
come up with a good way to distinguish accented upper- and lower-case
'S'.
I don't think Bedstead has enough coverage of these ranges to consider
them to be "functional":
47: Dingbats
62: Alphabetic Presentation Forms
68: Halfwidth and Fullwidth Forms
69: Specials
88: Musical Symbols + Byzantine + Ancient Greek
89: Mathematical Alphanumeric Symbols
Having a way to specify that the half-brackets extend upwards but not
leftwards avoids all the rendering problems they were previously
suffering from. And I've spotted the VT100 scan-line characters,
which should be extended to the left but not upwards. Since the
middle scan-line is unified with a line-drawing character, they really
need to extend leftwards for symmetry, but extending scan-line 1
upwards would be a disaster.
So now there are two flags, JOIN_U and JOIN_L, to specify joining in
each direction. I've renamed the both-directions flag as JOIN,
because it's not just specific to line-drawing any more. I might
eventually want a JOIN_D to suppress hinting of the bottom edge of the
character, but I need to do some testing first.
It doesn't work quite properly: some characters hit the left side of the
character cell, so I might want to separate the joins-leftward and
joins-upward flags.
In XLFD terms, Bedstead is a "character cell" font, where every
character fits entirely within its cell (defined by advance width,
ascent, and descent). Bedstead Bold maintained this because it
thickened into the unused column to the left of each character.
However, combining the new continuous line-drawing with emboldening led
to bold line-drawing characters that extended beyond their character
cell. This led FontForge to make the SPACING property of the BDF file
"M" (for monospace) rather the "C".
This commit simply clips the X co-ordinate of points in a bolded
character at zero. That's safe because line-drawing characters are
guaranteed not to be doing anything diagonal in the left-most column.
This is slightly ugly, in that the bold characters aren't quite so
algorithmically derived from the non-bold ones, but in most cases
there'll be another line-drawing character to the left anyway.
This is done my duplicating the top row of pixels upwards and the left
column leftwards. This is analogous to what MDA and other IBMish
adaptors do to expand eight-pixel wide characters to nine pixels on screen.
By default, FreeType 2.12.1 prefers to move the middle stems of
characters like 'B' and 'e' downwards, which is ugly. By applying a
tiny tweak to the "hstem" commands for such stems we can persuade
FreeType to move them upwards instead. This wasn't a problem when we
were using FontForge because FontForge didn't use proper stem hints on
the baseline.
The weight-changing code in adjust_weight() depended on the direction
that outlines were drawn in, so when I changed the direction to match
that required by CFF, it started lightening the font when it should have
been boldening it. A lot of swapping "next" and "prev" has corrected
that.
The magic numbers -21 and -20 shouldn't be scaled when the width of the
characters changes. The easiest way to fix this is to switch to
calculating the hints in actual font units. Only now of course that
will get bold fonts wrong...
I think I added it because a lot of mathematical operators (like '+')
have their bottom edge there. But such operators don't really need
their bottom edges aligned: it's much more important that they should
have their proper shapes and should have their centre lines aligned.
This only slightly improves the rendering of '+' in FreeType 2.12.1:
it's still asymmetric but the asymmetry is in a better direction.
Moreover, some glyphs with descenders like "section" are substantially
improved.
