KOEN
All notes
CODE & DESIGN

A different zero, the same source character

D2Coding’s alternative zero shape raises a small question about reading code—and the settings needed to reproduce what someone sees.

Two green oval paper shapes with a dot and a diagonal stroke beside a magnifying glass

Was that a zero?

Imagine reviewing a line of code. An identifier contains the digit zero, but it looks like an uppercase O. Read one character incorrectly and you can spend time looking for another name even though the code is fine.

You can zoom in or inspect the original character. Still, it would be useful if the distinction were easier to see before anyone had to squint.

The official D2Coding repository describes a choice of zero shape in version 1.4.0. The default is slashed; enabling the OpenType feature cv01 substitutes a dotted zero. The same option is available through ss01.

This changes the drawn shape. It does not replace the zero stored in the source file with another character.

A choice of one small dot can seem trivial until you think about where a person reading code pauses.

My editor, your terminal

In that imagined review, suppose one person is looking at an editor and the other at a terminal. Does ‘There’s a zero here’ mean they are seeing the same shape?

Installing the same font does not establish which font each app selected or which features it enabled. Matching the font’s name leaves settings to inspect.

D2Coding documents the zero option separately from programming ligatures. Someone who only wants a different zero need not want operator sequences drawn together too.

For this example, I would want to know the app and the enabled choices. ‘It looks fine on my screen’ is not enough to reconstruct someone else’s display.

Korean comments add another consideration to the line. The documentation specifies a Hangul syllable’s advance width as twice that of a Latin character, placing both on a common grid.

Reading that design description does not confirm that every character on my screen came from this font. A character rendered through a fallback can change part of the result.

I would keep the stored character, the shape on screen and the font drawing it as separate things to establish.

After ‘this looks wrong’

Suppose the imaginary reviewer sends a screenshot saying a line looks odd. We can examine the picture together. Reproducing it takes more information.

The official D2Coding specimen provides a size ladder, a character-coverage check and a report template for settings and environment. It gives the observation somewhere more precise to go.

In this example, I would ask for the string, font version, app and size settings, including whether the alternative zero is enabled. To ask someone to recreate what I saw, I first need to describe what produced my view.

How much time a font saves needs a separate measurement. The existence of an option does not establish a percentage improvement in productivity.

I do appreciate the direction: less unnecessary guessing over a character. Small distinctions matter on a line where Korean comments, Latin identifiers, numbers and punctuation sit together.

Some readers may prefer the dot; others may be accustomed to the slash. Giving them a way to distinguish the same character seems more useful than choosing one appearance for everyone.

The two people return to their code. They have confirmed that the stored character is a zero.

Perhaps the source is not what needs changing next.

First, I would like my screen to make that zero a little easier to recognize.

Sources