[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:       Sean McGlynn <sean () tmiau ! com>
Date:       2002-11-30 20:25:18
[Download RAW message or body]

On Saturday 30 November 2002 17:12, Thomas Diehl wrote:
> Am Samstag, 30. November 2002 17:22 schrieb Nicolas Goutte:
> > How is Scribus printing?
> >
> > As we are hitting limits in QT for printing (as QT hides Postscript), it
> > might be good to investigate.
>
> ... as a non-programmer I can't tell about the way Scribus is printing. But
> there may be a reason that _all_ high level DTP apps I know of (at least in
> Windows) are writing their own PostScript and do not solely rely on what
> the system offers them.
>
> Thomas

From the Scribus "About" page
http://web2.altmuehlnet.de/fschmid/about.html

<and I quote>
Printing is done via its own internal Postscript driver, since the driver 
supplied by Qt has limitations and no version has shown to be bug free. The 
internal driver fully supports Level 2 Postscript constructs and a limited 
subset of Level 3. This limitation is due to the lack of complete support for 
Level 3 constructs within some versions of ghostscript. The driver that ships 
with Scribus can embed fonts for printing and you can use and output high 
resolution EPS files.
</and I quote>

So I guess that Franz, at least, thinks that Qt's Postscript driver has 
limitations for a DTP-like app. If I remember correctly though, he wrote that 
before he ported to Qt3 (in September), so maybe things have improved in the 
meantime.

Scribus also has hyphenation, interactive PDF forms, manual kerning of type, 
python scripting (including a "console" for interactive scripting), layers, 
colour separation/management, CMYK etc. I guess there are things in there 
that KOffice might be interested in. Scribus itself is Qt (3.1) and released 
under the GPL, so (perhaps ;-) there wouldn't be much problems in 
borrowing/integrating code. It's also frame-based.

Of course Scribus is also missing things, such as filters (of course :-) and 
the architecture (KDE/KOffice libs) and infrastructure (translators, more 
developers, testers, publicity etc.) that joining KOffice would bring.

Even if Franz was still not interested in transforming Scribus into a KOffice 
application/component, I get the feeling that some friendly collaboration 
between the projects would benefit both parties. Maybe two versions of 
Scribus (one Qt only and one KOffice) could be maintained?

Apart from the Scribus homepage (http://web2.altmuehlnet.de/fschmid/), 
there's another site with some more detailed (and up to date) docs about 
Scribus and Linux-DTP in general in case anyone's interested.
http://www.atlantictechsolutions.com/scribusdocs/projects.html

Just my tuppence ha'penny worth :-)

Cheers,
Sean
-- 
Sean McGlynn
sean@tmiau.com
_______________________________________________
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]