I was just looking at the code and finding it confusing. Maybe more
comments will help, but maybe generating XML with enormous piles of
preprocessory is intrinsically confusing.
I think it would be unwise to make the editor usable on Bedstead's Web
page. This avoids the danger of Bedstead's Web page turning into a
regulated user-to-user service under the Online Safety Act 2023, with
all the paperwork that would entail.
Specifically, if there were an editor on Bedstead's Web page then
users could use it to create glyph designs. That would, indeed, be
the whole point. They might also send those designs to me for
incorporation into Bedstead. But if I accepted any of those designs,
then "content generated directly on the service by a user" might "be
encountered by another user, or other users, of the service" (OSA
s3(1)), making the site a user-to-user service.
Ofcom take the position that being hosted on a .uk domain name is
enough to give a service "links to the UK", and none of the exemptions
cover Bedstead's Web page. So if the page were a user-to-user
service, it would be a regulated one.
Being a regulated user-to-user service brings requirements for
risk-assessment, record-keeping, and terms of service. These might be
reasonable for a service of any significant size, but it's not worth
the effort for something that I expect will get me a few glyphs at
most. And there seem to be moves afoot to require age assurance on
all regulated user-to-user services, which would be particularly
annoying.
The OSA is arranged such that even if no new content can be created on
a service, the continuing presence of user-generated content on a
service causes it to be a user-to-user service. So ever accepting a
glyph designed on the Web page would permanently make it into a
user-to-user service. Thus it's important that I shouldn't do that.
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.
