在Win7中，一些字体不能像Win2K / XP那样工作 [英] In Win7 some fonts don't work like they did in Win2K/XP

问题描述

我的问题是如何改变字体以便在Windows 7下正常工作。我相信我已经对之前有效的东西做了一个假设，但不再有效。但我甚至不知道从哪里开始寻找！我祈祷有人可以帮忙！以下是我了解他们的细节（我也在微软Windows开发者论坛上发布了这个问题，但他们没有回答）：

是的， （哎呀，我还是用普通的C语言编写WIN32代码！）我有一个10年前的DLL，我写的是模仿一个窗口客户区域内更老的DOS屏幕I / O库。不用说，它只允许使用固定宽度的字体。当一些使用DLL的程序已经移动到Windows 7时，使用固定宽度的TRUE TYPE字体时会出现奇怪的闪烁（位图字体仍能正常工作）。我们已经将问题追踪到事实使用 ExtTextOut 编写的单个字符比应该宽。我已经用三种不同的方法检查了测量结果（通过使用 GetTextExtentPoint32 对132个字符串进行除以132，通过调用 GetTextMetrics GetCharABCWidths ），他们都认为字体宽度是相同的。但是 ExtTextOut 正在渲染比字体宽度宽一个或两个像素的背景矩形。不管是，还是开始背景渲染一个像素或两个在参数中给出的位置的左侧[我称之为： ExtTextOut（hdc，r.left，r.top，ETO_OPAQUE ，& r，&ch，1，NULL）。]请记住，这个EXACT代码在Windows 2000，Windows XP和Windows 7上的位图字体下工作得很好 - 但不再对于Windows 7下的固定宽度的真正的字体，正确的工作。

对于那些没有掌握我需要做的事的人来说：一张方格纸。每个方块使用相同的字体，但可能有不同的前景和/或背景颜色。我使用 TA_TOP | TA_LEFT 文本对齐方式，因为它是最简单的，任何一致的应用对齐方式都适用于固定宽度的字体。

我所看到的是ExtTextOut正在发射比我在 RECT * 参数中指定的更大的背景矩形。由于我提供的矩形是从报告的字体大小创建的，所以不应该发生这种情况，而且在Windows XP和更早的版本中都不会发生这种情况，而且Windows 7下的位图（即.FON）字体也不会发生，无论是。但它总是在Windows 7下使用固定宽度的TrueType字体。这是在Windows 2000，Windows XP和Windows 7（32和64）上运行的EXACT SAME EXECUTABLE。虽然我只想说Windows 7有一个bug ，我更倾向于相信我在Windows下的字体处理的一些基本假设不再是真实的（在为Windows编写软件20年之后）。

<但我不知道如何或在哪里发现可能是什么！请帮助我！

--- ammendment ---

对于任何感兴趣的人，设法解决我正在考虑一个错误 - 直到我找到相反的文档。我的解决方法包括对库的两个更改：
$ b $ ol

使用从 GetTextExtentPoint32（） $ X $，而
是来自 TEXTMETRICS 的数据。

包含所有 ExtTextOut（）调用中的ETO_CLIPPING 标志。

<以前，我已经使用了 tmHeight + tmExternalLeading 来计算连续文本行顶部之间的像素数量。我发现从 GetTextExtentPoint32（）返回的size.cy值是不一样的，看起来更准确。我发现的最糟糕的例子是OCRB真正的字体。这是我在调试器中看到的，我创建的OCRB字体（使用系统字体选择对话框）：

  ocrbtm。 tmHeight = 11 
 ocrbtm.tmExternalLeading = 7 
 
 ocrbsize.cy = 11 
  

$ b $因此，由于某些原因，我还没有发现，Windows忽略了为OCRB字体定义的外部主导值。使用size值而不是TM会产生漂亮，整齐，紧密的文本，这正是我想要的。

ETO_CLIPPING flag应该不是必须的，因为我将矩形设置为单个字符的尺寸，并使用 ETO_OPAQUE 来填充背景（并覆盖以前的单元格内容）。但是没有剪切标志，单个字符比尺寸，文本度量或ABC宽度都要更宽 - 至少，根据我目前发现的所有文档。

我认为HEIGHT问题已经存在了很长一段时间，但其余的是没有必要的，直到我们在Windows 7下运行我们的软件。我把这附加到我的问题看看有没有人可以解释我显然不明白的东西。

