What’s new in Scribus 1.3.5

Scribus team has just released a long anticipated yet unstable 1.3.5 version of this free desktop publishing application. Let’s take a closer look at the result of two years of hard work.

Highlights of this version are:

• switch to Qt4 and source code refactoring;
• rendering and loading of documents speedups;
• finally, sane inline text editing;
• new object type — render frame;
• new document view modes;
• new path editing tools;
• better linguistic tools;
• more typography options;
• much easier legal Pantone color swatches support;
• various user interface improvements;
• new and improved import/export filters;
• improved print preview;
• lots of bugs fixed and smaller improvements introduced.

I reckon I should warn you beforehand that the review is somewhat critical, but hopefully fair.

Internal changes

Quite a lot of time has gone into rewriting Scribus to use a newer version of Qt — the library that provides user interface elements and some basic features. While changing the code developers couldn’t help themselves rewriting a lot more, so the whole thing took a lot longer than expected.

Better performance

Rendering speed has been improved quite a lot and the application has become more responsive. This is mostly thanks to work by new member of the team — Pierre Marchand, and a new contributor — Tomas Mečiř.

Apart from that, documents seem to be loading much faster. Some users reported that it’s 4 vs. 20 seconds for some of their complex documents. You get the idea.

Tools

Sane inline text editing

If you compare the new version to any previous one, especially the misunderstanding called v1.3.4, ability to edit text right on canvas, without Story Editor, really looks like magic. You still can’t believe your eyes? Yes indeed — finally you can reliably select and remove parts of text, navigate inside a text frame and type in text. Long overdue and possible now.

Render frames

This new type of objects was born as a GSoC2007 project. The idea is that such a frame can hold description of data in some markup language and some external tool will vizualize it. Right now Scribus supports:

• LaTeX
• Gnuplot
• LilyPond
• Dot (GraphViz)
• POV-Ray

Contents of a render frame can be reedited at any time later. To do it just right-click on the frame and choose Edit Source in the pop-up menu Then you’ll see something like this:

In fact you can add your own visualizers. Localizable description of rendering options, where applicable, is stored in an XML file which has a rather easy syntax.

While elegant, this solution has a horrible disadvantage: rendering is always done into a bitmap file. This is perfectly fine for rendering POV-Ray, but doesn’t sounds like a good idea for the rest of the data types, where vector graphics would be just fine (apparently since PDF can be embedded now, you can customize pdflatex to produce PDF and vector data). However such a frame will be printed fine.

If you need support for Unicode in LaTeX, in the source editor dialog go to Fonts/Headers tab and add "\usepackage[utf8]{inputenc}" header in the Additional headers entry field.

Shape Presets

Shape tool has a bunch of new presets:

This, however, doesn’t help much with absence of parametric rectangle/ellipse drawing tools.

Polygon

Polygon’s curvature now can be adjusted:

Which looks quite cool unless you know you can do the same in Inkscape interactively :)

Sticky Tools

In earlier versions of Scribus current tool was automatically switched to Selector right after you released mouse button having had drawn something. Now you can suppress this and keep the drawing tool active by enabling Sticky tools option in the Insert menu. Well, I’m not really sure why this behaviour is optional and not a default. Works just fine in Inkscape.

New documents view modes and options

I’ll just list these new features, available from View menu:

• Preview Mode. Switches off displaying grid, guides, baseline grid and other indicators. It’s also available in the bottom toolbar (a button with an eye icon).
• Show Control Characters. If you ever used OpenOffice.org Writer and/or Microsoft Word, you know this feature: it toggles displaying of space, non-breakable space, smart hyphen and other indicators.
• Rulers relative to Page. If you changed page’s origin, reenabling this menu item will move the origin to its default position (top left corner of a page).
• Move/Resize Value Indicator. When you move or resize an object, the -

New path tools

Last year at Libre Graphics Meeting in Wroclaw Franz Schmid demoed the first tool that uses lib2geom library — Mesh Distortion effect. Later another tool based on lib2geom was written, and then — another set of tools that dont’ use lib2geom, but are somewhat related. They are all implemented as plug-ins and are available from Item > Path Tools submenu.

