11

In Windows 1.01 Write, the fonts were kind of blocky:

blurry text

Here's what the same text looked like in a modern word processor:

smooth text on Google Docs

Even the terminal had smoother text than Windows 1.01:
terminal

Why did Windows 1.01 Write had such blocky text?

9
  • 24
    Other than the pixel resolution difference, I don't see the problem with the Windows 1.01 rendering? Do you definitely mean 'blurry' in the sense of lacking contrast that should be present? Or more like 'blocky'?
    – Tommy
    Jul 31 at 0:27
  • 2
    @Tommy just really blocky. Jul 31 at 0:28
  • 8
    Cool. Someone else can probably give an actual definitive answer on the issues at play then, but TrueType wasn't implemented until Windows 3.x so I'm willing to bet they're bitmapped fonts, with inevitably scaling issues.
    – Tommy
    Jul 31 at 0:34
  • 2
    @StephenKitt I assume those fonts are actually ‘Tms Rmn’ and ‘Helv’, which were the predecessors of the later Times New Roman and Arial. Jul 31 at 8:14
  • 3
    @user3840170 maybe, but the use of the name “Arial” is rather surprising in a Windows 1.0 context. (The window decorations confirm the screenshot was taken on Windows 1.0, so it can’t really be using those fonts...) Jul 31 at 12:09
70

Your images appear to have been generated via emulation, with heavy anti-aliasing that doesn't show what it looked like in reality.

Here's Windows 3.1 Write in native VGA resolution without any image processing, captured from PC-Task running on an Amiga 1200:-

enter image description here

Here's part of that screen magnified so you can see the individual pixels:-

enter image description here

Finally, here's what it looks like running on a real PC and displayed on a VGA CRT monitor (HP Pavilion M50):-

enter image description here

You can still see the individual pixels, but the CRT has blurred them slightly. At this magnification you can also see the CRT shadow mask and even some of the individual RGB phosphor dots. A higher magnification would show that all the 'white' dots are actually triads of red, green, and blue.

Due to the natural blurring effect of the CRT display, there is no need to anti-alias the fonts. Anti-aliasing at this resolution can make the text look a bit smoother, but it also reduces the apparent sharpness and can reduce its readability.

Here's your screenshot magnified so you see the individual pixels. This text looks very blurry due to heavy anti-aliasing, making it harder to read than the original 'bitty' bitmap font.

enter image description here

4
  • 10
    The image at the bottom shows no antialiasing whatsoever — just a blurred aliased text. It's obvious in the diagonal line of the "r" letter, where an antialiased rendering wouldn't have these "rectangles connected at their corners and then blurred". Possibly the image in the OP was just upscaled, which would be the source of the blurring.
    – Ruslan
    Aug 1 at 17:40
  • 2
    Others are saying that this is a problem with using bitmap fonts; windows 3.1 had truetype fonts available, so unless you're using bitmap fonts in your examples, I have my doubts as to whether this is the true reason. At least, whether it's the only reason.
    – Hearth
    Aug 1 at 21:22
  • 1
    Nice catch. You have a keen attention to detail.
    – Evorlor
    Aug 2 at 4:50
  • 6
    "Due to the natural blurring effect of the CRT display, there is no need to anti-alias the fonts." just you try telling that to Acorn! RISC OS had native font anti-aliasing support way ahead of its time, and I must say I think it looks great, on a CRT or otherwise.
    – Muzer
    Aug 2 at 9:17
42

Because those were low-resolution bitmap fonts.

In Windows 1.01, most fonts were monochrome bitmap fonts, and not particularly high-resolution at that. (There were CONTINUOUSSCALING ‘plotter’ fonts included as well, but Write could not make use of those.) Additionally, Windows did not render any fonts with antialiasing before Windows 95 (with the Microsoft Plus add-on).

In the asker’s screenshot, Windows is running at (I am guessing) a pretty feeble (by today’s standards) 640×350 resolution with 16 colours, as offered by the EGA adapter. This was the highest resolution one could get with that Windows version (with built-in drivers at least). Your emulator stretches that small resolution to make it more legible on your screen, and additionally stretches the screen vertically to reproduce the 4:3 aspect ratio of computer monitors of the time. The bilinear interpolation algorithm employed by the scaling process produces a blur effect. This is how the picture looks like without any scaling:

Screenshot of the Write application running on Windows 1.01 with three lines of text set in the ‘Tms Rmn’, ‘Helv’ and ‘Courier’ fonts, respectively.