- ammendment 2 - $ /

1：我能找到的所有文件都说 tmHeight + tmExternalLeading 应该产生一个间隔文本的行。期。但是，这并不总是正确的，我找不到文档指出Windows如何确定有时由 GetTextExtentPoint32（）返回的不同值。

2：在Win7下（也许Vista） ExtTextOut 开始填充比它应该多一点的背景（通过向右添加几个额外的像素）只有当选择一个真正的字体。即使矩形是 double 字符的预期大小（在这两个维度中），它也会这样做。DPI /缩放可能是一个因素，但是由于我的系统设置为100％，所以似乎Windows在1：1比例因子方面遇到了麻烦，这似乎是一个错误。它只影响真实类型而不是位图（.FON）字体的事实似乎也排除了缩放（除非是缩放系统中的一个错误），因为Windows应该试图缩放所有的文字，而不仅仅是一些。此外，在自定义DPI设置对话框中有使用Windows XP样式DPI缩放的灰色（但是选中）设置。最后，这整个问题可能是我在Windows经典主题下运行的结果，而不是Aero或其他Win7本地主题之一。
$ b

- 修正3 -

简单地调用SetProcessDPIAware（）对我遇到的问题没有影响。由于我的问题存在于100％DPI设置（比例1：1），如果我的问题与DPI相关，那么我一定在DPI虚拟化中发现了一个错误，因为这是Microsoft如何描述功能：
$ b

此功能通过向应用程序提供虚拟化系统指标和UI元素，就好像它运行在96 DPI一样。然后，应用程序呈现96-DPI离屏表面，桌面Windows管理器将缩放结果应用程序窗口以匹配DPI设置。

我所有的设置都显示我在100％的缩放比例，并且在自定义设置框中清楚地显示这意味着96 DPI。因此，如果从96 DPI到96 DPI的DPI虚拟化不适用于我的固定宽度真字体字体，那么Windows有问题，对不对？或者是有一些我需要调用（或停止调用？）的函数，以便DPI虚拟器正常工作？

我仍然不相信所谓的缩放问题实际上与我原先想象的字体SIZE有很大关系。这是因为问题出现在由 ExtTextOut（）填充的背景矩形中，而不是被发射的文本字符。当字体为真类型时，背景矩形有点放大。我现在也已经验证，无论是使用Windows经典主题还是标准的Windows Aero主题都会发生此问题。现在建立一个简化的例子，以便其他人可以尝试它。

- 修正4 -

已经创建了一个最小的演示程序，显示了我所看到的（以及我在做什么）。Visual Studio 2010项目/源代码可以从 http://www.svalli.com/files/fwtt.7z - 我故意没有包含可执行文件，因为我不想冒传播恶意软件的风险。程序会选择一个固定宽度的字体，然后将两个5x5的字符网格写入客户区，一个是使用 GetTextExtentPoint32 大小创建的，一个是使用微软记录的TEXTMETRIC 大小。网格是黑色和白色的棋盘图案，红色字符最后写入中心以显示重叠效果（您可能需要使用缩放实用程序才能清楚地看到它）。该程序还绘制了一个以5 X就在网格的下面，从左边的偏移量开始，作为放置单个字符的方法比较（我匹配字符串）。菜单允许在 ExtTextOut 中打开/ code>并选择其他字体。还有一个命令行选项 dpiaware （区分大小写），当程序调用它时，程序会调用 SetProcessDPIAware（）启动，以便这个调用的效果也可以被评估。



从创建这个我已经了解到 ExtTextOut 正在填充正确的背景矩形，但是用不透明的背景渲染的字符可能比它应该宽，甚至可能不会开始 ExtTextOut 开始绘制！我说应该是，因为我结束的字符间距匹配我获得当我有 ExtTextOut 渲染一个完整的字符串。重叠可能显然是在给定的矩形的任一侧或两侧，例如，OCRB向字符单元的左侧和右侧添加额外像素，而我检查的其他真实类型字体向右侧添加两个像素我真的想做这个正确的方式，但我找不到任何文件，显示我做错了什么或缺少。那么，我可能会失去一些DPI意识除100％以外的尺度，但除此之外，我只是感到困惑不已。 >

