Optimize Part 1 § Document Index § Optimize Part 3

Hardware Needs

Scribus, for a graphics application program is rather efficient and is not a monster consumer of resources, unlike some other graphics programs. It will rarely need more than 16Mb of ram for itself on x86. As images are linked, files are small and save quickly. I have been running Scribus on a PII400 / 256MB, now 768Mb, with no real urge to upgrade hardware. As the saying goes, you can never have enough money or too much ram. For a modern Linux distro, serious DTP will probably need a minimum of 256 MB or more of ram. If you are working with large image files like Tiffs or full page EPS and converting to hi-res PDF, more ram will definitely speed up PDF exporting. You should be running X at 24 bit color for good color fidelity. Most monitors are set for 9300K color which is not ideal for on-screen color fidelity with printing. The Color Management and Profiling your monitor with littlecms will have the details for setting this and monitor gamma properly.

Fonts, Fonts, Fonts

Fonts are often where the trouble starts and often ends. Getting the fonts right and understanding how applications like Scribus access them is the first step. Font management, rendering and printing are all handled quite differently than Windows or Mac platforms. This alone can be the biggest source of frustration for refugees from other PC platforms. Moreover, addingto complications are the newer distros are converting to a new font configuration system, which is included in Xfree86 v.4.3, which in some cases requires major rewriting of applications and libraries. Understanding the how to work with Xfree86 and sub-systems like the printer daemon and Ghostscript will reduce the frustration in the beginning.

A bit of history... When X Windows, on which Xfree86 is based, was developed, the way the display handled fonts became a completely separate system from printing. Applications display fonts and image data in a rather abstract way, as they depend on the capabilities of X to handle the details. This makes a DTP programmer's job sometimes a bit difficult, as it is difficult to guarantee a dimensionally accurate on-screen representation of the document to be printed. Today, there is a lot of effort within the Xfree86 team to add much better font management, rendering and printing support to future versions in Xfree86. Xfree86 4.3 has a completely new rendering system which is also included in Red Hat 8.0. The new system has much better support for Unicode True Type fonts. This is an important step to make Linux a much more user friendly place for desktop publishers.

Where's my fonts??

Thus, many commercial,as well as, open source programs have resorted to various workarounds to overcome the font management limitation of the X server. Corel's Draw and Photopaint programs which were ported using the Wine libraries, carry their own separate True Type fonts and Bitstream font server. Abiword also insists on installing its own set of fonts. Star Office 5.2 and 6.0 similarly install their own set of fonts, as well as modifying the X font path upon program launch. Even KDE will modify the font path upon launching. This has probably been one of the biggest sources of problems in creating Scribus.

Moreover, the default Linux installation will include various and heretofore never seen fonts by Windows or Mac users. These fonts might include bit-mapped fonts for X itself, BDF, PCF, SNF,Speedo fonts and often as well as a complete set of fonts for Latex.

These differing flavors of fonts, usually end up installed in separate directories. Do not be surprised to have as many as 12-14 different font directories on fully loaded Linux Desktop. This has been obsoleted in the 0.9.x versions, with the new font preferences setup, but left for reference purposes. For details on the new font preferences, visit the Font Preferences section.The first workaround is to explicitly tell Scribus where your Type 1 and True Type Fonts are. Create a simple text file like this: (Scribus does this now automatically)

/usr/X11R6/lib/X11/fonts/TTF,
/usr/X11R6/lib/X11/fonts/Type1,
/usr/share/fonts/default/TrueType,
/usr/share/fonts/default/Type1,
/usr/share/fonts/userfonts,
/usr/share/fonts/wprequired,

Then name it .scribusfonts.rc and save it in your home directory. You do not need to add the bitmap fonts directories and I advise against this if you plan to export to EPS or PDF for printing on other platforms. Macs and Windows can handle TT and Type 1 fonts embedded in Postscript or a properly prepared PDF file just fine, but I doubt they would handle a Speedo or Xwindows bitmap font properly.

Scribus will typically be able to find the default fonts just fine. In the example above, we have high quality licensed Bitstream fonts from Corel Photo Paint. These fonts are known for their reliability in Postscript printing. Depending on your needs, these might be desirable to make available to Scribus. Star Office 5.2 will also include high quality, mostly Monotype, Type 1 fonts, but simply opening Star Office will typically add these to your font path.

The next is to check that each font directory has the correct fonts.dir and fonts.scale files. Fonts.alias is not important to Scribus, but if you have Type 1 .pfb files, make sure the corresponding .afm files are installed as well. Scribus can read these for font metrics. When adding True Type fonts from a Windows platform, the names should be in lower case, if they are in upper case, this can cause some unintended effects. For users of Red Hat 8.0 and Mandrake 9.x, please also see the hints in Red Hat 8.0 and Scribus.

