Mad Penguin: Scribus 1.1.6 Reviewed

Tuesday, 27 April 2004 | Binner

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.

Comments:

what kind of review is that? - Thomas - 2004-04-27

Summary: Scribus is ugly. Menus are cluttered. Don't use it yet, as it's not mature. It may be worth to take a look at it again though (maybe in a couple of years)? my opinion: stupid review(er)... Scribus is already mature enough to provide you with all what you need to layout some small to medium sized brochures. Well, it has its weak sides (hint: please improve the integrated story/text editor) and its strong sides (pdf export, scriptability, using littleCMS ... etc.) And no, it's not an app for your Gran, and yes, if you want something like MS Publisher, Scribus may not be your best choice (at least with MS Publisher you get the print preview from the file menu, I guess). But if I recall correctly, Scribus was once leaned towards the older versions of QuarkXPress, maybe the menu structure derives from Quark?

Re: what kind of review is that? - Anonymous - 2004-04-27

> Summary: Don't use it yet, as it's not mature. Are you sure that you read the same review as me? With 4 of 5 stars for features, performance, overall value and total score I wouldn't call it immature and so doesn't the reviewer.

Re: what kind of review is that? - Thomas - 2004-04-27

ok. I was reading the text. I overlooked the last paragraph with the score. Anyway, I'm a bit surprised, that the reviewer gave Scribus a fairly good score, but the review doesn't sound like he/she is impressed by the app. I don't see the point in picking the alignment feature as an outstanding nicety (where there are actually far more impressive features) versus "bad usability" as a major drawback. I can agree on improving the usability (who doesn't...) and standards-compliance (like putting the print preview under the file menu). This just did not make sense for me (and btw., I am a scribus user. I'm using it quite frequently for layout of sales brochures) and in my opinion the weak points of scribus are: a) zoom and selection tools. If you've more than one page the selection and view sometimes jumps around until you loose orientation on the page b) the story editor (text input in general) And Scribus has nearly the same demands on hardware like other comparable layout tools (Quark, etc...). An old PIII is really not enough to do serious work with scribus. But that's not a real minus, cause even scribus can't do magic. If you have to deal with lots of pixels or vector graphics, you need a fast PC and lots of RAM. period.

Re: what kind of review is that? - Boudewijn Rempt - 2004-04-27

I don't think the reviewer has ever used a dtp app (Pagemaker, or Quark, or Ventura) for something real -- and I count a hobbyist fanzine or a school mag as sufficiently real.

Re: what kind of review is that? - Tom Chance - 2004-04-27

I'm not sure it's what you'd call "stupid". The reviewer made many valid points, as you yourself point out. Whether Scribus models itself on MS Publisher or QuarkXPress, it ought to conform to the KDE standard in menus. It should also inherit standard icons. Finally, I'm sure the Scribus developers would agree that it could be more user friendly without making it any less powerful.

Re: what kind of review is that? - Evan "JabberWokky" E. - 2004-04-27

:: it ought to conform to the KDE standard in menus. It should also inherit standard icons Why should it conform to KDE standards? It's not a KDE app.

Re: what kind of review is that? - Anonymous - 2004-04-27

Not yet, but according to the roadmap it will become an option in 1.3.

Re: what kind of review is that? - a.c. - 2004-04-27

One of the mistakes that MS made was that they quit listening to their customers. The reviewer is simply a customer. He is telling you that he does not like the menu structure and find the useability to not quite be there. But all the working code is. I have used scribus and I can understand what the reviewer is saying. I would be very surprised to NOT see the interface change in a release or two. The author has always shown themselves as being responsive and productive with regards to comments. I would also guess that some folks will soon come up with alternative layouts for scribus.

Re: what kind of review is that? - boo radley - 2004-04-27

