[kde-linux] KWrite/printer problem

[John Layt]

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.

> Several observations:
> 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
>  changed. 

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 
seen???

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

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

File a bug, but see 6 below :-)

>  5. Don't bother looking for footers in Konqueror. They don't
>  exist. 

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

> Conclusions:

>  2. The problem rendering the
>  table (point 7 above) suggests that the KDE print engine still needs
>  considerable work. 

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

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

John.