Adële's blog

I am a smolweb advocate and, sometimes, I use LLMs.

Sat, 02 May 2026 19:15:00 +0000

I am a smolweb advocate and, sometimes, I use LLMs.

2026-05-02 19:15

I spend a lot of time thinking about simplicity. Fewer dependencies, lighter pages, tools that do one thing well. So yes, it might look strange that I also spend time talking to large language models. Let me explain where I draw the line, and why I think the contradiction is smaller than it appears.

What I avoid

I do not use LLMs to generate images, musics or videos. Not because I am against creativity, but because that kind of generation has a cost I can feel: massive compute, opaque training data, and an output that tends to look like everything and nothing at the same time. I am not interested in that.

More broadly, I avoid using a LLM as a replacement for thinking. The risk is real: ask, copy, ship, forget. That is not a workflow, that is a shortcut to not understanding your own codebase.

What I actually use them for

Debugging a tricky regex for example. Understanding an obscure error message at 11pm. Getting a quick skeleton for a function I know how to write but do not want to type from scratch. Reformulating something I wrote and cannot read anymore.

In short: acceleration, not delegation.

I never use a LLM as a starting point in unknown territory. If I do not understand the domain, I will not be able to evaluate the output, and a confident wrong answer is worse than no answer. I learn first, then I use the tool.

The environmental argument, in context

There is a fair criticism: LLMs consume a lot of energy. Fair. But I think the comparison is sometimes done badly. So true to generate a useless image to decorate a blog post. But false if it avoids other hard tasks.

A single LLM query costs more than a single web search, roughly ten times more, according to estimates floating around. But the right comparison is not one query vs. one search. It is five minutes of focused LLM use vs. one hour of tab-juggling, reading half-articles, and reformulating the same search query twelve times. That math is less obvious.

I am not using this to justify anything. I still try to keep sessions short and intentional. But I think the nuance is worth stating.

The smolweb angle nobody talks about

Here is something I did not expect: LLMs work better on simple stacks.

I work with plain PHP, vanilla JS, semantic HTML, lighttpd, Dolibarr (at work). No heavy framework, no abstraction layers, no magic. And the LLM handles that very well. The answers are short, precise, and mostly correct. No hallucinated method names from a framework it half-knows, no suggestions to install a package that wraps another package.

The more complex your stack, the more the LLM struggles, and the more back-and-forth you need. Every iteration has a cost. A simpler stack means shorter sessions, fewer tokens, more reliable answers.

So in a way, choosing the smolweb is also choosing a better LLM experience. Not because I optimized for that, but because simplicity compounds.

I always try to understand what it gives me

This is probably the most important thing I want to say.

Skill erosion is real. If you let a tool think for you often enough, you stop thinking. I have seen it happen. The LLM writes the function, you run it, it works, you move on, and three months later you cannot explain what it does.

My rule is simple: I read what it generates. I understand it before I use it. Sometimes I rewrite it my way. Sometimes it teaches me something I genuinely did not know, a cleaner approach, a built-in function I had forgotten, an edge case I had not considered. That is useful. That is the LLM as a fast colleague, not as a replacement for thinking.

And sometimes it is wrong. Not hallucinating exactly, just... slightly off. Missing context, outdated assumption, plausible but incorrect. I catch it because I read it. If I had just shipped it, I would not have.

One more thing: where the query goes

I run Ollama at home on my own machine. For personal projects and exploratory work, that is my first stop. No data sent anywhere, no privacy concern, no dependency on an external service when I can.

For more complex tasks I use an external model such as Claude, and I am conscious of what I send. No client code, no credentials, nothing sensitive. That is a deliberate choice, not an afterthought.

So

I am a smolweb advocate who uses LLMs. Not to generate fluff, not to avoid thinking, not as an oracle. As a tool, fast, sometimes very useful, always verified, occasionally wrong.

The key is knowing what you are doing with it.

Discuss about it on the Fediverse

The Fediverse deserves a dumb graphical client

