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

List:       koffice
Subject:    Re: printing extension (was Re: kohtml)
From:       weis () stud ! uni-frankfurt ! de
Date:       1999-04-03 21:01:44
[Download RAW message or body]

Hi,

On Sat, 3 Apr 1999, Simon Hausmann wrote:

> 
> On Fri, 2 Apr 1999 weis@stud.uni-frankfurt.de wrote:
> [...]
> > > You're right, for printing this is of course not useful.
> > > It's just that I think the printing extension is very useful for printing,
> > > but not for displaying a window's content. OTOH KWord/KPresenter need to
> > > handle an embedded view's content as image/pixmap for displaying, that's
> > > why I'm wondering about a different way to display a window's content, not
> > > for printing it. But perhaps I'm just mixing up things...sorry if so
> > 
> > Matthias Ettrich said there would be an efficient way to make snapshots 
> > of a window including its subwindows. This way we could make snapshots.
> > 
> > BUTTH: if you use a 32 bit display like I do, then a screenshot is 
> > expensive and it does not scale well if you resize it.
> > QPicture is usually much smaller.
> > 
> > I dont get the point: Where is the problem with QPicture in the
> > printing extension ? Is it the problemtic printing capabilities
> > of khtmlw ? Perhaps we should make screenshots there ? You can still
> > put a pixmap in a QPicture. That means: If kohtml wants to deliver a 
> > pixmap, then just draw it in the printing extension and thats it.
> 
> Well, I'm experiencing that, in case of HTML documents, the amount of
> encoded QPicture data seems to be rather big (in average) , leading to slow 
> embedded views. (no matter whether I paint a pixmap into qpicture (like
> it's currently done in kohtml) or paint to the qpicture directly) .
> Now I wonder whether making snapshots (from KPresenter's/KWord's side) is
> faster / less expensive? How does this snapshot thing work? 
> 
> But this affects only the part of displaying the view, not printing it. In
> this case it would make sense IMHO to extend khtml's API to support
> printing to a specified paintdevice (to avoid the 72dpi thing ;) ) and
> then use the printing extension.

Another stupid problem is, that the embedded parts can not print
on the QPrinter.

How does Microsoft do the printing ?

Bye
Torben

> 
> Ciao,
>  Simon
> 
> 

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