[Scribus] Long documents

[Peter Linnell]

On Thu, 2003-08-14 at 03:02, Thomas Ahlstrom wrote:
> Hi
>  
> I'm running Scribus 1.0.1 on RH8.1 with latest QT-version. Scribus
> seems terribly slow when working with text flowing through typically
> 25 A4 pages 2 columns. That includes both loading and -- when
> eventually loaded -- editing the text. Waiting 10-15 seconds between
> every edit move.
>  

>  
> Any comments?
>  
> /Thomas

Certainly, I run the same - with the exception of compiling my own Qt
3.1.2 from source. It is my experience with RH Qt packages that their
extensive patching of Qt has a lot subtle adverse affects on Scribus
stability. With 7.2 and 7.3 I reported many crashes and issues to Franz
which he could not repeat. In hindsight, I can attribute this to the
extensive patches RH applied to Qt and KDE.  I find the KDE-Redhat
packages on sourceforge - much better for running Scribus. 

Slow text handling is in part, owing to the XML based format. A trade
off - open, extensible and very resistant to corruption.  Since the I
started working with Scribus from 0.3.7 and throughout all of the
bleeding edge cvs versions, I think I have lost *at most* a half dozen
documents to corruption/crashes and IIRC three were related to a
specific bug which was quickly quashed by Franz. I have probably created
a few hundred Scribus docs over time. 

You should also be aware, as Franz has really made an honest effort to
really make Scribus useful in professional DTP settings, I have
continually pushed Scribus harder and harder in testing. My yardstick is
the DTP apps I use and support professionally. Example, with 1.0, I got
Scribus for the first time to export a print ready PDF of an EPS map
which has almost 60,000 curves and segments. This croaks even new P4
machines when opened in Illustrator or InDesign.  When printed, it is
identical to the print created in Acrobat 6. Earlier this week, I got
Scribus 1.0.1 to generate a 150 MB 2400 dpi PDF with lots of TIFFS,
imported PDF's from Indesign and smaller EPS files. 

Ask any long time Pagemaker or Quark user about doc corruption. For some
this is constant problem, which is solved only through very careful OS
setup, system maintenance and extensive network testing. Fixing this
stuff is part of my day job. When I started this took me many months of
testing and reading to avoid this for clients. Indesign in this regard
is better, but still not perfect. 

One other observation I have more recently noticed which affects Scribus
is image quality, flicker and redraw speed are partly a video card /
driver quality issue and the design of Xfree86. 

Honestly, some of the Xfree drivers, while stable are not as speedy as
Win2k or XP on the same hardware. Plus, keep in mind Xfree86 runs in
userland, so it shares equal billing with any other process. On Win32,
start a processor monitor and then start dragging windows around. The
CPU spikes immediately to 100% and stays there until you stop.  Do the
same with Xfree86 and there is a bit of a lag in CPU usage, nor can
display refresh hog the CPU.  With the 2.6 kernel, this should be much
better. A lot of attention was spent on the kernel scheduler and I/O.

Other examples: 

On the Win2k box which I test built versions of Scribus, The screen
display was overall sharper and less flickery than the Linux box I have
at home - and they have the same monitors with the same refresh rate. It
simply has a superior video card and very stable updated Win2k drivers.
Even with the beta ports of Qt and KDE on Win2k with the slower I/O from
way POSIX sockets are handled , the display is excellent and redraw is
snappy both with Scribus and KDE3. You can see the screen shots on the
kde cygwin page on line with the docs. 

One of the comments from the Slashdot story was crappy screen shots. I
have a test machine (luckily lent by one of my clients) which is the
only machine I now use for screen shots. Why? It has a very high end
dual display Matrox card chosen for DTP work with 120 DPI screen
resolution. 

A while back, I compiled earlier Qt2 versions of Scribus under Solaris
8. The font display was excellent with Type 1 fonts - on a par with a
good Win2k or Mac screen. Why? Solaris' Xwin has display postscript
technology from Adobe. And screen redraws were *very* quick. 

The difference is the basic Type 1 rasterizer in Xfree86 comes from
older IBM technology. Only with the latest Freetype/Xft2 tricks can
Xfree86 even approach that kind of font display quality you can get with
the Adobe display code. 


>Why so long texts you wonder? Answer: Books. Of course one can put
>chapters in separate files and so on in the future, but the slow
>handling of long texts worries me a little bit.

