The Scribus Team would also like to thank the many end users, testers and contributors to making this our finest release to date.
Comments:
klik://scribus-latest - ac - 2005-10-05
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
Re: klik://scribus-latest - Jonathan Dietrich - 2005-10-05
I just did a klik://scribus-latest and I got 1.3.2cvs dated Oct. 3
very cool.
Re: klik://scribus-latest - Joe - 2005-10-05
"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...
Re: klik://scribus-latest - ac - 2005-10-05
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?
Re: klik://scribus-latest - Corbin - 2005-10-06
I think he was talking about how hard it is to make a klik *PACKAGE*, not klik itself.
Re: klik://scribus-latest - Joe - 2005-10-06
"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.
sounds great - Marten - 2005-10-05
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.
KWord and Scribus - Fast_Rizwaan - 2005-10-05
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???
Re: KWord and Scribus - Boudewijn Rempt - 2005-10-05
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.
Re: KWord and Scribus - petr vanek - 2005-10-05
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.
Re: KWord and Scribus - Giovanni Venturi - 2005-10-05
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.
Re: KWord and Scribus - Boudewijn Rempt - 2005-10-05
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.
Re: KWord and Scribus - Meneer Dik - 2005-10-05
Why don't you submit a bugreport about this issue.
Re: KWord and Scribus - Nicolas Goutte - 2005-10-05
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!
Re: KWord and Scribus - mrdocs - 2005-10-05
Correct, Scribus implements its own PDF and EPS/PS exporters quite independent of Qt.
Re: KWord and Scribus - James Richard Tyrer - 2005-10-06
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.
Re: KWord and Scribus - anonymous - 2005-10-08
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.
Re: KWord and Scribus - James Richard Tyrer - 2005-10-09
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.
Re: KWord and Scribus - anonymous - 2005-10-09
Giovanni talked about printing a 4 Mpixel *photo* and loosing quality, not about some minor issue with font hinting.
Re: KWord and Scribus - James Richard Tyrer - 2005-10-09
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.
Re: KWord and Scribus - anonymous - 2005-10-16
> 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.
Re: KWord and Scribus - James Richard Tyrer - 2005-10-16
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?
Re: KWord and Scribus - James Richard Tyrer - 2005-10-16
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.
klik for Mandriva ? - MandrakeUser - 2005-10-05
Guys, has anyone tried klik in Mandriva ? Is it feasible to use it ?
thx!
Re: klik for Mandriva ? - Corbin - 2005-10-05
Try it and find out! It works in Gentoo pretty well, so I figure that Mandriva should work as well.
Re: klik for Mandriva ? - MandrakeUser - 2005-10-05
yeah, I'll try tonight (can't use linux at work unfortunately) -- thanks!
Re: klik for Mandriva ? - MandrakeUser - 2005-10-07
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!
Re: klik for Mandriva ? - Sam Balenti IV - 2005-10-11
I asked Olle Dierks to try the scribus klik. He told me it works but with some minor errors.
cairo? - uddw - 2005-10-06
I wonder why they start using cairo now. Is Qt4/Arthur lacking any important features?
Re: cairo? - Corbin - 2005-10-07
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).
Re: cairo? - Boudewijn Rempt - 2005-10-07
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.