Scribus Team Releases 1.3.1 Unité

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.

The Scribus Team would also like to thank Anduin.net/Øverby Consulting and n@work
GmbH, Hamburg
for gracefully sponsoring our Scribus Documentation site, our Bug Tracker and Anonymous CVS server. Also, a note of thanks to University of Salford - School of Media, Music and Performance for providing continued hosting of our website including upgrading the server hardware.

Getting Scribus 1.3.1

You can:

The Scribus Team would also like to thank the many end users, testers and contributors to making this our finest release to date.

Dot Categories: 

Comments

by ac (not verified)

Just for curiosity I tried

. . klik://scribus-latest

expecting it didnt work -- but boy, was I taken by surprise! I beautifully installed a Scribus-1.3.1cvs (build dated 29th of September) onto my SUSE-9.3 system.

I really, really, really wonder, wonder, wonder how the nice klik guys make this thing work. They seem to make wonders happen

by Jonathan Dietrich (not verified)

I just did a klik://scribus-latest and I got 1.3.2cvs dated Oct. 3
very cool.

by Joe (not verified)

"I really, really, really wonder, wonder, wonder how the nice klik guys make this thing work. They seem to make wonders happen"

When debs already exists for an application, making a klik package for it is a peace of cake. And Scribus has debs for debian and kubuntu so...

by ac (not verified)

You sound like an old-fart wisacre to me. ..."piece of cake"... Tss, tss!

If it indeed *IS* so easy as you pretend, why didnt *you* invent klik? And why didnt you do so 10 years ago already?

by Corbin (not verified)

I think he was talking about how hard it is to make a klik *PACKAGE*, not klik itself.

by Joe (not verified)

"If it indeed *IS* so easy as you pretend, why didnt *you* invent klik? And why didnt you do so 10 years ago already?"

Ok let me rephrase it for you:
"When debs already exists for an application, klik (which is a great app that we all love) will easily be able to use it."

This is what the developper KLIK page says about it:
"The easiest way to get your application in klik is to get it into debian - then it will appear in klik automatically. "

Thanx for the fart thing insult by the way, you're very mature.

by Marten (not verified)

Scribus is a great gt app. It is a pity that there are only few example files to play around with. Again a wonderful showcase for klik technology.

by Fast_Rizwaan (not verified)

Isn't KWord similar to Scribus, more like a Desktop Publishing software? But I find Scribus 1.3 *easy to work with*!

Could we include Scribus in KOffice???

by Boudewijn Rempt (not verified)

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.

by petr vanek (not verified)

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.

by Giovanni Venturi (not verified)

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.

by Boudewijn Rempt (not verified)

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.

by Meneer Dik (not verified)

Why don't you submit a bugreport about this issue.

by Nicolas Goutte (not verified)

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.)

Have a nice day!

by mrdocs (not verified)

Correct, Scribus implements its own PDF and EPS/PS exporters quite independent of Qt.

by James Richard Tyrer (not verified)

The problem is that KDE uses the Qt PostScript driver.

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.

by anonymous (not verified)

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.

by James Richard Tyrer (not verified)

OK anonymous, please tell us how (with Qt-3) to paint with a font using the UNHINTED font metrics and then print with the unhinted font metrics. I am sure that we would all like to know how to do it.

I would also like to know how to do it with Qt-4.

Note that IIUC, scaling the image will not do it because that would change the size of the glyphs as well as the space between them so the problem would remain the same.

by anonymous (not verified)

Giovanni talked about printing a 4 Mpixel *photo* and loosing quality, not about some minor issue with font hinting.

by James Richard Tyrer (not verified)

No, he talked about the problems with KDE apps:

> 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.

by anonymous (not verified)

> The result is that a high resolution photo is down sampled.

And this is where I believe you are wrong:

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.

by James Richard Tyrer (not verified)

You are partially correct.

The problem starts where the Qt PS print driver (like other printer drivers) does not produce a resoution independent PS file.

The PS driver uses a scale:

QPaintDeviceMetrics m( printer );
scale = 72. / ((float) m.logicalDpiY());

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?

by James Richard Tyrer (not verified)

I posted my test here:

http://home.earthlink.net/~tyrerj/kde/PS-test.png

This shows the original 640x480 image magnified to 11X in The GIMP

This image was included in a KWord document at 320x240 pixels which is shows in GSView magnified somewhat. This was magnified with X-Magnifier on the left.

These appear to correspond pixel for pixel so there is no loss of resolution -- no down sampling.

This was with KWord 1.4.2, KDE-3.4.3 & Qt-3.3.5. If this has been fixed -- it appears that it has been fixed -- I don't know exactly where.

by MandrakeUser (not verified)

Guys, has anyone tried klik in Mandriva ? Is it feasible to use it ?

thx!

by Corbin (not verified)

Try it and find out! It works in Gentoo pretty well, so I figure that Mandriva should work as well.

by MandrakeUser (not verified)

yeah, I'll try tonight (can't use linux at work unfortunately) -- thanks!

by MandrakeUser (not verified)

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.

Oh, I haven't tried the scribus klik yet ...

Cheers!

by Sam Balenti IV (not verified)

I asked Olle Dierks to try the scribus klik. He told me it works but with some minor errors.

by uddw (not verified)

I wonder why they start using cairo now. Is Qt4/Arthur lacking any important features?

by Corbin (not verified)

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).

by Boudewijn Rempt (not verified)

Scribus doesn't use the kde libs, so nothing would stop them from going over to Qt4, except that that is a pretty big undertaking.