mirror of
https://bjh21.me.uk/bedstead/.git
synced 2026-07-09 13:33:06 -04:00
350 lines
12 KiB
Plaintext
350 lines
12 KiB
Plaintext
Precise pixel layouts for mosaic graphics
|
||
=========================================
|
||
|
||
Based on a 6x10 grid of pixels:
|
||
|
||
............ 000000111111 ..0000..1111
|
||
......##.... 000000111111 ..0000..1111
|
||
....##..##.. 000000111111 ............
|
||
..##......## 222222333333 ..2222..3333
|
||
..##......## 222222333333 ..2222..3333
|
||
..########## 222222333333 ..2222..3333
|
||
..##......## 222222333333 ............
|
||
..##......## 444444555555 ..4444..5555
|
||
............ 444444555555 ..4444..5555
|
||
............ 444444555555 ............
|
||
|
||
Mosaic characters are not smoothed, and smoothing also doesn't apply
|
||
between mosaic characters and adjacent alphanumeric characters.
|
||
|
||
Reverse engineering
|
||
===================
|
||
|
||
https://stardot.org.uk/forums/viewtopic.php?t=21608
|
||
https://github.com/lanceewing/saa5050/
|
||
|
||
Character sets
|
||
==============
|
||
|
||
The SAA5050 series is generally compatible with the G0 primary
|
||
character sets defined by ETSI EN 300 706 V1.2.1:
|
||
|
||
SAA5050: Latin with English option
|
||
SAA5051: Latin with German option
|
||
SAA5052: Latin with Swedish option
|
||
SAA5053: Latin with Italian option
|
||
SAA5054: Latin with French option
|
||
|
||
SAA5057: Cyrillic (Russian)
|
||
|
||
There's no ETSI EN 300 706 character set that corresponds to the
|
||
SAA5055. The ETSI EN 300 706 Hebrew set is almost identical to the
|
||
SAA5056 set, except that the old Sheqel sign on the SAA5056 is
|
||
replaced by the new Sheqel sign in ETSI EN 300 706.
|
||
|
||
There appears to be an SAA5058, listed as "Afrikaans", but I haven't
|
||
found a datasheet for it and there isn't an Afrikaans character set in
|
||
ETSI EN 300 706.
|
||
|
||
ETSI EN 300 706 to Unicode mapping:
|
||
|
||
ETSI EN 300 706 just gives glyph images without names, so it's not
|
||
always obvious what the intended semantics are. ZVBI, the Zapping
|
||
teletext decoder has opinions on this in src/lang.c.
|
||
|
||
ZVBI uses quite a few bits of Private Use Area for characters that
|
||
aren't, or weren't, in Unicode, or where the author can't work out the
|
||
correct glyph:
|
||
|
||
U+E620..U+E67F Arabic G0 set
|
||
U+E720..U+E77F Arabic G2 set
|
||
U+E800 Turkish Lira "TL" symbol, 2/3 in the Latin Turkish subset
|
||
U+EE00..U+EE7F G1 Block Mosaics set
|
||
U+EF20..U+EF7F G3 Smooth Mosaics and line drawing
|
||
U+F000..U+F7FF Dynamically Re-definable Characters
|
||
|
||
ZVBI maps Greek G0 Primary Set position 5/2 to U+0374 GREEK NUMERAL
|
||
SIGN, but I think it's a tonos to go with a subsequent capital letter.
|
||
|
||
ZVBI doesn't have a proper mapping for Arabic characters, but maybe we
|
||
can.
|
||
|
||
0x20 0x0020
|
||
0x21 0x0021
|
||
0x22 0x0022
|
||
0x23 0x00A3
|
||
0x24 0x00A4
|
||
0x25 0x0025
|
||
|
||
0x40 0xFE94 # ARABIC LETTER TEH MARBUTA FINAL FORM
|
||
0x41 0xFE80 # ARABIC LETTER HAMZA ISOLATED FORM
|
||
0x42 0xFE92 # ARABIC LETTER BEH MEDIAL FORM
|
||
0x43 0xFE8F # ARABIC LETTER BEH ISOLATED FORM (also final?)
|
||
0x44 0xFE98 # ARABIC LETTER TEH MEDIAL FORM
|
||
0X45 0xFE95 # ARABIC LETTER TEH ISOLATED FORM (also final?)
|
||
0x46 0xFE8E # ARABIC LETTER ALEF FINAL FORM
|
||
0x47 0xFE8D # ARABIC LETTER ALEF ISOLATED FORM
|
||
0x48 0xFE91 # ARABIC LETTER BEH INITIAL FORM
|
||
0x49
|
||
0x4A 0xFE97 # ARABIC LETTER TEH INITIAL FORM
|
||
0x4B 0xFE9B # ARABIC LETTER THEH INITIAL FORM
|
||
0x4C 0xFE9F # ARABIC LETTER JEEM INITIAL FORM
|
||
0x4D 0xFEA3 # ARABIC LETTER HAH INITIAL FORM
|
||
0x4E 0xFEA7 # ARABIC LETTER KHAH INITIAL FORM
|
||
0x4F
|
||
0x50 0x0631 # ARABIC LETTER REH (final and isolated)
|
||
0x51 0x0630 # ARABIC LETTER THAL (final and isolated)
|
||
0x52 0xFEB3 # ARABIC LETTER SEEN INITIAL FORM (also medial)
|
||
0x53 0xFEB7 # ARABIC LETTER SHEEN INITIAL FORM (also medial)
|
||
|
||
0x5B 0xFE9C # ARABIC LETTER THEH MEDIAL FORM
|
||
0x5C 0xFEA0 # ARABIC LETTER JEEM MEDIAL FORM
|
||
0x5D 0xFEA4 # ARABIC LETTER HAH MEDIAL FORM
|
||
0x5E 0xFEA8 # ARABIC LETTER KHAH MEDIAL FORM
|
||
|
||
0x6B 0xFE99 # ARABIC LETTER THEH ISOLATED FORM (also final?)
|
||
0x6C 0xFE9D # ARABIC LETTER JEEM ISOLATED FORM (also final?)
|
||
0x6D 0xFEA1 # ARABIC LETTER HAH ISOLATED FORM (also final?)
|
||
0x6E 0xFEA5 # ARABIC LETTER KHAH ISOLATED FORM (also final?)
|
||
|
||
Misc
|
||
====
|
||
|
||
UK patent number 1343298 (filed 1971 by Mullard) describes the
|
||
character rounding technique used by the SAA5050.
|
||
|
||
FontForge's "Expand stroke" may be useful for converting single-line
|
||
font into something useful. A 50-unit circular pen generates Bedstead
|
||
Plotter. A 100×50-unit, 20° rectangular pen generates a surprisingly
|
||
good Bedstead Calligraphic.
|
||
|
||
Typography
|
||
==========
|
||
|
||
Typographers seem to like explaining how to design their languages'
|
||
unique letters:
|
||
|
||
Æ and æ:
|
||
https://medium.com/@frodefrodefrode/designing-the-letter-%C3%A6-862cffbe22b
|
||
|
||
Polish characters:
|
||
http://www.twardoch.com/download/polishhowto/
|
||
|
||
ẞ:
|
||
https://typography.guru/journal/capital-sharp-s-designs/
|
||
https://typography.guru/journal/how-to-draw-a-capital-sharp-s-r18/
|
||
http://cinga.ch/eszett/
|
||
|
||
ĿL and ŀl:
|
||
https://glyphsapp.com/learn/localize-your-font-catalan-punt-volat
|
||
|
||
Microsoft have their own suggestions:
|
||
https://docs.microsoft.com/en-gb/typography/develop/character-design-standards/
|
||
|
||
WebKit 'palt' bug
|
||
=================
|
||
|
||
As of 2024, Safari on Apple platforms mis-displays the Bedstead Web
|
||
page. The 'palt' feature is being mis-applied to U+0020 SPACE
|
||
characters. Most of them end up not being narrowed, but some instead
|
||
end up with negative width, as though different layers of the browser
|
||
are calculating the widths of spaces differently. The problem doesn't
|
||
appear to affect any characters other than spaces. Other characters,
|
||
including punctuation, get displayed correctly.
|
||
|
||
Adding a GSUB lookup that replaces space with a glyph with a smaller
|
||
advance width doesn't help: the new glyph is used, but with the
|
||
original glyph's width. Replacing each U+0020 SPACE with U+00A0
|
||
NO-BREAK SPACE followed by U+200B ZERO WIDTH SPACE leads to all the
|
||
spaces' being too wide, but consistently so without any overlaps.
|
||
|
||
This bug appears to be https://bugs.webkit.org/show_bug.cgi?id=236307.
|
||
|
||
Choice of design unit
|
||
=====================
|
||
|
||
Bedstead uses a design unit of 1/1000 em, largely because that's
|
||
traditional for PostScript fonts. But that does have some problems,
|
||
and in particular depends on being able to encode arbitrary rationals
|
||
in CFF fonts, which means that odd widths end up with significantly
|
||
larger font files.
|
||
|
||
So what are the constraints on design units if we want to get more
|
||
integers in the output? Assuming we can tweak XQTR if we need to.
|
||
|
||
UnitsPerEm must be a multiple of 10 for vertical pixels.
|
||
|
||
But horizontal pixels vary in width by factors of 1/8, so must be a
|
||
multiple of 80.
|
||
|
||
XQTR and YQTR want to be about (UnitsPerEm / 10) * (1-1/sqrt(2)).
|
||
That's about (UnitsPerEm / 10) * 0.29289321881345254.
|
||
|
||
XML silliness
|
||
=============
|
||
|
||
Not sure if these are a good idea, but they're fun:
|
||
|
||
#define XML_FOR_O_I (outer, init, test, step, inner) \
|
||
for (xml_open(outer), (init); \
|
||
(test) ? (xml_open(inner), true) : (xml_close(outer), false); \
|
||
(step), xml_close(inner))
|
||
#define XML_FOR_I (init, test, step, inner) \
|
||
for (init; \
|
||
(test) && (xml_open(inner), true); \
|
||
(step), xml_close(inner))
|
||
#define XML_FOR_O (init, test, step, inner) \
|
||
for (xml_open(outer), (init); \
|
||
(test) || (xml_close(outer), false); \
|
||
step)
|
||
#define XML_IF (test, inner) \
|
||
XML_FOR_I (bool _done = false, !_done && (test), _done=true, inner)
|
||
#define XML (elem) XML_IF(true, elem)
|
||
|
||
Version numbers
|
||
===============
|
||
|
||
Up until version 002.009, Bedstead's version numbers took the form of
|
||
two dot-separated three-digit numbers with leading zeroes.
|
||
|
||
The example fonts in "Adobe Type 1 Font Format" (version 1.1) have
|
||
version numbers like "001.003". The PostScript Language Reference
|
||
Manual (3rd edition) places no requirements on font versions as stored
|
||
in the "version" entry of the FontInfo dictionary.
|
||
|
||
The "%%Version" comment in DSC 3.0 takes a <real> followed by a
|
||
<uint>. <real> is defined broadly, and includes "-.002", "34.5",
|
||
"-3.62", "123.6e10", "1E-5", "-1.", and "0.0".
|
||
|
||
OpenType 'head' field "version" is a 16.16 fixed-point binary number.
|
||
This is recommended to be rounded and padded to three decimal places
|
||
for display. OpenType 'name' ID 5 is required to contain two numbers,
|
||
at most 65535 each, separated by a dot. It's recommended that this
|
||
come just after "Version " at the start.
|
||
|
||
dpkg (like many other things) thinks a version number consists of dot
|
||
separated integers. It treats "002.009" as equal to "2.9", but "1.3"
|
||
as different from "1.300".
|
||
|
||
So I think version numbers of the form "3.141" are sensible. Losing
|
||
the leading zeroes and having three decimal places means they can be
|
||
formatted correctly from the 'head' table. Not having leading or
|
||
trailing zeroes in the fractional part means that they can't be
|
||
suppressed by anything that might try to canonicalise version numbers.
|
||
|
||
Inspiration from a cycle ride: sticking the year in the version number
|
||
would make it easier to see how old a release is. 3.YYn for the nth
|
||
release in 20YY seems good. So the first one would be 3.246 (or maybe
|
||
3.251).
|
||
|
||
HP 264x large characters
|
||
========================
|
||
|
||
https://drive.google.com/open?id=1rtsO2rohVpmKGR6rF42JccKgAu8f4nFS has
|
||
an explanation of how the large character pieces in the Symbols for
|
||
Legacy Computing Supplement fit together.
|
||
|
||
Mapping between ASCII and large characters
|
||
------------------------------------------
|
||
|
||
! " # $ % & '
|
||
( ) * + , - . /
|
||
0 1 2 3 4 5 6 7
|
||
8 ? 9 : ; < = ▚ > ?
|
||
@ A B C D E F G
|
||
H I J K L M N O
|
||
P Q R S T U V W
|
||
X Y Z ▘ [ ▝ \ ▖ ] ▗ ^ ▀ _ ▌
|
||
|
||
Looks like Unicode has somehow missed out one of them.
|
||
|
||
8-cell mosaic unification
|
||
=========================
|
||
|
||
These cell patterns are missing from the main set of block octants,
|
||
apparently because they're unified with something else:
|
||
|
||
00 U+0020 SPACE etc
|
||
01 U+1CEA8 LEFT HALF UPPER ONE QUARTER BLOCK
|
||
02 U+1CEAB RIGHT HALF UPPER ONE QUARTER BLOCK
|
||
03 U+1FB82 UPPER ONE QUARTER BLOCK
|
||
05 U+2598 QUADRANT UPPER LEFT
|
||
0A U+259D QUADRANT UPPER RIGHT
|
||
0F U+2580 UPPER HALF BLOCK
|
||
14 U+1FBE6 MIDDLE LEFT ONE QUARTER BLOCK
|
||
28 U+1FBE7 MIDDLE RIGHT ONE QUARTER BLOCK
|
||
3F U+1FB85 UPPER THREE QUARTERS BLOCK
|
||
40 U+1CEA3 LEFT HALF LOWER ONE QUARTER BLOCK
|
||
50 U+2596 QUADRANT LOWER LEFT
|
||
55 U+2588 LEFT HALF BLOCK
|
||
5A U+259E QUADRANT UPPER RIGHT AND LOWER LEFT
|
||
5F U+259B QUADRANT UPPER LEFT AND UPPER RIGHT AND LOWER LEFT
|
||
80 U+1CEA0 RIGHT HALF LOWER ONE QUARTER BLOCK
|
||
A0 U+2597 QUADRANT LOWER RIGHT
|
||
A5 U+259A QUADRANT UPPER LEFT AND LOWER RIGHT
|
||
AA U+2590 RIGHT HALF BLOCK
|
||
AF U+259C QUADRANT UPPER LEFT AND UPPER RIGHT AND LOWER RIGHT
|
||
C0 U+2582 LOWER ONE QUARTER BLOCK
|
||
F0 U+2584 LOWER HALF BLOCK
|
||
F5 U+2599 QUADRANT UPPER LEFT AND LOWER LEFT AND LOWER RIGHT
|
||
FA U+259F QUADRANT UPPER RIGHT AND LOWER LEFT AND LOWER RIGHT
|
||
FC U+2586 LOWER THREE QUARTERS BLOCK
|
||
FF U+2588 FULL BLOCK
|
||
|
||
TIFAX
|
||
=====
|
||
|
||
The TIFAX XM11 was a 1975 Teletext decoder board made by Texas
|
||
Instruments Ltd. It used a 5 × 9 character matrix with rounding like
|
||
an SAA5050, but implemented over rather more chips. Unlike the
|
||
SAA5050, the XM11 had two black pixels horizontally between
|
||
characters, so the total character size was 7 × 10.
|
||
|
||
https://www.blunham.com/Radar/Teletext/PDFs/XM11-B183.pdf
|
||
|
||
The character ROM is an SN74S262, and the character shapes mostly
|
||
match the SAA5050, so treating it as a variant might not be
|
||
unreasonable. There is some uncertainty over some characters as
|
||
explained by Neil Williamson: https://p298.net/devnotes/
|
||
|
||
The different character pitch could mostly be accomodated by having
|
||
the application add extra spacing between characters, but what about
|
||
mosaic graphics? The XM11 generated those in a separate chip (the
|
||
X908), and they were the full 7 pixels wide, four in the left column
|
||
and three in the right. Would we want an entire extra set? At least
|
||
the XM11 didn't support separated graphics (added in the 1976 spec).
|
||
And what about box-drawing?
|
||
|
||
The XM11 has a dot clock the same as the Teletext bit clock: 6.9735 MHz.
|
||
Hence a nominal XPIX of 105.8.
|
||
|
||
There was also a Swedish ROM, SN74S263, which was used in the ABC80, a
|
||
Swedish Z80-based computer, so there is a purported ROM of it
|
||
available for emulators.
|
||
|
||
Also some real screenshots; e.g. https://www.youtube.com/watch?v=Jy6tQsyd4ho
|
||
|
||
I haven't found a datasheet for the SN74S262/3, but the schematics in the
|
||
ABC80 and RML 380Z service manuals provides a pinout:
|
||
|
||
1: D4
|
||
2: D5
|
||
3: D6
|
||
4: RA (row address)
|
||
5: RB
|
||
6: RC
|
||
7: RD
|
||
8: Y1 (output)
|
||
9: Y2
|
||
10: Gnd
|
||
11: Y3
|
||
12: Y4
|
||
13: Y5
|
||
14: CS*
|
||
15: CS*
|
||
16: D0 (character address)
|
||
17: D1
|
||
18: D2
|
||
19: D3
|
||
20: Vcc
|