我正在尝试将 ReportLab 与 Unicode 字符一起使用,但它不起作用。我尝试跟踪代码,直到到达以下行:
class TTFont:
# ...
def splitString(self, text, doc, encoding='utf-8'):
# ...
cur.append(n & 0xFF) # <-- here is the problem!
# ...
(此代码可以在 ReportLab 的存储库中的pdfbase/ttfonts.py文件中找到。有问题的代码在第 1059 行。)
为什么n
's 的价值被操纵?
在上面显示的行中,n
包含正在处理的字符的代码点(例如,'A' 为 65,'a' 为 97,或阿拉伯光泽 'ش' 为 1588)。cur
是一个列表,其中填充了要发送到最终输出 (AFAIU) 的字符。在该行之前,一切(显然)工作正常,但在这一行中, 的值n
被操纵,显然将其减少到扩展的 ASCII 范围!
这会导致非 ASCII、Unicode 字符失去其价值。我不明白这个声明有什么用,或者为什么有必要!
所以我的问题是,为什么n
's 的价值在这里被操纵,我应该如何着手解决这个问题?
编辑:
针对关于我的代码片段的评论,这是一个导致此错误的示例:
my_doctemplate.build([Paragraph(bulletText = None, encoding = 'utf8',
caseSensitive = 1, debug = 0,
text = '\xd8\xa3\xd8\xa8\xd8\xb1\xd8\xa7\xd8\xac',
frags = [ParaFrag(fontName = 'DejaVuSansMono-BoldOblique',
text = '\xd8\xa3\xd8\xa8\xd8\xb1\xd8\xa7\xd8\xac',
sub = 0, rise = 0, greek = 0, link = None, italic = 0, strike = 0,
fontSize = 12.0, textColor = Color(0,0,0), super = 0, underline = 0,
bold = 0)])])
在PDFTextObject._textOut
,_formatText
中被调用,它将字体标识为_dynamicFont
,并相应地调用font.splitString
,这导致了上述错误。