According to <https://github.com/fuweichin/xhtml5-esm-support>, an
internal script (a <script> element with content) can't be a module in
an XHTML page in Safari. So following the suggestion on that page, I
make the <script> on the page into a classic script, and use import()
to load the module containing the bedstead executable. Maybe this
will work on a reasonable selection of modern browsers.
Programs compiled with Emscripten end up statically linked against the
Emscripten runtime, which includes musl libc. So we need to comply with
their licences by including a copy of the licence and the relevant
copyright notices. I think putting them on the webstead page in small
print is probably the best approach.
This might need updating each release to match the version of Emscripten
that I build the editor with.
Add -sINCOMING_MODULE_JS_API because in newer Emscripten -sSTRICT
empties it. Remove -sMODULARIZE because -sEXPORT_ES6 implies it. Add
-O2 since the compiled code will probably be run more than once. Pass
standard compiler flags to emcc. Build bedstead.js in all-web, and
remove it in clean.
Apparently Chromium can't cope with "defer" scripts (which modules are
by default) in XHTML documents. But "async" scripts work properly,
so now we use one of those and then wait for DOMContentLoaded as
necessary.
There are various text files in the Bedstead sources (and hence on the
Web site) that have conventional names in all caps, like NEWS. These
should be served as text/plain. That can be achieved in Apache using
a <FilesMatch> block and ForceType.
It looks like by AddOutputFilterByType directive somehow overrides the
defaults, and also there are a few more types that could usefully be
compressd. So now it lists all the compressible file types in the
directory.
The ones that aren't separately encoded provided a clear indication of
how the numbered stem parts are meant to relate to the named ones, so
there weren't actually many decisions to make.
This is essentially all of them apart from the W and M pieces. There
turn out to be obvious places to have the diagonals cross character-cell
boundaries such that they should all join up. Whether this gives and
aesthetically tolerable outcome, I'm not so sure.
The W and M pieces are a bit confusing, because they're meant to span
two character cells vertically, but the obvious design doesn't.
This batch are the ones that can be implemented using the ordinary
box-drawing characters (and probably should have been unified with
them by Unicode).
Because in Bedstead the cell boundaries of 8-cell mosaic glyphs are a
superset of those for 6-cell mosaic glyphs, each of the existing
6-cell glyphs has an identical 8-cell glyph whose middle two rows of
cells are identical. Thus, these 8-cell glyphs can be aliases for the
corresponding 6-cell glyph. I've implemented this as a macro called
A() that can be mixed in with the existing O() macros in the section
of the glyphs table that generates U+1CD00..U+1CDE5, aliasing them to
characters in U+1FB00..U+1FB3B. That makes the table even more
confusing, but at least it's compact.
These are the ones scattered across Unicode and not in the main
U+1CD00..U+1CDE5 block that weren't already present. They're aliased to
the corresponding 6-cell characters.
These were mostly generated from UnicodeData.txt with a dodgy Perl
one-liner and an Emacs keyboard macro. The dodgy one-liner was (wrapped
onto more lines):
grep "BLOCK OCTANT" ~/Downloads/UnicodeData.txt |
perl -pe '/OCTANT-(\d+)/; $i=""; map{vec($i,$_-1,1)=1}split(//,$1);
$_=sprintf("%02X",ord($i))." $_";'
Now I need to find the characters elsewhere in Unicode that correspond
with the gaps in the table.
This follows the pattern of the 6-cell and 4-cell versions, but without
separated mode because Unicode doesn't have that. This required making
the bitmap data into an unsigned char array to allow for using all eight
bits.
The cell boundaries are chosen so that they line up with existing 6-cell
and 4-cell boundaries. So we have row heights of [3,2,2,3], which is
maybe less pretty than [3,2,3,2], but is more in keeping with the
existing mosaics. Indeed, it means that the existing 4-cell and 6-cell
contiguous characters could be expressed in 8-cell terms if I wanted to.
Before, the diagonal parts were the same as in the capital O. But that
was already a bit square, and the shapes one would draw with the box
drawing characters will generally be bigger. So now I've cut a bit more
off the corners. This means that arcs that join to the right need the
recent change to add JOIN_R in order to join up properly.
With this change, if you try to draw a circle with them, you get an
octagon with side lengths 2, 2.8, 6 instead of 4, 1.4, 8, which I think
is an improvement.
The new flags mark glyphs that join to the right and downwards. The
effect of these, and a new effect of JOIN_U and JOIN_L, is to arrange
that getpix() treats pixels beyond the edge of the character cell as
repeating the last row of real pixels.
In practice, this means that a diagonal stroke touching the right or
bottom edge of the cell will now be drawn as though it turns into an
orthogonal stroke across the edge rather than as though it stops. This
doesn't affect the outline of any existing glyph.
There is a more subtle consequence, which is that joining glyphs no
longer get edge hints on their joining edges. I think that's an
improvement: such hints might move those edges so that they don't touch
the adjacent character, which would be rather unhelpful.
Specifically, this adds:
U+1D0C LATIN LETTER SMALL CAPITAL L WITH STROKE
U+1D23 LATIN LETTER SMALL CAPITAL EZH
U+1D7B LATIN SMALL CAPITAL LETTER I WITH STROKE
U+1DF04 LATIN LETTER SMALL CAPITAL L WITH BELT
U+1DF10 LATIN LETTER SMALL CAPITAL TURNED K
Three of this had private-use encodings that appeared in earlier
Bedstead releases. These encodings have been preserved for backward
compatibility.
I've designed new versions of 0, 1, and 2 that fit within the
x-height. 6 and 8 don't change at all (and are unmapped). The other
digits are all moved down by two pixels so their top edges are at the
x-height and their bottom edges at the descender height.
This is very simple (and much simpler than my previous attempts), but
seems to be satisfactory.
