“How can I show someone how my blog articles actually render?”

It sounds like it should be super easy, but it turns out it really isn’t. I write in Markdown (and attach the source to all my posts if you’re interested) that then gets rendered as HTML on-demand by Pelican. (More on this on the thanks page.) But that means there’s no quick way to demo what any given input will render as: it has to run through the markdown processor every time. Markdown is a fairly standard language, but I have a number of extensions I use – some of which I wrote myself – which means to get an authoritative rendering, it has to actually render.

But I want to be able to demo the full rendered output after all the various markdown extensions process. I want a nice simple way to render snippets and show people how that works, like a live editor does. The CSS is already portable by default, but the markdown rendering is done with python-markdown, which has to run server-side somewhere, so that’s much less portable.

So I spent two evenings and wrote up gio-flavoured-markdown.glitch.me, which does exactly that. You can view the live source code here if you want to follow along.

As is common in Python, the mechanical process of displaying something on screen in Ren’py is at once easy to execute and deceptively complicated to execute correctly.

The Ren’py documentation does a fine job of defining the specifications of position properties, but intuitively understanding how to use those properties can still be hard because it doesn’t include much in the way of examples or elaboration, so here are some of those.

Befriendus; everybody’s favorite visual novel about making alien friends. It’s got trolls, yes, but it also has a slew of accessibility options. You can adjust everything: color, font, motion, even spelling. It’s clean, it’s easy, and it works. Here’s how we did it.

When I was designing the basic accessibility framework I had these principles in mind:

• Accessible scripts must be easy to write; work should never be duplicated
  • Demanding people write multiple versions of work is bad design and encourages accessibility to eventually be dropped in favour of efficient production
• Humans should never do postprocessing tasks
  • We’re writing software; a computer should do any and all mechanical work, not writers
• Accessibility options should have as granular control as possible
  • Whenever possible, players should be able to select exactly what they need, not be forced to use something that doesn’t match their needs.
  • Options should be compatible with each other whenever possible
  • Just pushing out transcripts is not accessible design.

The best way to explain these is probably to explain what we ended up doing, and how each design choice was made carefully in accordance with those principles.

This is a writeup of a project I did in April but never released. Well, I’ve definitely released it now, if you want to give it a try!

Instead of a real introduction, here’s a video demo, with camcorder LP technology from 2005:

Ever since Wild World, Animal Crossing has had a pattern system, where players can design their own textures and use them as clothes or decoration. New Horizons has one, but since it doesn’t have a stylus you have to either use the directional pad to mark individual pixels or draw with your fingertip.

I thought it would be fun to find a way to automate that. Now, granted, it takes a while, but it’s still much faster than trying to copy pixels over by hand.

“Tabs or spaces” is one of these age-old computer science preference issues (like whether you use Vim or Emacs¹) that gives people a binary preference they get to pick and then get very attached to, due more to sunk costs and personal identity than anything else. (Good thing that only happens with unimportant stuff.)

I was thinking about this the other day, and I realized that I have an opinion about this, but it’s actually the opposite of what I do. And it’s not because of filesize, or encoding, or anything like that.