Ascii Font Art

[Jonathon Burnside]

This tool is powered by FIGlet technology for text transformation and uses the figlet.js library for JavaScript. We acknowledge and thank the developers of these projects, which are licensed under the MIT License. A special thank you also goes out to all the talented artists and designers who have created the diverse range of fonts that this tool offers.

Small fonts have always been fascinating to me, so I decided to make the smallest font possible, which turned out to be 4x4 pixels per character. The font covers the entire range of visible ASCII characters, and most are immediately recognizable. A few characters had to be modified to fit within a 4x4 box, most notably the number sign (#) and the lower case x. I carefully designed the font so that no two characters share the same bitmap.

Although I didn't design this font with any particular function in mind, it would be useful in any situation where compact text is needed, such as on extremely low resolution displays. Feel free to use it for whatever you like.

With the help of an online font editor, I was able to rapidly test this font with sample text. This revealed a number of readability issues, which I was able to improve with a few minor modifications. After extensive testing of this revised font, I was unable to find any words or sentences which were illegible or lacked fluidity, so I now consider it complete.

You understand that your messages are coming to me in that ASCII salad? And that something down at the bottom of a thread is not visible?
And now that you have pointed it out, there is no repair option.
2022-10-15_emc_highascii-no-repair-option18341019 235 KB

Other people have started sending me examples of the messages they are receiving adding to the congestion in emClient. Today I wrote 0 words. It was 14 hours of tech support and trawling the web looking for possible fixes for bugs and design flaws, which generate more messages in this salad. This has become extremely distressing, and dangerous as it affects my medical treatment.

Who are all these users that you know have this issue?
I am interested to compare their issues with the issue that you have, perhaps it will be a good idea for you to ask them to post their issues here.

I am still struggling not being able to red e-mails, why do are the messages garbled when I read them, or in the preview pane, but legible if I hit forward or reply? No one else is willing to waste time complaining, they are assuming that you will fix it if they wait. I am under a lot of pressure and this is causing severe problems. I transferred my db to another machine. I had to install 9.2. Same problem on a completely different machine running a basic Windows 11 Home.installation.

If the file was corrupted, surely it would never look ok? The affected messages are garbage in the read pane, the preview pane, and print preview. Hit reply or forward and the included message is ok. The messages from gmail and my mail server are both affected.

I asked to stop the bolding of unread messages and support told me no, and that I should experiment with other fonts. It appears that some parts of emClient (only some) have problems with some fonts. Still an app problem though, because otherwise it would be consistent.

Is there any way to get this so it's equal width for all chars not just a subset? Ideally I'd like it for all unicode chars but I can live without the weirder ones, emojis and so forth. What I do want is subscripts, superscripts, fractions, currency symbols to all be consistently spaced.

The complex solution will be to set up fallback fonts that do include those characters, and also match the width of your primary font. This will involve "fontsets" and set-fontset-font (see this question and related).

Running Windows 7. Other people who ran into this error seemed to encounter it under different circumstances, so I decided to just make a new topic. If mods feel like it should be elsewhere, feel free to move it - just trying to help get around this frustrating thing.

I was forced to close After Effects via Task Manager as the dialog was persistent. I had used the font before this in CS6, so it's something definitely in the newer versions. Sad how "upgrading" has caused more problems... I uninstalled the font for good measure to be safe. However, I had to use the font in question for this project, and I didn't want to raster the text from Photoshop and then bring it in - a lot more work for something that should be working by itself.

I went back to CS6 and selected another font, then went back to CC2018; it worked, so it was clearly something with the font that After Effects decided to not co-operate with. I fiddled around a bit more and concluded it wasn't that my font file was corrupt. Although the error message was incredibly vague, I figured a way to get around the error, due to the keyword "ascii". The TTF font in question had Asian (Japanese to be specific) characters in its name, so I suspected this was causing issues (for whatever awful reason), so your mileage may vary on this point.

Was told by a friend to update this answer after they encountered it (small world), it seems the cause of the large number of error pop ups would be attributed to reading each individual glyph from font files with unsupported Unicode characters in its internal filename.

To be succint; the workaround in this specific situation is either uninstall the problematic font, or edit and rename its internal font name using a program like FontForge, which was mentioned in the original post.

I'm looking for a 6x8 font which includes the extended ASCII characters as described at -code.com
Languages like French and Spanish use many letters with accents which are in the extended ASCII characters set.

The Glyph Bitmap Distribution Format (BDF) by Adobe is a file format for storing bitmap fonts. The content takes the form of a text file intended to be human- and computer-readable. BDF is typically used in Unix X Window environments. It has largely been replaced by the PCF font format which is somewhat more efficient, and by scalable fonts such as OpenType and TrueType fonts. As of 2013[update] the current version of BDF is 2.2. No future revisions are anticipated. Earlier versions were refer...

I've got an LCD screen to which I can send pixel data. Currently I'm trying to use the Z80 itself to interface with the screen; I understand that a separate terminal processor would be doing this heavy lifting in the real world.

They get characters (typically ASCII-encoded) over a serial line from the computer, and they send keystrokes (typically ASCII-endoded as well) to the computer. As your question only applies to the display part, I'll ignore the keyboard-input part.

The terminal has a character-oriented frame buffer, with one byte for each character position on screen (typically 25*80 = 2000 bytes). The terminal also keeps track of the "cursor position" (the place where to put the next character received, and the place to be visualized with e.g. a blinking block).

A typical CRT needs to refresh every single dot 50 times per second (or so) to avoid nasty flickering. The display is physically driven by an electron beam deflected in a regular "scan lines" pattern that covers the whole screen and is repeated 50 times per second. White and black pixels are produced by switching the beam on or off while passing the pixel position.

For every scan line, it loops over the 80 characters in the corresponding text line, wiring the character code output from the frame buffer to the character generator ROM input, to have the ROM output produce the pixels. Typically, the ROM delivers 8 pixels as parallel outputs, and a shift register first sends the leftmost pixel to the CRT, then the second, and so on for all 8 pixels.

As a text line consists of 10 scan lines, the very same text line is scanned 10 times, and sent to the character generator ROM 10 times. As these 10 lines have to look different (from top to bottom row of the character pattern), the character generator ROM needs more than just the charater-code inputs. It also has scanline-number inputs, and these get counted up from 0 to 9 over the 10 scan lines, before the readout circuit switches to the next text line and resets the scanline-number inputs to 0.

One special feature is scrolling. When your cursor advances past the last row, you don't want it to show up at the first row, and have the screen unchanged. You want a fresh, empty line at the bottom, want every text line to move up one row, and forget the text that previously occupied the first row.

Your approach is fundamentally different, but for a very valid reason. LCDs don't follow the same model as CRTs, there is no electron beam that has to switched on or off at a very high frequency. Instead, they contain their own intelligence so you can send commands from your CPU, e.g. to fill some area with a given bit pattern (assuming it's a graphic LCD). So, your CPU needs to translate character codes into bit patterns and then command the LCD to draw these patterns at a specific location.

Your current approach seems to always transfer the whole frame buffer to the LCD. If that's the only operation supported, it will become quite tricky to achieve a reasonable performance (send at regular intervals, only if something really changed). If the LCD also supports partial transfers (ideally with the size of your character cell), you can greatly improve the process by just sending the area just modified.

c80f0f1006