Mad Penguin: Scribus 1.1.6 Reviewed

Mad Penguin has a review of the latest development version 1.1.6 of the desktop publishing application Scribus. Scribus was, besides K3b and KDevelop 3 recently proclaimed by Newsforge as being one of Free Software's killer applications. If you're curious what the future will bring, read the Roadmap Document for Scribus.

Dot Categories: 

Comments

by Axel I (not verified)

Well surprise. After all, this is the Internet.
And there are piles of people who think they "know" how things are supposed to be.
Nothing on Internet can be taken that seriously these days.

by David (not verified)

"And there are piles of people who think they "know" how things are supposed to be."

What qualifies you to criticize then? You don't have to read it, but as someone who does develop applications for people I know this to be true. Like it or lump it.

"Nothing on Internet can be taken that seriously these days."

Some things more than others :).

by James Richard Tyrer (not verified)

> making Scribus a true KDE app would solve some of the usability issues (e.g.
> print preview being where the user would expect it), and i hope the
> developers find success in improving KDE integration. i'd sooner see a full
> fledged KDE app emerge ... .

Hello! Did you read my previous posting. It is not possible to make Scribus a true KDE application because KDE relies on Qt's Painter and PS driver. The Qt WYSIWYG is broken. KDE prints WYGIWYS (i.e. it does it backwards -- the screen spacing on paper rather than paper spacing on the screen). The fonts spacing on the paper is WRONG when you print from KDE apps.

The fix for this is promised for Qt-4.

--
JRT

by Aaron J. Seigo (not verified)

it would be completely possible to keep Scribus' homebrewed WYSIWYG. it uses Qt right now, so it's demonstrably possible to do this. at least you got one more chance to complain about KWord's WYSIWYG, right? ;-P

by James Richard Tyrer (not verified)

Yes, it would be nice to have Scribus that used KDE widgets and dialogs, but I don't see this as a totally integrated KDE application. There might be a few issues -- print preview for example (finding the fonts), but yes that would be nice.

Also nice would be if KWord did the two things I mentioned in the previous posting as well as Scribus. But, my point was not really to complain about KWord but that being able to get what I want in the output is much more important than minor glitches in the user interface.

--
JRT

by Marc J. Driftmeyer (not verified)

The application's menus do have much to be desired, and it is butt slow but rapidly improving with each iterative revision.

The Documentation is sparse and if there is one area that could be drastically improved upon it is the documentation along with an indepth tutorial manual.

But it's not alone. The GIMP's docs are cursory at best.

The Export PDF produces bloated PDFs.

How come the folks haven't contacted Frank Siegert of PStill and done some collaboration ala what Andrew Stone of Stone Design does for OS X?

Hell if it wants to become a serious DTP application, offering Frank's software as a Service would rapidly improve its usability and feature set.

http://www.pstill.com

by Craig Bradney (not verified)

>The Documentation is sparse and if there is one area that could be drastically improved upon it is the documentation along with an indepth tutorial manual.

being rewritten right now, in time for the 1.2 release...

>The Export PDF produces bloated PDFs.

What version are you running???? With text and vector compression, and more, recently options for various image compression methods Scribus produces "normal" sized 100% spec compliant PDFs.

>The Documentation is sparse and if there is one area that could be drastically >improved upon it is the documentation along with an indepth tutorial manual.

That I will take issue with. There are approximately 100 pages of documentation for Scribus, including some in-depth tutorials on the more advanced features of Scribus like Javascripting PDF or color management to name two. DTP is a rather comlpex subject and it takes time to master. For every application I work with professionally, I might have anywhere from 3-6 different manuals or guides even beyond those produced by the software provider.

We have received many compliments for the docs both on the mailing list and directly. If you doubt it, I can forward two I have received in the past few days.

Moreover, we are in the process of completely re-writing the docs for the 1.2 version. There are sections which are a bit out of date, but when the application is progressing rapidly it is hard to catch up. A *nice* problem to have.

