libkdeprint

[Kurt Pfeifle]

Thomas Zander wrote:
> On Tuesday 16 October 2007 11:08:43 Pino Toscano wrote:
>> Alle martedì 16 ottobre 2007, Thomas Zander ha scritto:
>>> On Tuesday 16 October 2007 01:53:55 Pino Toscano wrote:
>>>>> Commnents/yes/no?
>>>> From okular's point of view, no.
>>> Simply objecting without giving alternate solutions doesn't help the open
>>> discussion. What do you have in mind as an alternate solution?
>> Fixing kdelibs?
>> (That, from my point of view, is more or less working, as I can print
>> preview and print to file, at least.)
> 
> Unfortunately the requirements have risen a bit over the years; 

No, Thomas, that's not exactly true.

Requirements are projected to rise a bit over the *coming* years.
But we are still very far from it.

> shuffling 
> postscript files around like kdeprint does is no longer enough.

No, Thomas, it *IS*.

There is currently *NO* program that is shovelling other files than
PostScript files towards KDEPrint.

What possibly *WILL* happen is that some programs will start to be
able to output PDF for printing and hand PDF to the printing system.

However, any sane program and its non-naive programmer will keep a
degree of backward compatibility over quite a few years and make sure
that they will be able to send PostScript to the printing system.
If they don't, they'll be screwed in a lot of use cases. Because
there simply *ISN'T* yet any printing system around that is expec-
ting PDF by default, or as the exclusive input.