Thu, 09 Apr 2026 18:30:00 +0000

The Fediverse deserves a dumb graphical client

2026-04-09 18:30

I love the Fediverse. I have been on it for years, and it remains the only social network where I actually enjoy spending time. No algorithmic feed pushing outrage, no dark patterns, no surveillance capitalism. Just people talking to each other over an open protocol.

But every time I wanted to recommend it to someone, I ran into the same wall: the clients are heavy. Mastodon's web interface ships megabytes of JavaScript. Elk, Phanpy, Ivory, beautiful apps, but they require a modern browser, a fast connection, and a device manufactured in the last five years.

There are CLI clients, toot and tut are both solid, genuinely lightweight, and a pleasure to use in a terminal. But the Fediverse without images is a lesser experience. People share photos, artwork, screenshots. A terminal client gets you the text; it does not get you the whole picture.

What I wanted was something in between: a client that runs in a plain browser, handles images properly, but does not require a JavaScript engine to display a list of posts. The API returns JSON; a server-side script can turn that JSON into HTML just fine. We have been doing that for 25 years.

So I built SmolFedi.

It is a PHP application. No npm, no Composer, no build step. It uses a SQLite database and basic PHP sessions. Every page is generated server-side and sent as plain HTML. It supports multiple accounts, timelines, notifications, polls, media attachments with alt text, content warnings, compose, reply, boost, favourite, everything I actually use day to day. CSS stays within smolweb Grade B. There is not a single line of JavaScript in the codebase.

It works with Mastodon, GoToSocial and certainly other compatible Fediverse platforms. It works in Firefox, in Chromium, in Safari, in any browser that can render HTML and display a JPEG such as Dillo or Netsurf.

I am not claiming this is the right client for everyone. If you want a smooth single-page experience with live updates and animations, SmolFedi is not that. But if you want to browse the Fediverse on a modest device, a slow connection, or simply a setup where you would rather not run megabytes of JavaScript fetched from the web, SmolFedi is for you.

The source is on Codeberg and a demo instance on Pollux

What do you think of that ? Let me know on the Fediverse

All my clients wanted a carousel, now it's an AI chatbot!

Sat, 14 Mar 2026 12:55:00 +0000

All my clients wanted a carousel, now it's an AI chatbot!

2026-03-14 12:55

It always starts the same way. The client pulls out their phone mid-meeting, navigates to a competitor's website, and holds the screen up like evidence. "You see? They have one of those." A little bubble. Bottom right corner. Blinking...

For years, that gesture was about carousels. Every homepage had to have one, big, slow, full of stock photos that nobody asked for. I built dozens of them. They spun. They faded. They slid. Visitors ignored them completely, scrolled past in half a second, and went looking for the phone number.

Then the trend quietly died, as trends do. Not because anyone decided carousels were bad. Just because something newer came along to copy.

Cookie consent banners came next. Every site needed one, even the ones with no cookies whatsoever. Then Google Tag Manager, even for clients who never once opened an analytics report. I asked one of them, eighteen months after launch, if he'd ever looked at the traffic stats. He hadn't. He didn't even remember the login.

Now it's the chatbot.

I've started asking clients a simple question when they bring it up. Not to be difficult, just to understand.

"Do you actually use chatbots when you visit other websites?"

There's usually a pause. Then a laugh.

No, not really. They close them immediately. They find them annoying. Half the time they answer something completely unrelated to the question. Once, a client told me about a competitor's chatbot that confidently gave out wrong opening hours for months. He thought it was hilarious. And yet: "but we should have one, right?"

That's the moment I find both fascinating and exhausting.

It's not about utility. It's not even really about the chatbot. It's about visibility, the fear of looking behind. A website without a chatbot in 2026 risks feeling unfinished, like something's missing. Even if what's missing is a half-broken widget that most visitors dismiss in three seconds. The chatbot has become a social signal, not a tool. A way of saying: we're keeping up.