The reviewer is simply a customer But he's not a customer, not really. Look at the author info at the end of the article -- he's a student and an open-source enthusiast. Well, so what? If he made his living as a layout designer or editor or, well, anything vaguely print-related, this review would carry some weight. As it is, he doesn't spend enough time with the core professional features of Scribus that he starts his article with : * CMYK Colour * "Press Ready" PDF Creation * EPS and PDF import/export * Complete ICC colour management * Font embedding and sub-setting in both postscript and PDF export instead we, got So all I do in Scribus is I select all three text boxes, select the Distribute/align function and the boxes are aligned. Therefore saving me the time and hassle of having to do that myself. It's things like that, that help to make Scribus a good program. Aligning columns and objects are things that were present in Adobe products when I was using Apple system 8 and Pagemaker back in the nineties. It's not a compelling feature for Scribus at all, and should, at best be glossed over in a sentence like "Scribus has all the features you'd expect from Pagemaker, like...", not given its own paragraph and screenshots. Did the contact sheets look ok? Did you take any samples to a professional printer? Were there problems with color matching or calibration? This software should have been put into the hands of a professional graphic designer to review, not a self-professed open source enthusiast.

Re: what kind of review is that? - Thomas - 2004-04-27

Second...

I think part of the GUI problem is the reviewer's - Brent Cook - 2004-04-27

That theme isn't quite so nice, nor is the icon set. I can only assume that, since the reviewer is probably a Gnome person, he hasn't spent much time tweaking the Control Panel to make things look nice. That said, I understand his frustration with where items are on menus. However, if you have ever used Quark, you will realize that an intuitive user-interface, esp. for first-time users, is by no means a prerequisite for a desktop publishing app. Of course, once you have figured out how to change fonts and such in Quark, it's not so hard, but it is also not obvious or standard. It would be nice if Scribus could break the mediocre tradition set by Quark in the interface department.

Review hints at one of my pet peeves - regeya - 2004-04-27

Ugly? Not intuitive? Has a learning curve, which is apparently its Achilles heel? Man, ever since Havoc Pennington and others decided to "ruin" GNOME, there's been this attitude that apps aimed at the Free Desktop had to be as simple as the rock-bottom consumer-level apps out there. Would it be so horrible if Scribus eventually ended up being suitable for production print work, or does it have to turn into Print Shop? ;-D

Re: Review hints at one of my pet peeves - mark dufour - 2004-04-27

that would be like vi turning into emacs ;) <bring it on>

Re: Review hints at one of my pet peeves - mark dufour - 2004-04-29

or not ;)

Re: Review hints at one of my pet peeves - Tom Chance - 2004-04-27

You're implying that if Scribus were to make its UI more user friendly, it'd become less functional, or otherwise worse. Is it not just possible that Scribus could do a lot to improve its UI without losing functionality? Just because a lot of production-level apps like Quark have terrible UIs, and a lot of GNOME apps have reduced functionality and/or configurability, doesn't mean KDE and Scribus have to emulate them.

Re: Review hints at one of my pet peeves - Derek Kite - 2004-04-27

Maybe complicated tools need complicated ui's. Desktop publishing isn't something granny sits down at. It's professional people generating stuff, usually on short notice, for printing. KDevelop has a complicated menu structure, buttons all over, and usually shows this wierd stuff in languages that most don't understand. I don't want to say what I would call someone who complains about it for those reasons. It is a complicated powerful tool. I use tools that require weeks of training to use effectively. And I wouldn't have them any other way because they are very effective for their purpose. The largest usability issues with an application like Scribus are not being able to do something that desktop publishers need to do every day. That is what would prevent people from using it. The icon themes and menu structures are frankly secondary. I would rather the developers spend the time finishing the necessary feature todos. Make a tool that people can use for their jobs. After that is done, put pretty icons everywhere. Or let someone else do it. Derek

Re: Review hints at one of my pet peeves - Aaron J. Seigo - 2004-04-27

> Maybe complicated tools need complicated ui's. complicated and usable are not necessarily mutually exclusive. > The largest usability issues with an application like Scribus are not being > able to do something that desktop publishers need to do every day. that's not a usability issue, that's a functional requirement. meeting the required func spec is, of course, #1 when creating software, as software that doesn't do anything isn't worth anything. but usability can (and should) be a parallel track while achieving that end. > After that is done, put pretty icons everywhere. Or let someone else do it. if only it were a matter of pretty icons =) but i (think i) know what you mean. i completely agree with you that it's probably best left to a team member whose aim is designing for usability. it should, however, be done in parallel with development if at ALL possible and it MUST involve the "feature" developers and bug fixers otherwise it becomes a frustrating and counterproductive affair.

Re: Review hints at one of my pet peeves - Derek Kite - 2004-04-28

