Java font.properties 配置文件(中文/翻译中。。。)

本文介绍Java2平台如何通过font.properties文件映射逻辑字体名称到物理字体,包括不同平台上的具体配置方法及文件加载流程。此外还涉及字体字符编码、排除范围等配置细节。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

The Java 2 platform defines five logical font names that every implementation must support: Serif, SansSerif, Monospaced, Dialog, and DialogInput. These logical font names are mapped to physical fonts in implementation dependent ways.

Java 2 平台定义了每种实现都一定支持的5种逻辑字体名称,其中包含了Serif,SansSerif, Monospaced, Dialog和DialogInput。这些逻辑字体名称以实现相关的方式映射到物理字体。

Sun's Java 2 Runtime Environments use font.properties files to map logical font names to physical fonts. There are several files to support different mappings depending on host operating system version and locale. The files are located in the lib directory within the J2RE installation. Users can edit or create their own font.properties files to adjust the mappings to their particular system setup. Note however that this is a modification of the J2RE, and Sun does not support modified J2REs.

Sun Java 2 Runtime Environment使用font.properties文件将逻辑字体名称映射到物理字体。根据主机操作系统版本和语言环境,有几个文件支持不同的映射。这些文件位于J2RE安装目录中的lib目录中。用户可以编辑或创建自己的font.properties文件,以调整对应特定系统设置的映射。但是请注意,这是对J2RE的修改,Sun不支持修改后的J2REs。

Note that font.properties files are implementation dependent. Not all implementations of the Java 2 platform use them, and the format and content vary between different runtime environments as well as between releases. This document describes the format used by version 1.4.2 of Sun's Java 2 Runtime Environments.

请注意,font.properties文件是与实现有关的。并非Java 2平台的所有实现都使用它们,并且格式和内容在不同的运行时环境之间以及在发行版之间也有所不同。本文档描述了Sun的Java 2 Runtime Environment 1.4.2版使用的格式。

  1. Loading font.properties Files
  2. Names Used in font.properties Files
  3. Properties for All Platforms
  4. Properties for Windows
  5. Properties for Solaris and Linux

     1.加载font.properties文件
     2.font.properties文件中使用的名称
     3.所有平台的Properties
     4.Windows的Properties
     5.Solaris和Linux的Properties

 


Loading font.properties Files

The font.properties files are properties files as specified by the Properties class and are loaded through that class. To find the appropriate file, the following information is used:

  • JavaHome - the J2RE's directory, as given by the "java.home" system property.
  • Language - the language of the initial default locale.
  • Country - the country of the initial default locale.
  • Encoding - the canonical name of the default encoding.
  • OS - a string identifying an operating system variant:
    • For Windows, "NT", "98", "2000", "Me", "XP".
    • For Solaris, empty.
    • For Linux, "Redhat", "Turbo", "SuSE".
  • Version - a string identifying the operating system version.

The runtime uses the first of the following files it finds:

	JavaHome/lib/font.properties.Language_Country_Encoding.OSVersion
	JavaHome/lib/font.properties.Language_Country_Encoding.OS
	JavaHome/lib/font.properties.Language_Country_Encoding.Version
	JavaHome/lib/font.properties.Language_Country_Encoding
	JavaHome/lib/font.properties.Language_Country.OSVersion
	JavaHome/lib/font.properties.Language_Country.OS
	JavaHome/lib/font.properties.Language_Country.Version
	JavaHome/lib/font.properties.Language_Country
	JavaHome/lib/font.properties.Language_Encoding.OSVersion
	JavaHome/lib/font.properties.Language_Encoding.OS
	JavaHome/lib/font.properties.Language_Encoding.Version
	JavaHome/lib/font.properties.Language_Encoding
	JavaHome/lib/font.properties.Language.OSVersion
	JavaHome/lib/font.properties.Language.OS
	JavaHome/lib/font.properties.Language.Version
	JavaHome/lib/font.properties.Language
	JavaHome/lib/font.properties.Encoding.OSVersion
	JavaHome/lib/font.properties.Encoding.OS
	JavaHome/lib/font.properties.Encoding.Version
	JavaHome/lib/font.properties.Encoding
	JavaHome/lib/font.properties.OSVersion
	JavaHome/lib/font.properties.OS
	JavaHome/lib/font.properties.Version
	JavaHome/lib/font.properties

 


