Ghostscript under linux: Times too wide

Question

How to make Times working for printing under linux? I have debian wheezy linux, ghostscript, cups, mscorefonts installed. But when i do print, i get Times too wide, comparing to windows one -- letter spacing are too wide.

Any way to fix that problem?

Printing done from same Java applet and on Win and on Lin. Postscript from Lin variant use Times fonts, postscript from Win variant uses TimesNewRomanPSMT font. Just replacement font name changes it, but not changes anything in output.

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

Debian Wheezy, Debian Squeeze, Ubuntu Natty checked as linux. Most of checks was in Debian Wheezy.

ghostscript: Installed: 9.02~dfsg-2 sun-java6-jre: Installed: 6.26-1 cups-pdf printer.

PPD is 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;"

Print result Comparsion: http://piccy.info/code2/1652248/4b2c3b10f5316f9836496af5501892d1/

I DO have Times New Roman font on linux system! PDF for windows was generated on linux with linux ghostscript from postscript source generated on windows machine.

For example, take a look into right upper corner, where 0401060 written. Windows postscript code:

%%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 code:

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

as you can see, it selects font #29 of size 10.0. Font #29 is /Times-Bold ISOF

and, worst thing, it already writes two lines -- so problem are somewhere in java<=>cups connector.

================== "Same Java Applet" is internet-bank application iBank2.

"Times" is substituted by Ghostscript to Nimbus, not to 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   ;

(BTW, are you using Ghostscript on Windows at all, or is your printing there going through a native printer driver?) On windows i'm print onto PostScript native driver to .ps file.

So it is NOT a Ghostscript problem per se... but it maybe originating from different Java versions + configurations on your Win/Lin systems. It looks like problem in java on printing, but that doesn't depends on java version -- both have latest java6 installed.

That PostScript most likely generated by your Java applet, and Ghostscript is only the consumer of it when it goes through the printing process. Normally, i just want to make sure it uses TimesNewRoman font for Times one, not Nimbus. And i have failed to make this.

ISOF macro generated by printing is:

/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

Here is cut of start files, and generated resulting PDF: http://datacompboy.ru/u/smpl.tar.bz2

If this is so, then copy the Windows fontfile to Linux.

it are already copy of windows file. msttcorefonts are identical to one, distributed with windows.

Since in generated postscript file already 0401060 split to two lines, that means, that java applet are while printing found that font too wide, and split upon generating... So question is -- how to substitute Times font in system so, that java printing will find TimesNewRoman instead of Nimbus, and generate correct output?

Answer 1

From what I see in the screenshot, your Win <--> Lin printing differences...

• ...do NOT originate in Times <--> TimesNewRomanPSMT differences,
• ...but rather come from [SomeTimes] <--> [SomeTimesBold] differences in the 2 PostScript output(s)

that is consumed by each printer queue (which on Linux very likely involves a Ghostscript installation). (BTW, are you using Ghostscript on Windows at all, or is your printing there going through a native printer driver?)

So it is NOT a Ghostscript problem per se... but it maybe originating from different Java versions + configurations on your Win/Lin systems.

The fact that your Linux PostScript code seems to make use of the /Times-Bold (ISOF????) font is outside of Ghostscript's responsibility. That PostScript most likely generated by your Java applet, and Ghostscript is only the consumer of it when it goes through the printing process.

It looks to me that this ominous ISOF you mentioned is not part of the fontname, but a PostScript procedure that must be pre-defined elsewhere in the PostScript file and is applied to the /Times-Bold font. It is probably a procedure which re-encodes the original font to ISOLatin1Encoding...

You say you have access to both font files (TimesNewRomanPS-BoldMT on Windows and Times-Bold on Linux). If this is so, then copy the Windows fontfile to Linux. Then, to verify the visual differences between the two fonts, run these two commands on each of the fontfiles:

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

and then

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

The resulting PDF(s), Times-fontfile-sample.pdf, will represent a tabular sample of each glyph contained in the fontfiles, and these will be mapped to the respective Unicode codepoints sections.

You can use these PDFs to reveal even minimal visual discrepancies between the two fonts (but I bet your differences will be rather glaring).

In case you don't have installed pdfoutline and fntsample in your Debian, just run sudo apt-get install fntsample...

---

Update 2 (taking into account the updated problem description):

datacompboy has now provided a tarball containing these 4 files:

-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

With these files, it should be very easy to pinpoint the cause of the problem. If datacompboy can run the Windows-generated PS file on a Linux Ghostscript, like this:

gs winout.ps

and if it renders OK (i.e.: the same as winout.pdf), then there is no problem with the GS font mapping, but a problem with the actual file differences in winout/linout.ps. From there, it should be quite easy to continue the analysis.

Unfortunately, right now I cannot run the test myself.

---

Update 3:

datacompboy's PDF files linout.pdf and winout.pdf have one huge difference: the Linux version doesn't have the font embedded, while the Windows one has... The consequence is that any posterior consumer of linout.pdf will produce fairly arbitrary results when displaying, printing, converting or processing this file with regard to the font.

So here is another test that I can think of. It checks how much the Linux versions of the fonts used for /Times-Bold (which is substituted by Ghostscript with the real /NimbusRomNo9L-Medi) and /TimesNewRomanPS-BoldMT` do differ in their font metrics.

Create three different PDFs with these Ghostscript commandlines:

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"

c.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"

The -dPDFSETTINGS=/prepress parameter should enforce the font embedding into output PDFs. (This is important, otherwise the viewer could use an arbitrary replacement font for displaying the PDF.)

What follows the -c parameter is a little PostScript snippet that provides content for the PDF page.

Files 'a.pdf' and 'b.pdf' should not differ. They only test if the font aliasing between /TimesNewRoman,Bold and /TimesNewRomanPS-BoldMT do indeed work as expectd.

File 'c.pdf' could show slight differences in comparison to a.pdf and b.pdf in the order of a few pixel here and there, but NOT in the tracking of the tested string.

If this test goes as predicted, the different fontfiles, the Fontmap.GS and Ghostscript itself all are OK. Then the problem is only with the way the Linux Java applet produces its output (PS or PDF).