High quality fonts are essential for reliable output, no matter which platform. Another good source of fonts for Linux is the URW fonts, which are available at the gimp ftp site. Be aware, some older versions of these fonts, as well as older versions of fonts included with ghostscript have been known to cause problems with PDF export in Scribus. Do not be surprised when shareware or clone True Type fonts from the Internet disappoint when printed. Sometimes shareware True Type fonts do not follow proper the proper encoding specs, so they are unreliable in a Postscript environment. Making good dependable fonts is not easy and requires a lot of QA testing. Also, do not be put off by the lack of a great screen preview with the URW fonts - they are excellent printer fonts. Font faces like Palladio and Utopia for example, are not really attractive on screen, but they make excellent fonts for printed documents and generally good readable fonts for documents. There is a reason service bureaus and printers spend literally thousands of dollars for high quality font libraries.

For those leery of messing around with the command line tools for font installation, KDE 3 includes an improved version of Keith Drummond's kfontinstaller program. See the links page for more details I have used this and it has worked fairly well on KDE 2.2.2 and 3.0.3 with some minor bugs. It also applies fixes to allow you to work with good True Type fonts and Star Office 5.2, which has been the Achilles heel of Star Office on Linux. This panel module has a superb font pre-viewer and makes installation of True Type fonts fairly easy. Be aware it really should be run from root, so the fonts you installed are available all the time. For desktop publishing, I would avoid using the anti-aliasing available in KDE 2.2x or KDE 3. This merely slows down the redisplay and you actually lose some on-screen precision.

Printing Issues

If you are a Red Hat 7.1 or 7.2 user, seriously consider replacing the whole Lprng / Printconf-gui printing system with CUPS and the GIMP CUPS printer driver. If you simply want to print high quality RGB prints from Scribus direct to your ink jet printer, this combination is superb. I was so fed up with the old system that this alone made me seriously consider abandoning Red Hat for Mandrake or SuSE. Red Hat 7.3 and 8.0 finally has CUPS and it works great. Moreover, getting rid of the printconf-gui and LPRrng combo relieves you of the dependency on Ghostscript 6.5x releases. You can then upgrade to the latest 7.x version, which continues to improve support for high end color printing. Another option is to get the ESP version of CUPS with Ghostscript 7.05. Easy Software or Cups Home Page. There is an easy to install rpm and source available.

The CUPS daemon replaces lpr and has an easy to use browser based interface. You can add the Gimp Print driver for fine tuning colors and resolution in RGB mode. CUPS uses the foomatic database for printers, so you can go to www.linuxprinting.org and get a custom .ppd, which you can also use with Star Office. I have never had such good looking documents from either Scribus or Star Office until I installed this combination. The output with images in documents rivals or exceeds Windows printers with these programs. The latest good news is recently CUPS added true CMYK printing support in 1.1.15.

KDE 3 has a vastly improved kprinter interface to CUPS. The other tool, which is quite useful for printing with CUPS is XPP, a nice graphical front end for accessing the extended features at print time, especially if you have installed the CUPS Gimp Print Drivers. From the printer panel, Scribus now has direct support for the CUPS and Gimp Print driver at print time to fine tune printing.

Export to PDF

The PDF driver in Scribus is a separate library in its sixth generation, custom designed for high resolution output. Full font embedding can also be enabled, so cross platform printing should be trouble free - a constant problem with creating pre press PDF's. My Scribus documents print from Acrobat Reader on Linux, Windows and Mac exactly the same. I have also distilled Scribus postscript files with large high resolution tiffs at 3600 dpi with Acrobat 5.0.5 without problem. Currently, the export library only performs flate compression on images, with no re-sampling so you need not be worried about image degradation.

If you are creating PDF's for the web or internal printing and file size is a concern, you can substitute PNG's in place of high res (and large) TIFFs. For Windows and Mac refugees, learn more about PNG, it is an excellent candidate to replace JPEGs and gifs in many instances. My only caution is when printing to raw postscript, some image setters may have problems with its more advanced alpha transparency features. Also, you may be tempted to upgrade to the latest version of PNG, but Qt2 and Qt3 is usually compiled with a specific version, so check your distribution's options. Lastly, the PDF driver enables bookmarks, annotations and presentation effects, so your printouts can match your screen presentation exactly - a nice touch for a DTP program.


Optimize Part 1 § Document Index § Optimize Part 3