While Scribus is not yet optimized for long documents, it can handle
them. I have a 390 page Scribus doc which I use for testing. When there
is page handling changes in the code, I open this up to test navigation
speed etc. Switching from the first to the last is usually fairly quick.
As another test, I imported the whole text of the Scribus on line docs
in one linked doc - 60-70 pages. It handles it fine, a bit slow, but
usable.   

Performance Fixes: 

If you are not adverse to compiling from source, get Qt 3.2.0 and make a
parallel install, so you do not affect KDE and other apps. Then set
QTDIR environment variable to /usr/local/qt32 or such. Then compile
Scribus and Qt 3.2 - hopefully against gcc 3.2 or better gcc 3.3 with
march=set properly.  Scribus has a lot of floating point math code which
optimized much better with gcc 3.2+ and the correct -march= set
properly.  This is especially helpful for P3+ and Athlon chips. A lot of
work was put into gcc 3.2+ to optimize the C and C++ compiler for newer
CPUs like PIII and P4.  Even the first 3.2 beta from Qt had some redraw
speedups vs. 3.1.2, but it was very unstable with Scribus. 


The main issue comes from auto flowing text. So, once the text is flowed
in, then break the text chains in to logical sections. Then lock the
text frames in place so they do not move. Both options speed redraws
quite a bit. 

Other DTP applications suffer similarly. Switching pages in Pagemaker
and Quark are not exactly speedy depending on your display settings in
the doc. Moreover, Quark has never been known to display graphics at any
thing more than low res proxy settings. Pagemaker is defaulted to low
res as well, but can be over ridden. Only with the latest hardware can
you tolerate the high res settings. I would also note Quark, PM and ID
have the option to "Greek" text under certain sizes - just to speed
redraws. 

I would also note Indesign 1.0 and 1.5 were heavily criticized for being
performance pigs - they were. I read a story about the program manager
for the release of 2.0 having a banner on his wall which said
"Performance, Performance, Performance". 

Use a faster window manager. I run KDE 3.1.2 with Mosfet's Liquid 90% of
the time, but when I am doing extensive work in Scribus at home I run
the minimalist Blackbox. It allows Scribus to start and redraws are
quicker. Other apps like Mozilla and Evolution seem to run much quicker.
Plus, the minimalist decor avoids helps to avoid visual distractions. 

Lastly, disable all animation tricks in your display settings. On the
DTP machines I support, they all have boring gray desktops with all the
eye candy completely disabled - no wallpaper, no animation, nothing
whether Macs or Win boxes. 


Fast Hardware helps DTP apps in particular.

Go back a few years to running Pagemaker on low end Pentiums - that was
painful at times. While, Scribus is not as hardware intensive as other
DTP apps, faster hardware helps any type of DTP related application. The
test box, purpose built for DTP - actually a modified HP engineering
workstation, I mentioned is really pleasant to use Scribus on. It runs
Scribus fast enough to actually just open and start typing. I would note
running Idesign or Illustrator 10 on anything less than a PIII takes
ages to load and is not fast in redrawing. Illy 10 burns up 48-60 MB of
memory on launch with no doc open, Scribus uses about 16-18 on RH 8/9.
Quark 5 and Indesign use more. 


>From a DTP viewpoint, my experience handling chapters in separate files
is probably good practice. Once the whole document is done you can
import the other pages and export PDF or print as one. 

For graphic intense docs, it is often better to handle them in even
smaller page groups. One of my clients creates a magazine in Pagemaker
and Indesign. They create separate files for every two pages in a
reader's spread (facing pages) layout. When complete, then they are
actually output as imposition ready PDF's as separate one page files.
This makes edits and changes actually quite a bit simpler and faster. 

I know this is a bit long, but I wanted to give those on the list (hard
core Scribus users) some perspective with other DTP apps and other
factors which affect this - it is just not the code. Scribus performs
very well in other areas like file saves, PDF generation and file
importing. The scripter plug-in works very quickly considering Python is
an interpreted language.  I find the scripts run as quickly as the
scripting engine in Pagemaker or Illustrator - and it is far easier to
use.

For first time users this can be a surprise with any DTP app and maybe a
disappointment on first use.  No, it is not ideal, but not hopeless for
the future.

Regards,

Peter
________________________________________________________________________