linux下的Ghostscript：時間太寬

Question

如何讓Times在linux下打印？ 我有debian wheezy linux，ghostscript，cups，mscorefonts的安裝。 但是，當我打印時，我得到時間太寬，比較窗口一個字母間距太寬。

任何方法來解決這個問題？

從相同的Java小程序和Win和Lin打印完成。 Lin變體使用Times字體的Postscript，Win變體的postscript使用TimesNewRomanPSMT字體。 只是替換字體名稱會改變它，但不會改變輸出中的任何內容。

=================

Debian的喘息，Debian的擠壓，Ubuntu的納蒂檢查爲Linux操作系統。 大部分支票都在Debian Wheezy中。

的ghostscript： 安裝：9.02〜DFSG-2 太陽的Java6的JRE： 安裝：6.26-1 杯-PDF打印機。

PPD是PDF.ppd：

*PCFileName: "CUPS-PDF.PPD" 
*Manufacturer: "Generic" 
*Product: "(CUPS v1.1)" 
*ModelName:  "Generic CUPS-PDF Printer" 
*ShortNickName: "Generic CUPS-PDF Printer" 
*NickName:  "Generic CUPS-PDF Printer" 
*1284DeviceID: "MFG:Generic;MDL:CUPS-PDF Printer;DES:Generic CUPS-PDF Printer;CLS:PRINTER;CMD:POSTSCRIPT;" 

打印結果Comparsion：http://piccy.info/code2/1652248/4b2c3b10f5316f9836496af5501892d1/

我有Linux系統上Times New Roman字體！用於windows的PDF是在linux上用linux機器上生成的postscript源碼生成的ghostscript生成的。

例如，看看右上角，其中寫0401060。 的Windows PostScript代碼：

%%IncludeResource: font TimesNewRomanPS-BoldMT 
F /F1 0 /256 T /TimesNewRomanPS-BoldMT mF 
/F1S53 F1 [83 0 0 -83 0 0 ] mFS 
F1S53 Ji 
4292 333 M (0401060)[42 42 42 42 42 42 0]xS 
N 367 367 M 1192 367 I K 
N 1667 367 M 2492 367 I K 
51282 VM? 

Linux的PostScript代碼：

10.0 29 F 
<303430313036> 37.44 526.0 52.0 S 
10.0 29 F 
<30> 6.24 541.0 62.0 S 
N 

，你可以看到，它選擇尺寸10.0字體＃29。字體＃29是 /時間加粗ISOF

和，最壞的事情，它已經寫了兩行 - 所以問題是在java < =>杯連接器的某處。

================== 「Same Java Applet」是Internet銀行應用程序iBank2。

「泰晤士報」是由Ghostscript的代入雨雲，不TimesNewRoman：

./Init/Fontmap.GS:/Times-Roman   /NimbusRomNo9L-Regu ; 
./Init/Fontmap.GS:/Times-Italic   /NimbusRomNo9L-ReguItal ; 
./Init/Fontmap.GS:/Times-Bold   /NimbusRomNo9L-Medi ; 
./Init/Fontmap.GS:/Times-BoldItalic  /NimbusRomNo9L-MediItal ; 
./Init/Fontmap.GS:/TimesNewRoman    /TimesNewRomanPSMT  ; 
./Init/Fontmap.GS:/TimesNewRoman,Bold   /TimesNewRomanPS-BoldMT  ; 
./Init/Fontmap.GS:/TimesNewRoman,Italic   /TimesNewRomanPS-ItalicMT ; 
./Init/Fontmap.GS:/TimesNewRoman,BoldItalic  /TimesNewRomanPS-BoldItalicMT ; 

（順便說一句，你在Windows上使用的Ghostscript所有，或爲您的打印有通過本機的打印機驅動程序會？） 在Windows上，我將PostScript本機驅動程序打印到.ps文件。

所以它本身不是Ghostscript問題......但它可能來源於Win/Lin系統上不同的Java版本+配置。 它看起來像在打印java的問題，但這並不取決於java版本 - 都安裝了最新的java6。

PostScript很可能是由您的Java小程序生成的，而Ghostscript在完成打印過程時只是它的消費者。 通常情況下，我只是想確保它使用TimesNewRoman字體作爲Times one，而不是Nimbus。 而我沒有做到這一點。

通過印刷產生

ISOF宏：

/ISOF { 
    dup findfont dup length 1 add dict begin { 
      1 index /FID eq {pop pop} {D} ifelse 
    } forall /Encoding ISOLatin1Encoding D 
    currentdict end definefont 
} BD 

這裏被切斷的啓動文件，並生成產生的PDF：http://datacompboy.ru/u/smpl.tar.bz2

如果是這樣，那麼在Windows拷貝fontfile到Linux操作系統。

它已經是windows文件的副本。 msttcorefonts與使用windows分發的一樣。

因爲在生成postscript文件已經0401060拆分爲兩行，這意味着，該Java小程序正在打印時發現，字體太寬，並在生成時分裂...所以問題是 - 如何在系統中替換Times字體那麼，java打印會找到TimesNewRoman而不是Nimbus，並生成正確的輸出？

Answer 1

從我在截圖中看到，您贏< - >林印刷差異...

• ...做不起源於時報< - > TimesNewRomanPSMT差異，
• ...而是來自[SomeTimes] < - > [SomeTimesBold] 2個PostScript輸出的差異（s）

