带尖括号的PDF Tj命令?

带尖括号的PDF Tj命令?,pdf,pdf-generation,Pdf,Pdf Generation,我试图找出在未压缩的PDF v1.4文档中使用Times字体的位置 描述PDF中时代字体的/Font对象为object65,如下所示: 65 0 obj <</Type /Font /Subtype /TrueType /BaseFont /PXAAAD+TimesNewRoman,Italic /FirstChar 1 /LastChar 35 /Widths [250 333 333 333 500 500 500 500 500 500 500 500 500 500 333

我试图找出在未压缩的PDF v1.4文档中使用Times字体的位置

描述PDF中时代字体的
/Font
对象为object
65
,如下所示:

65 0 obj
<</Type /Font
/Subtype /TrueType
/BaseFont /PXAAAD+TimesNewRoman,Italic
/FirstChar 1
/LastChar 35
/Widths [250 333 333 333 500 500 500 500 500 500 500 500 500 500 333 722 722 833 666 610 500 556 500 443 443 500 277 443 500 389 389 277 500 443 500]
/FontDescriptor 205 0 R
/ToUnicode 206 0 R>>
endobj
现在,我已经将Times字体对象的用法追溯到了一个
/Page
对象(许多对象中的一个),如下所示,它通过其页面
/Resources
中的
/F4
引用引用了字体对象
65

12 0 obj
<</Type /Page
/Parent 2 0 R
/MediaBox [0 0 432 648]
/Contents 92 0 R
/Resources <</Font <</F1 62 0 R
/F3 64 0 R
/F4 65 0 R>>
/ProcSet [/PDF /Text]>>
/Group <</S /Transparency
/CS /DeviceRGB>>>>
endobj
但是尖括号和数字
指的是什么?字体表中的特定字形?查看第5.3.2节和第5.3.2节,我找不到尖括号

编辑:鉴于上述代码和公认的答案,即
是文本的十六进制编码,
CMap
对象
206
中的
条目,因此分别映射到unicodes
。这意味着,字符串
指的是U+0031(a“1”)和U+0030(a“0”),因此,Times字体用于页面对象
12

上的字符串“10”:

  • 在内容流中,
    Tj
    命令被赋予要绘制的字符串
    。介于
    之间的字符串是十六进制字符串,因此会绘制字符#6和#5。链接PDF参考文件的3.2.3中解释了符号

  • 在文本绘制命令之前,使用
    Tf
    命令选择字体
    F4

  • 给定包含字体的页面的资源叉被引用为对象65修订版0。此字体对象是一个子集Truetype字体,其中定义了字形1..35。未指定
    编码
    (因此使用
    winansioncoding
    )。因此,嵌入的子集字体以非标准方式重新排列字体中的字符(经常发生)


现在,如果您想知道这些glyph id是如何链接到Unicode字符的:字体有一个
ToUnicode
链接,其中流包含定义映射的
CMAP
。这应该足以将字符串转换为Unicode字符串。

事实上,我认为你关于WinAnsiceODing的评论是不正确的。当谈到TrueType字体的字体字典中/Encoding的值时,来自PDF规范:“用于显示不使用MacRomanEncoding或WinAnsienceCodeing的字形的字体不应指定编码条目”。这本身就很奇怪,因为在字体字典的原始描述中,键被描述为“必需”。我猜字体确实使用了完全专有的编码,因此它也应该在字体描述符中设置符号位。字体不是很酷吗?:)@David:对于type1字体,默认值是StandardEncoding,对于TT字体,默认值是WinAnsienceODing。PDf文件中的字体通常是一团乱麻,你需要很多技巧/假设和正确的月相才能正确渲染这些字体(我构建了一个PDf渲染器,这部分是最糟糕的)。如果指定为符号字体,则编码应如您所述为1on1。几乎所有的PDF都包含错误(无效的条目、无效的名称、名称而不是字符串,反之亦然)。PDF阅读器真是了不起的野兽,它们能解析的垃圾量之大……我还写了(部分)PDF渲染器:-),但我想我漏掉了大部分字体内容;你的意思是,虽然PDF规范可能说明TrueType字体需要编码,但实际上在字段中没有正确遵循编码?还是我遗漏了PDF规范中定义默认值的部分?这确实很有趣(我想这说明了我的一些情况:)@RitsaertHornstra:我已经编辑了这个问题,添加了提到的
CMap
。如果我理解正确,则
CMap
对象中的条目,分别映射到
。也就是说,它们指的是U+0031(a“1”)和U+0030(a“0”)。对吗?如果是这样,那么泰晤士报字体将用于呈现字符串“10”@Jens:你说得对!请注意,ToUnicode CMAP仅用于文本处理应用程序,与渲染无关。因此,如果CMAP正确,PDF内容会在呈现目标上写出10。然后,
/Contents
流中充满了文本对象(包含在
BT
ET
中),它们都不包含文本,而是使用满是数字的尖括号。-正如@Ritsaert已经解释过的,尖括号中的数字是字符串,只是碰巧是用十六进制形式写的。@mkl:它总结了问题和答案:)
12 0 obj
<</Type /Page
/Parent 2 0 R
/MediaBox [0 0 432 648]
/Contents 92 0 R
/Resources <</Font <</F1 62 0 R
/F3 64 0 R
/F4 65 0 R>>
/ProcSet [/PDF /Text]>>
/Group <</S /Transparency
/CS /DeviceRGB>>>>
endobj
92 0 obj
<</Length 93 0 R>>
stream
...
BT
0.5020 g
72.0000 615.1512 Td
/F4 12.0000 Tf
<0605> Tj
ET
...
endstream
endobj