novelWriter项目中的字体设置问题分析与解决方案
项目地址: https://gitcode.com/gh_mirrors/no/novelWriter 问题背景
在novelWriter 2.6 Beta 1版本中，用户发现了一个关于字体设置的异常行为：当在"首选项"中修改"文档字体"后，即使"构建设置"中指定了不同的字体，系统仍会使用首选项中设置的字体进行预览和PDF输出。这个问题在2.5.2版本中表现为修改"应用程序字体"时出现类似行为。
技术分析
Qt字体匹配机制的问题
经过深入分析，发现这个问题源于Qt框架的字体匹配机制。Qt的QFont类表示用户选择的字体，但实际使用的字体可能完全不同，这可以通过QFontInfo类获取。当应用程序或文档字体发生变化时，Qt的字体匹配算法会做出一些非预期的选择，导致所有其他字体也被切换使用相同的字体。
具体表现为：
- 当修改主字体时，整个应用程序的字体都会被重置
- 文档字体随后也会被重置
- 整个流程变得混乱，导致字体设置不一致
特殊字体情况
在测试过程中还发现，对于Courier这类位图字体，Qt会将其映射为Courier New，并且在PDF输出时会出现字体大小异常的问题（固定为1.5pt）。这是由于位图字体在1200DPI的高分辨率模式下无法正确缩放导致的。
解决方案
字体匹配器实现
为了解决这个问题，开发团队实现了一个字体匹配器函数(fontMatcher)，其主要功能包括：
- 检查请求的字体与实际使用的字体是否匹配
- 如果不匹配，则在字体数据库中进行手动查找
- 找到匹配字体后返回正确的字体对象
- 如果找不到匹配，则回退到Qt选择的字体
def fontMatcher(font: QFont) -> QFont:
"""确保字体是正确的字体族，避免Qt使用GUI或文档字体替代"""
info = QFontInfo(font)
if (famRequest := font.family()) != (famActual := info.family()):
logger.warning("字体不匹配: %s != %s", famRequest, famActual)
db = QFontDatabase()
if famRequest in db.families():
styleRequest, sizeRequest = font.styleName(), font.pointSize()
logger.info("查找: %s, %s, %d pt", famRequest, styleRequest, sizeRequest)
temp = db.font(famRequest, styleRequest, sizeRequest)
famFound, styleFound, sizeFound = temp.family(), temp.styleName(), temp.pointSize()
if famFound == famRequest:
logger.info("找到: %s, %s, %d pt", famFound, styleFound, sizeFound)
return temp
logger.warning("无法找到匹配的字体")
logger.warning("您可能需要重启应用程序")
return font
分辨率处理优化
针对位图字体在PDF输出中的问题，解决方案是：
- 对于可缩放字体，使用1200DPI的高分辨率模式
- 对于位图等不可缩放字体，使用72DPI的标准分辨率
- 通过Qt的字体数据库API检查字体的可缩放性
这种处理方式既保证了可缩放字体的高质量输出，又确保了位图字体能够正确显示。
版本差异处理
在2.5.x版本中，这个问题表现为修改"应用程序字体"会影响构建设置，而在2.6 Beta 1中则表现为修改"文档字体"影响构建设置。对于2.5.x版本，建议用户通过重启应用程序来解决；而在2.6版本中，通过上述技术方案从根本上解决了问题。
结论
通过实现字体匹配器和优化分辨率处理，novelWriter项目成功解决了字体设置被意外覆盖的问题。这个解决方案不仅修复了当前版本的问题，还为未来可能出现的类似字体相关问题提供了可靠的解决框架。对于用户来说，现在可以更加可靠地在不同位置设置不同的字体，而不用担心设置被意外覆盖。
这个案例也展示了在复杂GUI应用程序中处理字体问题时需要考虑的各种因素，包括框架行为、字体特性和输出格式要求等。
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