Names Used in font.properties Files

Throughout the font.properties files, a number of different names are used:

  • LogicalFontName - one of the five logical font names: serif, sansserif, monospaced, dialog, and dialoginput. In font.properties files, these names are always in lowercase.

    Some existing font.properties files also use other names as logical font names, such as helvetica or zapfdingbats. This usage is deprecated, and support for it will be removed in a future release.

  • StyleName - one of the four standard font styles: plain, bold, italic, and bolditalic. Again, these names are always in lowercase.
  • PlatformFontName - the name of a physical font in a format typically used on the platform:
    • On Windows, a font face name, such as "Courier New" or "/uad74/ub9bc".
    • On Solaris and Linux, an xlfd name, such as "-monotype-times new roman-regular-r---*-%d-*-*-p-*-iso8859-1". Note that "%d" is used for the font size - the actual font size is filled in at runtime.
  • ComponentIndex - an integer identifying a component font entry within the set of entries for the same logical font and style. If there are n entries for a logical font and style, their indices must be 0 to n-1.
  • WindowsCharsetName - one of the following Windows charset names: ANSI_CHARSET, DEFAULT_CHARSET, SYMBOL_CHARSET, SHIFTJIS_CHARSET, GB2312_CHARSET, HANGEUL_CHARSET, CHINESEBIG5_CHARSET, OEM_CHARSET, JOHAB_CHARSET, HEBREW_CHARSET, ARABIC_CHARSET, GREEK_CHARSET, TURKISH_CHARSET, VIETNAMESE_CHARSET, THAI_CHARSET, EASTEUROPE_CHARSET, RUSSIAN_CHARSET, MAC_CHARSET, BALTIC_CHARSET.

 


Properties for All Platforms

Component Font Mappings

Component font mapping properties describe which physical fonts to use to render characters with a given logical font in a given style. Typically there are several component font entries for each combination of logical font and style so as to cover a wide range of Unicode characters. The entries are identified by component indices. When rendering a character, the runtime checks the component fonts in the sequence defined by the component indices and uses the first one that can render the character and is not excluded.

The keys have the form:

ComponentFontMappingKey:
	LogicalFontName.StyleName.ComponentIndex
	LogicalFontName.ComponentIndex

If the StyleName is omitted, it's assumed to be plain. Within one logical font, the style name plain must either be present for all entries or omitted for all entries. The ComponentIndex identifies a component font entry within the set of entries for the same logical font and style. If there are n entries for a logical font and style, their indices must be 0 to n-1. Component indices must be used consistently between different styles for the same logical font, because some other properties only refer to the logical font name and the component index.

The form of the values depends on the platform. For Solaris and Linux, the values are platform font names. For Windows, the values have the form:

	PlatformFontName , WindowsCharsetName

The Windows charset name identifies the primary character set that this font is supposed to cover. The Java 2 runtime environment uses this information to select the component font to use in peered AWT text components, and Windows may use it to substitute a different font if the specified one cannot be found.

Component Font Character Encodings

Component font character encoding properties indicate which character encoding AWT should use when accessing the corresponding component fonts. These properties are only needed if the component fonts cannot be accessed using Unicode - newer TrueType fonts can usually be accessed using Unicode and don't need this property.

The keys have the form:

	fontcharset.LogicalFontName.ComponentIndex

The values are fully qualified class names of character converters. In this release, character converters are accessed using the old sun.io interfaces, so only the character encodings provided by the Java 2 Runtime Environment can be used. The class names for the publicly supported character encodings are of the form:

	sun.io.CharToByteCanonicalName