I guess what frustrates me about this stuff is how 'usability' ends up being 'I can't figure out how to use it'. Desktop publishing entails concepts and skills that I don't understand. I could bang out a simple two column with picture and header, or a letterhead. Scribus would be overkill, OO, Kword, or any of dozens of word processors would suit better. If I can't get Scribus to do what I want, maybe it's not what I need. How can I judge? Someone who works with this stuff, production work, would be a good judge, and be able to offer constructive suggestions as to improvements. It may be that production demands different things than some HIG guideline could even contemplate. This is why usability is such a minefield. Serious usability work entails studying how people work, and figuring out ways to make it better. You are doing that type of work, and I do appreciate it. But essentially my point is that usability ultimately means someone can actually use it. I think of the earlier days of CAD, with the two letter commands, no menus, etc. To learn required cheat sheets, etc. Some packages came on the market that were more 'usable', with menus, easy stuff. The problem was these packages became 'unusable' once you had a drawing of even moderate complexity, because they took forever to redraw. To get work done, you needed one of the harder to learn packages, because they could be productive, or 'usable' with the hardware of the day. Or something I worked with today, a hardware/software package. The software has it's annoying points, requiring changing modes to do most things, etc. Somewhat time consuming and frustrating. Yet, it is ultimately very usable, since once set up, I literally can forget about it. So the designers put the energy and focus on what really matters. Derek

Re: Review hints at one of my pet peeves - Tom Chance - 2004-04-27

> Maybe complicated tools need complicated ui's. They do, to an extent, but that's not an excuse for unnecessarily bad UI decisions. The review highlighted a few (print preview in an odd menu) and suggested that there were many more problems that could be alleviated without decreasing functionality. Look at Konqueror's right-mouse button menus in KDE 3.0 and KDE 3.2. You have more or less the same functionality, but now the menus are far cleaner, and far more usable.

Re: Review hints at one of my pet peeves - a.c. - 2004-04-27

hummmm. So are you saying that many of the UI changes that have been made to KDE to improve the L&F have been a bad thing?

Re: Review hints at one of my pet peeves - Shane Simmons - 2004-04-27

Nope. Thanks for shoving some words in my mouth, though. I guess I deserve it since I associated the author of the article with the "options are hard!" crowd. I'm all for cleaning up UIs when it makes sense, really. I don't think that Scribus is all that bad, but then again I'm a QuarkXPress user. ;-D

Re: Review hints at one of my pet peeves - Melchior FRANZ - 2004-04-27

> Ugly? What is really ugly is the big font for menus and dialog boxes. Scribus does for some reason not respect the qtconfig setting, and there doesn't seem to be a way to configure it. It therefore looks different from any other Qt application and, of course, all KDE applications. It looks ungainly. Also the window menu icon at the left side of the menu is quite disturbing. I hope that this won't be in the KDE version. Apart from these problems, Scribus is really impressive!

Re: Review hints at one of my pet peeves - scribusdocs - 2004-04-28

The Fix ? Edit > Preferences > General > Font Size This is also noted in the docs - there is a whole separate page, just on setting preferences

Re: Review hints at one of my pet peeves - regeya - 2004-04-28

Hm. I just fired up Scribus over here on my Gentoo box, and I'm nost sure I know what you're talking about. Make sure your distribution bothered to set up X DPI settings (not just relying on the desktop at hand to do it), and I have no idea why your copy of Scribus wouldn't vaguely resemble a KDE app. Sure, it's not going to use the KDE icons (so?), but on my system Scribus seems to be using the same fonts and toolkit style as my KDE apps.

Re: Review hints at one of my pet peeves - Craig Bradney - 2004-04-28

Fix your system. Scribus uses the themes from qtconfig. (Yes they can be different (KDE/Qt), eg in the case if you build a new Qt after building KDE, sometimes many apps cant see all the KDE themes, answer is to rebuild kdelibs.. KDE issue AFAIK)

Re: Review hints at one of my pet peeves - Melchior FRANZ - 2004-04-28

Whoops. Sorry, and thanks to scribusdocs! I glanced through the configuration options and didn't see that (although I admit that it's quite obvious). Anyway, it was not my system that was to be fixed, but rather an old scribus config file. qtconfig has the GUI font set to 10pt (just like KDE) but scribus had still 12pt set. Damn, now my list of complaints is down to one trivial item ... ;-)

just finished - Sergey - 2004-04-27

