ReportLab stringWidth()计算异常：单项目符号文本持续截断问题排查

问题现象 #

每份生成的PDF中恰好有一处项目符号文本被截断，依赖stringWidth()的基于像素换行逻辑在特定字符序列下持续触发问题，示例：

• "...by 18 points" → 显示为 "...by 1"
• "...rates by 40%" → 显示为 "...rates b"
• "...recurring revenue" → 显示为 "...recurrin"

当前文本换行实现代码 #

def _wrap_text_by_width(self, text: str, max_width: float, font_name: str, font_size: int) -> list:
    from reportlab.pdfbase.pdfmetrics import stringWidth

    # Measure actual width of text
    text_width = stringWidth(text, font_name, font_size)
    if text_width <= max_width:
        return [text]

    words = text.split()
    lines = []
    current_line = ""

    for word in words:
        test_line = current_line + (" " if current_line else "") + word
        test_width = stringWidth(test_line, font_name, font_size)
        
        if test_width <= max_width:
            current_line = test_line
        else:
            # Line wrapping logic continues...

已应用的修复措施 #

1. ASCII归一化统一宽度计算
   转换智能引号、破折号、Unicode项目符号为ASCII，解决了90%的宽度计算问题：

   def _normalize_text_to_ascii(self, text: str) -> str:
       # Convert smart quotes, em-dashes, Unicode bullets to ASCII
       # This fixed 90% of width calculation issues
   

2. 添加保守边距缓冲
   为项目符号文本预留100px安全边距：

   wrapped_lines = self._wrap_text_by_width(
       clean_content, 
       available_width - 100,  # 100px safety margin
       "Helvetica", 
       body_font_size
   )
   

已尝试的其他方案（未解决剩余1%问题） #

• 调整安全边距范围（30px-150px）
• 替换为WeasyPrint/pdfkit等其他PDF生成库
• 实现智能断行逻辑
• 对比字符/像素级换行效果
• 更换字体族

问题根源推测 #

• 特定字符组合的字距调整计算偏差
• Helvetica字体指标在ReportLab中的解析不一致
• 宽度计算的浮点精度误差
• ASCII归一化未覆盖的编码边缘情况

咨询问题 #

1. ReportLab的stringWidth()针对特定字符序列是否存在已知问题？
2. 确保PDF文本测量精准的最可靠方法是什么？

内容的提问来源于stack exchange，提问作者M. Maddali