Bug 150155 - kprinter "Print to file" gives broken PDF or Postscript that won't convert to PDF.
Summary: kprinter "Print to file" gives broken PDF or Postscript that won't convert to...
Status: RESOLVED UNMAINTAINED
Alias: None
Product: kdeprint
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: KDEPrint Devel Mailinglist
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-09-24 17:33 UTC by Nathaniel Taylor
Modified: 2011-05-27 18:36 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nathaniel Taylor 2007-09-24 17:33:16 UTC
Version:            (using KDE KDE 3.5.6)
Installed from:    Compiled From Sources
Compiler:          gcc-4.1.1 
OS:                Linux

When using the "Print to file (PDF)" option on the kprinter dialogue, the output has text that is pixellated and is shifted around the page, mainly to the left margin, so that it is unreadable.  "Print to file (Postscript)" gives readable and printable postscript, but after ps2pdf conversion it has just the same problem as the directly generated PDF.

This happens every time that I've seen, when there's text involved. It happens with konqueror, kmail and kate, i.e. it seems to be kprinter, not just khtml.
Other generators of Postscript or PDF, e.g. seamonkey, acroread, dvips, don't have this problem.

This has been the case for about a year, with KDE-3.5.[4567] compiled on gentoo systems on several computers (P3, P4, Xeon, AMD64).
I have tried creating a new account, to test whether something in my configs is a problem: but the same thing still happens. 
 
Bug 62054 is the nearest I can find under the general KDE bugs, but the problem there was resolved as being in qt, a long time ago: my systems all have a much newer qt, e.g. 3.3.6 & 4.1.4, or 3.3.8 & 4.2.3. 
https://bugzilla.novell.com/show_bug.cgi?id=211235 sounds like this problem, and
they seem also to see it as a qt/kde thing rather than e.g. ghostscript.  But I haven't found a KDE bug report about it (am I in the wrong section?).  Since KDE builds on qt, shouldn't KDE itself report this or work around it, rather than separate distributions doing so?

I've left a simple example of the output at http://www.etk.ee.kth.se/personal/nt/comphelp/kprinter
Comment 1 Kurt Pfeifle 2008-05-01 14:16:08 UTC
Short advice:
-------------

When using kprinter's "Print to PDF file" feature with TrueType fonts, disable the "font embedding" of Qt first. Then the resulting PDF will contain the real TrueType font. Otherwise it will contain a pixelized, crappy looking, non-standard named "Type 3" font that Qt created because it cannot embed real TrueType fonts into its "I-can-only-do-PostScript-Level-1!" printfile.


Long explanation:
-----------------

The problem with printing from Qt-based applications over the last 10 years are
these:

  1) Qt, when generating PostScript for printing, can only support PostScript
Level 1.

  2) Qt can't handle TrueType fonts well when it comes to printing.

Taken together, these two points mean: Qt cannot embed the real, original TrueType fonts into its PostScript Level 1 printfile output; instead, Qt converts TT fonts to a sub-setted (and even crappy-looking at that!) "Type 3" PostScript font, and embeds this replacement font instead.

To add insult to injury, the font names used for its embedded "converted to Type 3 fonts" by Qt do not comply with the font naming standards for subsetted fonts that were laid down by Adobe in the official PostScript specifications. Try to run this command:

     pdffonts a-pdf-file-made-by-kprinter.pdf

and you will obtain something like that:

name                                 type         emb sub uni object ID
------------------------------------ ------------ --- --- --- ---------
[none]                               Type 3       yes yes no       9  0 
[none]                               Type 3       yes yes no      11  0 
[none]                               Type 3       yes yes no      19  0 
[none]                               Type 3       yes yes no      33  0 
[none]                               Type 3       yes yes no      39  0 
Symbol                               Type 1C      yes no  yes     44  0


when you really should be seeing this:

name                                 type         emb sub uni object ID
------------------------------------ ------------ --- --- --- ---------
OMMOFH+Optima                        TrueType     yes yes no     247  0
OMMOAN+Arial,Bold                    TrueType     yes yes no     250  0
OMMOBJ+Arial                         TrueType     yes yes no     253  0
OMMPFE+TimesNewRoman                 TrueType     yes yes no     266  0
OMMPHE+Arial,Italic                  TrueType     yes yes no     269  0
Symbol                               Type 1C      yes no  yes    318  0


This TT font handling "feature" of Qt has many more drawbacks:

1.  PDFs created from PostScript that was output by a typical Qt application don't only look ugly....

2.  ....and therefor do get downrated when it comes to "usability"...

3.  ....but they also are not "searchable"....

4.  ....and they don't let you extract the contained text ("pdftotext"),....

5.  ....they don't work with a screenreader....

6.  ....and hence are a complete failure when it comes to "accessability".


You can have a look at these two PDF files I did <a href="http://bugs.kde.org/show_bug.cgi?id=140546">generate quite some time ago</a> which show all 6 points from above in a comparison. The same OpenDocumentText (.odt) file was used as the base file:

-- to "Export to PDF" from OpenOffice.org: http://bugs.kde.org/attachment.cgi?id=19402&action=view
-- to "Print to PDF file" from KWord: http://bugs.kde.org/attachment.cgi?id=19403&action=view

These problems haven't been fixed (or even touched) by Trolltech for over a decade of Qt1-Qt3(-Qt4) development. At the same time, there have been quite a few bugs about it in Trolltech's internal (and published) bug tracking system. And various Trolltech promises ("will be fixed in next version") made inside their bug tracker have never
happened....

So, Qt sux donkeyballs when it comes to PostScript and TT font handling in PS print files. 

To be sure: the company's reason for that neglect is not evil-mindedness on the part of Trolltech. It seems there was just not much money to be made from "make printing work really well", while at the same time the effort to make that happen is considerable, and people with the appropriate Knowhow are very rare. 

Coding any stuff related to "printing" also isn't as "sexy" as coding for desktop bling-bling (see all these Compiz, Beryl and Plasma efforts) or audio players... so you'll not stand a big chance to have this tackled from the side of the "I'm-just-coding-for-my-personal-fun-or-to-scratch-my-own-itches" FOSS crowd 


"Oh, wait", I hear you saying, "there is Scribus, which is a Qt application, and it produces excellent PostScript or PDF output, and has no such problem with TT fonts."

That's true. But it is only true because the Scribus developers didn't rely on Qt when it came to generate their print files. They did their own thing on that field. They had to. Otherwise, they'd have to suffer from the same problem that
KDEPrint (up to KDE 3.5.9) did and still does....


"So isn't there a workaround when you want to generate PDFs via KDEPrint's 'Print to PDF' feature?", you ask.

Yes, there is:

----------------------------------------------------------------------------------------
  ==> Disable "Font embedding" when KDEPrint-ing documents that contain TrueType fonts.
----------------------------------------------------------------------------------------

You can avoid Qt's font embedding by 

 * running "kaddprinterwizard --kdeconfig", 
 * select "TT fonts", 
 * disable "Embed fonts with PostScript data when printing".

The net effect of that is that the original TrueType font used by the document will be referenced only by name in the resulting PostScript file. If the next step in print processing then is running Ghostscript on that PostScript file (in the case of kprinter's "Print to PDF" that *IS* the case), Ghostscript will try to use the real TT font and embed that into the file (and that way avoid an already embedded, crappy looking, badly usable, non-accessible, not-able-to-read-aloud-by-KSST, un-searchable Type 3 font as is generated by Qt).


What about the future? 

Qt4 introduces "export to PDF" and therefor seems to be much better for print fidelity and quality. However, the Qt-app needs to take advantage of that...

Whenever there is a Qt/KDE app that still outputs PostScript, you're still treated with Level 1 PostScript and with the dreaded "I-converted-your-nice-TrueType-fonts-into-my-crappy-quality,-ugly-looking,-pixelized-Type-3-fonts" feature.
Comment 2 John Layt 2011-05-27 18:36:07 UTC
KDEPrint is obsolete, unmaintained and will never be revived.  Closing all open bugs.