As for using PStill, I have only tested it in cursory fashion, but they require a commerical license for the equivalent features which Scribus already provides and some cases exceeds or provided first. The free license version offers only a small sub set of features.

Scribus was the first DTP application on the planet to natively export ISO standard PDF/X-3 compliant PDF. It so more than a year before anyone else.

The current version of Scribus now has variable compression schemes whcih drastically reduce the PDF size and they are comparable in size to other high end DTP apps.

by Frank Siegert (not verified)

>As for using PStill, I have only tested it in cursory fashion, but they require a commerical license for the equivalent features which Scribus already provides and some cases exceeds or provided first. The free license version offers only a small sub set of features.

Hi,

and sorry to burst your bubble but PStill on Linux runs without licensing with *all* PDF related features. It is not GPL however and commercial use needs a license. Personal or edu use is free.

Best wishes

Frank Siegert, Author of PStill

by Craig Bradney (not verified)

Can some people please make some unemotional pointers as to what would change in Scribus if more KDE integration was done?

The menus would all look the same, the canvas would be the same.
Some dialogs would or could change...

Be constructive... I'm just interested to see where you would change it.

by Sergey (not verified)

I'll try :)
For me the most important feature would be kioslaves-enabled file dialog. I often have to work with files that reside on the network (ftp servers) and ability to work with them just as with local files is *very* convinient.

Second important thing would be integration with KDE print system. This would allow faxing/emailing jobs in a transparent manner.

Integration with KDE help system would be nice, too.

Moreover, I firmly believe that Scribus should not be KDE-fied, it should be Koffice-fied :), and use Koffice libs and dialogs, including the spellchecker, and templates.

by Datschge (not verified)

