Is final release based on Unifont-15.1?

[roytam1]

I tried to download from https://github.com/stgiga/UnifontEX/releases/tag/final and its version says it is 15.0.

[roytam1]

and BTW,

Basilisk XPMod IA-32 (Firefox fork) on Windows XP with a Pentium 1

I will be very surprised if this combination works, since Pentium 1 has no CMOV support while VC2015/2017 compiled binaries requires them.

[stgiga]

@roytam1 Due to computer issues I haven't been able to update the releases. Please download UnifontEX from http://stgiga.github.io/UnifontEX/UnifontExMono.ttf

[stgiga]

It's not based on 15.1

[stgiga]

Here's the thing:

Unifont 15.1.0x is not part of UnifontEX. It's based on 15.0.06-JP (final and most comprehensive TrueType version) merged with 11.0.01 Upper (highest you can go. Also 11.0.01 Upper is the last version that can merge with its own version of non-Upper Unifont). It doesn't do 15.1 for many reasons.

[stgiga]

and BTW,

Basilisk XPMod IA-32 (Firefox fork) on Windows XP with a Pentium 1

I will be very surprised if this combination works, since Pentium 1 has no CMOV support while VC2015/2017 compiled binaries requires them.

Well, CMOV was added in the 1995 Pentium Pro, which is still a low-end CPU to run XP on. It was already 6 years old when XP launched.

[roytam1]

Well, CMOV was added in the 1995 Pentium Pro, which is still a low-end CPU to run XP on. It was already 6 years old when XP launched.

yes, but Pentium 1 (i.e. P54C/P55C) has no CMOV at all.
the only processor family in Socket 7 that has CMOV is Cyrix 6x86MX/MII/MediaGXm.

[stgiga]

Due to issues with my computer I'm having to do everything I can on mobile or my backup computers, and updating the Markdown and making a new tag is easier said than done. The SourceForge version can't easily be updated because the FTP login apparently tied itself to my currently-broken (fan dead) PC's FileZilla and resists all attempts at making it not divert from that. And then I have to go to all the sites I posted UnifontEX to and issue updates. Basically, until I get that machine's fan fixed, I can't do more comprehensive updates to anything. The TrueType in the repo and attached to the release are fine, (and presumably the rest of the files in the repo assuming I fully reverted the MATH table addition attempts that didn't work and actually caused problems). Stuff like the PNG never changed (funnily enough the last thing my main computer was doing prior to fan death was me trying to use Zopfli-krzymod, ECT, and Leanify to get the PNG even smaller. In light of recent discoveries it's a good thing that it didn't work. PNG isn't actually DEFLATEd BMPs, rather it's a much different beast, with filters that preprocess image data to make it compress better and it's chucked. Turns out that the filters transform the data in a way that makes integrated circuits intended for DEFLATE decoding have a harder job. Turns out that the PNG as it is now has the filters disabled so the data isn't transformed. And yes, I used PNGCheck and confirmed painstakingly that the entire image is filter mode 0 (no filter). Zopfli-krzymod, ECT, and Leanify all try to select the best mode for size. Well, if I did that, then I would have to say goodbye to easy IC decoding. On the topic of easy IC decoding, it turns out that very little buffer memory is needed. The PNG apparently sticks to a chunk size of 8192 bytes at maximum (surprisingly this doesn't create massive amounts of chunks. Including all non-IDAT/image chunks, there are only 126 chunks in the PNG, so the chunk index value can be 7 bits. Also keep in mind that the PNG is 4096x65536 which makes these figures amazing. Also 4096x65536 is needed to lay out 16x16 glyph cells from U+0000 to U+10FFFF in a way where they can be read sequentially without a lookup table and the associated processor overhead) which means that nowhere near the full data needs to be loaded at once. Combined with the fact that an uncompressed 16x16 1bpp image is 32 bytes, and 8192 divides by 32 to get 256, and that because the PNG is 4096x65536, and the characters are 16x16 max (making a row have 256 characters), it means that a chunk with poor compression will still contain a row. Also in PNG you can stop at a location and cease reading further. Also, not only does each row have 256 characters (because of the 4096x65536 size), but there are 4096 rows (65536/16 = 4096), and both 4096 and 256 are powers of two. Basically you can store the row number as a 12bit value, the column number as an 8bit value and of course the chunk index as a 7bit value. Based on this (and that PNG chunks are isolated enough to have individual checksums), you can use this structure (helped by no filter. PNG can actually select filters on a row basis. PNG is all about rows, which helps here) to make up for DEFLATE's lack of true random access. No need to decompress the entire 4096x65536 1bpp image into a giant buffer. Basically, using the PNG directly as a firmware file flashed onto a 1MiB flash chip (in conjunction with a DEFLATE decoder IC) actually helps matters if embedding it into something like a dot-matrix character LCD/VFD/OLED compared to doing conventional DEFLATE on a 1bpp BMP of the same data.
And to think that the action my computer fan stopped me from doing would have thrown it all away. When I was relegated to my early UnifontEX development computer, I had discovered that there were things that I hadn't added (Sample Text field in the name table which in that day said One font to rule them all, and I enabled the JSTF table like I had then, on an alternate Windows machine. Newer FontForge versions don't like MATH or BASE table addition unlike the version on that old Mac, and in fact attempting it removes more tables, while JSTF added missing tables. Also CacheTT can break certain apps. Furthermore, BASE and MATH tables apparently made Windows think it was plain TrueType, not OpenType TrueType, AND broke Winamp and FFDec, two programs which the JSTF update made UnifontEX finally work on. Basically, my first post-Sept12-2023 update was better. Also I used a program to recompress the DEFLATE streams in the WOFF1 version with Zopfli, getting the file size to under 3 1/3 MB or 3.17MiB rather than 3.7MB, which was already under the 3.768 of WOFF2, which doesn't have a Zopfli-type recompressor. Also, nobody has ported Zopfli-krzymod, ECT, or Leanify DEFLATE optimizations to WOFF1 streams yet (the compressor I used is hard-coded to Google's original Zopfli's 15 iteration maximum, and it doesn't let you go lower), so there is more room for compression savings, but currently-available code can't do it. However, a lack of known solutions now doesn't mean that they won't be developed. Nonetheless going down to under 3 1/3 MB (the WOFF1 just clears 3,333,333 bytes by a razor-thin margin), and 3.17MiB is even more justifiable than simply 3.7MiB, which was already around the size of a typical image (certainly smaller than many advertisements these days). Now it's even more within that figure. Basically, at the cost of one image's (or one ad's) worth of bandwidth, a website can make their support for Unicode MUCH better, improving globalization. Oh also because WOFF1 works on more browsers it means more users. Not all browsers which purport to be "evergreen browsers" truly live up to that standard.