You may notice the fonts look pretty squished vertically compared to how fonts look in Windows today. This was, in fact, deliberate: like your emulator, Microsoft also took screen aspect ratio into account, and provided separate versions of the ‘Helv’ (mislabelled above as ‘Arial’, later known as MS Sans Serif), ‘Tms Rmn’ (mislabelled as ‘Times New Roman’, later known as MS Serif) and Courier fonts for different pixel aspect ratios. Most PC screen modes of the time had non-square pixels, and not just because a pixel is not a little square.

At 640×350, the amount of screen space taken by one pixel is ~1.6‰ horizontally and ~2.9‰ vertically; for comparison, for a 720p (1280×720) screen those numbers are ~0.8‰ horizontally and ~1.4‰ vertically, making it about twice the granularity in each dimension. To be able to fit more text on a single screen at resolutions this low, fonts had to be frugal with pixel use, with some characters like ‘i’ or ‘l’ being as few as three pixels wide. If we zoom in on the pixel grid, we can see the amount of detail such resolution is able to afford:

Zoomed-in fragment of the above screenshot, with a gray grid highlighting pixel boundaries, with pixel aspect ratio of 3:4

With so few pixels to spare, some compromises had to be made, and because the display could only use 16 colours, we could forget about using shades of gray to approximate strokes not aligning with the pixel grid. To save disk space, Windows 1 didn’t even include higher-resolution sizes or bold variants of those fonts: they were rendered synthetically by drawing each pixel multiple times or drawing a glyph a second time at an offset. The screenshot demonstrates the latter with the ‘Helv’ font: look how the vertical stroke of the ‘T’ glyph is thicker than the horizontal one. Though some of the imperfections can be attributed simply to the fact that the fonts weren’t even all that well-drawn for their native pixel size: look for example at Courier’s ‘e’ glyph.

Compare that to the screenshot of modern Windows, where, thanks to a much higher resolution and sophisticated subpixel antialiasing, without zooming in we can barely notice that a rectangular grid of pixels cannot actually represent the curved strokes of the letterforms perfectly:

Zoomed-in fragment of the modern Windows screenshot posted by the asker, with the pixel grid similarly highlighted

Where in Windows 1.01 the glyph height of the first line written in ‘Times New Roman’ was barely 8 pixels, here the actual Times New Roman takes 15 pixels, leaving more room for subtle details like serifs.

But text mode also uses bitmap fonts. Why does it then look better? MDA/CGA text mode renders an 80×25 grid of characters from an 8×16 font, embedded (usually) inside 9×16 character cells, for a total resolution of 720×400 pixels. Because each character can use up the entire 8×16 area of the character cell, it has more room for strokes that are thicker relative to details like curvature and serifs, which makes the scaling artefacts less pronounced, especially with interpolation:

Zoomed in fragment of the text-mode screenshot posted by the asker, with the pixel grid and the character grid highlighted

Gray is the pixel grid, green is the character cell grid. Still a bit blurry, but much more pleasant to look at.

3
  • 2
    Correction: while it’s true that Windows did not support TrueType fonts until 3.1, it did support a more primitive vector font format, I think dubbed simply “scalable fonts” - at least as of Windows 2. I don’t know if it still supports them. They were ugly at small sizes, Decent at medium, and plotter-like at large sizes. By the looks at large sizes it’s quite obvious the format did not support stroke widths because thickness was achieved by drawing maybe 3 parallel hairlines where it needed thickness. Aug 1 at 2:25
  • 1
    Your "screenshot of modern Windows" is a good example of anti-aliasing making the text less sharp and harder to read. The use of orange and blue is perplexing - why not shades of grey? When Firefox introduced this the readability of small text on my LCD monitor went down dramatically. But hey, I guess that's my fault for using a display with 'only' 1280x1024 pixels! Aug 1 at 20:44
  • 3
    @BruceAbbott The orange and blue is called subpixel antialiasing. (Branded ClearType.) It kind of in a best-effort way tries to improve the apparent smoothness of text by taking advantage of how red and blue subpixels are offset from green on fixed pixel monitors. If correctly configured, the blue/orange fringes of ClearType will cancel out the orange/blue fringes your monitor creates. Personally, I find ClearType always looks a bit pinkish.
    – mm201
    Aug 2 at 7:09
13

It isn't. The examples are comparing apples and oranges. As they cover three different situations/usages:

Bitmap Emulation vs. Native Usage vs. Character Emulation

