PDF尺寸對實際內容尺寸

我目前使用php的imagick將一些PDF轉換爲圖像 - 這適用於圖像在輸出過程中被「切碎」的小細節。PDF尺寸對實際內容尺寸

這是由於包含在PDF VS實際內容維度信息的差異。

的PDF報告是一個612x792 72ppi文件，但是當我通過它預覽在Mac上導出圖像時，圖像是1651x1275 - 這怎麼可能？

顯然，出口是正確的，因爲該圖象在這些尺寸正確查看 - 可能不會是PDF被簡單地編碼錯誤，其中的寬度和高度進行混合？我怎樣才能通過代碼檢測到這一點？此外，圖像導出是一個不同的（更大）的大小，大約兩倍的大小，這導致我相信imagick沒有正確讀取一些信息。

基本上我想知道是否有確定實際的PDF內容大小合適的方式，這樣從它導出的圖像以最佳質量。

謝謝！

編輯：（添加的代碼）

<?php 
$im = new Imagick(); 
$im->readImage("SomeTest.pdf"); 
$im->setImageColorspace(255); 
$im->setCompression(Imagick::COMPRESSION_JPEG); 
$im->setCompressionQuality(60); 
$im->setImageFormat('jpeg'); 
$im->writeImages("SampleImage.jpg"); 
?>

使用的PDF格式如下： http://www.pantone.com/pages/MYP_mypantone/software_downloader.aspx?f=3

另外，這裏是imagick從identifyImage（）函數的輸出，這似乎有點不對看着文件大小。

Array 
(
    [imageName] => /tmp/magick-XXehkI8e 
    [format] => PDF (Portable Document Format) 
    [geometry] => Array 
     (
      [width] => 612 
      [height] => 792 
     ) 

    [type] => TrueColor 
    [colorSpace] => RGB 
    [resolution] => Array 
     (
      [x] => 72 
      [y] => 72 
     ) 

    [units] => Undefined 
    [fileSize] => 50mb 
    [compression] => Undefined 
    [signature] => 9426f3fc4f45afd71941435a37d585d01e01d32458f3ca241e72892c2f7f35d5 
)

來源

2011-05-19 TeckniX

似乎一切都很好。這真的很粗略。 – 2011-05-20 17:06:39

無論何時您將PDF轉換爲帶有圖像魔術貼的圖像，都要確保將「-density」參數設置爲正確的DPI，否則質量和尺寸將會非常可怕。 – Orbling 2011-05-20 18:21:47

標記，圖像大小實際上不起作用 - 在imagick中有一個明顯的圖像陣列，我需要弄清楚，這樣我才能在每個圖像上設置大小，然後再寫出它們。 – TeckniX 2011-05-20 20:14:51

PDF中的圖像在PDF內縮小到一定尺寸（或者在Reader等中查看它時會被裁剪）。

的ImageMagick（這是我的屁股-U-我imagick用途）使用GhostScript的到PDF轉換爲圖像。 GhostScript非常適合渲染PDF文件。我不知道你是否傳遞了一些不好的信息。

我們可以看到一些代碼嗎？鏈接到您的輸入PDF和輸出圖像[S]也不錯。

我只是GS 8.71跑了您的PDF，它呈現的罰款。你使用的是什麼版本的GhostScript？

來源

2011-05-20 00:51:17

感謝Mark發表評論。實際上代碼非常簡單，並且沒有設置尺寸，因此正在使用PDF尺寸。我將編輯我的原始帖子以添加一些代碼。 – TeckniX 2011-05-20 13:25:52

看起來像$ im-> getImageGeometry（）將返回PDF中的圖像大小 - 出於某種原因，pdf處於橫向並且返回的大小是縱向的？ – TeckniX 2011-05-20 16:53:45

頁面旋轉-90度。這是一種相對罕見的做風景的方式，但是完全合法。其他（更常見）選項是+90和11x8.5。 – 2011-05-20 17:08:49

您應該知道，PDF本身就是一個無分辨率的格式。頁面以數學方式進行描述，除了浮點數字所規定的限制外，頁面不受任何特定分辨率限制的束縛。

PDF唯一真正具有當它呈現給特定設備的分辨率（這可能會或可能不會在設備的分辨率）。

「但是圖像怎麼樣？PDF中的圖像肯定會給它分辨率！」有點。 PDF中的圖像被表示爲無單元樣本，並且在它們已經在頁面上實例化之前它們本身不具有分辨率。我可以將300 dpi 8.5「x11」1位圖像嵌入到PDF中，但是可以將相同的圖像放入填滿整個8.5「x11」空間的頁面的內容流中，從而維護該分辨率或它可以被渲染成一個更小的縮略圖（通過規模創建更高的分辨率） - 甚至這些「分辨率」不適用，直到頁面實際呈現給設備。另外，不會阻止PDF渲染器執行雙線性（或其他）插值來增加圖像的表觀分辨率。

爲了給你一個更具體的例子，如果我在100％呈現96 dpi的顯示器上PDF頁面，該頁面的分辨率不超過96 dpi的。如果我在1800 dpi照排機上渲染該PDF頁面，頁面的分辨率不會超過1800 dpi。

如果我在呈現100％96 dpi的顯示器上呈現的PDF頁面上100％300dpi的圖像，在頁面上的圖像的分辨率爲96 dpi的。如果我在1800 dpi照排機上以100％渲染的PDF頁面上以100％渲染300 dpi圖像，則頁面上圖像的分辨率爲300 dpi。

您從圖像magick中看到的輸出是可能是反映PDF單位中的8.5「x 11」頁面是612 x 792和1 PDF單位相當於1/72英寸。預覽渲染似乎在〜194 dpi完成。直到你得到的文件大小

來源

2011-05-20 17:46:05 plinth

plinth謝謝你對不同渲染的精彩解釋，因爲我不知道PDF背後的數學渲染 - 爲了確定基於jpeg渲染的正確dpi /質量，正確的數學公式是什麼？關於提供的PDF信息？在這個是一個8.5「x11」與300 x/y分辨率？ – TeckniX 2011-05-20 20:13:45

答案是沒有真正的答案。 *如果頁面是單個圖像，則必須從該頁面（或至少其尺寸）中提取圖像，然後將（0，0）和（w，h）通過從圖像空間（（ 0,0） - >（1，1））轉換爲PDF空間以找出「最佳」PDF渲染分辨率。換句話說，如果你有所有這些信息，那就很簡單。獲取這些信息絕對是不平凡的。 – plinth 2011-05-20 20:38:39

這正是我現在運行的問題 - 從現有的PDF中獲取所有信息以獲取旋轉，尺寸等，並能夠創建正確的輸出尺寸以使圖像顯示在其中適當的分辨率和旋轉。很高興我不是唯一一個正在努力解決這些問題的人之一:) – TeckniX 2011-05-20 21:24:29

PDF尺寸對實際內容尺寸

回答

相關問題