In a future release, character converters will be accessed through the new java.nio.charset API, which will enable the use of third-party character converters.

Exclusion Ranges

The exclusion range properties specify Unicode character ranges which should be excluded from being rendered with a given component font. This is used if a font with a large character repertoire needs to be placed early in the search sequence (for example, for performance reasons), but some characters that it supports should be drawn with a different font instead.

The keys have the form:

	exclusion.LogicalFontName.ComponentIndex

The values have the form:

ExclusionRangeValue:
	Range
	Range , ExclusionRangeValue
 
Range:
	Char - Char
 
Char:
	HexDigit HexDigit HexDigit HexDigit

A Char is a Unicode character represented as a hexadecimal value.

Font File Names

Font file name properties provide the names of the files containing the physical fonts used in the font.properties file. Providing a complete set of file names reduces startup time, since the runtime system doesn't need to open all available font files to find the fonts.

The keys have the form:

	filename.PlatformFontName

Space characters in the platform font name must be replaced with underscore characters ("_").

The values are the file names of the files containing the fonts. On Windows, simple file names are used; and the runtime environment looks for each file first in its own lib/fonts directory, then in the Windows fonts directory. On Solaris and Linux, absolute path names or xlfd names are used.

Appended Font Path

The Java runtime can automatically determine a number of directories that contain font files, such as its own lib/fonts directory or the Windows fonts folder. Additional directories can be specified to be appended to the font path.

The key has the form:

	appendedfontpath

The value has the form:

AppendedFontPathValue:
	Directory
	Directory PathSeparator AppendedFontPathValue

The path separator is the platform dependent value of java.io.File.pathSeparator.

Font Name Aliases

Font name aliases are deprecated, and support for them will be removed in a future release.

The keys have the form:

	alias.LogicalFontName

The values have the form:

	LogicalFontName

Missing Glyph Character

Missing glyph character definitions are deprecated, and support for them will be removed in a future release.

The keys have the form:

	default.char

The values have the form:

	Char

 


Properties for Windows

Text Input Character Set

Text input character set definitions are deprecated, and support for them will be removed in a future release.

The keys have the form:

	textinputcharset

The values have the form:

	WindowsCharsetName

 


Properties for Solaris and Linux

XFontSet Information

X font set definitions are deprecated, and support for them will be removed in a future release.

The keys have the forms:

	fontset.LogicalFontName.StyleName
	fontset.default

The values have the form:

FontSetValue:
	PlatformFontName
	PlatformFontName , FontSetValue
