mirror of
https://bjh21.me.uk/bedstead/.git
synced 2026-07-09 21:43:06 -04:00
For the most part they're not useful, and they're arguably under the GNU GPL. I've replaced them with an original prose description of some of the interesting facts. For everything else, you can go to ZVBI itself.
139 lines
5.2 KiB
Plaintext
139 lines
5.2 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.
|
||
|
||
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?)
|
||
|
||
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.
|
||
|
||
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/
|
||
|
||
Microsoft have their own suggestions:
|
||
https://docs.microsoft.com/en-gb/typography/develop/character-design-standards/
|
||
|
||
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.
|