Re: [kde-linux] KWrite/printer problem
- From: John Layt <johnlayt@xxxxxxxxxxxxxx>
- Date: Thu, 8 Oct 2009 21:00:31 +0100
Comments/responses in-line. Thanks for going to the effort.
On Thursday 08 October 2009 06:44:14 Bruce Miller wrote:
Late this evening, I checked the default printer settings under Kubuntu's
"System Settings." This is Kubuntu's substitute for the KDE Control
Centre. The default printer margins were set to the traditional maximum
imageable area for HP LaserJets (at least for the older ones; I am less
familiar with the most modern ones). This is 0.5" (12.7mm) top and bottom
and 0.25" (6.4mm) left and right. I altered these to slightly larger
margins all round.
This is the printer configuration tool and it directly adjusts the CUPS
default settings for the printer. None of these settings are KDE or Qt
settings per se.
1. the Printer Properties dialogue in the KDE print engine (at least when
Konqueror called it) did not respect the default margins which I had just
It is the Qt printer engine which we use, and the Qt dialog that you see, and
if it did not pick up the CUPS margins then that is a bug that I'll look into,
but Qt's handling of the CUPS settings is rather poor and inconsistent.
Qt4 also made major changes to how margins and page and paper sizes were
handled so older apps print rendering code may not handle them properly. From
all these posts, I suspect there's something wrong in Qt's non-metric stuff
that Qt being from the metric world has missed that it is messing up.
The unfortunate thing is we are thus hostage to the Qt release cycle and their
willingness to fix bugs and add features. At least they are now opening up
the development process and we are working on patches to try improve things.
2. the units of measure for the margins default to metric, rather
than to the user's system default.
Ah, that's definitely a Qt bug, the Qt dialog obviously cannot check the KDE
locale, but should be using the system one. I'll have a look into that and
file a bug. I wonder if that has something to do with the errors being
3. printing with the current KDE printer engine is still an all-or-nothing
proposition. There is no way to define a print range. This would be a real
bore if one wanted to print, say, only one page out of a 100-page
Nope, that's just a kate and khtml problem. They don't know about pages, and
don't want the hard task of pre-calculating page breaks, so just print
everything. The problem is that these are core components re-used by many
other programs, e.g. kwrite and kmail.
Under KDE3 the print engine allowed them to use CUPS to do the page selection,
but Qt doesn't currently support this. The good news is I a have a hack that
will restore this in KDE 4.4, and then in Qt 4.7 there will be proper support
for all types of page ranges (it missed the 4.6 freeze). Before KDE4.4 you
can just select the text you do want in kate/kwrite and print just that.
Other KDE apps such as Okular are quite happy to print simple page ranges.
4. There is no way to customize a Konqueror print header. It is
File a bug, but see 6 below :-)
5. Don't bother looking for footers in Konqueror. They don't
File a bug, but see 6 below :-)
6. My two texts, one quite long, printed without error. Konqueror
always broke the page at the end of a paragraph. I checked all 15 pages of
output carefully: there was no missing text. 7. However, a long table
caused a train wreck. In the document
http://en.wikipedia.org/w/index.php?title=RAID&printable=yes there is a
long table which begins on page 3. This table did not print on page 3; it
was superimposed (subimposed?) on page 4. This was not a paper jam, it was
a rendering engine failure.
Yep, khtml appears to have serious problems with printing at the moment, I've
seen lots of bugs logged. However the khtml/konqi guys are very short-handed
and it's hard enough for them just to keep up with the onscreen rendering and
js and every other feature people want, print rendering is a very low priority
2. The problem rendering the
table (point 7 above) suggests that the KDE print engine still needs
Nope, just that khtml needs a lot of work on rendering stuff.
3. The lack of a function for printing only a part of,
rather than an entire, document is an important hole in KDE's overall
Qt's hole actually, as mentioned above, but we're the most visible victim of
it, and we are working on it.
4. It is my personal judgement --- others will obviously
have different perspectives --- that the persistent problems with printing
in KDE4 are the most important outstanding regression in end-user
usefulness from KDE3.5 to KDE4. kprinter used to be a gem of KDE. I have
read that it was becoming beastly to maintain, but it remains a shame to
have lost it. I need to put on an asbestos suit to say this, but in my
view, the best currently available printer control software that I know of
is FinePrint and it is (gasp!) commercial software for Windows.
Not just beastly to maintain but undocumented, and no-one to maintain it or
port it, it wasn't even compiling under 4.0 let alone actually printing.
Using Qt was the only way would could ship with the ability to print and they
made us promises that they didn't keep about adding the missing features.
I miss kprinter as well, it's why I switched, hopefully when either Qt 4.7 or
OpenPrinting comes out we'll have the basis to be able to restore it.
Of course, if anyone is willing to pay for me to assemble a crack team of
coders-for-fortune we might be able to produce something to give FinePrint a
run for its money... :-P
This message is from the kde-linux mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde-linux.
More info: http://www.kde.org/faq.html.