An extended fork of GNU Unifont with a focus on high compatibility (and accessibility too, among other things), made from the last TrueType version of GNU Unifont (15.0.06-JP, which is the most comprehensive), merged with the last version of Upper that will successfully merge after removing the placeholders (11.0.01 Upper). I then did several compatibility steps to make it work under more environments, such as taking SEVERAL measures to make the font work in environments that only want monospace fonts (which Unifont is closer to than something like Times New Roman), as well as fixing the TeX table (among other structures, including stuff like the Panose and OS/2 stuff, among other things), activating Vertical Metrics to make Inkscape not reject it when dealing with Vertical CJKV text (the VDMX table and the BASE table's vertical section also help), and making the output TTF work best on ALL OS choices. I also used TTF2PNG by Data Beaver's Domain (plus GIMP to make it true 1bpp) to make an unabridged 1 megabyte PNG of the font, for use in situations where TrueType wouldn't make sense, as well as a BDF version also made by FontForge, and a PC-98 font BMP port of UnifontEX made by Neko Project 2 (the Wii port) from the TrueType. (This is for PC-98 emulators that expect ANEX86.BMP), as well as an Apple iOS Safari SVG webfont format version, plus WOFF and WOFF2 versions which are MUCH smaller, as well as the FontForge SFD version (the actual project file). I also added an EOT and a Proof-of-Concept SVGZ version, as well as a Mac DFONT and an X11 otb version for those using relatively-ancient Unix-like OSes. I've also made a special version derived from the TTF ran through BWTC32Key, renamed to have a .woff3 extension. Apparently, BWTC32Key's compression significantly beats DEFLATE and Brotli here, as well as in quite a few other cases. BWTC32Key being web-based (in JavaScript at least until someone ports it) allows it to be decoded in browsers, so technically WOFF3 COULD be decoded by a browser. But yes, WOFF3 is literally a TTF/OTF inside a .B3K file with a .WOFF3 extension. I'd even allow TTCs and OTCs to be inside that. For the WOFF-exclusive stuff like XML metadata and arbitrary data, I'd allow use of a TAR file rather than the font directly. I would likely need some form of convention regarding the contents (for a whole host of reasons), so for the moment I'm going simple. Oh and the 3 in .woff3 is an intentional reference to the 3 in .B3K, and it being a third WOFF version (and no, WOFF3 is not the only planned format I've derived from retrofitting BWTC32Key into various things). It just needs decoding code written. I've also provided UCGLIB and U8G2 versions for Arduinos to use with compatible dot-matrix LCDs/OLEDs/VFDs, though at present the best Arduino to run it on is the Arduino Pro Portenta H7, which luckily is compatible with both.
I've also made binary and C builds for the LVGL embedded display library, so now you can use it on even more embedded displays, and I've also made .js and .json versions for Typeface.js, plus FONTX2 Kanji and non-Kanji versions for DOS/V, as well as a C Uint8t file version that evidently some programs use, as well as an Adafruit_GFX version.
I also made a PostScript Type42 (PostScript-encapsulated TrueType) build for old classy printers as well as a LibreCAD LFF version, plus an iOS Mobileconfig version.
Basically, I've released builds for MANY formats, from the common (TrueType, which is no longer offered openly by upstream Unifont), to the most niche/obscure ones, of which BDF is the only one also offered by upstream Unifont. Stuff like the DFONT, BDF, OTB, WOFF1, EOT, and SVG versions are largely for legacy systems, because not everyone has the latest and greatest technology.
Sleeker page here
Firstly: You gain the fancy letters intended for math but used online to make social media posts have fancier fonts. This includes Fraktur, which has its own ANSI escape code that is defined but rarely used. Those characters, and their bold versions via the bold flag, now work.
Secondly: You gain emoji from 2018 and before (nothing newer due to being forced to stick to Unifont 11.0.01 Upper as the Upper version), as well as the rest of the characters in blocks that emoji only uses part of. So yes, you get the whole Playing Cards block, the whole Domino Tiles block, and the whole block allocated to Mahjong tiles. You also get all the symbol characters that didn't get emoji status. Stuff such as U 26FF, which is in the Miscellaneous Symbols block, and just so happens to be equivalent to the Rumpus Parable Agender Pride Flag from 2014. Yes, Unicode has THREE pride flags, not two. Samsung temporarily made the character an Emoji on some Android firmwares of theirs. You get the Alchemical Symbols block, including the Sublimate of Antimony symbol, which has been co-opted by nonbinary people as their gender symbol rather than the traditional male or female symbols (which DO have emoji status). So yes, this build of Unifont features the nonbinary symbol on top of the Plane 0 stuff like the transgender symbol, the symbols for various orientations, the Rumpus Parable flag, and etc. Oh, and unlike MANY Plane 0 fonts, Unifont DOES have U 2B89, something that accidentally resembles a gender symbol in the online LGBTQ furry community, one that is rarely used.
Third: You get many OS symbols not in Plane 0, as well as a full set of Wingdings, Wingdings 2, Wingdings 3, and Webdings, many of which ARE emoji, and many of which are NOT.
Fourth: You get more geometric symbols and historic scripts.
Fifth: You get both modern and ancient musical notation.
Sixth: You get "Transport and Map Symbols" as part of your emoji set.
Seventh: Having emoji makes you comply with the Shift_JIS extensions made by Japanese telephone carriers.
Eighth: You can handle more obscure dingbats, as well as the Japanese ARIB captioning character set standard.
Ninth: You have more characters to work with for the purposes of Unicode art, especially when doing animated Unicode art, especially when you are dealing with more than just BW. There's more characters to derive brightness values from.
Tenth: You can view even the most esoteric Kaomoji (Japanese emoticons that aren't emoji, such as the famous table flip one), including the ones that DO use emoji in them.
Eleventh: You gain more types of enclosed letters.
Twelfth: You can pass the current version of the BLNS test (a test file for string handling).
And that's only the beginning.
As part of the compatibility focus, the x in the filename "UnifontExMono" is lowercase just in case programs looking for "Mono" to determine monospaced status want a clear distinction. Also, I chose to use no symbols or spaces in the font name to make it work better on picky systems. If your system wants variable fonts, rename the font file to have "-VF" at the end before the extension, which can be .ttf or .otf (yes, TrueType fonts can be made to comply with OpenType too. In FontForge's TTF export, I turned on the "Apple", "OpenType", "Dummy 'DSIG'", "Windows-compatible 'kern'", "TeX Table", "FFTM Table" and ALL the PfaEdit Table checkboxes, so that the font would work on as many systems as possible. Also, the MATH, BASE, and JSTF tables are all fancy OpenType tables, so they further seal the deal, and tables they depend on like GDEF are present too. VDMX is listed in Microsoft's OpenType spec too. UnifontEX is basically what those in the industry call an OpenType TT
font, referring to the outline format being TrueType's. Also, regarding all the checkboxes in FontForge, I left those checked when generating the other SFNT formats. Yes, the DFONT had Windows-compatible 'kern'
checked, and yes, the EOT had "Apple" checked. And OTB also had the combo too. Basically, these cross-vendor checkboxes all come into play if you use FreeType to read DFONTs on Windows/Linux/BSDs/Hurd, or use Internet Explorer in Wine, or are using the EOT as the webfont URL in a browser other than Internet Explorer on a different platform. Most people won't do this, but they exist just in case. The OTB stuff may come into play if you're using WSLg on Windows 10/11).
Note that dashes on Linux are what are often used for command-line arguments, so that could confuse Linux machines, and heck, even old Kindles may have issues with their font enabling if "-VF" were added. Also, I chose to make the name of this version of Unifont distinct from the official version, because this is a specialized fork that diverged from non-current versions of Unifont (though not horrifically so by any means). That being said, I did
take quite a few measures to keep things faithful to the original. Compatibility is key. That's why I'm keeping the OS/2 table version identical, not touching the GASP table, and etc. The goal of this project is to build on Unifont to make it even greater than it already is, and to do it one better in many ways. That's why I'm so dedicated to it.
Oh, and by the way: This is a passion project that I have worked on for the last 10 years (because of the February 2nd, 2024 update being in 2024, that makes it a 10-year project. As for why I now say 10 years, I found Unifont CSUR 7.0.06 on a hard drive I last used in 2015, and the file was dated March 9th, 2015. Said computer also had FontForge installed, and some of what I was toying with back then were bitmap fonts, including Earthbound's Mr. Saturn and Lumine Hall fonts, both of which I felt needed more compatibility. I was also investigating the old Klingon characters in Minecraft back then, which I found out were from Unifont CSUR. The original versions of UnifontEX back in its early days used CSUR glyphs, and later Fairfax UCSUR glyphs. Later on, the PUA stuff stopped fitting. But ultimately, the program used to make UnifontEX as well as source was found on this old drive from before I thought the project started. March 9th, 2015 would have been around the end of my 7th grade year, namely the 2014-2015 school year. UnifontEX's first public version, based on Unifont, Unifont Upper, and Unifont CSUR 9.0.06 as well as Fairfax was published to Fontspace on June 20th, 2017, shortly after the end of my first year of high school, and I originally considered this the start of the project. Evidently I was wrong, and the project took 10 years, making it my longest one. I say 10 years because the Mr. Saturn/UnifontEX hybrid was actually from 2014, so it took a decade.), in part because I was waiting for new Unicode and Unifont versions to drop so I could see what was in them. This is the longest project I have done (the runners-up go to two projects, one of which I have spent 8 years on, the other 9 years. The 8-year one is a 3D model of Big Ben, the Eiffel Tower, and the London Monument To The Great Fire, made in 2014 via merging MakeALot's models of said structures by importing them all into MeshLab at once. The result needed a stray triangle removed, and printability fixes, which took the longest, namely 2022, but I haven't pleased every checker yet, but it's printable. Also it's CC-BY. A statue of mine that I did the same way, also in 2014, was made, and it's CC-BY-SA4. In 2019, I put an extruded version of a vector work I did in 2014 on the round disc back of the statue's head, for similar reasons to the creation of LEGO double-face characters. So that took less. Now for the other many-year (9 years) runner-up project, BWTC32Key. As far back as 2015, upon learning of Base64 and its inefficiency, I'd started searching for ways to do better. I had learned of Base64 when making the 30,000 byte version of my now-3081-byte JavaScript demo, which uses data URLs, though nowadays it uses special ones that only encode truly unsafe characters, done via URL encoding only them. Base64, as useful as it was to me, was quite bloated, and I was like, "surely there's a better option". Later on, after quite a few searches, I stumbled on Base16384, which uses Hanzi, around my second year of HS, and in 2018 I ran into a usable Base32768 implementation, and then threw in compression, then encryption into the mix too, and by 2019 I landed on BWTC32Key, and I improved it into 2024, without breaking compatibility, forwards and backwards. So that was a 9 year project from initial inception, making it the main runner-up), but it certainly was a long haul. I hope that my improvements help you in your endeavors.
In case you wonder why this repo was created a month early, that is so I could write the description to a heightened standard prior to release date, and decide on a name. Expect a better Github Pages site for this, among other things. Oh and the first link is the TTF.
Oh I am legally obligated to say that GNU Unifont is under GPL2 with font embedding exception and OFLv1.1, and can be found here and is by Roman Czyborra and Paul Hardy, et. al.
Also, my real-life name is NOT something I give out online willy-nilly, just in case you find yourself needing to know it to follow the crediting part of GPL2, in which case you should credit me as "stgiga". Online, I basically only use aliases, because I'm VERY paranoid about online safety, especially given the fact that I quite literally am certified in cybersecurity. And yes, you would be right in assuming that I use this Unifont build in my IDEs and terminals. As well as my Ubuntu window titles. As well as other stuff.
With that out of the way, I hope you enjoy this project as much as I enjoyed making it! Have fun, and do honor the original devs of Unifont. They do great work. Enjoy!
Also, if you want more glyphs (such as emoji from 2019 and newer, including the ones related to assistive technology) than can fit in the 65535 glyph limit in a conventional TrueType/OpenType/WOFF/WOFF2, please tell the OS and browser vendors to bring back Apple's iOS Safari pure-SVG webfont format (which, unlike SVG-in-OpenType, supports unlimited glyphs, so you could fit in ALL variation sequences if you wanted, define arbitrary tables like porting Apple's Zapf table used by Zapfino, as well as porting the animation and color tables from SVG-in-OpenType, and also using even Microsoft's diverse family ZWJ sequences. Also, you can embed PNGs for bitmap glyphs to help with rendering if you want, and implement the contextual shaping in scripts like Arabic, without worrying about glyph counts, especially when working with ALL scripts that have variations. Oh, and while uncompressed SVG fonts would be large (most likely why they got eschewed), I did try a merger of GNU Unifont 15.0.0x with 15.0.0x Upper with 15.0.0x CSUR (something VERY impossible in classic TTF/OTF), and then made it into an SVGZ (officially-standardized GZipped SVG, but has no MIME Type), and it gave a result that was the same size as a WOFF2 of my TrueType merger. So, have the OS vendors support SVGZ as part of the equation too. Also, please tell the W3C to give SVGZ its own MIME type so it can be better-supported by browsers again so that with the help of XHTML integration, we can have smaller webpages for people on slower connections, without having to fiddle around with Apache's httpd.conf or IIS's equivalent to it. Oh, and SVG(Z) webfonts would also allow the entire Unicode Code Charts font to be usable as a fallback font in OSes if needed, which could prevent missing character varieties of Mojibake entirely (assuming no Private Use Area characters are used.) It would be an even more successful fix than Noto or UnifontEX could ever be. All it takes is for the OS vendors, browser vendors, the W3C, and the Unicode Consortium to team up. But until that happens, we are stuck with what we currently have: 65535 glyphs maximum due to conventional TrueType/OpenType/WOFF/WOFF2 limits, and httpd.conf editing to allow loading of any SVGZ content, to the point where you need to set up a server even if you are running it offline.
Also, regarding the above, I am NOT in favor of anyone engaging in harassment when asking. Harassment is one of the MANY bad things I personally have endured from a young age, so please don't engage in it. I figured I should say this to avoid any possible drama. I'm someone who absolutely hates drama of any kind. With that out of the way, I hope that there will be better support coming soon.
I recently learned that HarfBuzz has been extending the TrueType/OpenType format to support over 65535 glyphs as well as make TrueType do BOTH cubic and quadratic outlines. It does require renderer updates though.
Oh fun fact: The 16px size of UnifontEX's emoji (namely the fullwidth ones) is actually slightly bigger than the 1999 DoCoMo emoji (which were 12x12), but the 1997 SkyWalker phone by SoftBank (which was the first mobile emoji set, because some earlier Sharp and Canon typewriters, PDAs, and word processors had what we would now call emoji on them in 1991, according to emoji.digital which has a whole section on them, and Emojipedia just found out that 16x16 emoji were used in a Sharp PDA from 1988 according to emojipedia which is absolutely amazing. Good to see 1980s-era emoji!) used 32x32 emoji in Emojipedia's examples of them, but looking at the image directly implies they were doubled from 16x16 by Emojipedia. Also the Copyright and Registered symbol looks like some versions of KDDI's.
The fun thing about UnifontEX being 16px though is that 16px on Windows is actually 12-point. Now, the MLA style guide that educators often use does not force Times New Roman, only "a readable 12-point font" (some educators will force Times New Roman, and APA DOES force Times New Roman in SOME versions, so don't do your papers in UnifontEX unless you have permission AND are using MLA or any other style guide that does not force Times New Roman), so, depending on the educator, you COULD write your papers in UnifontEX if you are using MLA or another permissive style guide. I mean, Unifont is exactly
12-point on Microsoft systems, it just has no subpixels at all. Also, I'm VERY sure that using emoji in your papers would be a very
bad idea. Now, IF you work as, for example, a technical writer (which is the career path I am on), there is no
better font than UnifontEX. It's 12-point, and it has MANY technical symbols and pictographs in it, even compared to stock Unifont. Oh, I should mention that large-print medicine bottles in the United States (or at least California) are printed at 12-point. So, 12-point is not considered an unreadable font size.
Now, I should also mention that ANOTHER thing that UnifontEX is useful for is stuff like creative writing, particularly if you are exporting to PDF. Quite a few sites with literature sections do stuff in PDF. I also use Firefox to force ALL page fonts on ALL websites to UnifontEX. Also, on Windows 11, any emoji involved that are newer than 2018 will be rendered by Segoe UI Emoji, so modern emoji DO show up.
Also, I feel like web literature would be something UnifontEX would be handy to use in, so writers could have access to technical symbols in something like sci-fi stories. I certainly know that anything I write from now on WILL feature this font, because it has quite a few special symbols handy for some of the things I intend to write. Now, when I'm actually working as a technical writer, I will be using a UnifontEX build in which I turn on the "No Subsetting" box in FontForge, meaning that apps like Word will never subset the font. At that point, I could afford the storage overhead, and it would allow collaborators who do not have the font to work with the document. However, I DO know that quite a few existing sites DO cap PDF size, so to avoid possible bugs on your end, the UnifontEX released here does not have that box checked, so have no fear of oversized files.
Now, I'm stating the obvious here, but if you integrate this into whatever you do, avoid doing something with it that would truly enrage the FSF. When in doubt, ask.
Additionally: Another use I've found for this font is for boosting Unicode support on legacy systems (including devices like the Kindle Touch). You even get emoji (up to 2018, but then you get Plane0 characters up to 2023-24, so stuff such as the Reiwa Era symbol, the Symbol For Type A Electronics, and quite a few of the extensions of certain scripts that were slotted into Plane0 are all present.) Throw this into ReactOS, and you have better Unicode support. Or you can give older-than-dirt machines better Unicode support, which can help if using InterWebPPC on a Tiger or better PowerPC Mac with a G3 or better (even a Power Mac 7500 can be coaxed into running a Mac OS X version that will work, but it will be slow), or Basilisk XPMod IA-32 (Firefox fork) on Windows XP with a Pentium 1-derived CPU with CMOV instructions, or Firefox 52 KernelEx on Windows 98, and allow the modern web to be more browsable on older machines, especially if emoji is involved. It's even useful for updating the emoji support of machines just old enough to be stuck on older emoji versions with no upgrade paths, but not ones from the 1990s or prior to the 2010s. For instance, I have a 2013 MacBook Air running Mac OS X 10.9 Mavericks (also 2013), and it has such a small drive that it was always upgrade-challenged with regards to macOS versions. Adding UnifontEX allowed it to go from 2013 emoji (the year before Wingdings, Wingdings 2, Wingdings 3, Webdings, and the other dingbats and characters added into Unicode then were added) to 2018 emoji plus many more symbols, including Unicode 15 Plane 0. So, if you are using a secondhand computer, you can attain fairly-reasonable levels of Unicode support, even without installing something such as Linux, BSD-family OSes, or Hurd (yes, I know what that is.) Many people are stuck with older machines or devices for one reason or another, and UnifontEX can assist with how they handle Unicode, especially given how often people on various websites use Unicode to make fancy text. Being able to at least see something other than mojibake or boxes is a good thing. Personally, I just tell Firefox (or any other browser capable of overriding page fonts) to set ALL page fonts to UnifontEX, but that isn't strictly necessary.
Also, now your terminal and IDE can support Unicode better, which can definitely help when localizing stuff.
Additionally, all the circled and boxed letters, the checkboxes, radio buttons, check marks, X marks, the number dot/comma, etc. al. and the consistent font pixel size make using UnifontEX for creating school assignments, surveys, or polls very attractive (especially anything in Scantron style.) Oh and yes, I've physically printed UnifontEX documents and they look fine. It is after all, the size recommended for essay text, and the font size for California large-print medicine bottle labels.
With regards to accessibility, while this font DOES enable one to engage in Unicode overuse, it DOES at least rid them of mojibake on older devices, and it does at least allow one to not have to represent certain symbols as images. Also, there were several accessibility decisions made: firstly, according to FontForge documentation, it is said that hinted fonts can flicker when animated/moved. This can create an epilepsy risk, so hinting is being forsaken. Even the Kindle Touch does not need it. Secondly, this makes CacheTT only produce a VDMX table (and even then you have to tell it to). Apparently, LTSH and hdmx tables being present indicate a font is non-linear (this doesn't concern VDMX). Android 14 made accessibility font scaling non-linear, and what this does is impose a maximum size for magnified text, which could be a problem for users with low vision. So, UnifontEX by having an orphan VDMX table due to not being hinted (hinting sets certain bits in the head table, which CacheTT looks for when determining what to do, and if it doesn't find them, it won't generate hdmx or LTSH tables. Microsoft says this happens because the font is already linear. LTSH = linear threshold, the threshold at which a font becomes linear. hdmx is married to this. VDMX however is not reliant on either of those two tables or two bits being present. It's like a cousin to those two tables. Microsoft apparently uses VDMX in UI fonts but not hdmx or LTSH. I guess UnifontEX is a UI font...) improves vertical text handling as well as general spacing and accessibility, getting the best of both worlds. Basically, by not going for hinting, UnifontEX in two ways becomes more accessible. Oh and it's handy for typing physics-level math symbols into a document for people with dysgraphia (this was pretty much my first use for it early in development) so that they can do math. Don't get me wrong, inserting special characters isn't exactly quick, even in LibreOffice. But the fact that it has plenty of math characters not in most math fonts, PLUS the MATH and TeX tables is what makes it quite useful for doing math work when you can't hand-write it. Obviously tell your instructors.
Also, I see plenty of accessibility device applications for it beyond the TrueType version, like for TDDs and AlphaSmart clones using the 1MiB PNG version. The idea is that you could express a LOT more than just ASCII on one. It's got all sorts of glyphs from all over the world, and it has symbols found in all sorts of different disciplines, so if you're having an international and/or specialized conversation over a TDD you can better get the point across. The sheer amount of pictographs is helpful when literacy is limited, and it could also be useful in character LCDs/VFDs/OLEDs in a kiosk. Or for making larger bubbles on a form intended to be read by a machine. There are just SO many ways you could use it in an accessibility context. Signage for those who have limited literacy, and that's not even all...
Also, it works wonderfully on even a Kindle Touch (it does require some tech skills to install), so now you can see fancy text (and a LOT of Unicode in general) on an e-ink device from 2012. It works on newer Kindles too. Kindle Touches are cheap and they have no backlight so they last nearly forever before you need to charge them. They're perfect for those who travel often or who have power outages often. Now these can do Unicode better. And these aren't the only devices UnifontEX supports!
With regards to LCD usage, on May 11th, 2024, I found a better-trodden way of getting it into a character LCD/VFD/OLED than before, and it all started when I did some searching of "UnifontEX" on Bing (I frequently see what people do with my content), and found that there was code to make the Unifont BDF (including elusive higher-plane characters normally obtained through compilation) into a u8g2 C file (it can also export ucglib too) (and I knew that the BDF was usable for this last week, I just didn't know quite how to implement it). Sadly, both the Windows and Linux versions on the Github page gave assert errors on the RLE step when trying to handle the whole BDF, but the specific bdfconv_2_22.exe
converter deep in the u8g2 repo just happened to work (including RLE), and it works for both ucglib AND u8g2 outputs. Having said that, I've specifically instructed bdfconv_2_22.exe to export the entire font (which forced me to use this particular version). As such, I highly advise using 8 megabytes of external memory if you do need any (it will work regardless of ucglib or u8g2 usage). Of course, if hardware support of TTF2PNG happens, you have a lot lighter load. I DID try to make an old-style U8GLIB version for older stuff, but the problem is that usually only 256 characters are allowed at once, and Unicode support is spotty at best, so like with PSF, it's not worth doing.
Funnily enough, a day after making the U8G2 and UCGLIB Arduino versions whose file size is within 8MiB but bigger than 4MiB, I found out that there there IS an Arduino with 8 megabytes of RAM and 16 megabytes of flash storage, the Arduino Pro Portenta H7. So if you use one of these, your life is made much easier. Also the Portenta X8 is just an Arduino and Raspberry Pi having a baby, so that is probably excessive, and the Portenta C33 is a budget and mysterious board, so I can't verify if it will work, and the maximum non-Pro Arduino memory is 1MiB, so IF you want to use UnifontEX on Arduino, you MUST use a Portenta H7 at the time of writing. Also, the UCGLIB version almost uses all 8MiB of the Arduino Portenta H7's RAM, while the U8G2 version is significantly less of a memory filler. In fact, you have about 2MiB free, so unless you are locked into using a display that requires UCGLIB and does not work with U8G2, I wholeheartedly recommend use of the U8G2 version because it will make the lives of your engineers and developers easier. So the game plan here is to get an Arduino Portenta H7, and a display compatible with U8G2, and then you can have full UnifontEX on an Arduino-controlled display, AND you aren't needing to include what is effectively a Raspberry Pi in your display board alone. Also, a lack of known solutions now doesn't mean they won't be developed, so the RAM cram feng shui won't be needed in the long run if you want to have the pony of using your UCGLIB-only display. Funnily enough, some of the Noritake VFDs I originally wanted to order UnifontEX on can work with this Arduino pipeline and also the SED1330, by the makers of the Roland MT-32's display, as well as a certain HD-series controller, as well as some displays that have 400x240 (3DS top screen 2D resolution), and 320x240 (common 40-column retro computer resolution). The question is what display do I want to toy around with? I'd probably go for the 400x240. So hook one of those to an Arduino Pro Portenta H7, and then you can be in business. Unabridged UnifontEX that can actually display 15 lines of text, on a dot-matrix display. Think of the uses! (Obviously you can go for the smaller types of displays supported by U8G2, I just chose this one due to it having the most room, also the controller is part of the display, so I can more-directly interface the display with the Arduino.) There's so many things one could do.
Hopefully I can use this whole arrangement involving a beefy Arduino to make a planned Unicode TV head costume like the Mk.2 version (24x18, I can center each glyph vertically or make them bob up/down by one pixel, and I can do 3 halfwidth glyphs at a time, or I can do one halfwidth plus one fullwidth, or I can do a centered fullwidth, and the Mk2 has mobile control so I can just send that. Obviously text would scroll, and the emojis present could allow me to have a "face". Also I'd decorate mine in a manner akin to my fursona) on this website.
Also, if you're designing display hardware, now you can have most of Unicode in your display at once. I'd always wanted to see it on an LCD, and now I might be able to have that pony. From other experiments people have done with regular Unifont, like this one I feel like it would look GREAT. Now, building an AlphaSmart clone around it may be a bit daunting (it would be easier with that 400x240 display), but the TV head idea or a souped-up PC-connected LCD that shows stuff on command (even Tamagotchi characters are in UnifontEX's Unicode support, and proving THAT took most of a day) would be cool. I was also thinking about using such a display on a shirt (or hat, though the TV head is more bombastic in that role) to display messages without speaking, namely due to me talking too fast to be completely intelligible. Throw in a brain-to-computer interface like I've always wanted, and we have Lumine Hall from Earthbound in real life. And yes, I've named my TV head costume Lumine, after Lumine Hall. None of these are the only applications for UnifontEX LCDs, and I've listed many in earlier sections of this giant readme, but you could do so many things with a dot-matrix LCD/VFD/OLED that supports a giant chunk of Unicode, really, the only limit is your imagination. Why wouldn't you want a low-budget text display capable of displaying a very large chunk of Unicode? The utility of such a component in electronics would be boundless. I'd love someone to actually seriously do something with this. It even got used in a web app as a webfont (albeit the sucky WOFF2), and it was liked by a Japanese Mastodon developer with their own gacha game for font names.
Also, to those who have used UnifontEX in games (at present Gem Frenzy, Ocean's Heart, Teatime Samurai, and Marsinah do) or at least something (even their coding workflow), I applaud you. I spent 10 years on this, and I hope y'xll find use cases for it that I haven't thought of in this giant readme. And on that note:
TL;DR: UnifontEX's use cases could fill a book (literally). This README is lagging my Firefox, so I'm not going to start listing more (not to mention I'm falling asleep at my keyboard so don't expect a SourceForge readme update today). Go enjoy UnifontEX!
In memory of Albrecht Biedl, the Berlin professor that the original creator of Unifont, Roman Cyzborra, according to his website, had as a thesis advisor, who passed away on December 16th, 2023. I'm glad he lived to see UnifontEX.