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

List:       koffice-devel
Subject:    Re: Explanation on WP vs DTP modes in KWord (Re: Kde-cvs-digest request for information)
From:       Simon Hausmann <hausmann () kde ! org>
Date:       2002-12-01 17:32:13
[Download RAW message or body]

On Sat, Nov 30, 2002 at 03:43:32PM +0100, Dirk Schönberger wrote:
> > a) Scribus uses completely different drivers for his printing output than
> > KOffice
> >     Therefore it would be impossible to get the high quality output of
> Scribus
> >     when it's run as a part of KOffice.
> 
> > If a) is (still) true then perhaps it'd be worth investigating the Scribus
> > printing code (by someone who knows what they're looking at of course,
> i.e.
> > "not me"[tm] ;-)
> 
> Do you think it would be worthwhile to work for a better imaging model in
> KOffice?
> For purely graphical elements (vector paths) the code in koffice/karbon
> could be used, but I think the text functionality is not quite up to par of
> e.g. KoText.
> IMHO this would mean KOffice specific graphics code, so that the current
> QPainter based graphics should be abandoned.
> Instead a more powerful imaging model should be supported, similar to things
> like
> Postscipt/PDF/SVG, Java2D or gnome-print.

Is it really the QPainter API that is the problem or is it the
backend bound to it?

Did you consider writing a new paint device that generates the
output you want? While probably still a hell of a lot of work I
could imagine that it is less work than changing existing code to
not use the QPainter API anymore.

(just a thought :)


Simon
_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]