typesetting a large (5'x3') conference poster in Scribus 1.1.6 on the dated PIII (450). Sure, it was slow, and story editor sucks (ruins subscript/superscript when you open your text frame). But it helped me to set a fairly complex layout with lots of graphics and two-column textframes in <1 day. And PDF output looks perfect -- just got a proof print on our color laserjet. Next step -- bring it to the professional printer and hear the verdict [rolleye], hope font embedding works. Keep up a great work -- Scribus is the next best thing to Latex/Lyx combination ;)

Re: just finished - Boudewijn Rempt - 2004-04-27

Keep us updated on what the pro printer says, please?

Re: just finished - Craig Bradney - 2004-04-27

As I posted on the slashdot article yesterday, we have professional printers with real DTP hardware, RIPS, printers etc.. that are testing Scribus in a few countries, eg, USA, Canada, France, Germany, India. Scribus produces compliant PDFs and PS3 output, with very exacting colour matching capabilities. As I am also a user of Scribus, I can say that when I produce my 24-36 page magazine and send to the printer in PDF form, he has no trouble with it. Seems to be perfect, and the result is as good as ID2 for sure. I recently have had letterheads and business cards produced that I did in Scribus. Perfect. Scribus isnt perfect in all areas, but we are aiming sky high and with more time and more help we can take it there. Remember.. we all have day jobs and families etc, like the rest of the FOSS developers out there. 48 hours in the day would be a big help. If someone wants to design new icons, mockup new dialogs.. fine.. we would welcome any input and help.

Re: just finished - Sergey - 2004-04-27

sure, by the end of the week it should be printed on a nice 1m wide roll of paper :)

Questionable review. - James Richard Tyrer - 2004-04-27

I don't understand the reviewer's problem. :-) Yes, Scribus could use some MINOR improvements in the user interface. BUT, this is not a consumer word processor, it is a DTP program intended for professional use. What I like about it is that: 1. It will find and use ALL of my fonts (e.g. different widths and weights of Helvetica). Something that KDE doesn't seem to be able to do. 2. Although the screen image of fonts could use some work (this would slow it down by requiring a FT transform (scale and shift) of each letter), the printed output has the correct spacing. Again, something that KDE doesn't seem to be able to. A desktop publishing application must be judged first by its output. In that criteria, Scribus is a clear winner. If it takes a few hours to learn how to use it, so what. -- JRT

Re: Questionable review. - jo - 2004-04-28

There are only no professionals that use it. Bad usability cannot be excused with that kind of argument.

Re: Questionable review. - James Richard Tyrer - 2004-04-29

I am NOT talking about BAD usability. I stated what I believe to be the case -- that Scribus needs some _minor_ improvements in its user interface. What it does not need is for the changes in its user interface to change the paradigm of using it. It should remain a desktop publishing application with its major purpose to combine text and images created by other applications -- it should not become something which is usable as a wordprocessor and it does not need to be as usable as a wordprocessor. -- JRT

nice.. - Aaron J. Seigo - 2004-04-27

so.. i finally got a chance to read the article. ;-) it's unfortunate that it garnered only 2 stars for usability, but it got 4 stars for everything else. awesome. 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 than a Windows app (looking at their roadmap), but that's my selfish "i don't use windows" side speaking ;-) Scribus is a very cool app. looks like the biggest thing it needs it some UI refinement. will be nice to see a review where they get four stars for usability too =)

Re: nice.. - Craig Bradney - 2004-04-27

The GUI has improved in various places since 1.1.6 was released. We are working towards a 1.2 stable release in the coming months. We will NOT totally integrate with KDE as we will limit ourselves to KDE. We want people to be able to run on Gnome, Blackbox etc, as well as future ports to Windows and Mac OSX (why shouldnt the rest of the world have great, free DTP capabilities?). We are however planning to build in whatever KDE integration we can based on build time includes, so therefore perhaps it will seem a lot more KDE integrated than it is now. We will probably move Print preview to the file menu in CVS.. the reason is where it is now is that it is a type 1 Scribus plugin and therefore appears in the Extras menu.

Re: nice.. - Spy Hunter - 2004-04-28

Making Scribus a completely KDE application wouldn't limit anything. Gnome and Blackbox users can use a KDE application just as easily as they can use a plain QT application. There is a port of KDE to OS X and a port to Windows too (and free, whereas QT/Win costs money, though it has advantages). KDE offers a lot of great technologies (IOSlaves, XMLGUI, DCOP, etc) that really can't be leveraged unless you go all the way and make Scribus a KDE application. I hope you'll consider it some more.