Their shared disadvantage is that, contrary to Inkscape’s live path effects (that are lib2geom based as well), they are destructive, hence you cannot safely undo them. So if you import a vector drawing. changed its size, applied Lens effects effect, the only undoable change will be resizing. That is: if you undo, the object will go back to its original size and still have lens-distorted look.

Since Scribus developers choose not to add tooltips to menu items, I’ll quickly go through all of the new path tools and try to illustrate them.

Lens effects

Applies an effect of lens distortion created by either of two lens types: a fish-eye lens and a magnifying glass. You can also change radius, either by typing in new value or just dragging a corner of the lens, and strength of the effect.

Works for Bezier paths, shapes, polygons, selections and groups of them. Any usable amount of lenses can be created and manipulated simultaneously. You can also select and delete a lens.

Mesh Distortion

A shape, a path or a group of shapes and/or paths is distorted in a grid defined by 16 draggable nodes.

Path along Path

A very well-known effect to Inkscape users. You draw a leading path and an object, then select them:

Fire up the dialog, pick options:

And the result is:

Connect Paths

Connects two paths with a segment by their ending or begin nodes. So you draw two Bezier paths:

Open the dialog and define options:

And you get this:

Cut Polygon

The command cuts any closed path or shape using any unclosed path that you can draw using Bezier path tool or Freehand tool (note that the Line tool won’t work here, which is a bummer). Amount of final pieces is equal to amount of times the cutting path intersects the underlying shape.

Path operations

Finally boolean operations with object are available in Scribus. This is a long overdue feature that for some reason works only for shapes and polygons and doesn’t wish to know anything about Bezier paths. I don’t really know why — maybe it just doesn’t get the hang of unclosed shapes/paths.

The principle is dead easy. Let’s try to do a simple UFO picture. You draw two ellipses, align them and select:

Open the dialog:

Get your a unified editable image:

And if you really need a row of lights, this won’t be a problem too. Draw a circle and fill it with a white color. Inside the UFO draw a path of two nodes and bend it to follow the bottom side shape. Use the path along path effect, remove the leading bent path, then subtract the circles from the main UFO shape.

Three things I’d like to note on the functionality:

• In Scribus you can apply this effect to two objects only. In Inkscape you can at least unite and subtract any amount of objects.
• The Cut boolean op that in Inkscape is available from Path menu right next to other boolean ops is a separate tool in Scribus, discussed above.
• Scribus allows retaining copies of original objects after applying a boolean op, which Inkscape doesn’t do.

Create Path from Stroke

The name is self-explanatory, Unfortunately the released version is somewhat buggy. Let’s take a very simple object:

What we get is:

Now compare it to result of the same command in Inkscape:

Do you see the difference? Let’s zoom in:

Basically Scribus screwed inner angles. Also, both applications created an extra node on either side of an object, but in Inkscape those can be easily removed by pressing Ctrl+L to simplify a path, while Scribus sadly doesn’t have this feature. So it’s manual work again.

The bug was noticed too late and was fixed in 1.5.0 branch only. Hopefully the fix will be backported to 1.3.6. (20090817: the fix is backported to 1.3.6svn now)

Subdivide Path

If I didn’t see an extension with a similar name in Karbon and Inkscape, I would never guess what it does (creating more nodes while retaining original shape). Well, in fact it doesn’t do anything: I tried all combinations of objects and the menu item was still inactive. Hello, developers? :)

Quick summary

It’s very cool to finally have all of the described path tools, but generic tools to draw and edit Beziers paths have barely changed for last seven years. They are not really usable much — the Bezier path drawing tool alone acts differently from everything I used on Linux and Windows. It would be lovely to have these tools "copied" from Inkscape where they do shine.

Improved multilanguage support

Two main changes here.

First of all, you can now manage exceptions and ignored words for hyphenation for each language (the list of words is shared between languages). This is quite important, because hyphenation tables shipped with Scribus are not really perfect.

