Thirty-six flights were cancelled at an airport in Japan, because a pair of scissors went missing. Spoiler: the scissors weren’t actually missing, they just weren’t in the secure locker where they were supposed to be stored between authorized uses.
International political comparison left as an exercise for the reader.
(this is one of those shows that has a triple fuckton of fan-art, almost none of which is any good)
Y’know, I often disagreed with Tog’s classic Apple User Experience standards, and with many of his later recommendations, but it was all evidence-based; his teams tested the hell out of everything, and produced clear, usable rules. Now, with the modern Apple feels-over-facts lack of any standards, I realize that the reason I’m having difficulty communicating with the author of Typeface is that we don’t even speak the same language. Neither in UI design nor in typeface management.
He doesn’t seem to understand why scattering information all over the screen is bad design, or why adjusting the font display with a mix of menus, buttons, popups, pulldowns, and modifier keys, often requiring you to move the mouse 6+ inches between steps, is bad design. Sigh.
I’ve completely overhauled my old termanal
script that analyzes
fixed-width fonts for their suitability for coding (vertical alignment
of characters commonly used together in code, common width for math
operators, precise metrics, and full metadata), and it now generates
JSON output for all the fonts you feed it, allowing me to generate
comparison tables for my whole collection, as a technical companion to
programmingfonts.org.
All of this is being done by calling the tx
and ttx
tools from the
Adobe Font Development Kit for Opentype
(AFDKO). With the right
options, they can export pretty much all the usable data from a font,
including the actual glyph outlines.
This gave me an idea for calculating something termanal
doesn’t do:
estimate the color of the font. That is, how thicc are the glyphs,
and therefore how dark does a line of text look.
ttx
exports selected glyphs from a font as an SVG font.inkscape
renders each glyph to individual PNG files.magick
counts the number of black pixels.And it even worked on the first try, more or less, although the launch
overhead for inkscape
seems to dominate, producing the odd result
that it takes twice as long to render everything at 10% of the size,
while 50% is twice as fast. I’m going to tinker with batching things
up so I can call inkscape
and magick
only once and have them work
from tempfiles instead of directly piping from one to the other. This
might involve switching it to Python, since all the components appear
to have some degree of API support.
I named it coloranal
, of course.
Anyway, have some cheesecake:
Inkscape doesn't actually support SVG fonts (in fact it silently ignores them, hence the "more or less" for my first try), but the "d" attribute of a glyph is identical to the "d" attribute of a path. They're just vertically flipped. Which, honestly, doesn't matter for this use. 😁
<glyph unicode="y" horiz-adv-x="600" d="M131,-217C241,-217 300,-140 338,-42l213,552l-78,0l-106,-287C350,177 332,124 315,76l-4,0C291,125 270,178 251,223l-119,287l-83,0l227,-512l-14,-36C236,-105 196,-149 128,-149C113,-149 97,-146 84,-142l-17,-65C84,-213 108,-217 131,-217z"/>
<path id="y" d="M131,-217C241,-217 300,-140 338,-42l213,552l-78,0l-106,-287C350,177 332,124 315,76l-4,0C291,125 270,178 251,223l-119,287l-83,0l227,-512l-14,-36C236,-105 196,-149 128,-149C113,-149 97,-146 84,-142l-17,-65C84,-213 108,-217 131,-217z" transform="scale(1,-1)"/>
Markdown formatting and simple HTML accepted.
Sometimes you have to double-click to enter text in the form (interaction between Isso and Bootstrap?). Tab is more reliable.