[cups] Printed output has umlaut instead of capital P

Johannes Meixner jsmeix at suse.de
Mon Jun 30 01:38:53 PDT 2014


Hello,

only for clarification:

On Jun 29 22:01 Peter Flynn wrote (excerpt):
> On 06/27/2014 08:59 AM, Johannes Meixner wrote:
>
>> 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).

My wording "original data" was not clear enough.
I did not mean the original PDF that was produced by LaTeX tools.
I meant the print job data that was submitted to CUPS.

In your case you would have seen that when you print your
original PDF via evince then the PDF print job data that was
submitted by evince to CUPS is different than your original PDF.


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

When you like to check how the content in a PDF would look like
when printing, I recommend to use Ghostscript to display the
content on-screen because when printing it is usually Ghostscript
that is used to interpret the PDF or PostScript print job data.
This means:
When you use Ghostscript to render the print job content on-screen
you use the same tool that is also used for printing that content.
Therefore:
http://en.opensuse.org/SDB:How_to_Report_a_Printing_Issue
------------------------------------------------------------------
If printing from an application program fails, the first test is
to check if what the application had submitted as printing data
to CUPS seems to be correct.
...
   gs -r50 /tmp/print-job-data.save
...
Possible errors are shown at the command line where you typed
the "gs" command. In case of errors, the application had submitted
invalid PostScript or PDF to CUPS.
...
The graphical content that is shown by Ghostscript is what the
application had submitted and what your printer should print. 
------------------------------------------------------------------

Bottom line:
For a "personal preflight" I recommend to also use Ghostscript
(regardless that Ghostscript is no real preflight tool).


> 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 :-)

I think it will again take a longer time until PDF as the standard
print job format works as reliable and stable as PostScript does.
I think the main advantage of PDF over PostScript is that users know PDF
as a standard format when sending documents to arbitrary recipients.
With PDF as print job format users can treat a printer as one of
those arbitrary recipients - regardless that application programs
must support the difference between printing and viewing, cf.
http://en.opensuse.org/SDB:Landscape_Printing#Again_there_is_a_subtle_distinction


Kind Regards
Johannes Meixner
-- 
SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany
HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer



More information about the cups mailing list