Last February I released probably my most popular project so far, an analog game icon font called Dicier, with icons for 6-sided dice, dominoes, and poker cards. At first it was just an update of an earlier, simpler font (Dicey), but it slowly grew, through about 6 months of on-off work, into a relatively big typeface covering everything from polyhedral dice to dreidels to coinflips across 10 styles:

But there are problems with Dicier.

Before I get into that, here's some terms that'll be useful to know:

glyph

A visual representation of a character in a written language (e.g. lowercase “a” is a character; regular, superscript, and subscript lower “a” are different glyphs of that character).

OpenType (OT)

A modern font format that supports features that swap glyphs for different glyphs, among other things.

OT feature

A set of rules that change how a font displays. For instance, smcp swaps lowercase letters for smallcaps.

OT code

The computer code that describes OT features. Usually a list of rules like this:

sub a by a.sc;

This rule substitutes lower “a” for smallcap “a”.

ligature

A glyph made by joining 2+ characters together (e.g. lower “f” + lower “i” = “f_i” ligature). Usually, the ligature also looks like the glyphs of of the individual characters, but it doesn't have to (for instance, they almost never do in Dicier). OT code for ligatures looks like this:

sub S P A D E S by S_P_A_D_E_S;

The characters on the left get joined into the ligature on the right.

icon

In Dicier, an icon is a glyph representing an analog game randomiser (dice, card suits and ranks, dominoes, etc.).

code

In Dicier, a code is the characters you type to display an icon (e.g. 6 to make a d6 face with 6 pips; HEARTS to make a hearts suit). Under the hood, this uses the OT feature for ligatures.

subset

The process of reducing the size of a font file by removing unused glyphs.

The problem(s) with Dicier

Wanna skip this part and go straight to the “future” part? Click here.

Dicier started with the d6 icons. Once I had those down I realised I could reuse the parts to make dominoes. When I posted on twitter asking if there was anything else people wanted, someone asked for poker suits, so I drew those and a full set of ranks (ace to king). That was about enough, I figured; I never really expected it to take off like it did. When it did take off, I was kinda caught off-guard and just started adding more and more to it while feeling like if I stopped to rethink then it'd lose people's interest.

Getting locked in meant I got stuck with a bunch of limits that weren't that important at first, but got more troublesome the more I worked on the fonts:

  1. big font files
  2. maximum code length
  3. all-caps codes
  4. locked codes
  5. unique translations

1: Big font files

