by dpla
Cloned from bin2x2grid_rough by dpla.

Download disabled

The designer of this FontStruction has chosen not to make it available for download from this website by choosing an “All Rights Reserved" license.

Please respect their decision and desist from requesting license changes in the comments.

If you would like to use the FontStruction for a specific project, you may be able to contact the designer directly about obtaining a license.

Clone of bin2x2grid_rough.


The tutorial for this 2x2 grid is here :
Comment by dpla 8th May 2013

What's the difference between a rough and a safe version?

Comment by ImmaPooh 19th April 2017

rough ~ unsafe ;-)


Hi ImmaPooh!

I just downloaded your '4x4' font (finalized on 2016-11-30, and its '4x5' clone b.t.w.)… ^_^

This big message may take a while to read, even days to assimilate and apply its advices.
I hope my limited 'frenglish' will make sense (with the help or Wiktionary and Reverso)…

[OFFTOPIC (with my love)]

By the way, here is a partial comment on it, without waiting (since I still have to search for the new related fontstructions released after 2013, while being busy offline on Wikipedia with pixel and voxel stuff)…
Comment moved to

[/OFFTOPIC (with your hate - kidding)]

Now I have to pass over a few details in my reply (because of the relatively lengthy comment above, and a few more reasons I only want to skate over in public for the time being)…

As I already posted above, a long explanation is provided since 2013, as a 'tutorial'…
So, in case it was not enough to deduct the logical counterpart (to post your wondering there), then please just bear in mind the following considerations, friendly.

• Simply open the both pages ('2x2 rough' and 2x2 'safe') and spot the differences (or the 'evolution'): you get emptied dots in the 'safe' version (which constitutes a selection of 'safe' glyphs)…
Actually, *** 'rough' was another word (of mine) for 'UNSAFE' ***… Then, the 'safe' (= usable) version of the font is just a modified version of the latter, created for the humans (and their 'micro' type designers). It 'disables' visually the 'unsafe' (= 'invalid') glyphs that the original 'rough' (i.e. -possibly- 'unsafe') font kept blindly (you can see that the initial blank columns are discarded - in 3x3, the one in the middle would have been rejected too, imagine it painted in a crippling red).

• At this point, you must have already understood the underlying issue pertaining to the horizontal positioning of the glyphs (all is nicely and conventionally colored in my example files: imagine a dreadful magenta column on the left…). The 'safe' font is variable in width (imagine that its narrow glyphs can include one or more blank columns in green on the right); while the 'rough' font was undetermined in its horizontal spacing (let's say monospaced, if you define subjectively a fixity in this case of very limited width, which is not applicable from 3 dots of width, where you'd get too many duplicates because of the left (magenta) or 'center' (red) blank columns…).

• Didactically, when the humans are part of the 'information interchange' (from the 'Ascii' wording), the dots of the matrix-based characters are bound to be arranged in a visual fashion (i.e. according to the script of language, sorry for the linguistic shortcut…). In Ascii (which is a Latin script), structurally speaking to begin with, our reading needs (at least is eased by) a coherent separation of the characters (horizontally and vertically), a direction (left to right, with an implicit or omitted top corner), and a (contextual) uniqueness (vs. 'O/0', even 'V/U' in the past). The rest of the mandatory design is less specific (to a grid-based family all the same), like a mix of some 'historical conformance' and 'skills in graphics'. The so-called legibility is thus a compound of the written prerequisites (= the objective discriminations), and of a secondary work (= the subjective art).

• In practice, with '2x2' grids, we get (2^4=) 16 candidates (as virtual glyphs) to map the font characters with (you know how to count from 0 to 15 in big-endian binary: "00", "01", "10", "11", "000" etc. up to "1111"). You realize that it is by far too short to encode the 93 or 94 ones that are needed in basic Ascii. On the contrary, with e.g. a 3x3 matrix (512 possibilities), this is quite (computationally) feasible (the humans will strive to retain the less ambiguous glyphs, though, as you did yourself). This is why this type of 'too-small' grid (in basic Ascii) cannot but be used for placeholders fallbacks (where e.g. "X" and "O" could share the same 2x2 glyph visually using its '1111' binary value). Designing the placeholders (or filling the blocks of text with unreadable gibberish, in part or in all) is another topic for later (since it is unanswerably less useful, even less Ascii-wise respectable, at least in my to-do list).

