老式PC字体包v2.0

旗舰老派PC字体包一开始就是为了向古代PC和它们的位图、图形用户界面出现前的排版致敬(如果你可以这样称呼它的话)。它的灵感来自于覆盖其他老式机器的类似努力：来自Amiga、C64、Apple II、Mac、ZX Spectrum、Atari 8位/ST等的经典系统字体都得到了赞誉。另一方面，IBMPC和它的复制品似乎没有得到多少人的喜爱……。除了那一种VGA文本模式字体(它已经被重制了无数次，获得了不同程度的成功)。

这个集合是为了弥补这一点，并为您带来来自文本模式时代PC的各种字体样式的像素完美翻拍-以现代的、多平台的、兼容Unicode的TrueType形式(加上直接的位图版本)。

虽然我们的目标是使其成为一个完整的资源，但主要关注的是硬件字符集：这种字符集位于系统主板或显卡的ROM芯片中，这是您在文本(或图形)模式下工作时默认看到的字符集。软件可加载字体也在此集合的范围内(如果与特定的机器或显示系统相关联)，因此其中一些字体也已加入其中。

当清晰的外观很重要时，你会想要位图渲染。这在'；Mx'；('；混合格式'；)和'；BM'；(位图)变体中可用。

当感知逼真度很重要时，你会想要原始字体的真实纵横比。这在'；ac'；变体中可用('；宽高比校正'；，或者可能是'；准确'；，随您挑选)。

在上述格式不能(很好)工作的任何地方，您都可以使用'；px&39；(#39；像素轮廓)变体，它们是具有正方形像素宽高比的TrueType字体，应该是最兼容的。

'；Plus'；有更多的选择(总共约780个字符)以支持更多的脚本和符号；其中很多是自定义添加的，因此只对少数选定的字体执行此操作。

答：这些指示字体的缩放方式。在许多情况下，原始视频硬件会通过修改驱动显示器的像素时钟将文本宽度加倍或减半。例如，以80列文本模式和40列文本模式为例：每行的字符数各不相同，但每行在屏幕上的宽度相同。换句话说，更改的是水平像素长宽比。

为了再现这种效果，其中一些字体提供了额外的双角和/或半角版本。通常，父字体(不带后缀)的像素纵横比最接近正方形，"；-2x"；用于双宽(2：1)版本，"；-2y"；表示半角(1：2)。有关这些不同版本最初是如何使用的详细信息，请参阅每种字体的详细信息页面。

答：这些字体使用直角像素轮廓复制原始位图字符，不能平滑缩放。这意味着它们只有在原始像素高度(或其整数倍)时才会看起来很好；字体列表中的每种字体都会注意到这个大小。例如，对于8x16像素的字体，TrueType版本应显示在16的高度(/32/48/64/...)。像素。

大多数当前软件以磅(Pt)为单位确定文本大小，而不是以像素为单位。转换取决于分辨率，因此您要选择的大小可能会因您的操作系统、显示器和DPI设置而异：更多信息请参见下面的内容。

答：如果它在这个收藏品的范围内，那么当然可以！换句话说，如果：

这不是很难的科学，所以自然会有一些边缘案例，但如果没有这些指导方针，范围将变得明显疯狂(这是相当深的兔子洞，因为它是)。如果你能贡献任何符合这些标准的东西，那将是非常受欢迎的-请让我知道。

答：没有，没有这样做的计划。这样的现代图形用户界面概念与最初考虑到纯文本模式的字体不能很好地配合，因此它们在视觉上不会真正起作用。大多数当前的文本渲染器已经可以通过使字形变胖或倾斜来模拟粗体/斜体样式，但是如果您尝试过，您应该会明白我的意思。

检查我的基于DOS的VGA字体编辑器Fontraption-下载包括大多数原始二进制格式的老式PC字体。少数例外是对于VGA文本模式来说太大的那些(即超过8/9点宽)。

答：不，不是“每一个”都有。首先，带有扩展字符集的Plus版本通常包含许多原本不存在的自定义字形。即使是变种，也有需要进行一些更改的情况：其中一些是*重新映射*的，因为它们是基于例如日文字体的，而且原始版本只有代码页的下半部分(ASCII)。这些重新映射在字体索引中清楚地注明(并在字体名称中注明)。其他人则有明显的错误，比如奇怪的基线漂移，或者框画字符的错位-这些情况列在"；Differs&；勘误表"；下面。