It is also not in any way, shape or form apparent to me how it would
have been a very complicated thing to extend KDEPrint and kprinter
to handle PDF submissions by applications side by side with Post-
Script submissions. (The only problem seems to be that of the 3 or
5 people who took a closer look at the existing KDEPrint code said
"we don't understand it, and it will take us too long to do so"...
fair enough. That's the *only* valid argument I've heared and that
has to be respected. "He who does the work, decides."

> As I 
> explained a couple of times before.

And as you everytime exaggerated in the same way, since it serves
your desire/goal/plan to make everything "PDF-only". And as has been
met with counter-arguments and hints that do trim down your PDF-
favoring and PDF-biased assumptions to a realistic level.

> So while it may be enough for you, it will not be enough for the majority of 
> our users/apps.

The problem with PostScript-based printing in current KDE3 is not
that it is PostScript based. The problem is that the PostScript it
has to handle is low quality.

The problem is that KDEPrint ever only receives rather crappy Post-
Script Level 1 input (and it can't be fixed at that level), because
PS Level 1 is all that Qt3 offers out of the box. And along that goes
the *completely crappy* handling of TrueType fonts: for embedding, it
converts them into ugly-looking "Type 3" PostScript fonts  (and a
Type 3 quality that is worse than it could be!), which will make sure
to result in 'unsearchable' (and un-KTTS-able, un-Accessibility-able)
PDF files if converted to PDF (as, for example, with kprinter's "Print
to File (PDF)" virtual printer).

The problem is the numerous bug reports addressing these two problems
(Qt3's PS Level 1 and TT font handling) which remained untackled or
even ignored over nearly a decade.

The problem is that Trolltech never showed any willingness or sign
to upgrade their printing output to PS Level 2 or 3 (which can embedd
the original TrueType fonts easily -- impossible in Level 1?), and/or
fix their TrueType conversion code. (I'm sure you'll be able to find
lots of references in KDE's bugzilla).

[BTW, I repeat what I said before: I don't blame Trolltech too much
for this attitude -- it just didn't pay enough $$$ to fix that part
of the code, and printing in general just isn't a field that is "sexy"
enough to attract volunteers developers either. You'd rather see
dozens of text editors, and audio players, and image viewers and
photo albums than one added feature that improves printing...]

The problem is that everyone in KDE (and KOffice) did rely on Qt for
creating print files, and just (un)happily lived with what they got
from there. (But!, in fact you *can* work around that Qt limitation,
and make your application spit out excellent, highest-quality, indu-
stry-leading PS3 and PDF from a Qt-based application is amply proven
by the Scribus folks.)

The problem is that no-one in KDE did want to add code (or look into
re-using Scribus' code) to by-pass the Qt-provided PS generation for
print output.

The problem is that there is also no apparent *skill* level amongst
the KDE community that is able or willing to deal with with these
areas. Printing, PostScript, fonts -- these are also rather compli-
cated, and in addition non-sexy things to deal with in code. It's
not *only* that it's boring, it's challenging at the same time, and
who likes to deal with a boring challenge?

So here we are: complaints about sub-quality PS printing in KDE3;
an innocent KDEPrint which just processes whatever it receives (even
if it is "crappy" PS Level 1) and which adds a lot of shiny skin on
top of less-than-mediocre content -- even so much so that a lot of
people start loving and being amazed what KDEPrint can do; some ten-
tative announcements from the Linux Desktop Printing Summit that
declares "we'll work to move towards making PDF the default print
spooling and processing format"; a developer that declares this new
bright PDF future already having happened since a long time ago with
only a few users still wanting "PS at all" and pulling a few more
invalid arguments towards his cause at their ponytails...

But he's the only developer who puts work and code in the change/im-
provement/modification/re-architecture/re-design of KDE printing --
so *of course* he has his way. What else?

If only he would not use false arguments and false assumptions to
defend his decisions!

> But I fear I'm repeating myself not because I'm not being clear, but because 
> you don't want to hear what I have to say.  What I have to say is simple; the 
> KDEPrint solution (either the one in HEAD as well as the one in KDE3) is not 
> good enough anymore and has to be replaced with something else. 

It could be "good enough" and even *very* good for quite some time
to come, *IF* somebody was willing and skillfull to put some work
into it (probably much less work than you and Trolltech will be
putting into the re-architecture).

> (read my 
> various past emails on this topic for why).

Most of your past emails didn't go unanswered, and to most of the
counter-arguments you never bothered to respond.

So the only (or main) argument you have in your favor is: "I'm doing
the coding, and Trolltech is backing me up." That's fine, and that's
what trumps everything else (as long as no-one steps up and does work
on an alternative that starts from the current code base).

But don't expect to get your statements un-answered when and to which
degree they are proofably false.

> The best solution for this problem is QPrinter.

*IS*?? "Will be" may be a more appropriate wording. Hardly anyone has
seen it in action. So we all have to take your word for it. And we all
hope you are right.

[...]

>> Sorry, but the objections to the QPrinter solution were raised before (for
>> example by Albert), but they were happily rejected.
>> How can I being "costructive" this way, when any other solution than
>> QPrinter was simply rejected?
> 
> Because objections without plausible alternative solutions does not mean we 
> just abandon quite good solutions. 

"abondon good solutions"?

These solutions (really plural?) nobody yet has seen in action. It is
rather a "projected" solution, but not an existing one, as far as the world
outside of an Oslo office is concerned.

But in your next sentence you already fully explain the driving motivation
behind your plans:

> Only when you work with us to create a 
> *better* solution for the huge problem of being able to print on WIndows/Mac 
> or using apps like KWord that want to output PDF on all platforms.

It is *KWord*. Not current KWord, not working KWord, not released KWord.
*Future* KWord. You want to output PDF, and PDF only for printing. You want
to avoid PostScript altogether (not just the crappy PS1 type). Everything
else has to take very low level consideration.

That's what we have to live with; as long as you are the only one actively
working on KDE printing stuff, it's your final right to do that, and it's
your call.

(If you're loosing "friends" and friendliness over it because of your neg-
lect of existing applications, it's also your call...)

> So please do work with us to such a solution.
> 
> That's what I mean with being constructive.  If you can't do that, I'm afraid 
> you will indeed be feeling ignored. Yes.
> 
> I hope we can look forward to you working with us to solve these problems, as 
> I surely aim to make sure Okular has great printing in KDE4. And I assume you 
> want the same.


KDEPrint3 (via the kprinter utility, started from the commandline, and
able to pick up any file from any location, or read from stdin) was
able to serve non-KDE3 applications. And serve even very, very, very
legacy applications extremely well as a drop-in "print command". Or
serve users who just needed it as standalone application to print their
files.

Is the goal of "great printing in KDE4" to serve only KDE4 application,
or will it (sometime) also cater for arbitrary external applications
again?

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