I've tried the opposite approach. When a client mentions the chatbot, I'll sometimes open a few smolweb sites, fast, minimal, readable, calm. No pop-ups. No blinking corners. Just content, clear and immediate.

Their eyes change. "Oh, that loads fast." "That's easy to read." "I like that."

And they mean it. Genuinely.

Then I ask if they'd want something like that.

"Well... but it looks a bit simple, doesn't it?"

Simple is the word that keeps coming up. And I've learned that when a client says simple, they don't mean easy to use. They mean not impressive enough. They mean what will people think. A lean, fast website doesn't look like it cost anything. It doesn't signal effort. It doesn't say: we take this seriously.

The real irony is that building something genuinely simple, something that loads instantly and says exactly what it needs to say and nothing more, is often harder than bolting on a chatbot. But that's invisible work. Nobody sees the restraint.

I don't have a solution to offer here. I'm not going to end this with a tidy list of tips for convincing clients to embrace the smolweb. That's not how it works, and pretending otherwise would be its own kind of dishonesty.

The pressure isn't really coming from clients anyway. It's coming from the web itself, from a decade of bloated pages, dark patterns, and feature arms races that quietly redefined what a "real" website looks like. Clients are just reading the room. The room is wrong, but they're not imagining it.

The shift might come from users, not decision-makers. It might come when enough people notice that the fast, calm site was easier to use. That they actually found what they came for. That they didn't have to close three things before reading a single line.

Maybe we plant the seed and wait.

In the meantime, the chatbot is live. It sits in the corner of my client's homepage, blinking patiently. It doesn't know the opening hours. It doesn't know the prices. It doesn't really know anything.

But it's there. Just like everyone else's.

You encounter the same behaviour? Share it with me on the Fediverse

Building your first smolweb page

Sun, 01 Mar 2026 12:05:00 +0000

Building your first smolweb page

2026-03-01 12:05

A simple news article that takes ten seconds to load and eats 50 MB of data. You've seen that. We all have. Mountains of JavaScript, giant CSS frameworks, third-party trackers, custom fonts pulled from remote servers... all of that to display a few paragraphs of text.

The smolweb pushes back against that. The goal is to write small, clean, accessible HTML that works on any device, any browser, any screen, even without CSS or JavaScript. A smolwebsite should load on a smartphone from 2010, work in a text browser like Lynx, and be readable on a Braille display. Not because those are common cases, but because if your page works there, it works everywhere.

This is a hands-on guide for building your first smolweb page. No framework, no build tool, no npm. A text editor and a browser are all you need.

The philosophy in a few lines

A smolwebsite has a few core rules. No element unless it adds real value. Structure comes from HTML, not from styles: the page must be readable without any CSS. JavaScript is allowed, but the page must remain usable without it. No external dependencies: no CDN, no Google Fonts, no remote scripts. Use the right HTML tag for the right content. Think less about visual style and more about discipline.

Step 1: the bare minimum

Create a file called index.html and open it in your text editor:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>My smolwebsite</title>
  </head>
  <body>
    <p>Hello, world!</p>
  </body>
</html>

That's already a valid, working webpage. Here's what each line does.

<!DOCTYPE html> tells the browser this is HTML5. It must always be the very first line.

<html lang="en"> is the root element. The lang attribute matters: screen readers use it to pronounce content correctly, and search engines use it to understand what language your page is in. Use the ISO 639-1 code for your language (fr, de, es, etc.).

charset=utf-8 prevents browsers from misinterpreting accented characters. UTF-8 covers every language and special character you will ever need. Always declare it.

viewport is one line that makes your page usable on mobile. Without it, a smartphone will try to render your page as a shrunken desktop screen, which makes the text unreadably small.

Open the file in your browser. It already works.

Step 2: filling the `<head>`

The <head> section contains information about your page, things the browser and search engines need but the reader does not see directly. Here is a complete one:

<head>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  <meta http-equiv="Content-Security-Policy" content="default-src 'self';">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <meta name="color-scheme" content="light dark">
  <meta name="description" content="A page about my hobbies and projects.">
  <link href="/style.css" rel="stylesheet" type="text/css">
  <link rel="icon" href="/favicon.ico" type="image/x-icon">
  <link rel="icon" href="/favicon.png" type="image/png">
  <title>My smolwebsite</title>
</head>

Content-Security-Policy: default-src 'self' tells the browser to only load resources from your own server. No external fonts, no remote scripts, no third-party images. It is both a security header and a smolweb commitment in one. As a side effect, if you write <p style="color:red"> directly in your HTML, this header will block it. That is intentional. CSS belongs in a stylesheet.

color-scheme: light dark respects whatever dark or light mode the user has set in their system. The browser will automatically adjust default colors for backgrounds, text, and form controls. Zero extra CSS needed.

About the favicon: browsers look for /favicon.ico on every page request, even when you have not provided one. That is a failed HTTP request on every page load. Provide a favicon once, it gets cached, and the problem disappears.

Step 3: semantic tags

HTML has a tag for every major part of a webpage. Using them correctly costs nothing and gains a lot: better accessibility, cleaner code, and a page that still makes sense when CSS is stripped away.

<body>

  <header>
    <strong>My smolwebsite</strong>
    <nav>
      <ul>
        <li><a href="index.html">Home</a></li>
        <li><a href="about.html">About</a></li>
        <li><a href="contact.html">Contact</a></li>
      </ul>
    </nav>
  </header>

  <main>
    <article>
      <h1>My first post</h1>
      <p>This is the content of my first post.</p>
    </article>
    <aside>
      <p>Related: <a href="another-post.html">Another post</a></p>
    </aside>
  </main>

  <footer>
    <p>Published by me under <a href="https://creativecommons.org/licenses/by-sa/4.0/">CC BY-SA</a>.</p>
  </footer>

</body>

Here is a quick reference:

Tag	Used for
`<header>`	Site name, logo, navigation at the top
`<nav>`	Links to other pages of your site
`<main>`	The main content, used once per page
`<article>`	A self-contained piece of content: a post, a story
`<aside>`	Secondary content related to the main article
`<footer>`	Credits, license, bottom links

Avoid scattering <div> everywhere. A <div> carries no meaning, it is just a box. If an appropriate semantic tag exists, use it.

Step 4: a small stylesheet

Your page must remain readable without CSS, but a small stylesheet can still improve it. Here is one that stays within smolweb principles:

/* style.css */

html {
  font-size: 100%;          /* Inherit the user's font size preference */
  font-family: sans-serif;  /* System default, no download required */
  max-width: 65ch;          /* Comfortable line length for reading */
  margin: 0 auto;
  padding: 1rem;
}

h1 { font-size: 2rem; }
h2 { font-size: 1.6rem; }
h3 { font-size: 1.2rem; }
small { font-size: 0.8rem; }

nav ul {
  list-style: none;
  padding: 0;
  margin: 0;
}

nav ul li {
  display: inline-block;
  border-right: 1px solid black;
  padding: 2px 10px;
  margin: 0;
}

footer {
  border-top: 1px solid;
  margin-top: 2rem;
  padding-top: 1rem;
  font-size: 0.8rem;
}

A few things worth explaining here.

font-size: 100% on the html element inherits whatever font size the user has configured in their browser. A lot of people, particularly those with visual impairments, set it larger than the default. Writing font-size: 16px overrides their choice. Using sizes in rem units afterward keeps everything proportional to that base.

max-width: 65ch keeps line lengths around 60 to 70 characters, which is generally considered the most comfortable range for reading.

Skip float. Floated elements force the browser to do extra layout work. Stacking blocks vertically is simpler and lighter.

Skip web fonts entirely. The sans-serif keyword maps to whatever font the user has set as their preferred one in their browser. It loads instantly and costs nothing.

Step 5: things that will trip you up

