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）的方式上。