稍微有点困惑...问题是由ClearType造成的。关闭ClearType使所有的字体再次工作。在XP下打开ClearType导致同样的问题。显然，ClearType可以默默地（直到有人告诉我如何检测它）水平拉伸字符一个像素，以便为阴影像素腾出空间，以增加平滑效果。

<解决这个问题的唯一方法？

- 修正6 -

部分回答我的剪辑问题上面：当创建一个新的字体，我现在做以下（伪代码）：

pre $ CreateFontIndirect
（（tmPitchAndFamily& TMPF_TRUETYPE）&& Win6.x或更高版本）
GetTextMetrics
if（SystemParametersInfo（SPI_GETCLEARTYPE））
lfQuality = NONANTIALIASED_QUALITY
DeleteObject（font）
CreateFontIndirect


几乎没有启用剪切 总是与我正在使用的字体大小一起工作，尽管我发现了一些仍然在字符单元的右侧（或左侧）渲染了一个额外的像素。幸运的是，那些似乎是在互联网上找到的免费字体，所以他们的整体质量可能低于专业字体代工厂的标准。

如果有人可以找到更好的答案，我真的很喜欢听到它！在此之前，我认为这是一样好。感谢您的阅读！

解决方案

确保您的代码是 high DPI aware ，然后告诉操作系统您的进程是否支持DPI 。

如果您不告诉操作系统您是DPI，某些测量功能将会出现，并根据显示器DPI实际上是96 dpi的假设给出数字它是什么。同时，绘图功能会尝试向另一个方向缩放。对于简单的高级绘图，这种方法通常起作用（尽管通常会导致文本模糊）。对于单个字符的小尺寸和精确放置，这通常会导致导致诸如不一致的字体大小。此行为是在Windows Vista中引入的。

您可以在Visual Studio 2010+中随时查看它，因为语法突出显示器会将文本和文字颜色上移几个像素并在那里键入。真正frickin'烦人。
$ b >关于修正案：

tmExternalLeading 仅仅是字体设计师的建议，可以在文本行之间放置多少额外的空间。 MSDN文档通常会说，应用程序在行之间添加的额外领先（空间）的数量。那么，你是应用程序，所以正确的事情就是在你自己绘制文本的时候在行之间添加它，但这取决于你自己。 （我怀疑像DrawText这样的更高级别的函数会使用它）。
$ b

对于 GetTextExtentPoint32 （和朋友）返回 size.cy 等于 tmHeight 并忽略 tmExternalLeading 。作为程序员，最终你选择了多少实际使用。

你可以看到，这只是一些简单的绘制代码。 -zero tmExternalLeading（Arial对我有用）使用 TextOut 和一个独特的背景颜色绘制一些文本，然后用 GetTextExtentPoint32 ，然后根据返回的值绘制一些行，你会看到背景颜色的矩形不包括外部的引导，外部的引导就是这样的：external，它不在字符单元格的边界。 >

  //绘制带有不透明背景的示例文本
 assert（:: GetMapMode（ps.hdc）== MM_TEXT） ; 
 assert（:: Get BkMode（ps.hdc）== OPAQUE）; 
 assert（:: GetTextAlign（ps.hdc）== TA_TOP）; 
 COLORREF rgbOld = :: SetBkColor（ps.hdc，RGB（0xC0，0xFF，0xC0））; 
 :: TextOutW（ps.hdc，x，y，pszText，cchText）; 
 :: SetBkColor（ps.hdc，rgbOld）; 
 
 //文本右边的垂直线显示不透明的
 // background正好是GetTextExtentPoint32返回的高度。 
 SIZE size = {0}; 
 if（:: GetTextExtentPoint32W（ps.hdc，pszText，cchText，& size））{
 :: MoveToEx（ps.hdc，x + size.cx，y，NULL）; 
 :: LineTo（ps.hdc，x + size.cx，y + size.cy）; 
} 
 
 //这些横线显示正常的行间距，取
 // account tmExternalLeading。 
 assert（tm.tmExternalLeading> 0）; //确保它是一个有趣的例子
 :: MoveToEx（ps.hdc，x，y，NULL）; 
 :: LineTo（ps.hdc，x + size.cx，y）; //这一行的顶部
 const int yNext = y + tm.tmHeight + tm.tmExternalLeading; 
 :: MoveToEx（ps.hdc，x，yNext，NULL）; 
 :: LineTo（ps.hdc，x + size.cx，yNext）; //下一行的顶部
  

