From kde-core-devel Fri Sep 14 20:38:36 2007 From: Kurt Pfeifle Date: Fri, 14 Sep 2007 20:38:36 +0000 To: kde-core-devel Subject: Consider me sceptical if we rely on Trolltech's qprinter only, and Message-Id: <46EAF14C.1080003 () gmx ! net> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=118980251001860 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