Some observations about UnifontEX that make it rather funny:
The Unifont 15.0.05 (and even more so with 15.0.06, whose JP version went into UnifontEX due to it being more comprehensive) Hangul characters are based on their creator's font "Galmuri Gothic", which was somewhat inspired by the Nintendo DS Korean font (not anywhere near a full clone). The sans-serif fullwidth glyphs in Unifont-JP (and UnifontEX) prior to 15.1.0x have a funny exclamation point that I later found out was like the one in the Japanese game Gakuen Sodom (Don't worry, I've never played it. The intro and OST are safe for YouTube, which is how and where I found out.) Also Unifont's emoji for the "ghost" is actually a monochrome version of the Pac-Man ghosts. UnifontEX carries it over. UnifontEX's Plane 1 smiley emoji characters are based on forum smilies, the Plane 0 ones are based on Codepage 437 (see also playing card suits, also the Tarot cards use Roman numerals), and those plus some of the people emoji (like the bride one) hark back to Zelda 1 NPCs. Also Unifont and UnifontEX emoji at 16px monochrome are equivalent in quality to the 1997 SoftBank DP-211SW SkyWalker phone's emoji set, the first one known. Also Unifont and UnifontEX emoji tend to take stuff literally. The brain emoji actually is modeled after a brain scan of a head. The Moyai emoji is based on the Unicode-intended Shibuya Moyai statue rather than the Easter Island heads that many emoji vendors use that codepoint for. They follow the standard enough to have the pulled emoji and even a pulled CJK character. Also the tuxedo emoji is actually a tuxedo. Also the skull emoji is based on to some extent the SkullCandy stuff from eons ago, but resembles the modern Samsung skull emoji. Funnily enough, the Plane 0 skull emoji (Skull and crossbones) emoji resembles Samung's non-emoji version of it. Also, via zFont, I set my Samsung Galaxy A52 5G to use UnifontEX as my UI font and it actually feels natural. Another thing to note is that Unifont and UnifontEX are in the same family of sans-serif fonts (Humanist + Neo-Grotesque Gothic hybrid) as the Discord message fonts. Also, I've used UnifontEX for writing papers and it worked. Furthermore, I've found that even people in their 80s (my grandparents) can read UnifontEX, and amongst the people I know who can read CJK scripts (among UnifontEX's most complex characters), they can read it. Also, I've found that Google Translate OCR (and Samsung Gallery's OCR) can read it. Also California large print medicine bottles are printed in 12pt. So UnifontEX isn't unreadable, and its mathematical italics put it in the "has italics" category some academic style guides like. So, technically speaking, it can be used in essays (please ask your instructor anyways) or other papers. Also UnifontEX works well in print and e-ink. In short, I've ran all sorts of tests with great results. Also knowing that it has some rather amusing references in some of its glyph shapes is honestly hilarious. Also, the Halfwidth Kana and Halfwidth Hangul are actually approximately what such characters were in size during their heyday on Japanese and Korean computers. 8x16 Hangul Jamo and 8x16 Katakana would have been historically-accurate during the era of Halfwidth Hangul and halfwidth katakana. Also on the topic of historical accuracy, 8x16+16x16 was the resolution of glyphs for MANY CJK computers. Also, the PNG version being 1MiB (actually under) puts it within the file size of the 3DO's Kanji ROM, meaning that UnifontEX COULD have been an actual chip in the olden days (due to 8x16+16x16 glyph size, DEFLATE existing since the 1970s, and being the 3DO Kanji chip file size, plus other factors, disregarding anachronistic characters like the Bitcoin symbol). I can see all sorts of ways in which even nowadays such a chip would be useful. Closed-captioning, TDDs, industrial status displays, industrial DOS/V Unicode upgrade (which I call DOS/U), etc. al. I just see so many things one can do. See how many you can find!

TL;DR: Recent UnifontEX updates were a checkered process. I wish I'd known quite a few things beforehand in a better way.

[stgiga]

@roytam1 The release has been updated to reflect the changes made in the repo.