[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-linux
Subject:    Re: [kde-linux] KWrite/printer problem
From:       Bruce Miller <subscribe () brmiller ! ca>
Date:       2009-10-08 5:44:14
Message-ID: 101046.97893.qm () web88308 ! mail ! re4 ! yahoo ! com
[Download RAW message or body]

Comments are bottom-posted

 --
Bruce Miller, Ottawa, Ontario, Canada
bruce@brmiller.ca; (613) 745-1151


No tyranny is so irksome as petty tyranny: the officious demands of policemen, \
government clerks, and electromechanical gadgets.



----- Original Message ----
> From: Steven Friedrich <freebsd@insightbb.com>
> To: kde-linux@kde.org
> Cc: jim <jimtrish@att.net>
> Sent: Wed, October 7, 2009 10:40:56 PM
> Subject: Re: [kde-linux] KWrite/printer problem
> 
> On Wednesday 07 October 2009 12:59:51 jim wrote:
> > On Tue, 6 Oct 2009 22:10:21 +0100 Anne Wilson wrote:
> > > As for the comment about no-one caring about losing lines - that's about
> > > as silly as it can get, and not worthy of a reply.
> > 
> > Maybe not, can you do me a favour? Compose a text file similar to
> > ''Line 1", "Line 2", etc. for a total of approximately 70 lines.
> > Save it and then load it into KWrite and print it. The type of printer
> > should not matter. Let me know if all the lines and headers/footers
> > are printed correctly.
> > 
> > Thanks,
> > Jim Phelps
> 
> I had an issue with CUPS, but I resolved that.
> 
> So then I had time to check kde3 vs kde4.
> 
> Under KDE4, when I print the file without headers and footers, no lines are 
> missing, but when I print it with a header and no footer, the header causes 
> lines to extend into the bottom margin and there is no header on the second 
> page. Line 56 is missing and Line 57 is in the top margin of page 2.
> 
> KDE3 worked correctly, that is, it printed the header, recognizing the top 
> margin, then printed the body lines 1-54, a blank line(this might be a bug), 
> and then the footer, respecting the bottom margin.
> 
> In short, it appears than when headers or footers are used under kde4, their 
> size doesn't get subtracted from the page when it calculates the room for the 
> body.

This note updates my earlier contribution to this thread.

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.

I then tried starting Konqueror and printing two text documents from Wikipedia; I \
used the "printer-friendly" versions of both articles.

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. 2. the units \
of measure for the margins default to metric, rather than to the user's system \
default. I was raised to be "bilingual" (bisystemic?) between Imperial and SI measure \
, but for some, that might be a bother. Were I outside North America, I would use SI, \
including SI paper sizes. But here in North America, we use distinctive paper sizes \
and Imperial measure (or at least that's what we call it north of the Canada / US \
border and we have bigger gallons than they do, which only goes to prove that not \
everything in the USA is the biggest in the world <grin>). 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. 4. There is no way to customize a Konqueror print \
header. It is hard-coded. 5. Don't bother looking for footers in Konqueror. They \
don't exist. 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.

Conclusions:
1. The lateness of the hour here in eastern Canada (and the length of my day) did not \
allow me to test Konqueror in a plain vanilla form, that is, without changing any of \
its default margins. However, after a change to the margins, documents printed \
without text being lost at the page breaks. This was the problem that has driven me \
crazy for the last two years and which led another user to start this thread. 2. The \
problem rendering the table (point 7 above) suggests that the KDE print engine still \
needs considerable work. 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 \
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. \
___________________________________________________ This message is from the \
kde-linux mailing list. Account management:  \
                https://mail.kde.org/mailman/listinfo/kde-linux.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.


[prev in list] [next in list] [prev in thread] [next in thread]