The results are based on what hardware is emulated, in what mode and _on which modern device.

Lets for simplicity assume the modern screen is a rather average, if not lower end 2560 by 1440.

  1. Native Handling (Example #2)

    Here the full native resolution will be used by windows and fonts are projected using this. So using a font (and scaling) that gives like 40 text lines on a screen will allow each letter to be rendered in a character cell of 36 pixel. Quite some room for fine detailed rendering.

  2. Character Adaptor Emulation (Example #3)

    Here the emulator provides a classic character based display adaptor, like MDA or CGA (or any other offering character mode). To display its 80 by 25 character on a full screen it gets a 32 by 57 pixel character cell. Quite more than the 8 by 8 of a CGA or 9 by 14 of a MDA.

    Now, the emulation could simply scale the genuine font. Due the way higher resolution users would perceive this as, well, blocky :)) So the emulation goes ahead and uses a native scalable font, modelled after the adaptors font, instead, giving a quite smooth appearance.

  3. Bitmap Emulation (Example#1)

    Here the emulation does not work font based, as before, but pixel based. Windows 1 sees for example an EGA graphics card with its 640 by 350 pixel resolution and draws as fine as it can do. With a font/scaling size set to reach for example 30 text lines, this comes down to 12 pixel height per line. Nice for back then.

    The emulation has no idea what Windows 1 is displaying here. All the emulation sees is the same bitmap buffer which it needs to display. Scaled to the modern screen each emulated pixel gets displayed as 4 by 4 native pixel. There is no way an emulation can smooth that out the same way as a native implementation can, as it has no knowledge what the pixels are about (*1,*2).

    On the other hand is does add a little smoothing on each pixel (*3), which already helps to reduce blockyness, but since this can only be done on a pixel by pixel base it will not remove any blockyness due the original rendering (*4). It's more like emulating the analogue nature of classic displays, where each and every pixel was kinda smooth.

    All it can do is turn them into rather sharp (aka blocky) 4 by 4 blocks.

Bottom Line: what you see is simply the effect of emulating old output methods on modern hardware in a best possible effort.


Now, if one would run the Win 1 Write in a more modern Windows (*5), the display would be quite smooth as ist would render with the native resolution supported by this version.

A similar effect might be possible by adding a higher resolution screen driver to Win 1 (*6).


*1 - Same way anti-aliasing of a graphics card does need model information to work.

*2 - Well, if the emulation does not just emulate the PC Hardware, but also hooks the loaded windows, it could guess what some output is about. That more like letting an older program run on a newer Windows/screen. It will be not only imperfect, but also result in tons of potential incompatibilities.

*3 - When looking close at the first picture it's visible that the emulation tries to smooth out the bitmap. Two adjacent white pixel meet in in white, while black do the same in black. But a white to black border in either direction is turned into a gray scale ramp. Nicely visible at the i-dot.

enter image description here

Since pixels are the only data elements the emulation has to work with, all smoothing is done around each pixel in conjunction with its 8 neighbors.

*4 - Without it would look incredible blocky on today's super sharp digital screens. Maybe the emulation you're using has some way to switch the improvements off :)

*5 - A Win version still offering the 16 bit interface - so essentially at least up to Win95.

*6 - Within limits as fonts weren't scalable as now. So adding some new fonts as well might be necessary to use the higher resolution.

2
  • Yup, it's VirtualBox Jul 31 at 2:30
  • 1
    @Someone_who_likes_SE Well, then what you see is what that emulation does, not what a real PC or Windows does. After all it needs to transform whatever Adapter (EGA,VGA, ...) it emulates onto whatever your actual display is. In that it will add smoothing depending on function.
    – Raffzahn
    Jul 31 at 10:13
11

Windows 1.0’s Write application doesn’t care about how the text it displays is rendered — it relies on its operating environment to display it. As such, it supports smooth fonts, even though Windows 1.0 itself (and Windows 2.0 etc.) doesn’t.

Thus if you run the Write executable in a more modern environment, you’ll see it display anti-aliased text (I don’t have a setup right now to provide a screenshot). This might be difficult with the original Windows 1.0 Write binary, but you can perform a similar test with the Windows 3.0 binary.

This is how Windows 95 with Microsoft Plus! was able to provide anti-aliasing for most applications running on it: the font rendering was changed, and all applications which relied on Windows to display fonts for them used the new font display code.

1
  • Toasty Tech managed it. His package includes an updated Write executable. Jul 31 at 13:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.