It doesn't work quite properly: some characters hit the left side of the
character cell, so I might want to separate the joins-leftward and
joins-upward flags.
In XLFD terms, Bedstead is a "character cell" font, where every
character fits entirely within its cell (defined by advance width,
ascent, and descent). Bedstead Bold maintained this because it
thickened into the unused column to the left of each character.
However, combining the new continuous line-drawing with emboldening led
to bold line-drawing characters that extended beyond their character
cell. This led FontForge to make the SPACING property of the BDF file
"M" (for monospace) rather the "C".
This commit simply clips the X co-ordinate of points in a bolded
character at zero. That's safe because line-drawing characters are
guaranteed not to be doing anything diagonal in the left-most column.
This is slightly ugly, in that the bold characters aren't quite so
algorithmically derived from the non-bold ones, but in most cases
there'll be another line-drawing character to the left anyway.
This is done my duplicating the top row of pixels upwards and the left
column leftwards. This is analogous to what MDA and other IBMish
adaptors do to expand eight-pixel wide characters to nine pixels on screen.
This is a bit of C pedantry. POSIX requires that an exit status of
zero is success and non-zero is failure, but the C standard says no
such thing. Instead it provides EXIT_SUCCESS and EXIT_FAILURE. Since
Bedstead aspires to work on non-POSIX systems, it should use the
defined constants. Also removing magic numbers is a good thing.
It should be the DEFAULT_CHAR in BDF, but that needs it to have an
encoding. U+2395 APL FUNCTIONAL SYMBOL QUAD happens to look
identical, but I don't think I should rely on that.
Wdieresis.sc is obviously wrong: a capital shouldn't have an 'smcp'
mapping. A 'c2sc' mapping for that character would also be wrong
because it's already squashed to fit under its accent. On the other
hand, there should be a wdieresis.sc that maps to the upper-case,
because the characters are slightly different.
Wdieresis.sc is retained as a compatibility alias (for Wdieresis),
just in case.
It should be centred between the uprights of the Ls, and that makes it
so. Sadly, it's not possible to do the same for the lower-case.
Also add a relevant link to NOTES.
That's the default value that FontForge uses. I'd like to change it,
but fontconfig makes it available to applications as "foundry" and I
somehow ended up with Emacs recording that in its configuration. So if
I'm going to make that change I think it should go with a major version
bump.
But at least I can make sure it doesn't change unexpectedly and give
myself somewhere to make the change when it comes.
Future versions of C are likely to make octal integer constants
obsolescent. Switching to something non-obsolete seems wise, and also
using octal character constants saves eight characters per line that I
can use for other things.
I did consider just using one character per row, but I think that might
be a little too hard to read.
The SAA5050 character images appear at the bottom-right corner of the
character cell, with a blank pixel to the top and the left. This can
be seen if you put am alphanumeric character and a mosaic graphics
character side-by-side, since mosaic graphics characters fill the
entire character cell.
However, when I first made Bedstead, I put the character images in the
top-right corner, and the co-ordinate system matched that. When I
fixed this in 2013 (commit 7bea0c6fadc35de50ea08eb184d4b15a7b411ef3),
I just did it by adjusting the final transformation of the vector
co-ordinates, leaving all the internal co-ordinate systems intact.
This was visible when I added mosaic graphics, which had to be offset
by one pixel to compensate.
Now I've finally corrected the problem somewhat properly. Pixel
co-ordinates count from (0,0) in the top-left corner of the character
cell. Vector co-ordinates count from (0,0) in the bottom-left corner
and are offset to the baseline on emission. The conversion between
the two forms is still weirdly spread all over the place though.
Apparently I didn't know about chained comparisons when I wrote this
code, so I didn't take the opportunity to write '0 <= x < limit'.
Also, removed the wildcard import from tkinter, replacing it with
explicit references to the things needed. There weren't that many of
them, so I think the 'import *' didn't gain much.
Apparently I was incredibly lazy at some point in the past and forgot
to say what the problem was when the paste data couldn't be matched
against the regex.
Previously the editor just expected to find it in your cwd. Now by
default it looks in the same directory as its own script, which means
you can run it from some other directory.
Also, I've provided a command-line option to override the default, in
case you keep the executable somewhere else again.
The previous code organisation had a tiny 'Container' classlet that
held all the mutable variables, just so that all the event handler
functions could reach into it and modify it without having to faff
with 'global'.
But if you're going to make that much of a class, it makes more sense
to go further, and make all those functions _methods_ of the class. So
here's a reorganisation that wraps up the Tk code into a more or less
conventional class structure.
The patch for this commit looks like a total rewrite, but it's not
really: everything is indented further to the right (with a couple of
reflowings of long lines), and a lot of variables have a new 'self.'
on the front, but in other respects the code is substantially
unchanged.
At the time I wrote this editor, it was sensible to try to be Python
2/3 agnostic. P2 is now thoroughly obsolete, so I've removed the P2
affordances. That lets me fix the shebang line to say 'python3', and
chmod the file +x, so that you can run it by its name.
Also, it can be renamed to just 'editor', because now that it's
executable, the fact that it's in Python is nothing but an internal
implementation detail.
Ben is trying to make Bedstead into a Debian package, which involves
clarifying copyright and licences anywhere it's unclear. When I
contributed this editing tool I did it on a very informal basis ('look
at this fun hack!') and didn't make that clear. Time to fix that.
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.
ZVBI is under LGPL v2, but the NOTES file isn't a library so I need to
licence the excerpt under GPL v2 instead. But actually I think I want
to remove that text, so this is just to legitimise the distribution of
the Git history.
Safari badly misdisplays Bedstead in proportional mode. This is
caused by a bug in WebKit, and I haven't found an acceptable
workaround. Thus, I think the best thing to do is to turn off
proportional spacing on the Web page entirely. I think it looks nice,
but even I'll admit that it's a little too tight, and I know others
prefer the monospaced version.
Also, I can't think of a way that a real chip anything like the
SAA5050 could produce proportionally-spaced text. It's fundamentally
based on getting fed character data at a constant 1 MHz. There's no
way it can ask for a character early because the previous one was
narrow.
It's more compact and works just as well. In fact, I think it might
work better on browsers that support background-image but not
background-size. On such browsers the entire rule will be ignored,
which is what I want. If the background image can't appear at
precisely the correct size, it shouldn't appear at all.
Of course, ideally on a browser that fails to display the background,
the title also wouldn't fade out to the left. I wonder if there's a
sensible way to achieve that.
The "sizes" attribute on the icon <links> wasn't allowed by XHTML 1.0
Strict, so I've removed the DOCTYPE for that. Meanwhile HTML 5
doesn't want you declaring a <meta http-equiv="content-type">
specifying XHTML, so I've removed that as well. So now it's
XML-syntax HTML 5, which seems sensible to me even if other people
don't like XML.
HTML doesn't allow <div> inside <h1>. I found before that using a
<span> caused the background not to work. That seems to be down to CSS2
section 10.6.1, describing inline, non-replaced elements: "The height of
the content area should be based on the font, but this specification
does not specify how."
Happily, we can just define this particular <span> to be a block
element, so that it behaves like a <div> even though it's a <span>.
That works fine, and because we're only using it to get a well-defined
content area it doesn't matter if it's ineffective when the stylesheet
is missing.
The W3C HTML 5 checker objects to my use of "–" and I can't see
any reason why I should use it. The page is unashamedly in UTF-8, so
there's not much benefit to singling out this one character for special
treatment.
The page is still officially in XHTML 1.0 Strict at the moment, but I
might want to change that, which is why I'm paying attention to an
HTML 5 checker.
The code predated the introduction of bold variants, so it was
significantly incorrect. Also it appears that some software uses the
PANOSE classification to distinguish monospaced fonts. After careful
study of the specification, I think all the variants of Bedstead can
be classified as text fonts, so I've removed the code that described
some variants as decorative. Then I did some calculations and a lot
of playing around with GeoGebra to work out which parts of the design
space give which values of Stroke Variation, Letterform, and Midline.
At least Noto Sans and Noto Sans Symbols2 think that EM SPACE should
be the same width as mosaic graphics characters, and I think we could
do with a space that doesn't get changed by 'palt'.