• The 'micro' fonts have many limitations (more than in this topic, e.g. about the ranges and styles). Building some conventions become a necessity (I defined myself a few specifiw neologisms, even had to design a classification etc.). One part of this shortage of freedom in design comes from strong matrix-wise limitations, like the vertical blanks. Many type designers stumble against these difficulties. {We have to regret that they are still all newbies in these fields of creation, where a standard background of type design, besides knowledges in pixels and code crafting are very helpful - I found no specialists with this multidisciplinary attention, in terms of years of experiments, not only of hours or days of recreative or frustrating pastime, but a handful of serious projects tried to emerge all the same, e.g. from 3x5-based grids… I am currently reviewing their efforts, while the rest of the trials are incomplete fonts in basic Latin, included in my comparisons too.} Most of these designers often surrender, when the grid is made of 12 dots or less, by adding e.g. more width (typically on "M/W/m/w"), if not more height (e.g. on "@"), the both being even weaker. This is always a great waste as a whole (considering the space, elements, energy, and memory usages… like a kick into touch, sometimes a lie too, when the goal was e.g. a gain)…

• When you design a 'micro' font, the monospaced version cannot be the reference (as it resembles a lot the 'rougher', full, easier-to-design but a lot more ambiguous binary version, crippled with unusable per-width duplicates (even Braille discarded this major design flaw in the 2x3 binary layout for his script -not a font-, where he could afford getting free of our ancestral Latin shapes by the way, as the computers do). At present, I don't feel like explaining again the differences between fixed and variable width in dot-based fonts. Try yourself converting your monospaced font to get the mentioned pitfalls. This is feasible, all is a matter of (sometimes bad) choices and more or less logical conventions (humans are analogical by nature, that is why my thousands of related fonts all begin with the variable width, where one character cannot be different from its neighbour just because a lazy designer could move it horizontally thanks to his monospaced-only abuse).

• If you needed a least example, try designing a dot (the punctuation or symbol) in 2x2. From the original, "rough" version, two candidates stand out substantially (always in binary), with "01" and "10" (1 and 2 in decimal, respectively) on the bottom row ("00" on the top row in the both glyphs; their full big-endian binary being therefore "00 01" and "00 10" without the spaces). Now tell me: is it 'safe' to use "01" instead of "10"? (with a variable width or not.) I don't think so (then I discard "01", i.e. the leading blanks, at the design step, because I don't mix the glyphs and their formatting, it'd be unsafe in many ambiguous situations, e.g. when the glyph is displayed alone at distance, or when its horizontal juxtaposition produce one or more unexpected duplicates from a pair or trio). Moreover, is it 'safe' to state that e.g. "01"="," and e.g. "10"="."? I don't think so either (then "I take the wind out of the lazy hackers' sails", before they try to delude people by abusing of the relative freedom of horizontal spacing, namely the deceptive extra glyphs that the monospacing style offers, because I don't mix the glyphs and their displaying).

• In this field of minimalist creations, a built-in spacing is typically of exactly the same width as the actual space character: 1 dot (or block, pixel, voxel, element etc.). This is the main reason why it is coarse and counter-productive to use it on the left as a mean of extension of the possible set of glyphs, while it is very likely to be ambiguous when it divides the glyphs like you did in your 4x4 font (see the point right above for more sadistic sermon…). A leading built-in blank makes the glyph less legible and spoils or weakens the space character (which is one of the most important punctuations in a font, if not the most important character at distance). A middle (centered or not) built-in empty column splits the glyph into more glyphs directly, and indirectly into even more potential duplicates. As a general rule, in 'micro' typography, avoid including built-in spaces like the plague; the only ones that are really necessary are added at the output (final) step (by a software generally): the displaying of the monospaced is indeed of formatting nature. The design has to be variable in width (as most of our Latin characters are).

• My tip/rant of the day: the double quote (with its necessary blank column in the center) is a legacy flaw in Ascii. {I wish I were there in the 1960s to warn the engineers to the tremendous consequence 50 or 60 years after this acceptance of a duplicated glyph as an exception to the rule. I have to remind that a character that is said 'double' horizontally cannot be displayed as a single character when the built-in spacing equals the legal, real one. Consequence: we have to edit our 'micro' double quote or/and single quote… a shame and almost impossible task if you know all the similar glyphs in Unicode in both cases}. ''=" as variable width, misery! (I'll double all my fonts just for this historical and pernicious allowance.)

I must have forgotten many points.
Now you know. Tell me if still not…


Comment by dpla 19th April 2017

yay dpla is back!

Comment by opipik 21st April 2017

@pipiko: I am on the verge of posting on your "micro" font 8-)…

@all: I cannot review all the 'micro' submissions for now, before I feel comfortable with my own 'typeface', sorry… (but privately message me on FontStruct - or contact(at) if you prefer with a decent title else it's spam-trashed.)


Tip/rant of the day: to the ones that still need to design a placeholder (i.e. from a tiny matrix below the basic Ascii prerequisite of sum of codepoints), I see roughly two* approaches (before the artwork), both incomplete pertaining to the width. The first one endeavors to show every visible character (this is my preference [PS example]; major drawback: the original row of text gets like stretched); the second one strives to display the corrected percentage of width (horrid drawbacks: the narrowed/cut glyphs get unreadable without fixing them by hand -when it is feasible, which is rare-; some may have a null width and become invisible; e.g. "SmallFonts" - it destroys a well-known spreadsheet for many years without an alternate typeface like mine… who cared? just a great deal of millions of real customers… :/)

So much so that I postponed this kind of fake fonts sine die.



* PS: besides the old(skool) way: 1x1 pseudo-font (or stretched to 1x2) where chrs 33-126=1, 32(space)=0… (kind of useful to highlight the words.)

B.t.w. 2x2 pseudo-fonts (or enlarged to 2x3) may have different looks (e.g. dithered like a checkerboard, the so-called 'artwork').

B.t.w. bis: Wikipedia's definition of a placeholder is incomplete (I may edit this item in the future): it is not necessarily a 'filler text', i.e. made of actual text. Word-looking pixels are enough to be deceptive (as in pixel art)…

@ImmaPooh: these grids are not fonts (of characters), but they can help the new 'micro' designers understand on one hand that the possible glyphs are often more numerous than they expected (beginning from e.g. 3x3), and on the other hand that they should discard the unsafe ones (all the duplicate-related issues, especially as variable width). You can understand 'raw' instead of 'rough' if you prefer, pertaining to the binary grids that anyone can generate from a script. As human readers, we need a selection that match our known characters, something less 'rough'… that was the idea in 2013, I assume.

Comment by dpla 23rd April 2017

In the following example
 ("IAM" glyphs in a -too wide- 5x3 grid):
• Green = valid (= left-aligned = monospaced-ready);
• Red = invalid (e.g. "Il|‖i" = bad trick/hack in row #1).

We need to classify all the horizontal duplicates as INVALID
in order to let the human reader get one unambigous mapping.

As a proof, try spotting yourself my expected "IAM" letters…
(Counting the extra/flawed spacing pixels is almost undoable!)

Comment by dpla 1st August 2017

Also of Interest


Get 10% off the world’s leading font editor for OSX.

More from the Gallery

D33SPMby dpla
D33SPM V25by dpla
Retro gamin, wasted matrixby dpla
bin1x4grid_rough_safeby dpla
Mobivusby Michel Troy ~UrbanPixel~ (Upixel)
zteamboat eYe/FSby elmoyenique
G1 Frilleraby geneus1
Emily Playby laynecom

From the Blog


Twenties Comp


Supporting FontStruct: Introducing FS Patrons


OpenType Downloads (with CFF outlines)