关于字体的尺寸与设置的值不一致的问题
最近同事反映说打印预览不是所见即所得,这个问题已经存在已久,我知道是屏幕分辩率与打印分辩率不一致的问题,但是更具体的原因没有去深究,现在翻出n年前做的打印预览程序,仔细检查,最后发现打印使用的11磅,在预览时(屏幕显示时),磅数是11.25 ,这样造成预览并不是所见即所得,十分苦恼。进而发现可以使用的字体尺寸都是0.75的整数倍,如9(指定9磅),9.75(10),11.25(11),12,12.75(13)...
简单的说,字体的大小单位磅(points) 是1/72逻辑英寸,屏幕的分辨率是96DPI(96点每英寸),那么屏幕每个点就是72/96=0.75磅,那么屏幕字体大小可以选择的尺寸就是屏幕点/磅(也就是0.75)的整数倍,注意,如果屏幕的逻辑分辨率不是96DPI,那么可能不是0.75。
因为打印预览时尺寸的测量和字体的大小很有关系,如果是用drawtext输出多行文本,字号差一点,屏幕上的显示就和打印不一致,让人很是头疼,好在我们输出主要使用的都是11磅(其它尺寸使用的比较少,不影响整体显示),目前我的解决办法是预览的时候100%实际使用的是108%的比例去显示,只能先凑合解决问题,如果那天默认尺寸是12磅,那我的预览又不对了:S ,当然,也可以用打印字体大小就迁就屏幕的大小,11磅都输出11.25磅,但都不是解决之道, 不知道word是怎么处理的? 怎么缩放,一个文本框内的多行文字换行的位置都不变,谁知道能告知一下,不胜感激。
(另外,我们打印主要是一段英文文字在一个框内,也许中文问题不大,但我想应该还是存在的)
网上搜索,发现一篇文章,可以参考一下:http://support.microsoft.com/kb/138801/en-us
You can call Windows API functions to obtain the enumerated FontSize list. This is useful to know for fixed, non-TrueType fonts. Visual Basic also offers font properties (Fonts, FontName, FontSize, and FontCount) to determine font information.
The enumerated FontSize list for non-TrueType fonts may vary from one screen resolution to another. This can happen because the number of logical pixels per inch can vary between resolutions. This means that the number of points per pixel can also vary. The point size of a font is adjusted to the nearest pixel.
The point size on a screen is based on logical inches. Logical inches are somewhat arbitrary because Windows has no way of really knowing how big a pixel is on your screen. For example, you could be hooked up to a projection TV or a tiny monitor. Usually the logical inch is overly large; tiny text is often difficult to read on a video display.
Because the point size is based on the logical pixels per inch of a device, not all point sizes can be represented. For example, on a standard VGA, Windows will tell you that the device has 96 pixels per logical inch (according to the Windows API GetDeviceCaps(hDC, LOGPIXELSY) function). A 96-pixel tall glyph is 72 points because each point is about 1/72 of an inch. This means each pixel is 72/96 point or 0.75 point per pixel. The system could theoretically represent fonts of the following heights:
2 pixels = 1.50 point
3 pixels = 2.25 point
4 pixels = 3.00 point
Rounding errors are unavoidable in this scheme. Even if the device displayed exactly 96 dots per inch (DPI), it could not represent a font that was exactly 2 points. The closest it could come would be 2.25 points. Usually, this small difference is not noticeable. However, if two screen drivers have different logical pixels-per-inch, you might see different point sizes in the enumerated list in Windows.
字号和磅的对应关系:
http://soft.ccw.com.cn/apply/office/htm2008/20080608_441970.shtml
本文来自博客园,作者:James-yu,转载请注明原文链接:https://www.cnblogs.com/james-yu/archive/2009/05/29/1491600.html
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 从 HTTP 原因短语缺失研究 HTTP/2 和 HTTP/3 的设计差异
· AI与.NET技术实操系列:向量存储与相似性搜索在 .NET 中的实现
· 基于Microsoft.Extensions.AI核心库实现RAG应用
· Linux系列:如何用heaptrack跟踪.NET程序的非托管内存泄露
· 开发者必知的日志记录最佳实践
· TypeScript + Deepseek 打造卜卦网站:技术与玄学的结合
· Manus的开源复刻OpenManus初探
· AI 智能体引爆开源社区「GitHub 热点速览」
· C#/.NET/.NET Core技术前沿周刊 | 第 29 期(2025年3.1-3.9)
· 从HTTP原因短语缺失研究HTTP/2和HTTP/3的设计差异