Re: ps-print question

[Peter Dyballa]

Am 03.01.2011 um 03:19 schrieb David Penton:

> The content of the pdf file is not directly relevant to the problem,  
> nor is ps2pdfwr. The problem arises before conversion to pdf.

You don't seem to print (send to the printer, queue into the printer  
queue) the PS file, so the PDF file *is* the problem. And there, by  
means of a Character Mapping table (the CMap table) the ` (GRAVE  
ACCENT, U+0060) becomes ‘ (LEFT SINGLE QUOTATION MARK, U+2018).

> In my earlier posts I pointed out that the backquote IS preserved in  
> the simple little postscript example that I supplied.

Why is not possible to print the PS file directly?

> It is preserved in interactive ghostscript, and also by my modified  
> ps2pdfwr script so that the backquote appears properly in the  
> resulting pdf file.

Please, tell me which Ghostscript version you are using and what the  
command line is! I'd like to see this result myself. With the output  
of ps-print, if you refer to this. If you mean your own PS test file,  
then I understand that omitting -dSAFER allows gs some reasonable doing.

> However, postscript generated by ps-print does NOT preserve the  
> backquote - even when viewed interactively in ghostscript, without  
> converting to pdf.

I see! Before I just looked into the PS file... (it's OK) It's a bug  
on the presentation level. Certainly! The font encoding used in the PS  
file, /ISOLatin1Encoding, does not change the ` to ‘ – and I think  
it's even not applied because the /FontType of BitstreamVeraSansMono  
(I just noticed the "Roman" in its PostScript font name!) is 0 (and  
PostScript font is only then re-encoded when it does not know about  
the /ISOLatin1Encoding). And so its Unicode font encoding is used  
straight away – which might cause the application of some default  
features of the font, one of them being the change from ASCII quotes  
to "typographic" quotes. You can check this behaviour in OpenOffice or  
TextEdit. There must be some way of turning these default features  
off! I am thinking of reporting a bug... Or at least a request for  
enhancement!

Your first report was with the "standard" Ghostscript fonts in use,  
i.e. with substituting the real fonts, Courier, with clones from urw+ 
+, NimbusMonL. These are PostScript Type 1 fonts, they have kind of a  
backquote, which could be clearer. When I produce with a ps-print  
output from the ascii(7) man page it uses the Courier font name but  
looks up NimbusMonL. Pdffonts tells Courier is used in the PDF file –  
which shows ‘ instead of `. When gs or gv are displaying the PDF file  
I can't see an open font file with lsof, will try later–European  
evening, five or six hours from now–with some DTrace to determine  
which font file get used. If at all! Libfontconfig might supply them.  
And then they'll be TrueType or OpenType.

I'm thinking of one more experiment: embedding the PostScript fonts,  
Courier and LuxiMono.

> So something about the way ps-print generates postscript is  
> interfering with the use of the added fonts, perhaps.

No! This is *not* happening. Although I can understand the cause of  
this: your short test file shows `, the other file from ps-print  
not... But see above!

> Thus inspecting the resulting PDF is unlikely to tell us anything  
> interesting. It would be far easier to just inspect the original  
> postscript generated by ps-print.


As far as I can understand the PS code it's OK. Inside it no  
conversion of ` to ‘ happens. But then I wonder why when I use the  
PostScript Type 1 LuxiMono fonts from X11, which do not have a TT or  
OT "counterpart", the same conversion happens! It's a deep mystery,  
making life worth living, presumingly.

The Mac OS X software uses this to convert between formats:

	/System/Library/Printers/Libraries/convert -f Vera.ps -o Vera.pdf -i  
application/postscript -j application/pdf -P « path your printer's PPD  
file, for example /etc/cups/ppd/EPSON_EPL_5800.ppd or where ever the  
Installer installs the printer driver package; /etc/cups/ppd is the  
place where the PrintUtility copies and customises it »

--
Greetings

  Pete
Progress (n.): Process through which USENET evolved from smart people  
in front of dumb terminals to dumb people in front of smart terminals.