所以我有这种情况:
使用来自sourceforge.net的pdftoxml.exe
我得到了文本标记及其坐标。如果pdf文件被旋转(即它的源代码中有/Rotate 90
),pdftoxml.exe会交换给定页面的高度和宽度以及任何给定对象的x和y坐标。这就是我的理解。
我很满意,直到我遇到一个使用re
绘制粗线的pdf文件。也就是说,对于粗线,绘制4条细线并填充空间,如图中所示。在左侧,您会看到两条细线(非彩色),它们是较大矩形的一部分(高度放大)。我把它们之间的空间倒空,实际上是用黑色填充的,看看这些线条:
此外,上面的pdf是旋转的。因此,为了使B
最终正确,使用了这个文本矩阵:0 1 -1 0 90.72 28.3705 Tm
。细线是从83.04 27.891 0.48 0.48 re
这样绘制的(这里的坐标可能会有所不同,但这是一些重新操作。操作类似于x y width height re
而re
适用于{{3}的矩形第133页)。这里的相关内容是计算27.891 + 0.48 = 28.371
,由于浮点问题而未舍入或更改。它是行x的精确值,不幸的是,它大于硬编码B
的x,即28.3705
:
83.52 27.891 m 92.39999999999999 27.891 l s
92.39999999999999 27.891 m 92.39999999999999 28.371 l s
92.39999999999999 28.371 m 83.52 28.371 l s
83.52 28.371 m 83.52 27.891 l s
根据左上角的PDFXChange查看器,页面的坐标类似于842 x 595,2
。自页面旋转以来这似乎很自然。没有旋转,它将是左下角,所以应该没问题。
当文本被1 0 0 1 90.72 28.3705 Tm
更改为其原始方向时,可以看到折叠的底线与左侧的行:
这是我所期望的,因为B
'sy是28.3705
并且该行的水平位置是28.371
(可以在上面代码行的第二行看到) 。因此,B
的底线超出28.371
,但我无法缩放。
现在第一张图片中线与B
之间的差距在哪里?这对我来说很重要,因为我试图找出左边最近的一行B
,并对这两个值感到惊讶,即我从pdftoxml.exe获取的文本的x值是28.3705
和水平线28.371
。因为我知道这条线实际上远远超出了B
左边那条不可能正确的线,至少在“走x线的位置”的意义上,取B的x位置,比较,如果线的是x小于B
'sx,该行在左侧“。
我找不到带有x值的正确行。相反,我在左边得到了另一条线......好像文本落在它们两个之间。
这是文字绘图代码:
BT
%0 7.5 -7.5 0 90.72 28.3705 Tm
0 1 -1 0 90.72 28.3705 Tm
%1 0 0 1 90.72 28.3705 Tm
/F1 1 Tf
1 Tr
q
0.01 w
(B) Tj
Q
ET
因此,B的尺寸或线条厚度没有任何奇特的发生。
你能帮我解决一下吗?这是一张更新的图片,其中两个I
在同一页面上绘制,上部I
使用0 1 -1 0 90.72 28.3705 Tm
(数学上旋转90度),下部1 0 0 1 90.72 28.3705 Tm
}。所以我没理解,下I
如何旋转+90
并最终成为上一个?
这是pdf代码。它相当大,但您应该能够将其复制到您的文件中,并将其命名为sth.pdf。
EDIT
我实际上发现了一些关于找到字形边界框的PDF Sample ( you have to actually zoom into the upper left corner real big to see the I
),但是我还没把它们放在一起。
答案 0 :(得分:2)
请看一下
字形原点是字形坐标系中的点(0,0)。 Tj和其他显示文本的运算符应将要绘制的第一个字形的原点定位在文本空间的原点。
(从Figure 39, section 9.2.4 of ISO 32000-1无耻地复制。)
如您所见,字形所在的坐标(字形原点)不一定是实际字形边界框开始的位置。这可以解释您第一张图片中的差距。
因此,当你试图弄清楚哪个是左边最接近B 的线时,取x线的位置,取x的x位置是不够的,比较,如果线的x小于B的x,则线在左边,而你还必须考虑字体数据本身并考虑字形原点和字形边界框之间的间隙由 B 表示的字形。
如需更深入的分析,请提供字体数据。
编辑关于你的双重问题...在上面的评论中你说你实际上希望看到一个共同的点 - 旋转点 - 在两个I字符中,所以你可以获得角色左边界框一侧的可靠水平坐标。
是不是红线交叉的点,你的旋转点?它应该是两个Tj操作的字形起源,并且I字形起源于那里。现在你可以从那里开始测量。