Index of /~nt/computer/kprinter
Name Last modified Size Description
![[DIR]](/icons/back.gif)
Parent Directory -
![[ ]](/icons/layout.gif)
problem.pdf 24-Sep-2007 17:27 5.8K
![[ ]](/icons/a.gif)
problem.ps 24-Sep-2007 17:26 37K
![[TXT]](/icons/text.gif)
problem.txt 24-Sep-2007 17:29 203
KDE bug 150155: kprinter "Print to file" gives broken PDF or Postscript that
won't convert to PDF.
This bug was submitted in September 2007, about a bug that has caused a
lot of annoyance. The other files in this directory are some examples
of the bug. The report is below: the reply (Kurt Pfeifle) is informative
and helpful, although the problem can't be fixed by KDE except by the
KDE4 move to a newer Qt. See http://bugs.kde.org/show_bug.cgi?id=150155
for the rest.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
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/computer/kprinter
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Comment #1 Kurt Pfeifle 2008-05-01 14:16:08
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 generate quite some time
ago 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 KDEPrinting 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.