Secondly, Scribus features sipellchekeng at last, using Aspell dictionaries. It’s quite clear that in an ideal world all texts should be proofread in text editors abd typesetting should be something that is done to a perfectly correct text. In reality, however, it is often the case that section editor of a magazine applies hotfixes to text to fit it to a page. So in such cases spellchecking will make proofreader’s life a little easier. The dialog is activated by pressing F7 or choosing Item > Spell Checker menu item, which means: you need a text frame selected.

Typography

Earlier hanging punctuation worked for the right border only or none. Now you can choose between just left side, just right side, both or none.

Besides, in the new version of the app you can define the vertical offset of a first line in a paragraph by either calculating it from maximum height of used glyphs in a font file, or maximum height of all glyphs in a font file or just using an already defined line spacing.

EPS and AI as swatches

Importing EPS and AI files as swatches actually means that you can easily enable Pantone color palettes in Scribus. This is how you do it:

• Register at Pantone web site.
• Download swatches installation package.
• Install it (using WINE on Linux — it does work). Just installing EPS files will be sufficient.
• Go to Edit > Colors.
• Click Import button.
• Point to a EPS with a Pantone palette (inside ~/.wine/dosdevices/c:/Program\ Files/PANTONE(R\) color bridge(TM)/ for me on Linux).

Here is what you see in the end:

Various user interface improvements

I’ll just list them as well:

• Optional use of smaller widgets in palettes (a checkbox on General page of Preferences dialog). You really want this enabled, trust me.
• More verbose information on changes in the Action History dialog.
• A long anticipated page navigation by dragging with middle mouse button.
• Grouped text frame options in the Properties palette.
• A much better Guides Manager.
• A new dialog that allows parametric insertion of text and image frames.
• Align and Distribute dialog now handles guides and can swap selected objects (a feature reported as being unique among DTP tools).
• Print Preview dialog now displays ink coverage.

Shortly before releasing 1.3.5 Pierre Marchand started working on modularization of the Properties palette. The work on that was supposed to be started back in 2005 or so, but it’s only now, and the changes will be available in v1.5.0.

New and improved import/export filters

PDF

I’d pick out three significant changes (there are many smaller ones, plus refactoring of source code).

• Scribus now embeds subset of glyphs as Type3 fonts, not just as paths. Developers say that they can implement embedding them as CFF later.
• Several bugs related to exporting text on path were fixed.
• A cherry on the cake: PDF and EPS files can be embedded into PDF as is. This new feature is considered experimental (the checkbox says exactly that, in all caps), because, e.g. mixing RGB and CMYK images in such a file will result in disaster.

Of course, if you only need to convert JPEG to PDF, there are much more suitable tools for that. But then you are probably not DTP user.

SVG

Judging by bugs tracker a dozen of bugs were fixed, the most significant of them — incorrect import of drawings that contain text. I reckon, when it comes to supporting OpenRaster, it will be difficult for developers to neglect support for SVG Filters :)

AI (Adobe Illustrator)

You don’t really need introduction to this file format, do you? So, PDF based AI files (v9 and above) are supported only, and without proprietary bits, that is — only files that were save in AI with "Create PDF Compatible File" checkbox enabled will be read. This is why 1.3.5 now has a dependency for PoDoFo library. I have to note here that even though Scribus will ask for fonts substitution where required it still will outline glyphs, so no text will be editable. This is what will happen to all the rest vector file formats except SVG. On the other hand, Scribus preserves color space:

Windows Meta File

The old not-so-good file format that is so roughly supported in all existing applications including Microsoft’s one while Microsoft actually invented WMF. I tested this import filter on both "real-world" clipart I have around from prehistoric age (20th century that is) and a test suite created by sK1 team. Only a couple of most cunning files from the test suite didn’t render at all, and the rest of them rendered without any visible bugs, so it looks like you won’t have a lot of issues with artistic legacy. However I’d spare some time to do a really good test.

XFig

This application and file format are well known to UNIX programmers and engineers and absolutely unknown to Windows and Mac users. You will appreciate the new import filter only if you have a lot of legacy illustrations in .fig files or if you are actually a UNIX programmer or engineer and you don’t need Unicode text input. The filter was added simply because one of developers had a bunch of these files around and the file format was easy to parse.