彩色矩形底部与下一个顶部之间的间距行代表外部领导，这总是在字符单元格外。

专为银行设备中的可靠光学字符识别而设计。具有较大的外部领导（相对于实际文本的高度）可能适用于某些OCR应用程序。对于这个特定的字体，这可能不是一个美学的选择。

My question is about how font handling needs to be changed in order to work correctly under Windows 7. I'm sure that I've made an assumption about something that was valid before, but is no longer valid. But I don't even know where to begin looking! I'm praying someone can help! Here are the details as I understand them (I've also posted this question on a Microsoft Windows Developers forum, but they're not answering):

Yes, I'm behind the times (heck, I still write WIN32 code in plain C!) I have a 10 yr old DLL I wrote that mimics an even older DOS screen I/O library within the client area of a window. Needless to say, it only allows the use of fixed-width fonts. When some of the programs using the DLL have been moved to Windows 7, there is a strange flickering that appears when a fixed-width TRUE TYPE font is used (bitmap fonts still work perfectly.) We've tracked the problem down to the fact that a single character written with ExtTextOut is wider than it should be. I've checked the measurements three different ways (by using GetTextExtentPoint32 on a 132 character string and dividing by 132, by calling GetTextMetrics and even by using GetCharABCWidths for all 256 characters) and they all agree that the font is the same width. But ExtTextOut is rendering the background rectangle one or two pixels wider than the font width. Either than, or it is beginning the background rendering a pixel or two to the left of the position given in the parameters [I call it like this: ExtTextOut( hdc, r.left, r.top, ETO_OPAQUE, &r, &ch, 1, NULL ).] And remember, this EXACT code worked perfectly under Windows 2000, Windows XP and, with bitmap fonts on Windows 7 -- but it no longer works correctly with fixed-width true type fonts under Windows 7.

For anyone who isn't grasping what I need to do: try to imagine writing one character per square on a piece of graph paper. Every square uses the same font, but may have a different foreground and/or background color. I use TA_TOP|TA_LEFT text alignment, because it is the simplest and any consistently applied alignment should work for a fixed-width font.

What I'm seeing is that ExtTextOut is emitting a larger background rectangle than I've specified in the RECT * parameter. Since the rectangle I'm providing is created from the reported size of the font, this should NEVER happen -- and it never happened on Windows XP and earlier, and doesn't happen with bitmap (i.e. .FON) fonts under Windows 7, either. But it ALWAYS happens with fixed-width TrueType fonts under Windows 7. This is with the EXACT SAME EXECUTABLE running on Windows 2000, Windows XP and Windows 7 (32 & 64.) While I would love to simply say Windows 7 has a bug, I'm more inclined to believe that some fundamental assumption that I've made about font handling under Windows is no longer true (after 20 years of writing software for Windows.)

But I have no idea how or where to discover what that might be! Please, PLEASE help me!

--- ammendment ---

For anyone interested, I've managed to work around what I am considering a bug -- until I find documentation to the contrary. My workaround consists of two changes to my library:

1. Use the size returned from GetTextExtentPoint32() of an 'X' instead of data from TEXTMETRICS.
2. Include the ETO_CLIPPING flag in all ExtTextOut() calls.

Previously, I was using tmHeight+tmExternalLeading for the number of pixels between the tops of consecutive rows of text, as is documented. I discovered that the size.cy value coming back from the GetTextExtentPoint32() wasn't the same and seemed more accurate. The worst example I found was the OCRB true type font. Here's what I saw in the debugger for the OCRB font I'd created (using the system font selection dialog):

ocrbtm.tmHeight          = 11
ocrbtm.tmExternalLeading =  7

ocrbsize.cy = 11

So, for some reason that I've yet to discover, Windows is ignoring the external leading value defined for the OCRB font. Using the size value instead of the TM results in nice, neat, close packed text, which is just what I wanted.

The ETO_CLIPPING flag should not be necessary for me because I am setting the rectangle to exactly the dimensions of a single character and using ETO_OPAQUE to fill in the background (and overwrite the previous cell content.) But without the clipping flag, a single character is wider than either the size, text metric, or ABC width would indicate -- at least, that is true based on all of the documentation I've found so far.

I believe that HEIGHT issue has existed for a long time, but the rest was unnecessary until we ran our software under Windows 7. I'm appending this to my question to see if anyone can explain what I obviously don't understand.