由每個打印機隊列（在Linux上很可能涉及到Ghostscript安裝）使用。 （順便說一句，你是在Windows上使用的Ghostscript所有，或爲您的打印有通過本機的打印機驅動程序去？）

所以這是不是一個Ghostscript的問題本身...但它也許來自不同的Java始發版本+ Win/Lin系統上的配置。

您的Linux PostScript代碼似乎使用了/Times-Bold (ISOF????)字體的事實不在Ghostscript的責任範圍之內。 PostScript很可能是由Java applet生成的，而Ghostscript在完成打印過程時只是它的消費者。

在我看來，您提到的這個不祥的ISOF不是字體名的一部分，而是PostScript過程，必須在PostScript文件中的其他位置預先定義並應用於/Times-Bold字體。這可能是其中一個程序重新編碼原始字體ISOLatin1Encoding ...

你說你有訪問這兩個字體文件（TimesNewRomanPS-BoldMT在Windows和Linux上時報大膽）。如果是這樣，那麼將Windows字體文件複製到Linux。然後，以驗證兩種字體之間的視覺差異，在每個fontfiles的運行這兩個命令：

fntsample \ 
    -f /path/to/Times-fontfile.suffix \ 
    -o Times-fontfile.suffix.pdf \ 
    -l \ 
    > Times-fontfile.suffix.txt 

然後

pdfoutline \ 
    Times-fontfile.suffix.pdf \ 
    Times-fontfile.suffix.txt \ 
    Times-fontfile-sample.pdf 

所得PDF（S），時間 - fontfile樣本.pdf，將表示包含在字體文件中的每個字形的表格樣本，並且這些將被映射到相應的Unicode碼點部分。

您可以使用這些PDF來揭示兩種字體之間最小的視覺差異（但我敢打賭，您的差異將會相當明顯）。

如果你沒有在您的Debian安裝pdfoutline和fntsample，只需運行sudo apt-get install fntsample ...

---

更新2（考慮到更新的問題說明）：

datacompboy現已提供包含以下4個文件的壓縮包：

-rw-r--r-- datacompboy/datacompboy 37722 2011-06-22 08:54 smpl/linout.ps 
-rw-r--r-- datacompboy/datacompboy 15324 2011-06-22 08:54 smpl/linout.pdf 
-rw-r--r-- datacompboy/datacompboy 54422 2011-06-22 08:57 smpl/winout.pdf 
-rw-r--r-- datacompboy/datacompboy 99099 2011-06-22 08:56 smpl/winout.ps 

有了這些文件，應該很容易找出問題的原因。如果datacompboy可以運行在Linux的Ghostscript的Windows生成PS文件，像這樣：

gs winout.ps 

，如果它呈現OK（即：同winout.pdf），再有就是與GS字體沒問題映射，但與winout/linout.ps中的實際文件差異存在問題。從那裏開始，應該很容易繼續分析。

不幸的是，現在我無法自己運行測試。

---

更新3：

datacompboy的PDF文件linout.pdf和winout.pdf有一個巨大的差別：Linux的版本沒有嵌入字體，而Windows一個有...的後果是，任何linout.pdf後消費者在顯示，打印，轉換或處理該文件時都會產生相當隨意的結果。

所以這裏是另一個我能想到的測試。它會檢查用於/Times-Bold（由Ghostscript替換爲實際/NimbusRomNo9L-Medi）和/ TimesNewRomanPS-BoldMT的字體的Linux版本的字體度量是否有所不同。

這些Ghostscript的COMMANDLINES創建三個不同的PDF文件：

a.pdf：

gs \ 
-o a.pdf \ 
-sDEVICE=pdfwrite \ 
-dPDFSETTINGS=/prepress \ 
-c "100 700 moveto \ 
    /TimesNewRoman,Bold findfont \ 
    12 scalefont \ 
    setfont \ 
    (0401060 0401060 0401060 0401060) show \ 
    showpage" 

b.pdf：

gs \ 
-o b.pdf \ 
-sDEVICE=pdfwrite \ 
-dPDFSETTINGS=/prepress \ 
-c "100 700 moveto \ 
    /TimesNewRomanPS-BoldMT findfont \ 
    12 scalefont \ 
    setfont \ 
    (0401060 0401060 0401060 0401060) show \ 
    showpage" 

℃。PDF：

gs \ 
-o c.pdf \ 
-sDEVICE=pdfwrite \ 
-dPDFSETTINGS=/prepress \ 
-c "100 700 moveto \ 
    /Times-Bold findfont \ 
    12 scalefont \ 
    setfont \ 
    (0401060 0401060 0401060 0401060) show \ 
    showpage" 

的-dPDFSETTINGS=/prepress參數應該執行字體嵌入到輸出的PDF。 （這很重要，否則觀衆可以使用任意替換字體來顯示PDF。）

-c後面的參數是一個爲PDF頁面提供內容的小PostScript片段。

文件'a.pdf'和'b.pdf'不應該不同。他們僅測試/TimesNewRoman,Bold和/TimesNewRomanPS-BoldMT之間的字體混疊是否確實按預期工作。

文件「C.PDF」可以顯示比較a.pdf和b.pdf在這裏和那裏的幾個像素的順序略有差別，但不在跟蹤測試字符串的。

如果此測試按預期進行，則不同的FontFiles，Fontmap.GS和Ghostscript本身都可以。然後，問題只出現在Linux Java applet生成其輸出（PS或PDF）的方式上。