為什么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現在使用的。