[cups] Printed output has umlaut instead of capital P

[Peter Flynn]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/27/2014 08:59 AM, Johannes Meixner wrote:
> In general it is not CUPS itself that converts the original data 
> that your application had submitted as print job to CUPS.

Thank you all very much for your detailed responses.

I am printing it via the commandline and it seems to be fine so far.

> Actually CUPS calls various "external" programs that do the data 
> conversion

Yes, I erroneously called these "drivers".

> I think what first and foremost should be done is to check whether
> or not that "P characters substitution" is already in the original
> data

I mentioned this in the original post: the characters in the PDF are
correct (they display on-screen correctly).

> When you display that original printing data with Ghostscript

I haven't involved GS in the toolchain as I am generating PDF directly
from LaTeX, but...

On 06/27/2014 10:38 AM, Helge Blischke wrote:
[...]
> As the printer in questeion ( an HP K7100), if configured for use 
> with CUPS, uses HP's HPIJS or HPLIP software, and the final
> content type then is application/vnd.cups-raster. That means, the
> filter chain used by CUPS with direct PDF printing is PDF ->
> gstoraster or pdftoraster -> vnd.cps-raster -> foomatic-rip using
> Ghostscript's IJS device

HPIJS.

gstoraster / pdftoraster were what I had in mind when I originally
referred to CUPS's "drivers".

> On the other hand, qpdfview or evince (probably) converts the PDF
> to PostScript, which will bi again converted to PDF by tne pstopdf 
> filter of the cups-filters package.

Aha. I didn't know they were doing this. ps-pdf-ps is not 100%
circular, and is something I would have avoided, had I known.

> From my experience, I have learned not to trust to-ps-conversions
> by PDF viewers etc,

Amen.

> especially as LaTeX generated PDFs tend to use the same font with 
> rapidly changing encoding vectors (in case of Type1 fonts, as 
> indicated by the OP),

I don't think so. The encoding vector is fixed at the time that the
TeX-related files are created for installation (TFM, VF, STY, FD, etc)
so I wouldn't expect them to change at all.

> so that the issue may well be due to conversion errors in the PDF
> viewer.

Almost certainly. The one application I didn't try was Okular (which I
avoid because of its sucky interface and slow rendering). A pity that
Evince (and presumably qpdfview, which is nice because it's fast)
still re-render to PS before submitting.

However, as this is the first time I have hit an error like this in
30+ years of using [La]TeX and printing via special drivers at first,
then PS and now PDF, I'm prepared to suck it up and mark down those
viewers that cause the error.

I generated PS for the (different) publishers for my first book (on
HTML, in 1995), and PDF for the second (on SGML/XML, in 1998), and in
both cases got a note back to the effect that their printer (well,
platemaker) was curious to know what software had been used, because
both of them passed preflight and ripping without dropping a single
bit and with an empty error log :-)

Again, thanks for all your help.

///Peter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQEcBAEBAgAGBQJTsH7EAAoJEHt9ZfbX6inQWzkH/18OmXnAmral+SlcR9qyLsx6
XKKCFmHh8wAWXNip2gs9laYIv2I5EoU/wTgPdG5HubwEdHgAY1PvcuAfvqHFcF6o
yWcYSsLVnduA+O6ghrSBGwtcm1kaoLhn/9xZxDIX52/qqe7yobF2/DAngdXR960Q
xE9n0pKViIlD1GpvKr3Lk5NzE503tiGXzki2WgYfDwCOIJTUumxRTsFpu8gtdYRE
QNI50WHMv5YHpwnihmhENZbwhUDCTnFrZywzdaQf+XgIw2sHgKTTcbQKZ/Cb6KKk
nitW1Fr+PLtmMGe9Md8RjaBcS23W1MHquPqiDPau1VneThXFO/RFmNF4XfTnBgc=
=FnJl
-----END PGP SIGNATURE-----