What I would understand as "KDE integration" (using Scribus 1.1.6 as reference, note that I try to make this list complete and not as an all around criticism, I can perfectly use Scribus as is, it just clearly isn't a KDE application at all a.t.m.):

*kde -> scribus*
-using KDE icons, KDE style of disabled buttons.
-using KDE file picker which comes with KIO (remote files) integration.
-menu structure like used in KDE, ideally as KXMGUI so it can be customized.
-KMDI for MDI so that users can also choose from IDEAl, Toplevel, and Tabbed mode next to the current Childframe mode.
-KSpell integration for spell checking.
-using KTextEditor for text input so the user can choose his favorite editor (usually Katepart, especially useful for included JavaScript).
-embedding of KParts for potentially editing e.g. images, spreadsheets within Scribus.
-true KDE combobutton for the Open button (i.e. without delayed menu when dragging).
-DCOP interface for communication between applications (e.g. for updating content automatically with that of another KDE app, e.g. texts, JavaScript scriptlets, spreadsheets).
-Kiosk lock down interface (here only for completion ;).

*scribus -> kde*
-let KDE applications profit from Scribus superior PSF rendering backend (KDE wide color management?).
-share custom UI extensions with other KDE applications.
-cooperate with Karbon14 on vector drawing.
-cooperate with KJS and KPSF for developing a PSF viewer which can interpret all features (forms, JavaScript).

*kde.org environment*
-develop in KDE CVS allowing other KDE developer to easily contribute.
-organize translations through KDE i18n, currently in up to 87 languages.
-manage bug reports in KDE bug tracker with many registered users.
-porting to other platforms as part of KDE (ideally fix shared issues only once).

I surely missed some further points.

by Datschge (not verified)

Uh, while reading replace all instances of PSF with PDF please, thanks...

by Craig Bradney (not verified)

"*kde -> scribus*
-using KDE icons, KDE style of disabled buttons."

half of them are already from various KDE apps... the disabled version.. yes.. thats a bit nicer.

"-using KDE file picker which comes with KIO (remote files) integration."

yes.. would be nice, one of the things we are interested in

"-menu structure like used in KDE, ideally as KXMGUI so it can be customized."

menu structure changes based on various things on startup.. how does this affect KXMGUI? (never used it) Most of the GUI in Scribus is hand coded (and yes.. needs work) because kdevelop produced GUI code is not nice.

"-KMDI for MDI so that users can also choose from IDEAl, Toplevel, and Tabbed mode next to the current Childframe mode."

possibly..

"-KSpell integration for spell checking."

true, tho theres a myriad of other spellcheckers out there.

"-using KTextEditor for text input so the user can choose his favorite editor (usually Katepart, especially useful for included JavaScript)."

not really appropriate. the Story Editor, which is getting a rewrite soon to fix its current issues, will handle all text input AND formatting abilities (better than it does now). a basic text editor will not. Note.. Scribus has Story Editor at v1.1.x, InDesign has it at v3.

"-embedding of KParts for potentially editing e.g. images, spreadsheets within Scribus."

interesting.. but we dont use the Qt canvas.. its not appropriate and not fast enough. not sure if we can then use kparts to put stuff on the libart canvas. remember gimp.. its the best editor out there... and not a kpart.. and we integrate with it now.

"-true KDE combobutton for the Open button (i.e. without delayed menu when dragging)."

not sure what u mean there? I cant see any special open button in koffice

"-DCOP interface for communication between applications (e.g. for updating content automatically with that of another KDE app, e.g. texts, JavaScript scriptlets, spreadsheets)."

yes, could be interesting, where applicable.

-Kiosk lock down interface (here only for completion ;).

"*scribus -> kde*
-let KDE applications profit from Scribus superior PSF rendering backend (KDE wide color management?)."

Colour management might be ending up in X/Xorg someday. We have discussed various ideas with them, as well as the ghostscript team enhanced support for ghostscript colour management.

"-cooperate with Karbon14 on vector drawing."

We work closely with the Inkscape team.. probably the best vector graphics program emerging at the moment from what Ive seen, wipes Karbon14 over the floor with its capabilities, imnsho.

"-cooperate with KJS and KPSF for developing a PSF viewer which can interpret all features (forms, JavaScript)."

I'm all for KPDF to get better. The only PDF viewer that comes close to being able to view the 100% spec compliant PDFs we produce is Acrobat, and in some cases, Acrobat 6 on The Other Platform.

by Datschge (not verified)

> (icons) half of them are already from various KDE apps... the disabled version.. yes.. thats a bit nicer.

Well, it's a whole framework, using KDE's current icon set and its current settings for effects how to display icons in normal state, on hover and when being disabled, it's all customizable.

> KXMGUI

I meant KXMLGUI, sorry for the typo, see http://tinyurl.com/3dpcg It is part of a larger core framework of KDE (KActions).

> true, tho theres a myriad of other spellcheckers out there.

KSpell itself is only a frontend to numerous spellcheckers, embedded into applications like KMail and Konqueror offering as-you-type spellchecking as well as the classical dialog.

> not really appropriate. the Story Editor, which is getting a rewrite soon to fix its current issues, will handle all text input AND formatting abilities (better than it does now). a basic text editor will not. Note.. Scribus has Story Editor at v1.1.x, InDesign has it at v3.

I don't really see how it's not appropriate since the abilities of KTextEditor depend on the part used, Scribus' Story Editor could just be a part as well, allowing it to be reused in other apps using the KTextEditor api. Also that still leaves the JavaScript editor which could use syntax highlighting and the like.

> not sure what u mean there? I cant see any special open button in koffice

I was referring to http://tinyurl.com/2a28f used in many places within KDE (but not often enough i.m.o.).

by Craig Bradney (not verified)

FWIW: print preview is now on the file menu in CVS.

by Kurt Pfeifle (not verified)

### -let KDE applications profit from Scribus superior PDF rendering backend (KDE wide color management?). ###

I think it is not the *rendering* of the PDF, but the *generation* of it, what you mean, no?

by Datschge (not verified)

Well, the whole progress necessary to create the kind of highly compliant PDF file Scribus does. I honestly have no idea what verb is most appropriate for this progress (how about "compiling"?). ;) Sorry for the mix up.