-- ammendment 2 --

1: All documentation I can find says that tmHeight+tmExternalLeading should produce single spaced lines of text. Period. But that is not always true and I cannot find documentation indicating how Windows determines the different values that are sometimes returned by GetTextExtentPoint32().

2: under Win7 (maybe Vista) ExtTextOut started filling in a little more background than it should (by adding a couple extra pixels to the right), but only when a true type font is selected. It does this even if the rectangle is double the expected size of the character (in BOTH dimensions.) DPI/Scaling might be a factor, but since my system is set to 100%, it would seem that Windows is having trouble with a 1:1 scaling factor and that would seem to be a bug. The fact that it only affects true type and not bitmap (.FON) fonts also seems to rule out scaling (unless there is a bug in the scaling system), since Windows should attempt to scale all of the text, not just some of it. Also, there's a greyed (but checked) setting "Use Windows XP style DPI scaling" in the "Custom DPI Setting" dialog. Lastly, this entire issue may be a result of my running under the Windows Classic theme instead of one of the Aero or other Win7 native themes.

-- ammendment 3 --

Simply calling SetProcessDPIAware() has no effect on the issue I'm having. Since my problem exists at the 100% DPI setting (scale 1:1), if my problem is DPI-related, then I must have discovered a bug in the DPI virtualization because this is how Microsoft describes the feature:

This feature works by providing "virtualized" system metrics and UI elements to the application, as if it were running at 96 DPI. The application then renders to a 96-DPI off-screen surface, and the Desktop Windows Manager scales the resulting application window to match the DPI setting.

All of my settings show that I'm at 100% scaling, and looking in the custom settings box clearly shows that means 96 DPI. So, if the DPI virtualization from 96 DPI to 96 DPI is not working for my fixed-width true type fonts, then Windows has a problem, right? Or is there some function I need to call (or stop calling?) in order allow the DPI virtualizer to work correctly?

I'm still not convinced that the supposed scaling issue actually has as much to do with the font SIZE as I originally thought. That's because the problem is manifesting in the background rectangle being filled by ExtTextOut() instead of the text character being emitted. The background rectangle gets enlarged a bit when the font is true type. I've also now verified that this problem occurs whether using the Windows Classic theme or the standard Windows Aero theme. Now to build a simplified example so others can experiment with it.

-- ammendment 4 --

