The Ultimate Oldschool PC Font Pack
int10h.org
int10h.org
http://i.imgur.com/LDSOade.png
(code at https://github.com/Elv13/ , but that particular theme isn't pushed yet as it require upstream patches still in the CI)
For amber, the X11 color "goldenrod" (#daa520) is near perfect.
Makes me wanna go to old regional offices in case some of their 80s computer are still in a basement somewhere. Just to run the OS of the day and re-experience fonts, layouts, proportions, dithering-patterns..
https://damieng.com/blog/2011/02/20/typography-in-8-bits-sys...
https://damieng.com/blog/2014/07/20/typography-in-bits-other...
Me, I grew up on Acorn machines, so those are my classic nostalgia font. Although, on a modern LCD with square-edged pixels, they look like arse --- jaggy and overly bold. I wonder if there's a way to emulate fuzzy CRTs with Truetype...
If these fonts are used in some kind of retro game, those shaders could be applied as well. Desktop compositor on X11 effects could do the same. Not sure if there is a way to apply shaders to an entire desktop elsewhere (maybe f.lux do something like that to change the colours?)
One of the first things I learned to do was write a script to load something else on boot - Acorn's Arial knockoff I think. That was ugly too, but better by far.
I find the old typefaces from the early 8 bit and 16 bit days really charming. They were working with such severe limitations. I remember designing my own font on my Amiga and using it on my desktop...I kinda wish I still had those files. But, they weren't nearly as legible as the fonts from the vendors.
BTW, just to correct one of the above comments: a few of my own versions did involve some redrawing/original design (specifically the extended 'PxPlus' unicode variants, and the BIOS-only fonts which originally included only the lower 128 ASCII characters). Although of course this has no bearing on any copyright (or lack thereof) on the originals.
At any rate, sure - I encourage you to use these fonts in your projects, and thanks for the comments!
So far the only font I found that supports a lot of that sort of thing is DejaVu Sans mono but even that is rather sparse- there's very few Greek letter super/subscripts say, and there's a limited selection of Latin superscripts. Block elements and box drawings wouldn't hurt either.
I know about pragmata pro and unifont. I've tried Unifont, I think it hurt my eyes a bit but it sure has lots of glyphs. Pragmata is very pretty and has great coverage but it's not free and I don't see that it has more glyphs than free fonts, for instance with DejaVu mono I have a subscript for j which I don't see in Pragmata. Or, the APL glyphs for instance; unifont has them too and it's free.
I'll give ReactOS a try, thanks. I had given up hope to be honest, I guess Unicode is just too big to implement fully.
Edit: Ok, Pragmata costs €19 for just the regular weight- I thought it was costed by unicode range. I could definitely give that a try, so thanks for the hint mietek.
2nd Edit: Ouch, no- the mono font is €59. That's too high again :)
It's all my mathy friends use for taking notes.
I would also suggest iPython notebook (if you can live with web apps, I don't) as it allow you to see what you write in real time and add some code too (and being able to use mathplotlib). That being said, I used computer to take note in high school (The KDE3 version of basket notepad, the evernote of 2006, now defunct), but switched back to pen and paper for college, formatting was much easier ;)
Some text editors even let you enter rare characters with key combinations (frex, Vim's digraphs). The end result is pretty much WYSIWIG mathematical notation.
Here's an example from my machine learning class notes:
⎛ ₙ ⎞ ⎝ ⁱ⁼⁰ ⎠
That's what I'm going on about- but there's not enough super/subscripts in ASCII itself. :)
Especially when you say "with a font that has all the necessary characters". ASCII is ASCII. All fonts (except Wingdings) have 100% of the ASCII characters.
Maybe you're pasting in Unicode; maybe you're using the Windows-only ALT-numeric keypad garbage.
But I suspect your "nice formula" that renders in a text editor maybe isn't as clean or standard as you think.
I can't edit it unfortunately so it has to stay there, in perpetuity reminding me of my failings in life.
Does anyone know if there's something similar for Amiga (for ascii art)
PAL didn't suffer too much from this, but NTSC did. Single pixel verticals light up in a rainbow of color. This is actually how the monochrome Apple 2 did it's color graphics!
White on blue is a secondary helper here. On sharp displays, the human eye sees the white text at full detail. Humans have only a fraction of blue receptors, compared to red and green. This means screen noise gets lost in a sea of blue.
On composite displays, that same sea of blue tends to was artifacts away. SGI IRIX offered it's Xterm with a great font, white on blue and it was very easy on the eyes.
I've used that combo for terminals ever since.
I became fond of the white on blue scheme with the MSX machines, but kind of abandoned it when I moved to PCs.
I remember the frustration that my Apple II+ with Videx card (plugged to a monochrome monitor through composite) had nicer looking text than the IBM (mono CGA on RGBi) next to it. Even more infuriating, it was also better than the much better specced Apple IIe that sat to its other side (and used the stock font for 80-column text). And yes, even under PAL-M (PAL with NTSC timings), 80-column text on a color composite screen was awful. My II had a switch installed to turn off color signal generation, making the text much more readable.
At NTSC timings, 80 column text is basically color information. It's just terrible.
Interestingly, sets from about the 80's onward can display 80 column text nicely, given a good DAC driven signal. The signals from back then were square, or coarse, if not square. This makes NTSC light right up. I've been toying with a micro and a DAC and a full interlace, color phase shifting NTSC signal performs well on older analog sets. If the timing is right for the digital ones, they do well too, but it's all about hitting that 13.5Mhz sample window common to most digital sets today.
Back then, just having a full interlaced signal would have helped considerably with text, though at the expense of tearing. Low ambient light and moderate contrast on the display would have largely mitigated this.
As we got Y-C capable displays, one could just use a resistor and send the composite signal into both inputs. This actually did very seriously improve text.
This is something I should try with my 8-bit machines.
Part of the reason for this is that IBM split the market into CGA for graphics and MDA for better text (9x14 character cell). Because the MDA adapter didn't display graphics, IBM made it possible to run both a CGA and a MDA in the same machine. Software like Lotus 1-2-3 could put the spreadsheet on the MDA and the graphics on the CGA. Dual monitors in the mid-80's.
Prior to the development of the EGA and VGA, there were a few interesting competitive responses to IBM's CGA/MDA split. The first was the Hercules card. This would let customers that had bought IBM's MDA (and it's matching monitor) get access to graphics. It wasn't compatible with CGA graphics, but it was higher resolution and wound up being fairly widely supported where it mattered. Compaq also had a solution to the problem... they shipped adapter/monitor pairs that could display MDA-quality text in the text modes and would scale down to 640x200 to display graphics.
What ultimately wound up happening is pretty much what you'd expect. As graphics resolutions got better with EGA and VGA, the quality of text on color displays got to the point where the MDA didn't represent an improvement. That said, there was always the ability to run an MDA (or clone) in parallel with a EGA, VGA, etc... that configuration was useful to programmers because it let you put debug information on one display while the main display ran the software you were developing.
I had that on my II+. Motherboard would drive the modified 16" TV (40 column, graphics) and a Videx Videoterm-like card would drive the monochrome monitor with beautiful (for the time) text.
I remember that in the late 80's I started seeing MDA/CGA hybrids that would drive MDA monitors with CGA-compatible text modes with MDA-like fonts and PWM grays. By then I was getting used and their ugliness no longer offended me.
To show the other end of the original PC spectrum, my family's first PC was a Compaq portable (a clone of an IBM PC), bought in the late 80's. That machine had 2 5.25" 360K floppy disk drives, 20MB Hard Disk, an 8087 FPU, 1200 baud modem, a mouse, and a higher-than-CGA resolution display for text. It was really a nice machine, and when I last checked a few years ago, it still runs.
The demoscene prod "8088MPH" demonstrates this to spectacular effect.
That's a 16 color, any color any pixel display 160x200.
Some PC games offered this option. It should have been in the CGA spec. For memory reasons, 1 and 2 bits per pixel were common. However, the same amount of RAM offers the full color set at a reasonable, if modest, resolution. (For the period)
16 colors on a 160x200 display was considered "nice" at that time, and having it be official would have improved early PC gaming considerably.
There was also a hack to set the display to text mode and reprogram the character height to fit 100 characters vertically on the screen, then use chopped-off block graphics characters to yield, in effect, a 160x100, 16-color, any color any monitor (composite or RGB) pseudo-graphics mode that compared favorably to, say, the 128x48 mono pseudo-graphics mode of the TRS-80. More PC games made use of this mode; one of the more notable recent ones is Paku Paku, a (remarkably good) Pac-Man clone.
I like 160x100 presentations and thought they were a good use of the CGA personally. A lot of game can be done at that resolution.
Really, the thing for IBM to have done was 16 color graphics of some kind. 160x200 was the obvious choice in that it would have worked with their memory scan scheme.
I thought those were on an RGB screen. All the more impressed by the brilliance of those guys.
It's also worth noting they had no such restriction on their TTL-based monitors.