Re: nice.. - Eric Laffoon - 2004-04-28

> We will NOT totally integrate with KDE as we will limit ourselves to KDE. We want people to be able to run on Gnome, Blackbox etc, as well as future ports to Windows and Mac OSX (why shouldnt the rest of the world have great, free DTP capabilities?). I never really understood why it wasn't built on KDE. In the case of Quanta we felt the choice was obvious. We were using the Kate editor, KHTML and the file dialogs. On top of that we get DCOP, kparts and a very cool API. I have a lot of users who use Quanta on GNOME and Blackbox as well as OS X. (What is cool is that there are teams of people working to bring the KDE repository up on OS X.) Beyond Qt they only have to load kdelibs and our module. It can also run on Windows under Cygwin, but I tend to agree with Trolltech, Windows is not a free platform. In my experience your reasoning is flawed. I say this from having been the number 10 most active project on sourceforge when there were 5,000 projects to now when we are part of KDE. Let me explain. If someone wants Quanta they load the required library (kdelibs). It doesn't seem to be a problem for them. On Linux it seems to be pretty standardly installed too. People who have a problem with KDE seem to have a problem with Qt and why change toolkits. A better question is to compare the benefits for you and your users by going with KDE as compared to what you lose by being just Qt. Granted if you want to do the work you can do integration and stand alone but usually it becomes a lot more work. With KDE you get: 1) Very nice file and service dialogs (like Ktip) that you have to build now. 2) A number of enhancements to the API for more productive development. 3) Kparts to enable easy use of plugins in your application. 4) DCOP to enable interaction and scriptability. (For instance Kommander is being improved right now and can easily add functionality in custom dialogs driven by DCOP and scripting.) 5) Usability enhancements of a complete team of people who focus on this. For what ever small annoyances this may occasionally bring it will bring many times the benefit with feedback and people reviewing and fine tuning your code (when you are in KDE CVS). 6) More developers and support! While Scribus is a great app I noticed that by being in KDE CVS with Quanta that more people were involved with our development both peripherally and by general interest. 7) Translation team, and though we do our docs we get help from the doc team. Being in KDE makes you available in more languages than I can list without lifting a finger or asking for help. 8) Even more promotion and exposure in a great community. KDE is really outstanding because it is a community that bands together to promote their packages. Like Scribus Quanta is a great desktop application and while it was not mentioned in the recent article of killer desktop applications I feel it deserved to be. For me one of the best things about Quanta has been the association with a great community that has been very helpful in our efforts to make an even better tool. Conversely your presentation of the limitations of KDE integration are a quantum leap. For GNOME and Blackbox, if they are one of the few Linux desktops without KDE installed, they only need to load an extra library. It's worth it. There's a good chance they already do for Quanta anyway. For OS X, somebody else would have already been working on it for you. For windows... the Cygwin team works on KDE apps, but honestly who really cares? I'd rather give people a reason to opt out of monopoly control and reduce the odds of all information being coopted for profit. Without insuring freedom there is no guarantee that free (as in beer) can be sustained. All it takes is a patent or the right application of DRM. Why should we remove the incentive to reduce the leverage of a monopoly whose lust for power is a risk to our freedom to give freebies to those who are funding them? In our final analysis, even if we didn't use an editor and HTML widget from KDE I still would have wanted to be part of KDE because for all the other reasons it was obviously my best course of action to produce the best possible software. If someone needs to load kdelibs or get a Live CD to run it then so be it. You don't compromise your way to ultimate status. ;-)

Re: nice.. - Craig Bradney - 2004-04-28