As a matter of fact Xfig has some drawing related functions unmatched in Inkscape and Dia, so don’t wonder if you find some .fig files in your system (libboost has them, for instance).

Dia and Kivio stencils

Scribus can import stencils (shape primitives) from open source flowcharting/diagramming tools Dia and Kivio. The support was implemented just for fun as well (well, what isn’t? :)).

Documentation

The documentation is basically the same. The only significant change is a quick start guide available now inside Scribus Basics section and a chapter on render frames. On the other hand, there is now a complete user manual in English written by developers.

The versioning craze

So we have now 1.3.3.x versions, 1.3.5 and both 1.3.6 and 1.5.0 mentioned. And how does one possibly figure out what is stable and what isn’t? Here is how:

• Officially stable 1.3.3.x. Recommended for production by developers, based on Qt3, no new functionality. Advantages: Just Works, has a complete user guide. Disadvantages: unbearably slow, is missing a lot of useful features that simplify workflow a lot or improve output quality (crop marks, symbol styles, hanging punctuation etc.).
• Officially unstable 1.3.5. Pros and cons are mostly described above. This version works quite reliably if you know what you do (and you should always know what you do in prepress). However if you decide to try moving to it, you really need to try a lot of your files through the whole workflow and do a number of hard proofs before your do the final transition. This development branch will eventually stabilize (v1.3.6) and become a new recommended stable version (v1.4.0), while 1.3.3.? will be declared orphaned.
• Officially unstable 1.5.0. No released versions yet, and SVN builds are a can of worms. Work on that branch was started right after publishing the first release candidate for 1.3.5 back in April 2009. Will eventually become 2.0.

Google Summer of Code 2009

This is the third time Scribus participates at the annual Google Summer of Code program. This year:

• Exporting to PDF/X-1a & PDF/X-4, better PDF-to-PDF embedding, better fonts subsetting.
• New Search and Replace dialog, using regular expressions too.

Another person is working on importing XTG (QuarkXPress tags) files.

The code will be part of 1.5-2.0 versions.

Conclusion

In my opinion this new version perfectly illustrates how difficult it is to maintain a large project: any rewrites can postpone releasing for years. The fact that Scribus developers are doomed to be perfectionists (because PDF output errors equal to financial losses by users) only adds up to this.

During Libre Graphics Meeting 2009 Andreas Vox named four main ways to further improve Scribus and explained of of them in details — a better file format. You can actually watch the video.

Well, to me a new file format (especially its text markup related part) is quite important, but not most important. Scribus has already become a production ready desktop publishing tool de-facto used to create books, full-colour magazines etc. Some works even win prizes. To make it work more or less on par with InDesign, which is currently state of the art app in DTP, the following tasks should be accomplished:

• Better accessibility from keyboard.
• Automation of accomplishing typical tasks, such as adding footnotes, syncing frames (e.g. a sidebar frame connected to a paragraph) etc.
• Sane drawing tools — it still feels a whole lot easier to draw a layout in Inkscape and import it to Scribus; this practice simply should stop.
• Simpler work on complex structured documents.
• Fully functional undo/redo.
• Advanced OpenType support.

This list is quite subjective. Everyone has his own priorities after all.

What I’d love to say in the end is: Scribus belongs to a kind of complex applications that are full of hi-end math and suppose that users think hard about what they do with an app. Existence of such free/libre applications (e.g. Ardour, the digital audio workstation, or GRASS, the geographic information system) means that free software can go far beyond beeing a toy up to being a tool. But this, in return, means a crash test for actual developers: they are expected (and often demanded) to do exactly (and more than) what a larger number of highly paid proprietary software developers do.

You have to agree that one needs a backbone and a unique mix of stubbornness, curiosity and ability to share to work on such projects in spare time and actually achieve success. And even though work on free software is mostly started from "I wonder, what if…" said by a curious to-be-developer, it progresses over the years mostly with the magic words "thank you" coming from end-users. So what I’d really love you to do is give a big virtual hug to Scribus developers.

Now, if it is the language of money that you speak better, a rare free software developer will refuse to accept donations. Even though Libre Graphcis Meeting 2010 is nine months away, it’s never too early to start financing it.