我完全是为了准确，但这不是一个纯粹的保存项目；这些字体是用来使用的，而不仅仅是作为博物馆的复制品。当某个原始字符集出现阻碍可用性的问题时，我倾向于修复它并将其记录下来。

答：简而言之：就我所能进行的研究而言，这批藏品没有任何非法或侵权之处。与.fon和TrueType(符合软件资格)等特定格式的字体不同，原始位图字体不具有版权；至少在本网站的总部所在的美国是这样。有关更长、更无聊的答案，请参阅下面的法律内容部分。

此包中的字体有几种格式，由字体名称上的前缀("；Ac437&34；、"；PxPlus"；等)标识。2.0版本引入了更多这样的变种，所以为了不让每个人都感到困惑，这里我们来介绍一下它们的用处。

这与此包的1.x版中使用的TrueType变体相同。这些字体中的轮廓遵循原始光栅字符的像素网格：原始字符中的每个像素都表示为轮廓字形中的正方形区域，因此字符形式可以很好地复制到正方形像素显示器上(即，几乎所有今天制造的监视器和显示设备)。

'；px'；前缀后面是字符集，可以是'；437'；或'；加号'；。'；Px437'；字体涵盖了由原始IBM PC(也称为代码页437)建立的256个字符的选择。PxPlus字体涵盖了更广泛的字符选择，以支持更多的脚本和符号；这两种字体都与Unicode环境100%兼容。有关详细信息，请参阅下面的字符集和编码(&A；ENCODINGS)。

这些字体与字体基本相同，但除了轮廓形式外，它们还包含字符的位图版本。在正确的大小(即，与原始的老式字符集相同)下，这提供了原始字符集的1：1像素再现，没有任何倾向于在ClearType/FreeType/等中显示的灰度或亚像素平滑的伪像。(=。

虽然没有广泛使用，但这实际上是sfnt容器(.ttf格式的基础)的标准特性：轮廓字体可以嵌入针对特定大小进行调整的位图，并且渲染器应该在可用的时候使用它们。栅格化轮廓的整个混乱过程被绕过，您可以获得完美清晰的渲染效果。

这听起来像是复制老式位图文本的理想设置，因此您可能会问自己，它是否不会使变体变得多余。如果同样的格式既可以处理轮廓也可以处理位图-而位图对于我们的*目的来说要好得多-那么仅限大纲的格式有什么用呢？(#39；px；#39；px#39；)。为什么不在任何地方都使用这种字体，免去我们的磁盘空间和混乱呢？

平淡无奇的答案是，规范是一回事，现实世界的支持是另一回事：交易中的位图部分并没有在所有地方得到正确实现。也就是说，要使这些字体与Windows兼容需要一个丑陋的技巧，因为Windows会忽略该规范*除非*这些字体满足某些未记录的(！)。标准。结果是Windows在使用字体时行为怪异：它们可能会在字体列表中以"；@"；前缀显示，更令人恼火的是，您无法选择"；DOS/OEM&34；脚本。这意味着他们无法正确显示使用真正的8位OEM编码的文本-例如，来自DOS的使用非ASCII字符(.NFO图稿等)的CP437文本文件。为此，'；BM'；字体(8位.FON)更兼容。我没有在Linux上进行过广泛的测试，但在那里，事情似乎取决于渲染引擎、桌面环境和各个程序本身。

实际上，当编码为Unicode时，Mx&39；字体在Windows和Linux中似乎工作得很好，并且可以使用'；Mx437'；字体提供全系列的CP437(DOS/OEM)字符。与其他格式一样，一些字体也有支持更广泛的文字和符号的变体。

Px&39；和'；Mx&39；字体变体针对正方形像素进行调整，这是当前显示所基于的，也是几乎所有常见GUI环境的默认假设。这使得确保老式字形*形状*的1：1复制变得容易，但在大多数情况下，纵横比与原始的不同。

这是因为CRT或LCD显示器上显示的原始字体*不一定是正方形像素。CRT通常为4：3，但像素长宽比取决于分辨率，分辨率随硬件和所选显示模式的不同而不同。LCD或等离子面板(用于便携式机器)出现了令人眼花缭乱的形状和大小。

因此，除了简单的正方形像素版本之外，这些字体还具有(经过纵横比校正的)变体以再现原始外观；索引中的每种字体都列出了正方形和校正后的像素比例。有些字体最初使用的是正方形像素比例，而另一些字体则非常接近，差异可以忽略不计。对于这些字体，正方形像素的版本应该足够好了，所以没有提供任何变体。

当经过纵横比校正的版本显示在当前显示器上时，字符的轮廓仍会栅格化到正方形像素网格上，因此需要权衡锐度/质量。在高DPI显示器上，或者在合适的文本大小(具有良好的亚像素抗锯齿效果)下，结果看起来仍然相当不错-如果您从索引中选择一种字体并使用预览选项，您可以在此网站上试用。有关这些字体的更多详细信息，请参阅下面的纵横比。

就像'；px&39；和'；Mx&39；一样，这些字体可以是'；Ac437'；(覆盖所有CP437 DOS/OEM字符)，也可以是'；AcPlus&39；(扩展的多语言字符集)。

BM&39；字体采用纯位图格式，因此它们不会受到光栅化问题的影响，并且始终呈现为1：1像素。不幸的是，没有一种普遍支持的广泛使用的位图格式；目前，这些字体只能作为Windows.FON文件使用，但可能会在某个时候添加其他格式。

由于.FON格式不支持Unicode，因此它不能用于扩展的Plus字符集，因此此系列仅包括遵循旧式DOS/OEM编码的变体；由于Windows在幕后映射代码点，因此它们仍可在Unicode程序中使用。

位图字体始终贴紧到显示器的像素网格，并且不受灰度或亚像素(ClearType)抗锯齿的影响，因此它们总是尽可能地锐利和清晰。

FON格式的字符集(在本例中为DOS/OEM)似乎总是被正确解释，没有假设或但是。一些程序可能会对DOS/OEM字体不屑一顾，因此这些版本可以有效地迫使它们善用CP437数据。

某些程序/用例仍然不能正确支持TrueType字体；例如，Windows控制台过去就是这种情况(除非您编辑了注册表)。Windows10似乎已经纠正了这个特定的问题，但其他问题可能仍然存在。

基本上，这些都是TrueType字体的版本，针对Web使用进行了优化和压缩。当前所有主要的浏览器本身都已经支持纯.ttf字体，因此使用另一个版本可能看起来像是浪费空间，但有几点需要考虑：

在.woff版本中，调整大小要简单直观得多。值得庆幸的是，网络使用仍然没有典型的操作系统坚持使用不相关的单位(如积分)、限制您可以选择的大小以及其他类似的愚蠢行为。CSS允许您以em或px单位独立指定任何所需的字体大小和行高；因此，.woff版本使em大小始终等于行高，行高可以始终与字体的原始像素高度匹配。如果原始字体是8x14字符大小，则Web版本应该简单地使用字体大小*和*行高14px(然后变为等于1em)-简洁性本身。

有了Web字体，就不需要为字符集和加字符集分别使用不同的字体了。(#39；437&39；；和'；Plus&39；；字符集不需要单独的字体。这是因为字符集/编码是在文档级别处理的，而不是在字体级别-浏览器只关心您使用的字形是否存在。对于具有'；Plus&39；字符集的字体，.woff版本仅包含'；Plus&39；版本中的所有字形(已包含完整的CP437字符集)；对于仅以'；437&39；字符集提供的字体，.woff将仅包含这些字形。这消除了不必要的重复，使您避免了使用哪个版本的另一个难题。

那么，为什么只为这些变种制作网络版，而不为其他变种制作网络版呢？理由是：

如果您想要进行纵横比校正(就像在变种中一样)，那么您并不需要单独的字体来进行校正--您总是可以使用CSS转换自己来完成这项工作。(这句话的意思是：“如果您想要进行纵横比校正(就像在变种中一样)，那么您并不需要单独的字体来进行校正。这就是这个网站在字体预览页面中所做的事情。

如果您需要位图字形(如在#39；Mx&39；或'；BM&39；变体中)...。唉，没有人能做到这一点。从技术上讲，该格式*确实*支持位图嵌入的风格方法，但目前的浏览器似乎都是通过一种名为OpenType Saniizer的工具来运行所有传入的网络字体，该工具可以验证字体并清除不好的东西。在撰写本文时，嵌入的位图已经随垃圾桶一起扔掉了，尽管可能的修复还存在一个未解决的问题。如果这个问题得到解决(无论是在浏览器端还是在杀菌器端)，那么位图版本可能还会发生。

把上面的文字墙说得更简洁一点，它的工作原理是这样的：

让人迷惑？可能吧。我*希望*有一种方法可以把所有这些都变成一种方便的字体格式，可以在任何地方都能用，但我们没有那么幸运，所以我试图涵盖尽可能多的基本内容。

此集合中的字体有两个字符集，如字体名称前缀中所示。

'；437'；(适用于所有字体)：这是由原始PC建立的256个字符的经典集合，也称为代码页437(或"；PC ASCII"；，"；拉丁文-US DOS/OEM&34；和其他朗朗上口的名称)。到Unicode的字符映射旨在最大限度地兼容原始代码页，因此除了正常使用之外，这些字体还应该允许您以原始编码查看CP437文本。

Plus'；Plus(仅针对特定字体)：在CP437范围之上，它们支持扩展的拉丁文、希腊文、西里尔文和希伯来文以及一些附加的字形和Unicode符号。额外的字符取自原始硬件的国际版本(如果有)，或者设计成紧跟现有的版本。总共有782个字符(超过Windows字形列表v4--实际上整个WGL4范围都在那里)。一小部分CP437字形不得不重新映射(阅读下面的原因)，但它们仍然存在。

在大多数情况下，代码页437是源字体的原始字符集。这个包的转换版本仍然是标准的Unicode字体-它们只是不包括整个Unicode范围。

CP437不能以简单的1：1方式真正映射到Unicode。罪魁祸首是字符00h-1Fh和7Fh，它们既可以被解释为控制代码，也可以被解释为图形符号。因此，有两种广泛使用的映射：标准的IBM/MS映射(执行前一种映射)和Unicode映射(执行后一种映射)。问题是，期望其中之一的软件可能并不总是与另一个友好相处。

作为一种解决方案，这些字体在一个映射中涵盖了两个基础：复制歧义字符，以便您的程序在任一位置都能找到它们。Windows将字体检测为OEM/DOS，您可以在理解此字符集的任何程序或环境(包括命令提示符)中使用它们。只要您的软件配置正确，在其他平台上也是如此--RTFM、GIYF等。

代码页437(值=列+行)映射到Unicode；所有值都是十六进制。*=这些字符也在控制代码点重复(Unicode值=CP437值)。

一些选定的字体还具有扩展字符集的多语言版本。这些Plus版本并不严格复制原始硬件/软件，原始硬件/软件几乎总是使用256个字符的集合。相反，他们将来自不同来源的人物组合在一起。

在某些情况下，我可以访问原始字体的多个代码页-例如，从非美国版本的CGA/MDA板、从多语言ROM(如Amstrad或Tandy 1000套装)或从IBM的适配器接口字体数据；这些都被拉到了Plus版本中。然而，大多数情况下，它们必须通过自定义添加来充实，对于那些额外的字形，我会尽可能地与原始字体的样式相匹配。

备用数字形式：有一个平顶的Ʒ映射到U+01B7&39；拉丁文大写字母EZH&39；，它更容易与西里尔文字母ZeЗ区分开来。另外，两个可选的零(点和斜线)被映射到U+2299⊙'；带圆圈的点运算符和U+2300⌀'；直径符号。

光标形状：UNICODE字符U+2581UNICODE▁'；下八分之一块可用于模仿经典的文本模式光标外观。U+2584▄'；下半块和U+2588█'；全块也可以代表这些相应的光标形式。

重新映射的代码页437字形：PxPlus字体仍然包括CP437(DOS/OEM)版本的所有原始字形。但是，它们还包括完整的希腊字母表，它接管了Unicode分配给CP437希腊/数学字符的代码点，新的字形看起来不一定相同。出于完整性的考虑，我尝试在重新映射的代码点保留它们，而不是仅仅删除CP437的原始代码。以下是更改：*不一致：在某些字体中看起来像Beta(β/03B2)，在其他字体中看起来像夏普S(？/00df)。这两个映射都有自己的代码点，因此新映射只保留原始的(不管它看起来是什么样子)。

根据定义，大纲TrueType字体是可伸缩的，因此。

.