Hi Eric, I take all your points into consideration but I ask this: You have said to me the limitations placed on being the KDE release schedule would limit a LOT of our freedoms we enjoy now. I disagree on the kdelibs thing, there are MANY people that do not want ANYTHING to do with KDE, and will go out of their way to find other apps just because of KDE dependencies (of any sort). The cygwin idea is NOT acceptable. Its a solution, but the file system performance within that environment is SLOW from what Peter has said. Why shouldnt we be able to offer a native Windows port, like OO.org etc? Eg, in the case of a friend, I recently built a PC.. they got Doze with the PC by default, but ALL the apps they run are FOSS based. They would not have the technical knowledge to install cygwin etc etc. Even many of the Qt libs are slow or so buggy we have had to work around various issues. One such was the Qt canvas (possibly fixed in qt4) but libart provides a fast and powerful canvas and without it.. we would have had to write our own. I'm sure that KDE integration and the benefits of KDE libs would be a great thing but the downsides have to be considered too. Its all up for discussion, but up until this point we have not seen enough reasons to start using kdelibs. Dont get me wrong.. Im a KDE user on all PCs.. I love it for all it provides. Craig

Don't cater to stupidity! - Moritz Moeller-Herrmann - 2004-04-28

> I disagree on the kdelibs thing, there are MANY people that do not want > ANYTHING to do with KDE, and will go out of their way to find other apps just > because of KDE dependencies (of any sort). These people are fools and probably would not use a qt application anyways. I mean seriously, who would use Qt from supposedly "evil" Trolltech and not the LGPL kdelibs? I think that not using kdelibs for this reason means succumbing to irrational, stupid prejudice. IMNSHO, people who don't want to use a great application like scribus because it needs kdelibs, don't have to use it. Personally I think these people should be ignored.

Re: nice.. - Spy Hunter - 2004-04-28

The people who have an irrational grudge against KDE in many cases also have an irrational grudge against any app that is based on QT. There's no point in basing your development decisions on the opinions of these crazy people. I doubt you would lose any more users by using KDE in addition to QT. Scribus could go into kdenonbeta and not be subject to the KDE release schedule. I agree that Cygwin isn't the most ideal solution, but if you don't use it you'll have to buy QT/Win, which is probably impossible for an open-source project like Scribus. As I see it, you're going to have to use Cygwin if you want a Windows port. And if you're already using Cygwin, why not bring along KDE too...

Re: nice.. - Craig Bradney - 2004-04-28

There are plenty of Gnome users who dont use or want anything to do with KDE, for one. While many dont use Gnome, it has its place, and just because this is primarily a KDE haven, doesnt mean that the rest of the WMs out there dont deserve a decent DTP app without KDE dependencies. Well, one of the team members is being asked to do a native Windows port by his employer (a university) and therefore has a copy of Qt/Win (Educational). As for how to publicly release the final version/qt libs.. not sure of that yet. Anyway, this discussion doesnt change anything for our upcoming 1.2 release. It will be a stable release based on the current releases, without massive changes here and there but with decent bug fixes and functionality enhancements. We have large under-the-hood changes in line for 1.3, AND we have plans for conditional use of KDE libs, who knows.. maybe more than just that. Decisions will be made later down the track based on what makes sense then.

Re: nice.. - gerd - 2004-04-28

QT looks somehow ugly, like an alien, and that applies for Hbasic and other pure qt apps too. I think a KDE integration would be very helpful. I don't think that anybody refuses to use Abiword beacuse it is a Gnome app. In the last month we saw more and more desktop unification.

Re: nice.. - David - 2004-04-28

"There are plenty of Gnome users who dont use or want anything to do with KDE, for one." Think of users who know nothing or very little of KDE or Gnome - DTP users using Windows or Mac OS? "Anyway, this discussion doesnt change anything for our upcoming 1.2 release. It will be a stable release based on the current releases, without massive changes here and there but with decent bug fixes and functionality enhancements." Cool! "We have large under-the-hood changes in line for 1.3, AND we have plans for conditional use of KDE libs, who knows.. maybe more than just that. Decisions will be made later down the track based on what makes sense then." Cool!

Re: nice.. - Datschge - 2004-04-28

"limitations placed on being the KDE release schedule would limit a LOT of our freedoms we enjoy now." This is the primary reason why Extra Gear (extragear.kde.org) exists afaik: allowing independent but KDE-using project to use the KDE.org infrastructure (centralized CVS, i18n and bug tracker with the respective advantage of more "looking eyes") while not being bound to any release schedule etc. But seeing how other Qt apps with KDE integration avoid it so far I'm not sure how well a Qt-only/KDE-integrated split within Extra Gear would be managed. Possibly it might be a good idea to move KDE integration to Extra Gear and sync the backend development of both trees?

Re: nice.. - David - 2004-04-28