I've created a minimal demo program that shows what I'm seeing (and what I'm doing.) The Visual Studio 2010 project/source may be downloaded from http://www.svalli.com/files/fwtt.7z -- I intentionally didn't include executables because I don't want to risk spreading malware. The program has you choose a fixed-width font and then writes two 5x5 character grids to the client area, one created using the GetTextExtentPoint32 size and one using the TEXTMETRIC size as documented by Microsoft. The grids are in a black&white checkerboard pattern with a yellow on red character written last into the center to show the overlap effect (you may need a zoom utility to see it clearly.) The program also draws a string that starts with 5 X's just below the grid, starting at the same left offset, to be used as a comparison for my method of placing individual characters (I match the string.) The menu allows toggling clipping on/off in ExtTextOut and selection of other fonts. There is also a command line option dpiaware (case-sensitive) that causes the program to call SetProcessDPIAware() when it starts up, so that the effect of that call may also be evaluated.

From creating this I've learned that ExtTextOut is filling the correct background rectangle, but the character being rendered with an opaque background may be wider than it should be and may not even begin where ExtTextOut was told to begin drawing! I said "should be" because the character spacing I'm ending up with matches what I get when I have ExtTextOut render a whole string. The overlap may apparently be on either or both sides of the given rectangle, for example, OCRB adds an extra pixel to both the left and right sides of the character cell while the other true type fonts I've checked add two pixels to the right edge.

I really want to do this the "right" way, but I cannot find any documentation that shows what I'm doing wrong or am missing. Well, I am probably missing something for DPI Aware at scales other than 100%, but otherwise, I'm just baffled.

-- ammendment 5 --

Slightly less baffled... the problem is caused by ClearType. Turning off ClearType made all of the fonts work again. Turning ON ClearType under XP causes the same problem. Apparently ClearType can silently (until someone tells me how to detect it) stretch characters horizontally by a couple pixels in order to make space for the shaded pixels it adds to smooth things out.

Is clipping the only way around this problem?

-- ammendment 6 --

Partial answer to my clipping question above: When creating a new font I now do the following (in pseudo code):

CreateFontIndirect
SelectFont
GetTextMetrics
if( (tmPitchAndFamily & TMPF_TRUETYPE) && Win6.x or above )
   if( SystemParametersInfo( SPI_GETCLEARTYPE ) )
        lfQuality = NONANTIALIASED_QUALITY
        DeleteObject( font )
        CreateFontIndirect

Without enabling clipping this almost always works with the font sizes I'm using, though I've found a few that still render an extra pixel to the right (or left) of the character cell. Luckily, those appear to be free fonts found on the internet, so their overall quality might be below the standards of professional font foundries.

If anyone can find a better answer, I'd really, REALLY love to hear it! Until then, I think this is as good as it will get. Thanks for reading this far!

解决方案

Make sure your code is high DPI aware, and then tell the OS that your process is DPI aware.

If you don't tell the OS that you're DPI aware, some of the measurement functions will lie and give you numbers based on the assumption that the display DPI is actually 96 dpi regardless of what it really is. Meanwhile, the drawing functions will try to scale in the other direction. For simple high-level drawing, this approach generally works (though it often leads to fuzzy text). For small measurements and precise placement of individual characters, this often results in round off problems that lead to things like inconsistent font sizes. This behavior was introduced in Windows Vista.

You can see it all the time in Visual Studio 2010+ as the syntax highlighter colors the text and words shift by a couple pixels here and there as you type. Really frickin' annoying.

Regarding the amendment:

tmExternalLeading is simply a recommendation from the font designer as to how much extra space to put between lines of text. MSDN documentation typically says, "the amount of extra leading (space) that the application adds between rows." Well, you're the application, so the "Right Thing To Do" is to add it between rows when you're drawing text yourself, but it really is up to you. (I suspect higher level functions like DrawText will use it.

It is perfectly correct for GetTextExtentPoint32 (and friends) to return a size.cy equal to tmHeight and to ignore tmExternalLeading. As the programmer, it's ultimately your choice how much leading to actually use.

You can see that this with some simply drawing code. Select a font with a non-zero tmExternalLeading (Arial works for me). Draw some text using TextOut and a unique background color. Then measure the text with GetTextExtentPoint32 and draw some lines based on the values you get back. You'll see that the background color rectangle excludes the external leading. External leading is just that: external. It's not in the bounds of the character cell.

  // Draw the sample text with an opaque background.
  assert(::GetMapMode(ps.hdc) == MM_TEXT);
  assert(::GetBkMode(ps.hdc) == OPAQUE);
  assert(::GetTextAlign(ps.hdc) == TA_TOP);
  COLORREF rgbOld = ::SetBkColor(ps.hdc, RGB(0xC0, 0xFF, 0xC0));
  ::TextOutW(ps.hdc, x, y, pszText, cchText);
  ::SetBkColor(ps.hdc, rgbOld);

  // This vertical line at the right side of the text shows that opaque
  // background is exactly the height returned by GetTextExtentPoint32.
  SIZE size = {0};
  if (::GetTextExtentPoint32W(ps.hdc, pszText, cchText, &size)) {
    ::MoveToEx(ps.hdc, x + size.cx, y, NULL);
    ::LineTo(ps.hdc, x + size.cx, y + size.cy);
  }

  // These horizontal lines show the normal line spacing, taking into
  // account tmExternalLeading.
  assert(tm.tmExternalLeading > 0);  // ensure it's an interesting case
  ::MoveToEx(ps.hdc, x, y, NULL);
  ::LineTo(ps.hdc, x + size.cx, y);  // top of this line
  const int yNext = y + tm.tmHeight + tm.tmExternalLeading;
  ::MoveToEx(ps.hdc, x, yNext, NULL);
  ::LineTo(ps.hdc, x + size.cx, yNext);  // top of next line

The gap between the bottom of the colored rectangle and the top of the next line represents the external leading, which is always outside the character cell.

OCR-B is designed for reliable optical character recognition in banking equipment. Having a large external leading (relative to the height of the actual text) may be appropriate for some OCR applications. For this particular font, it's probably not an aesthetic choice.

这篇关于在Win7中，一些字体不能像Win2K / XP那样工作的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！