Inline styles are blocked by your Content-Security-Policy header and break the separation between content and presentation:

<!-- avoid this -->
<p style="color: red; font-weight: bold;">Warning!</p>

<!-- do this instead -->
<p class="warning">Warning!</p>

Misnested tags cause browsers to guess what you meant, and they often guess wrong:

<!-- wrong -->
<b><i>text</b></i>

<!-- right -->
<b><i>text</i></b>

Tables are for data, not for positioning parts of your page. If you are using a table to put your navigation next to your content, that is the wrong tool.

External scripts and stylesheets break the default-src 'self' policy and introduce a dependency on a server you do not control:

<!-- wrong -->
<script src="https://cdn.example.com/jquery.min.js"></script>

<!-- right -->
<script src="/js/myscript.js"></script>

Missing alt attributes on images leave users with broken image icons and screen reader users with nothing:

<!-- wrong -->
<img src="photo.jpg">

<!-- right -->
<img src="photo.jpg" alt="A sunset over the mountains in July 2024">

Step 6: before you publish

Two validators are worth running before putting your page online.

The W3C validator checks that your HTML conforms to the standard. The smolweb validator checks that you are staying within the smolweb HTML subset.

Then do these four quick tests. Open your page in a regular browser. Disable CSS (in Firefox: View > Page Style > No Style) and check that the content is still readable and logically ordered. Try Lynx or w3m in a terminal if you have access to one: a text-only browser is about as demanding a test as you can run. Finally, resize your browser window down to a narrow width and see if the layout stays usable.

The complete template

Copy and adapt from here:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
    <meta http-equiv="Content-Security-Policy" content="default-src 'self';">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <meta name="color-scheme" content="light dark">
    <meta name="description" content="A short description of this page.">
    <link href="/style.css" rel="stylesheet" type="text/css">
    <link rel="icon" href="/favicon.ico" type="image/x-icon">
    <link rel="icon" href="/favicon.png" type="image/png">
    <title>Page title - My smolwebsite</title>
  </head>
  <body>
    <header>
      <strong>My smolwebsite</strong>
      <nav>
        <ul>
          <li><a href="index.html">Home</a></li>
          <li><a href="about.html">About</a></li>
          <li><a href="contact.html">Contact</a></li>
        </ul>
      </nav>
    </header>

    <main>
      <article>
        <h1>My first post</h1>
        <p>Hello! This is my first smolweb page. It's small, fast, and works everywhere.</p>
        <p>No framework, no tracker, no bloat. Just HTML.</p>
      </article>
    </main>

    <footer>
      <p>Published by me under <a href="https://creativecommons.org/licenses/by-sa/4.0/">CC BY-SA 4.0</a></p>
    </footer>
  </body>
</html>

A few more things, once you are up and running

Consider adding an RSS feed. Smolweb readers tend to follow sites through RSS rather than social media, and it is not complicated to set up a basic XML file.

Enable HTTPS if your host supports it. Let's Encrypt provides free certificates. You can also use the w. subdomain (like w.yoursite.tld instead of www.yoursite.tld) to signal that your site follows the smolweb guidelines.

When you add images, optimize them before uploading and always write an alt description. Better yet, ask yourself whether the image is necessary at all. Sometimes a sentence says more.

The smolweb is not about building something ugly or retro. It is about building something that loads fast, respects its readers, and will still work ten years from now. Start with the template above, add only what you actually need, and keep it that way.

Further reading:

smolweb.org - the official guidelines
HTML for People - a gentle HTML introduction for beginners
Modern Font Stacks - system font combinations that look great everywhere
Wiby - a search engine for small, simple websites

Discuss about this post on the Fediverse

fen2board for chess players

Mon, 26 Jan 2026 07:40:00 +0000

fen2board for chess players

2026-01-26 07:40

A Python script to convert chess positions (FEN notation) and games (PGN format) into beautiful chessboard diagrams.

Available on codeberg

Supports multiple output formats:

Terminal display with Unicode chess pieces and ANSI colors
ASCII text with monochrome or color modes
RTF documents with Chess Cases font or ASCII characters

Perfect for creating printable chess study materials, generating game annotations, or displaying positions in the terminal.

Features

FEN to diagram: Convert any chess position to a visual board
PGN to diagrams: Generate diagrams for every move in a game
Multiple display modes:
- Unicode with ANSI colors (default terminal display)
- ASCII monochrome (-am/--ascii-monochrome)
- ASCII with colors (-ac/--ascii-color)
- Chess Cases font for professional RTF output
RTF export: Generate professional documents with the Chess Cases font or ASCII art
Board orientation: View from White's or Black's perspective (--black)
Move filtering: Display specific move ranges (--start, --end)
Multi-game support: Process PGN files with multiple games (hide variants)

Requirements

Python 3.10 or higher
For RTF output with Chess Cases: Chess Cases font installed
For ASCII RTF output: Microsoft Consolas font (optional)

Installation

# Clone or download the script
git clone https://codeberg.org/adele/fen2board.git
cd fen2board

# Make it executable (optional)
chmod +x fen2board.py

Usage

Display a position in the terminal

Unicode display (default)

python fen2board.py "rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1"

ASCII monochrome

python fen2board.py "rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1" -am
  +----------------+
8 |r n b q k b n r |
7 |p p p p p p p p |
6 |  =   =   =   = |
5 |=   =   =   =   |
4 |  =   =   =   = |
3 |=   =   =   =   |
2 |P P P P P P P P |
1 |R N B Q K B N R |
  +----------------+
   a b c d e f g h

ASCII with colors

python fen2board.py "rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1" -ac

View from Black's perspective

python fen2board.py "rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1" --black

Process a PGN game

# Display all moves in terminal
python fen2board.py --pgn "1. e4 e5 2. Nf3 Nc6 3. Bb5 a6"

# Display moves 5-10 only
python fen2board.py --pgn "..." --start 5 --end 10

# Read PGN from stdin
cat mygame.pgn | python fen2board.py --pgn

Generate RTF documents

Chess Cases font font (default)

python fen2board.py "rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1" -r output.rtf

ASCII monochrome RTF

python fen2board.py "rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1" -am -r output.rtf

ASCII color RTF

python fen2board.py "rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1" -ac -r output.rtf

PGN game to RTF with Chess Cases font

python fen2board.py --pgn mygame.pgn -r analysis.rtf

PGN game to ASCII color RTF

cat mygame.pgn | python fen2board.py --pgn -ac -r analysis.rtf

Command-line Options

Option	Short	Description
`--black`	`-b`	Display board from Black's perspective
`--pgn [FILE]`	`-p [FILE]`	Process PGN game (use `-` or omit for stdin)
`--start N`	`-s N`	Starting move number (PGN only)
`--end N`	`-e N`	Ending move number (PGN only)
`--format-rtf FILE`	`-r FILE`	Generate RTF file
`--ascii-monochrome`	`-am`	Use ASCII characters (monochrome)
`--ascii-color`	`-ac`	Use ASCII characters with ANSI colors

Display Modes

Unicode Mode (Default)

Uses Unicode chess pieces (♔♕♖♗♘♙) with ANSI colors for terminal display. Best for modern terminals with Unicode support.

ASCII Monochrome (`-am`)

Uses standard ASCII characters:

Pieces: K Q R B N P (uppercase) and k q r b n p (lowercase)
Empty squares: space (light) and = (dark)
Portable, works in any terminal or text editor

ASCII Color (`-ac`)

Uses ASCII characters with ANSI color codes:

Pieces: K Q R B N (uppercase), o (pawns)
Color distinguishes White (white text) from Black (black text)
Background colors: gold (light squares), brown (dark squares)
Same colors in console and RTF output

Chess Cases Font (RTF)

Optimal output using the Chess Cases font. Requires the font to be installed. Generates publication-quality diagrams.

RTF Output Details