"I disagree on the kdelibs thing, there are MANY people that do not want ANYTHING to do with KDE, and will go out of their way to find other apps just because of KDE dependencies (of any sort)." Mmmm. If people don't want anything to do with KDE then they won't use a Qt app - Qt is tainted, remember? You can't get into political games like this - look at what is laid before you, and really leverage the potential of your application. Besides, I think this comment is flawed because if you are attracting people to Scribus sane people will not see KDE or Qt or kdelibs - they will see the makings of a very good DTP application. Try not to tie yourself in knots over this issue. "The cygwin idea is NOT acceptable. Its a solution, but the file system performance within that environment is SLOW from what Peter has said. Why shouldnt we be able to offer a native Windows port, like OO.org etc?" The OO Windows port is important because of the nature of the application (MS Office competition and migration), but honestly, if you have a good alternative platform and operating system, Windows quickly becomes pointless. A new DTP application on Windows is too much of a niche considering what is already out there commercially. Look at the Gimp. That now runs on Windows, and no one really cares that much. From this perspective, Trolltech's attitude to a GPL'd Windows Qt does make complete sense. "I'm sure that KDE integration and the benefits of KDE libs would be a great thing but the downsides have to be considered too." Definitely, but the downsides currently don't make too much sense to be honest. However, can definitely understand you wanting to provide a multi-desktop port wherever you can. It just depends whether it really gets used enough on Windows or Mac OS to justify that attitude and effort.

Re: nice.. - Craig Bradney - 2004-04-28

There are already plenty of Mac people using it under Fink, and would be very happy to use it natively, have a look on the site stats for www.scribus.net for the browser/platform status. 20% of them are IE users, and 35% of them are Windows users. Only 3% of them are Mac users.. but oh well, maybe they just scream loudest. We have professional DTPers on Windows and Mac begging for native versions. Of course, 51% of them are Linux users. Go to the end of these posts.. and reply to my as yet unanswered questions regarding what you think would change in Scribus if KDE libs were used. In the end, its not just my decision, I'm just saying the reasons as discussed in the past by the team.

Re: nice.. - Aaron J. Seigo - 2004-04-28

> We are working towards a 1.2 stable release in the coming months. i look forward to it .. thanks for all the hard work you guys/gals are putting into it; this is a rather important niche to fill. who said complex apps for (relatively) niche markets won't be developed as Free Software? =) > We will NOT totally integrate with KDE as we will limit ourselves to KDE. you are currently limited to Qt, if one wants to look at in those terms. the major challenge you would run into with full KDE integration versus pure Qt would be getting it to run acceptably on Windows. blackbox, GNOME, etc are not really issues. yes, there would be the one or two moaners, but i doubt those individuals would represent the core userbase. given a better app, people doing page layout would welcome the improvements (e.g. XMLUI and a nicer file dialog =). i guess you probably know all this, but i like stating the obvious all the same ;-) it will be interesting to see what the Scribus Windows and MacOS X userbase ends up becoming. if they remain paltry in numbers compared to the Linux/UNIX userbase then the Scribus userbase will be getting short-shrifted by the push to Windows; if they come on strong then it will have been worth it (viva la Free Software). too bad we can't see the future, hm? ;-) as an aside (which means: this has less to do with Scribus then it should for me to post it here ;), to provide compelling reasons to use our Free Sotware desktops, i can't help but feel that at some point we have to gather our courage up and be willing to tap into the full potential of our Free desktop frameworks to create the best apps possible even if it comes at the expense of certain non-Free platforms. the traditional, incumbent software companies understand this concept well: applications beget users. if using Scribus and the host of other Insanely Great(tm) apps we have floating about meant using a Free Software desktop, more people would do just that. either that or else support our Free Software frameworks on non-Free platforms. either way we all win. but if our best apps remain lowest-common-denominator then not only will people have less motivation to explore Free Software in general, those who are exploring it will enjoy fewer benefits from doing so. > We are however planning to build in whatever KDE integration we can based on > build time includes the more the merrier; i'll be first in line to download it when it's ready to play with.... =)

Re: nice.. - David - 2004-04-27

