The Scribus Team is pleased to announce the release of Scribus 1.3.1, Unité. The 1.3.1 release is the second development version towards a new stable 1.4. This release brings new features never before available in any open source application including enhanced spot colour printing, intelligent colour wheel, in-line graphics, variable page sizes and ICC colour support. There has also been work towards Cairo support and a native Windows version and an initial MacOS X native build is available.

Scribus now natively supports spot colour printing for true DeviceN colour space support, natively rendering spot colours, with no maximum limit to the number of spot colours. Scribus uses enhanced spot and separation previews for previewing all separations when a new version of Ghostscript is available. The new spot colour support can also convert spot colours into composite CMYK in both print and PDF export. DeviceN support works with both EPS and PDF export.

This release also adds support for displaying colours and making colour choices with an intelligent colour wheel for colour schemes and to help individuals with colour viewing impairments. This is a first, we believe, for any page layout application.

Scribus text frames now support in-line graphics, both images along with scaled vector drawings.

Additional code, patches and fixes for Win32 and Mac OSX compatibility. Substantial progress has been made for both platforms and an initial 1.3.1 release of Scribus for MacOS X is available. A Win32 native release is hoped to be available for one of the next 1.3.x releases.

Scribus now has a Calendar Creation Wizard python plug-in with support for several languages.

New experimental, optional build time support for using the Cairo graphics library as a rendering engine. Currently, there are some minor performance issues, however, most notably gradient display is improved.

Many improvements in page and document layout. Scribus now supports variable page sizes and orientations within a single document, as well as when printing or exporting PDF.

Implemented a new startup dialogue with more options for creating, or opening recent and existing documents.

Continued improvements in ICC colour support including searching system directories for ICC profiles. Scribus 1.3.1+ now supports the proposed OpenICC specification for colour management profiles.

It's a little similar, in that both applications allow you to use frames. The difference is that in KWord, you edit your text in place, while in Scribus you have to import the text or use the story editor. And while I love Scribus, and think it would be useful to be able to embed KOffice parts right in a Scribus document (the other way around would be weird...), I don't think that replacing KWord with Scribus will gain us much fans. Besides, from a purely technical point of view, it would take quite a bit of effort.

well, both apps use frames. But there are differences in the goal of each app. Kword is determined mainly for text writting as in "office" suite. Scribus is designed for DTP work - it handles things which are unnecessary for common office users. I cannot imagine that one app replace the other one.

I think that all KDE application has to learn how to create a very good PDF from Scriubus, for KDE 4 could be very very cool and fine. An exporting PDF framework. I tryed to insert a 4 Mpixel photo into KWord and create a PDF that losts the hi quality photo definition and I got a bad printing PDF. I made the same thing with Scribus and I don't lost the photo definition and I got a well done printing with a coulor printer. I like KWord and I use it very often, but a PDF framework into kdelibs/kdebase could be a very good thing for KDE future.

Yes, integrating Scribus PDF capabilities into KDe would be a good thing. I'm not sure how easy it would be. I have created just one little patch for Scribus startup dialog, and taken a look at their use of cms; I haven't looked at the pdf code yet.

Unfortunately Qt does not allow to modify the generated Postscript. That even leads that EPS files are not transfered to the Postscript stream.

As far as I know, Scribus has chosen to re-implement everything of the PostScript generation.

As for putting it in kdelibs, it needs to be LGPL. That is one reason why the work was never started in KOffice (as the goal was clearly kdelibs). (The other reason being also the need of people having knowledge and time, and especially knowing how to handle Asian fonts in PostScript.)

The Scribus developers recognized that the Qt PostScript driver doesn't print correctly so they wrote their own.

There is also the Sun PostScript driver which was donated to OpenOffice.

Clearly, if the Qt PostScript driver doesn't print KWord documents (and other KOffice documents) correctly that something needs to be done. Using one or the other of these two PostScript drivers appears to be a possible solution to the problem.

Bogus. If KWord chooses to scale the imagine before it's printed using a QPainter on a QPrinter, of course you loose quality.

This is a kword bug, not a Qt bug.

Also not that a driver buys you nothing if it's not integrated in your painting abstraction.

The Scribus guys needed features not provided by the Qt3's painter. Qt4's painter does everything they need, so hopefully they'll port to use Arthur soon. With Qt4 there's no point in using libart or cairo anymore with a Qt application.

> I think that all KDE application has to learn how to create a very good PDF
> from Scriubus,

As I said, the cause of this is the use of the Qt PS driver.

What I said was about "font metrics" not about "hinting". This is the usual subtle difference between a a noun and the adjective modifying it. E.G. if I mention green cheese, I am taking about "cheese", not "green".

Now, the specific problem that you refer to is probably related to the fact that you can't set the resolution with the Qt-3 PostScript driver. The result is that a high resolution photo is down sampled.

Even in Qt3, the painter has a drawImage function that takes a rectangle and an image. If you print with this, *all* image data ends up in the PS file, it's scaled by the postscript interpreter when you print it.

Some programs seem to call QImage::scale() first, and by doing so sample the image down to 72 DPI, then they call drawImage() with a sampled down image, and then they blame Qt's postscript driver.

A driver can only print the data you put in, if you give it a 72 dpi image, it will print a 72 dpi image. If you give it a 300dpi image, it will scale it properly to the degree the printer supports it. Postscript, as I'm sure you know, is meant to be resolution independent.

computed from a DPI passed from the Painter which is normal for PostScript drivers -- not a good thing, just common.

KDE's libs don't appear to currently pass anything other than 72 DPI for the logical DPI of a page unless your are printing to PDF. IIUC, this is because higher resolution doesn't work (exactly where it dosen't work is another question)

IMHO, it would be better if there was a way to include images in the PS file at their original resolution and let the print system (GhostScript in most cases) resample the image to fit the printer, but this isn't the way that Qt appears to work.

It appears that the current version of KPrinter/KWord will do this, but only if you print directly to a PDF. But, I can't get it to work for a PDF. :-( So, I tried it printing to a PS file (no resolution specified) and I don't see any loss of resolution using Qt-3.3.5. Was this fixed?

I tried klik and it worked. Pretty cool. Many packages do not work in Mandriva, especially (not surprisingly) the ones based on debian. But generic packages are totally fine. They just work slower than the native Mandriva packages, but hey, with one click you install a generic package, this is pretty sweet.

I do share the sentiment that this does not replace distro packaging of software, but is is a very nice way of installing self-contained software, or bleeding edge packages for testing. Excellent work from the klik team.

Well right now they are using Qt3. They may figure it would be better to use cairo now instead of waiting for the application to be ported to Qt4 to get the improvements. Also if Scribus uses KDElibs the developers would have to wait about 1 year before they could port it to Qt4 (for the KDElibs to be ported).