我浏览了包含图形元素的不同pdf的内容流。 Some pdf包含用于图形的常规CTM文本坐标系。像下面
在这里,我可以将CTM位置与页面坐标进行比较。
但是我在pdf中发现了一些奇怪的东西(x和y转换数以千计,我的页面坐标为576、720。如何与页面坐标进行比较?)。您可以在下看到。在这种情况下,CTM是如何计算的。
我看到了in之类的规则,例如“符合规范的PDF内容流的读取器或写入器可能会将图形状态运算符的排列方式更改为其他任何能实现相关图形状态参数相同值的排列方式每个图形对象。”
任何人都可以解释一下图形解析这样的其他情况吗?需要以什么方式来通用地处理它?</ p>
请说明解析可用图形坐标的所有方法。
答案 0 :(得分:2)
请说明解析可用图形坐标的所有方法。
实际上,只有一种方法可以做到这一点,即PDF规范所隐含的方法:读取内容流时,根据您的指令效果更新当前转换矩阵(CTM)。找到。
让我们看看您的第二个内容流。
在开始时,CTM将默认用户空间映射到设备空间。因为我们对默认用户空间本身中的坐标感兴趣,所以对我们来说这些空间是重合的,因此我们从单位矩阵开始。此外,还没有保存的图形状态,因此在保存的状态下还没有CTM值:
1 0 0 |
0 1 0 |
0 0 1 |
q
第一条指令q
保存当前图形状态;因此,我们现在在图形堆栈上有了CTM的副本:
1 0 0 | 1 0 0
0 1 0 | 0 1 0
0 0 1 | 0 0 1
.1 0 0 .1 0 0 cm
下一条指令.1 0 0 .1 0 0 cm
从左侧乘以CTM:
.1 0 0 1 0 0 .1 0 0
0 .1 0 * 0 1 0 = 0 .1 0
0 0 1 0 0 1 0 0 1
因此,我们有
.1 0 0 | 1 0 0
0 .1 0 | 0 1 0
0 0 1 | 0 0 1
... re W n ... rg ... gs
这些说明不会更改CTM或状态堆栈。
q
下一条指令q
保存当前图形状态;因此
.1 0 0 | 1 0 0 .1 0 0
0 .1 0 | 0 1 0 0 .1 0
0 0 1 | 0 0 1 0 0 1
(我将堆栈的顶部绘制在右侧。)
1 0 0 1 3398 2608 cm
(为简洁起见,我将这些值截短了一部分。)
下一条指令1 0 0 1 3398 2608 cm
从左侧乘以CTM:
1 0 0 .1 0 0 .1 0 0
0 1 0 * 0 .1 0 = 0 .1 0
3398 2606 1 0 0 1 339.8 260.6 1
因此,我们现在有
.1 0 0 | 1 0 0 .1 0 0
0 .1 0 | 0 1 0 0 .1 0
339.8 260.6 1 | 0 0 1 0 0 1
由于成千上万的价值,这是您不确定的第一条说明。不过,在评估之后,您会看到原点被推到相当正常的值339.8 260.6
。
... m ... l ... l h f*
这些说明不会更改CTM或状态堆栈。
Q
下一条指令Q
恢复最近保存的图形状态。因此,我们有
.1 0 0 | 1 0 0
0 .1 0 | 0 1 0
0 0 1 | 0 0 1
... RG ... w ... M
这些说明不会更改CTM或状态堆栈。
q
下一条指令q
保存当前图形状态;因此
.1 0 0 | 1 0 0 .1 0 0
0 .1 0 | 0 1 0 0 .1 0
0 0 1 | 0 0 1 0 0 1
1 0 0 1 3607 2339 cm
(为简洁起见,我将这些值截短了一部分。)
下一条指令1 0 0 1 3607 2339 cm
从左侧乘以CTM:
1 0 0 .1 0 0 .1 0 0
0 1 0 * 0 .1 0 = 0 .1 0
3607 2339 1 0 0 1 360.7 233.9 1
因此,我们现在有
.1 0 0 | 1 0 0 .1 0 0
0 .1 0 | 0 1 0 0 .1 0
360.7 233.9 1 | 0 0 1 0 0 1
这是您不确定的第二条指令,因为该指令具有成千上万的价值。但是,在评估之后,您再次看到原点被推到相当正常的值360.7 233.9
。