"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 than a Windows app (looking at their roadmap), but that's my selfish "i don't use windows" side speaking ;-)" Well, Scribus is quite an application (wow!) and I wouldn't expect to see KDE integration overnight. They seem to be moving towards it quite steadily though. I like the way they have developed this application up. This I found interesting: "Scribus has an unusually small development team and is mostly the work of a German programmer called Franz Schmid." For an app like this that is absolutely incredible. It seems to show what you can get done with Qt. They're web site is also very nice. "it's unfortunate that it garnered only 2 stars for usability, but it got 4 stars for everything else. awesome." Well, I think the author has unfortunately picked up the definition of usability from somewhere else... "Since you can't just pick it up and go with it, its not something you can give your Gran to play with for instance. Your Gran is not going to want to spend time working out which icon to click on the tool bar to click so she can insert text into a box she's already drawn. At most all she will want to do is double click it, and then be able to type. Any more and she's just not going to understand it and will rapidly give up with it. Which is a real shame." This is rubbish, and is one of the reasons why I think the 'usability' drive by some people who don't know the meaning of the word has done a great deal of harm. No one can just waltz into a DTP program and start doing things. You have to know about the subject of DTP first, understand what you are doing and read up on tutorials so you know how to get those things done effectively. That is just like anything in life. You absolutely cannot create any application that anyone can walk straight into - that is not bad usability, that is just the reality of the functional requirements of the application. Anyone that does think like this obviously hasn't programmed apps and trained users in the real world; I mention no names. "Performance wise, I really couldn't ask much more from Scribus. It's stable, I haven't encountered any bugs in it and it flys along. I mean the thing is amazingly fast even on an old Pentium 3 450mhz computer, that is a great achievement for an application so heavily dependent on graphics that it really should be demanding more from your system." I think that we can safely say that Qt works quite well then :). "...the user interface turned out to be poor and for there to exist a learning curve." Wow. A learning curve for a spreadsheet, a financial application or a DTP program. Imagine that?

Re: nice.. - Craig Bradney - 2004-04-27

>"Scribus has an unusually small development team and is mostly the work of a >German programmer called Franz Schmid." >For an app like this that is absolutely incredible. It seems to show what you can >get done with Qt. They're web site is also very nice. 5 of us. Franz Schmid, DE, does most of the work of coding. Peter Linnell, USA, docs writer, tester, manages www.scribus.net. (professional DTP consultant with access to his customers high end software and hardware) Paul Johnson, UK, optimiser, coder, tester. Peter Vanek, CZ, Scripter, plugin writer, coder Craig Bradney (myself)(LU, from AU), manage IRC (#scribus on freenode) and bugs site (bugs.scribus.net), new 1.2 docs proofing, testing, coder. Plus many translators, script submitters, testers, bug and feature request reporters..... of which we send our thanks to!

Re: nice.. - David - 2004-04-27

"Peter Linnell, USA, docs writer, tester, manages www.scribus.net. (professional DTP consultant with access to his customers high end software and hardware)" Wow. I can imagine that would be a huge help. There's nothing like some real-world experience and testing. Well, you've all done a lot of fantastic work. Onward and upward!

Re: nice.. - Axel I - 2004-04-28

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.

Re: nice.. - David - 2004-04-28

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

Re: nice.. - James Richard Tyrer - 2004-04-28

> 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

Re: nice.. - Aaron J. Seigo - 2004-04-28

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

Re: nice.. - James Richard Tyrer - 2004-04-29

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

Here's to Scribus 1.2 speed improvements, hopeful - Marc J. Driftmeyer - 2004-04-28

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

Re: Here's to Scribus 1.2 speed improvements, hope - Craig Bradney - 2004-04-28

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

Re: Here's to Scribus 1.2 speed improvements, hope - scribusdocs - 2004-04-30

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

Re: Here's to Scribus 1.2 speed improvements, hope - Frank Siegert - 2004-05-07

>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

KDE integration ideas.... - Craig Bradney - 2004-04-28

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.

Re: KDE integration ideas.... - Sergey - 2004-04-28

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.

Re: KDE integration ideas.... - Datschge - 2004-04-29

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.

Re: KDE integration ideas.... - Datschge - 2004-04-29

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

Re: KDE integration ideas.... - Craig Bradney - 2004-04-29

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

Re: KDE integration ideas.... - Datschge - 2004-04-29

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

Re: KDE integration ideas.... - Craig Bradney - 2004-04-30

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

Re: KDE integration ideas.... - Kurt Pfeifle - 2004-04-29

### -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?

Re: KDE integration ideas.... - Datschge - 2004-04-29

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.