Bedstead's standard weight is 500, reflecting the fact that it's
naturally quite heavy. CSS defaults to 400, so we were depending on
CSS's font-matching rules to fall back from 400 to 500. That's fine
at the moment, where there is no 400-weight version. But Bedstead
could be made lighter, and indeed the code to do it already exists.
And I hope that somewhere in the future is a variable Bedstead that
might allow for lighter weights. So for future-proofing I think the
CSS should specify the weight that it actually wants. Obviously I can
update my CSS if I ever introduce a 400 weight, but other people might
reasonably use my CSS as an example and I shouldn't lead them into
trouble.
I was looking for something completely different in the Unicode
Standard and found a note that U+23B4..U+23B6 can be used in terminal
applications with text printed vertically. So obviously I had to add
them.
Apparently the same doesn't apply to the other horizontal brackets at
U+23DC..U+32E1, which are purely stretchy mathematical brackets and
not interesting to us.
The odd positioning in the character cell is based on the Unicode code
chart.
These are treated as particularly odd Unicode code points and packed
into the "unicode" field. Currently only the encoding side is
implemented, withe the slashed zero, <U+0030, U+FE00>, as a motivating
example.
Generating a format 14 'cmap' subtable and properly formatting the
glyph complement are still to come.
This re-uses the old Oslash glyph I drew that had the slash entirely
inside the O. I've seen something similar on simulations of old
character generators, though I'm not sure I've seen any actual character
generators using this shape.
We were only using negative numbers for the "no Unicode mapping"
constant, and even there it was mostly cast to unsigned before we used
it (because it needed to sort last). So just using an unsigned type
throughout seems to be a bit cleaner. It will also make me less dubious
about packing extra information in when I want to support variation
selectors.
I noticed some occasions where my attempts at 16-bit cleanliness had
failed because I hadn't noticed that "unsigned" was a species of "int"
and hence potentially only 16 bits. So now I'm trying to be more
explicit and saying "unsigned int".
Next several of them will need to be replaced with something else.
GCC 15 gives a warning (-Wunterminated-string-initialization) if you
initialize an unsigned char array from a string constant such that the
terminating null character isn't included. Bedstead does this in most
rows of the glyphs array, which is quite noisy. I've chosen to work
around this by making the array one byte larger. That doesn't
actually affect the size of the struct on systems that align struct
fields, so the major loss is that now we might not get warnings if we
overflow by one byte.
There are several other ways this problem could be solved. One could
disable the warning entirely, but that would remove a valuable warning
from the rest of the program. We currently disable two other warnings
for the sake of the glyphs array, but working around them would
require ugly changes on every line of the array.
Probably the ideal approach would be to tag the "data" field with
"[[gnu::nonstring]]". That would not only suppress the warning but
also enable warnings if the array was ever passed to a function
expecting a null-terminated string. However, I think Bedstead is
currently written in plain ISO C99, while attributes like that were
only standardised in C23. I'm not averse to moving to a newer
standard, but C23 is a but _too_ new right now. I'm also a little
reluctant to rely on the implementation-defined behaviour of
particular compilers, which is why I'm not using "#pragma GCC
diagnostic".
I don't think it's appropriate to use 'name' string 0 (copyright
notice) for something that isn't a copyright notice. Perhaps I should
have something other than a URL that explains Bedstead's copyright
situation, but that field isn't it.
We now have a manufacturer, vendor URL, licensing URL, and sample text.
I've added an anchor to the Web page so to make the licensing URL more
useful.
Most of these are displayed by Firefox when listing the fonts used on a
page, so they seem like a good idea.
It turns out that Firefox (version 140 at least) will happily use an
HTTP Link header for a CSS stylesheet on a plain text file. It works
a bit weirdly because it applies the stylesheet to the HTML conversion
of the file, but that actually means that the existing bedstead.css
works pretty well.
This doesn't work on Chromium, but that's no worse than what we've
already got.
Now we don't assume that stdout is line-buffered and that we'll
therefore get a single call to print(). Instead, we collect up all
the output in a string and use it when the program exits.
The usual focus ring in Firefox and Chromium appears at the same
stacking level as the element it's attached to. This means that it's
hidden by elements after it in the document, including pixels below it
and to its right. Fiddling with the z-index of the focussed pixel
helps with this.
This makes it more obvious that something is happening when the mouse
button is pressed, even though the tickybox doesnt change state until
it's released. Thus should make the UI feel less sluggish.
The new code triggers when the <input> is edited. It updates the
pixel tickyboxes and the rendered glyph, but suppresses updating the
<input> itself. This can be used for interactive editing, but is
mostly to allow for pasting in character bitmaps.
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.