<think>好的,我现在需要解决用户关于kkfile预览DWG文件时遇到的PDFBox字体渲染警告的问题。首先,我得理解用户的问题是什么。用户提到在2025-03-13 14:15:02.091这个时间点,系统日志中出现了警告信息:“WARN TTFGlyph2D No glyph for code 0 CID 0000 FAAABG+FangSong”,这可能是因为PDFBox在渲染字体时找不到对应的字形,导致DWG文件预览时出现字体显示问题。 接下来,我应该考虑如何解决这个问题。根据用户提供的引用内容,特别是引用[2]和引用[3],用户已经尝试了一些跨域解决方案但未成功,并且现在需要处理字体渲染的问题。首先,我需要确认这个警告的具体原因。通常,PDFBox在渲染字体时如果找不到对应的字体文件,就会抛出这样的警告。这可能是因为系统中缺少所需的字体,或者字体配置不正确。 解决方案的第一步可能是安装缺失的字体。用户提到的字体是FangSong(仿宋),这是一个中文字体。如果服务器上没有安装这个字体,PDFBox就无法找到它,导致渲染问题。因此,用户需要将FangSong字体文件(通常是.ttf或.otf格式)安装到服务器的字体目录中。在Linux系统中,通常是/usr/share/fonts,然后需要更新字体缓存。例如,使用命令fc-cache -fv来刷新字体缓存。 然后,检查kkFileView的配置。用户提到在application.properties中进行配置,可能需要设置PDFBox的字体相关参数。例如,添加配置项pdf.font.ttf.path=/path/to/fonts,指向字体文件所在的目录,确保PDFBox能够正确加载这些字体。此外,可能需要调整JVM参数,比如增加字体缓存大小或指定字体目录,例如-Dsun.java2d.fontpath=/path/to/fonts。 另外,用户可能需要替换或升级PDFBox的版本。如果当前使用的PDFBox版本较旧,可能存在已知的字体处理问题,升级到最新版本可能会解决这些问题。不过,这需要测试兼容性,确保kkFileView支持新版本的PDFBox。 如果以上方法无效,用户可以考虑修改源码来绕过字体缺失的问题。例如,在调用PDFBox渲染时,设置一个默认的替换字体,或者在渲染时忽略缺失的字形警告。这需要对kkFileView的源码进行修改,并重新编译部署,这对用户的技术水平有一定要求。 最后,用户需要验证解决方案是否有效。安装字体并调整配置后,重新启动kkFileView服务,再次尝试预览DWG文件,查看日志中是否还有相同的警告信息。如果警告消失且预览正常,说明问题解决;如果仍然存在,可能需要进一步排查其他配置或依赖问题。 在帮助用户的过程中,要确保步骤清晰,并且考虑到用户可能的技术水平,提供具体的命令和配置示例。同时,提醒用户在操作前备份配置文件,避免因配置错误导致服务不可用。如果用户遇到其他问题,建议他们查阅kkFileView的官方文档或社区支持,获取更多帮助。</think>### 解决方案:KKFileView预览DWG文件时PDFBox字体渲染警告的处理 #### 问题分析 警告`No glyph for code 0 CID 0000 FAAABG+FangSong`表明PDFBox在渲染DWG文件时找不到仿宋字体(FangSong)的字形数据[^1]。可能原因是: 1. 服务器未安装仿宋字体文件(`.ttf`或`.otf`格式)[^2] 2. PDFBox字体缓存配置未正确指向字体目录 3. kkFileView未启用自定义字体加载逻辑 --- #### 解决方案步骤 1. **安装缺失的仿宋字体** - **Windows服务器**: - 下载仿宋字体文件(如`simfang.ttf`) - 复制到`C:\Windows\Fonts`目录 - **Linux服务器**: ```bash # 创建字体目录(若不存在) sudo mkdir -p /usr/share/fonts/custom # 复制字体文件到目录(需替换实际路径) sudo cp simfang.ttf /usr/share/fonts/custom/ # 更新字体缓存 sudo fc-cache -fv ``` 2. **修改`application.properties`配置** 添加以下配置以指定PDFBox字体路径: ```properties # 指向字体目录 pdf.font.ttf.path=/usr/share/fonts/custom # 强制PDFBox使用系统字体 pdf.font.use-system-font=true ``` 3. **调整JVM参数** 在启动脚本(如`startup.sh`)中添加: ```bash -Djava.awt.headless=true \ -Dsun.java2d.fontpath=/usr/share/fonts/custom \ -Dpdfbox.fontcache=/tmp ``` 4. **验证字体加载** 通过以下命令检查字体是否被系统识别: ```bash fc-list | grep FangSong ``` 5. **清理缓存并重启服务** ```bash # 清理kkFileView缓存 rm -rf ${KKFILEVIEW_HOME}/cache/* # 重启服务 ./shutdown.sh && ./startup.sh ``` --- #### 高级调试方法 - **强制替换默认字体**:修改`PDFDocument.java`源码,添加: ```java PDFont font = PDType0Font.load(document, new File("simfang.ttf")); ``` - **日志级别调整**:在`logback.xml`中设置: ```xml <logger name="org.apache.pdfbox" level="ERROR"/> ``` ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值