为什么GetImageCTM始终将pdf中图像的X / Y协调器归零？

Question

我正在网上搜索很长时间。 但是没用。 请帮助或尝试给出一些想法来实现这一目标。 任何帮助将不胜感激。

我通过ImageRenderInfo＃GetImageCTM（）获得矩阵，并获得X / Y协调器。 但始终为0！

我已经尝试过这些api，GetStartPoint（）和GetImageCTM。 但是，X / Y协调器始终为0 :-(

注意：我在某些位置上有一些pdf图片（不是（0,0）协调器）。

void IRenderListener.RenderImage(ImageRenderInfo imgRenderInfo)
{
    Matrix mtx = imgRenderInfo.GetImageCTM();
    // x, y
    float[] coordinate = new float[] { mtx[Matrix.I31], mtx[Matrix.I32] };

    // Why the coordinate[0] and coordinate[1]
    // are always be ZERO regardless the positon in Pdf

}

Answer 1

照原样回答问题

我使用渲染监听器解析了手头上任意文件的页面内容（ 此问题的示例PDF），其中包含您的实现代码以及坐标的输出：

public void ExtractImageCoordinatesFromArchmodels()
{
    using (PdfReader reader = new PdfReader(@"EVERMOTION ARCHMODELS VOL.78.pdf"))
    {
        PdfReaderContentParser parser = new PdfReaderContentParser(reader);
        ImageCoordinatesRenderListener listener = new ImageCoordinatesRenderListener();
        for (var i = 1; i <= reader.NumberOfPages; i++)
        {
            parser.ProcessContent(i, listener);
        }
    }
}

internal class ImageCoordinatesRenderListener : IRenderListener
{
    public void BeginTextBlock()
    { }

    public void EndTextBlock()
    { }

    public void RenderText(TextRenderInfo renderInfo)
    { }

    public void RenderImage(ImageRenderInfo renderInfo)
    {
        Matrix mtx = renderInfo.GetImageCTM();
        // x, y
        float[] coordinate = new float[] { mtx[Matrix.I31], mtx[Matrix.I32] };
        Console.WriteLine("Image at {0}, {1}.", coordinate[0], coordinate[1]);
    }
}

和输出是

Image at 6,00029, 52,15466.
Image at 19,84251, 363,4501.
Image at 294,091, 361,5604.
Image at 300,0336, 81,089.
Image at 15,59055, 72,94052.
Image at 5,322647, 340,7029.
Image at 288,5311, 386,0621.
Image at 291,7613, 69,35573.
Image at 28,50845, 53,13286.
Image at 41,2021, 380,3172.
Image at 290,8796, 368,9564.
Image at 295,8532, 50,71478.
Image at 19,13385, 49,21146.
Image at 25,5118, 385,9343.
Image at 282,4584, 379,8427.
Image at 293,5927, 65,19702.
Image at 4,535416, 60,35075.
Image at 3,364258, 374,4344.
Image at 288,0557, 373,5591.
Image at 299,9102, 59,13971.
Image at 11,33858, 66,10181.
Image at 11,66959, 380,3134.
Image at 297,1836, 378,4615.
Image at 299,9689, 66,74164.
Image at 10,62991, 53,18137.
Image at 5,180252, 377,7065.
Image at 279,9567, 377,9544.
Image at 289,9219, 69,23323.
Image at 6,400314, 68,17795.
Image at 11,33858, 361,2458.
Image at 297,1935, 373,4553.
Image at 299,8854, 68,30142.
Image at 7,086609, 68,13367.
Image at 3,82518, 352,3451.
Image at 287,9208, 373,4846.
Image at 294,6425, 68,3132.
Image at 41,2271, 68,15968.
Image at 5,709488, 356,2161.
Image at 304,9857, 373,593.
Image at 282,4557, 48,97745.
Image at 5,669281, 53,65367.
Image at 27,34265, 382,0123.
Image at 297,1409, 373,494.
Image at 300,0584, 50,23624.
Image at 7,245102, 68,23528.
Image at 8,503922, 380,1963.
Image at 290,1901, 355,9355.
Image at 287,2598, 60,53516.
Image at 5,102356, 68,01541.
Image at 17,00786, 378,9057.
Image at 296,8928, 373,5667.
Image at 299,9655, 68,04535.

（我的语言环境使用逗号作为小数点分隔符。）

因此，我无法复制您的主张

X / Y协调器始终为0

因此，您观察到的结果是由于剩余代码的某些问题，还是由于所有测试PDF的特殊情况； 可能他们确实确实将所有图像定位在0,0

评论的澄清

同时，OP在评论中澄清了感兴趣的图像位于注释外观流中，而不是页面内容流中。

其中的坐标位于相应的注释外观流坐标系中，这由外观的边界框（其BBox条目）隐含。 然后可以选择通过外观矩阵（其矩阵条目）来转换此边界框。 然后，将得到的四边形区域缩放并移动到注释的矩形（其Rect条目）中。 并且取决于页面旋转和注释属性，此矩形可以相对于页面坐标旋转90°的倍数。

因此，将这些坐标转换为页面的默认用户空间坐标系的一般解决方案需要一些数学运算。

但是，注解外观中的位图通常（几乎）完全填充边界框。 通常没有外观矩阵。 注释通常随页面旋转。

因此，通常的近似方法是简单地使用注释矩形。 这也是OP现在使用的。