Each Dicier file's a few hundred kB (except Dicier Pixel), and only a little of that's gonna be used in any one project. That's not a big problem if you're exporting to PDF (most apps will subset fonts as they're added to the PDF file), but it's harder for HTML-based formats like EPUB or websites (in both cases because of Dicier's codes).

2: Maximum code length

I started out making Dicier for myself, and I use Affinity Publisher to make PDFs—but Publisher doesn't display ligatures over 8 characters long. Icons with longer codes, e.g. 14_ON_D20, have to be made with more complex OT features that contextually transform and overlap parts of the icon using fragments of the code (e.g. 14_ON_ displays the number 14 and D20 displays a d20 shape, and typed together the d20 overlaps the number).

These fixes are a pain to add and aren't 100% reliable (see the Troubleshooting Dicier section of the User Guide).

3: All-caps codes

Some TTS apps may read any all-caps text letter-by-letter, even text made of dictionary words (e.g. reading HEARTS as "H E A R T S"). I never ran into this while testing, but it could happen… maybe?

4: Locked codes

You can't change Dicier's codes without a font editor, which can be an issue in edge cases. For instance, if someone makes a game where light and dark dice have different meanings, they might use Dicier's Light and Dark weights for the different types. The problem is, both fonts have the same codes (1, 2, 3 etc. for faces with that many pips), so they'll sound the same when read by TTS software and look the same in plaintext.

Translations are a specific form of this, and way more of an issue than niche stuff like light/dark dice semantics.

5: Unique translations

Dicier's original codes are in English. Every translation uses mostly the same icons, just with translated codes. For instance, French uses the same poker suit icons, but the codes are CŒUR, CARREAU, TRÈFLE, and PIQUE.

Here's what it takes to add a translation:

  1. someone who knows the language (preferably as their first language) checks the list of codes up for translation
  2. they talk with me to fine-tune stuff
  3. I copy and rename >450 icons
  4. I write the translation's OT code
  5. sometimes I need to actually draw new icons (e.g. new card suits for the Croatian translation)
  6. I double-check for errors

This is a bunch of work! Mainly for me. It's also got another pitfall: every glyph name in a font file (so, every code) has to be unique, but sometimes codes clash, e.g. PIK (used in Croatian and German) or KREUZ (used twice in German). None of the fixes for this are great:

  1. use language-specific OT code: You can set OT rules to only apply in certain languages, and you can set the language of a file (or section of a file). So, Dicier could be set up so the only codes that work in your file are the ones in your language. Technically the best solution, but some apps (Apple Pages, TextEdit, maybe more) don't support it.

  2. make 1 font file per language: This would work, but I'd have to make and manage way more files.

  3. add underscores to the start or end of clashing codes: For instance, KREUZ and KREUZ_ (with underscore after). It works, and it's convenient, but it's the worst and ugliest option.


So those are some major, or at least significant, problems with Dicier. The reason I haven't fixed them yet is because fixing them is hard—but now, with a bit more programming experience, I'm in a better place to start working on it than back when I first started on this project.

Edit: none of this is to say Dicier's bad or non-functional the way it is now, it's just that it's inflexible and it takes more and more work to add new icons and translations to it (to say nothing of e.g. adding new styles).

The SVGs-vs-icon fonts problem

One final problem is that icon fonts aren't necessarily the best way to add icons to text in HTML-based formats. Scalable vector graphics (SVG images) are arguably better for that now, with advantages like:

I dunno how things stack up in PDFs, though, and obviously if you're making PDFs for print then almost none of the above actually helps.

The Future(s) of Dicier

Here's how to fix the 5 problems above:

Those are some pretty big asks, though. They're, way, way bigger than the work it takes to e.g. add a new translation to Dicier as it is now. The good news is, like I said above, I'm in a way better position to do this than I was when I first released Dicier. It'd still take a lotta work, but I actually have some kinda plan now, based off what I've seen of services like Font Awesome and Icomoon.

I'm tentatively calling the solution The Dicery.

The Dicery: a mix-and-match Dicier web app

Here's how this would work:

  1. you go to the Dicery web app on whatever website it's on
  2. the app fetches a single font file containing every Dicier icon
  3. you go through menus of all the icons and pick the ones you want
  4. you write in a code for each icon you pick
  5. you name and export your personalised font

That's more complicated than how Dicier works now (“go to itch page, download font files”), but you'd have way more control, and the files would be way more useable online. Plus, it'd be a lot simpler to use with no need to fit all the sets of icons in using OT features. Practically, it'd look a little bit like the code tables that fill out a lotta the Dicier User Guide:

A grid-like table of dice icons and their numerical codes—a blank, square d6 shape for the code “0”, a square d6 shape with a single pip in the middle for the code “1” and so on, plus the same for Fudge dice (plus, minus, blank).

Here are some possible extra features:

The tech underlying this would (hopefully) be opentype.js, a javascript library I discovered earlier this year that can open, edit, and export font files inside web browsers. If I could get this up and running it'd sweep two big hassles out of the way—building translations into the fonts, and using the more complex OT features to make combined icons. All that'd give me more time to design new icons and new styles.

Another option: SVG dice generator

This option would be another simple web app that would work as a basic SVG editor for making d6 dice icons in your browser.

By “basic editor” I mean you'd be able to choose how pips are laid out, what the pips/numerals look like (out of a set of options, or upload your own), what the faces look like (out of a set of options, or upload your own), what colour different parts of the icon are, and then what the title and description are. Then it'd spit out SVG files for 6-sided dice faces, from 0 to 9, according to your design. It wouldn't be too hard to add custom faces like fudge dice (plus, minus, blank).

I say all that like it's super-simple, but honestly it'd probably be more work than the Dicery, for a much, much narrower set of icons that wouldn't be as easily useable in WYSIWYG apps (like Publisher).

What next?

At some point I'll investigate opentype.js in depth and start putting together mockups. There'll probably be some ko-fi/patreon-type crowdfunding involved because this'll be a complex project.

If any of that sounds relevant to you then look forward to it! I'll probably start later this year, maybe early next year.

Return to top