Consider me sceptical if we rely on Trolltech's qprinter only, and if we do that long-term (was: "KDE4 printing: results of IRC meeting")

[Kurt Pfeifle]

Thomas Zander wrote:

> The long term solution IMO is that applications use the KDE kcm for printer 
> configuration and job-queue tracking, but use a pure Qt solution for the 
> actual printing.

Color me extremely sceptical about the long term prospects for this
(i.e. relying, permanently on a pure Qt solution for printing).

I very strongly try to convince myself that it is the only realistic
path to go right now, given the manpower, though

But how long will TT devote resources into this? They may leave it
bit-rotting as soon as it "somehow" works. As they did with the rest
of the "print stuff" support in their toolkit since KDE 1.0 was relea-
sed...

Developing for printing simply isn't sexy at all (and seems to be not
very profitably either, otherwise TT would have had some other incen-
tive). You can see that in the fact that all existing and prior print
subsystems (LPR/LPD, LPRng, CUPS) basically were/are one-man shows.
They never attract lots of developers, and one must be thankful there
is some working printing support at all.

You can even see it in KDEPrint3 ("one man show" characterization [*])
Or did it ever attract any developer to put his effort in?  No, we in-
stead have dozens of media players, file managers, chat applications
and editors...

Anyway, going from experience, where we relied on TT's efforts for
print support in the past we were completely left in the rain, despite
numerous bug reports. To name the major 3 issues (and there severity
was constantly painted over by KDEPrint's other shining features, but
nevertheless they were there all the time and did bite a lot of users):

 --> only PostScript level 1 support... since KDE 1.0
     -----------------------------------------------------------------

     Applications that wanted to have at least decent, if not excellent
     printing support, had to do their own stuff (Scribus). Applications
     that hoped for Qt to improve on this front, had a stream of bug
     reports that can be tracked back to this (KWord, all image appli-
     cations which get those reports complaining about slow printing
     that produces huge printfiles...)


 --> a really crappy way of font handling for TrueType fonts.... since
     KDE 1.0;
     -----------------------------------------------------------------

     Qt converts TrueType fonts into not even well-made "Type 3" fonts,
     which then are not even searchable if the PS should ever be conver-
     ted to PDF -- something our KDE users did often do, thanks to that
     Virtual PDF Printer. And it isn't "accessible", because it can't be
     read by KTTS either..

     Qt applications that wanted decent font handling invented their own
     stuff (Scribus) -- the ones that relied on Qt suffered (KWord), some-
     times even to the degree of making their developers deny that there
     is a problem at all...

     (See for examples: http://bugs.kde.org/show_bug.cgi?id=141572
                        http://bugs.kde.org/show_bug.cgi?id=140251#c1 )

 --> complete non-support for "custom" page sizes... since KDE 1.0.
     -----------------------------------------------------------------

     Qt applications that wanted custom page size handling invented their
     own stuff (Scribus) -- the ones that relied on Qt suffered (KWord,
     which even offers the custom page size in its UI, but can't deliver
     it when printing, because Qt simply can't create PS output with cu-
     stom page sizes....)

     Trolltech has this in their bug tracker since many years, and
     always promised a fix for the next release. So far, it didn't
     happen.

     (See for example: http://bugs.kde.org/show_bug.cgi?id=54410#c2 )


This is not a Trolltech bashing; Trolltech may have their completely
valid economic reasons to not have found the fixing for these deficien-
cies attractive enough.

Instead, this is merely a warning to not rely on a permanent mainte-
nance and developer love provided by Trolltech for whatever printing
support they create for Qt 4.4. Because the same reasons may again
apply to neglect printing once more. And it's not like programming
for printing suddenly became sexy, and like CUPS development suddenly
became a gang effort either.

In the past 10 years, whoever wanted to go beyond a very, very, very
basic, and in many respects, very inferior printing support, had to
do it on their own. It didn't help to wait for improvements from TT
for the next, or the next after, release of Qt.

Unless someone from the KDE ranks steps up to look after printing
long-term, we may quickly be in a similar position very soon again.

But *IF* a person steps up, he/she'll be a hero for a long time to
come.

----------

 [*] this term is not at all meant to belittle the work of our Michael
     Goffioul -- on the contrary: he created a giant thing with his
     one man effort [I should have used that term instead], that mira-
     culously lasted, without much active maintenance, from KDE 2.2.0
     to KDE 3.5.7 -- for more than 6 years !
     (http://www.kde.org/announcements/announce-2.2.php)


-- 
Kurt Pfeifle
System & Network Printing Consultant ---- Linux/Unix/Windows/Samba/CUPS
Infotec Deutschland GmbH  .....................  Hedelfinger Strasse 58
A RICOH Company  ...........................  D-70327 Stuttgart/Germany