Font sizes: 14pt titles, 11pt text, 11pt Chess Cases boards, 10pt ASCII boards
Pagination: PGN meta data and starting position on page 1, then 2 complete moves (4 boards) per page
Headers: Game information (Event, Players, Date, etc.) on first page
Move labels: Include move numbers and piece icons (Chess Cases mode)
Comments: PGN comments are included in italic

Examples

Tactic puzzle in terminal

python fen2board.py "r3r1k1/ppp2ppp/2n5/3p2N1/N2P2n1/2P4P/PP1Bb1Pq/R3Q1K1 w - - 1 22"

Game analysis to RTF

# Create a professional game booklet
python fen2board.py --pgn mygame.pgn -r analysis.rtf

Study material in ASCII

# Generate printable ASCII diagrams (compact, good for emails)
python fen2board.py --pgn study.pgn -am -r study.rtf

Color diagrams for presentation

# Beautiful colored ASCII diagrams
python fen2board.py --pgn game.pgn -ac -r presentation.rtf

License

This project is licensed under the GNU General Public License v3.0 - see the LICENSE file for details.

By Adële - adele.pages.casa

Credits

Chess Cases font by Matthieu Leschemelle - https://www.dafont.com/chess-cases.font
ANSI 256-color palette for terminal display
Consolas font by Microsoft (used as fallback for ASCII RTF output)

Acknowledgments

Special thanks to the chess community for the PGN and FEN standards that make chess software interoperable.

A mailbox for Christmas

Thu, 18 Dec 2025 09:45:00 +0000

A mailbox for Christmas

2025-12-18 09:45

Christmas is often the time when geeks get bombarded with technical questions from their loved ones. Last year, I gave my opinion on Gmail accounts and was asked what alternative to use for email. I was a bit stumped for an answer: ProtonMail or Tuta? But they regularly encourage users to switch to their paid service and use their other services (VPN, drive, password vault, etc.). What's more, standard email clients are not compatible.

That's what gave me the idea to offer message.casa, an email account (with an XMPP account) that is limited in size but free and complies with standard IMAP/POP3/SMTP protocols.

So, if you too are asked about email accounts at Christmas, you can suggest message.casa ;-)

Comment on the fediverse

Adële's blog

I am a smolweb advocate and, sometimes, I use LLMs.

I am a smolweb advocate and, sometimes, I use LLMs.

What I avoid

What I actually use them for

The environmental argument, in context

The smolweb angle nobody talks about

I always try to understand what it gives me

One more thing: where the query goes

So

The Fediverse deserves a dumb graphical client

The Fediverse deserves a dumb graphical client

All my clients wanted a carousel, now it's an AI chatbot!

All my clients wanted a carousel, now it's an AI chatbot!

Building your first smolweb page

Building your first smolweb page

The philosophy in a few lines

Step 1: the bare minimum

Step 2: filling the <head>

Step 3: semantic tags

Step 4: a small stylesheet

Step 5: things that will trip you up

Step 6: before you publish

The complete template

A few more things, once you are up and running

fen2board for chess players

fen2board for chess players

Features

Requirements

Installation

Usage

Display a position in the terminal

Unicode display (default)

ASCII monochrome

ASCII with colors

View from Black's perspective

Process a PGN game

Generate RTF documents

Chess Cases font font (default)

ASCII monochrome RTF

ASCII color RTF

PGN game to RTF with Chess Cases font

PGN game to ASCII color RTF

Command-line Options

Display Modes

Unicode Mode (Default)

ASCII Monochrome (-am)

ASCII Color (-ac)

Chess Cases Font (RTF)

RTF Output Details

Examples

Tactic puzzle in terminal

Game analysis to RTF

Study material in ASCII

Color diagrams for presentation

License

Credits

Acknowledgments

A mailbox for Christmas

A mailbox for Christmas

Step 2: filling the `<head>`

ASCII Monochrome (`-am`)

ASCII Color (`-ac`)