November 2006


One of the oldest feature requests for Scribus have been character styles and hierarchical styles. These are now finally implemented in Scribus 1.3.4cvs. Also Tsoots has done some good work on the new Style Manager, which replaces the old Paragraph Styles dialog, and he will hopefully describe it in a blog entry soon. I’ll take some time here to explain the new concepts behind styles.
Before 1.3.4 there were only named styles for paragraphs and direct fromatting for character styles. Now there are named styles for both paragraph styles and charstyles; and also direct formatting for paragraph styles and charstyles (Yes, this means you finally don’t have to define a new paragraph style if you just want to change the margins for one paragraph).

In the following I’ll describe the logic behind hierarchical styles as it is implemented in Scribus 1.3.4. Paragraph styles, charstyles and line styles behave much the same in this respect. Also other styles which are implemented in the future will share this behaviour. I’ll use paragraph styles as an example in this explanation.

What does “hierarchical” style mean? It means that each style does not just define a bunch of attributes, but also has a flag for each attribute which tells if it is defined in this style or inherited. So consider a style A has as parent a style B:

Style A Style B
parent: “B” parent: “”
font: “Courier” defined font: “Palatino” defined
fontsize: “12” inherited fontsize: “12” defined
color: “black” inherited color: “black” defined

If you now format some text with style A, it will take the attributes (“Courier”, 12, black). If you change the fontsize of style B, then style A will automatically pick up the new fontsize. On the other hand, changing the font from “Palatino” to “Times” will not affect style A.
The new stylemanager displays attributes in bold if they are defined locally and in regular font if they are inherited.
It’s also possible to have chains of inheritance, eg. A has parent B, B has parent C, and so on. Only cycles are not allowed.

So what about direct formatting? That is implemented as unnamed styles. I also call those “physical styles” and the named ones “logical styles”.
Physical styles are attached to some content, eg. a run of characters, a paragraph or a story (that’s the combined text of a chain of textframes).
A physical style can have a logical style as a parent and then inherits all attributes which are not set directly.

There’s not only a logical hierarchy but also a physical hierarchy of styles. The physical hierarchy depends on the nesting of elements, so a physical style will pick its attributes from character run, then paragraph, then story, then document. See figure for how those contexts are nested.

Figure: Nesting of contexts

nesting of contexts

So how do I know which attribute value ends up in the style I use? Well, it follows these rules:

1. if the attribute is locally defined (not inherited) in this style, the local value is taken.
2. if the style has a named style as parent, the attribute is searched in this named style(yellow line). If neither the named style nor its ancestors (red lines) define the attribute, go on with 3.
3. the attribute is searched in the next physical style in the hierarchy (follow blue lines). If it’s not defined in any of those styles, go to 4.
4. Use a compiled-in default value.

The documents default style will define all attributes, so rule 4. is never reached.

Ok, that’s all. Complicated? Probably, but I still hope you like it 🙂

One of our translators and contributors mentioned to me that they had comments to the effect that Scribus is a “closed shop”. In other words, the team is really not open to adding new developers and contributors. So let’s dispel that rumour right now.

It is not true. Not now, not before, never.

To an outsider, it might appear that way, but not by intent. The Scribus Team is probably a bit different than most in that we are a bit older, perhaps than the average OSS team. Several of us have a few grey hairs on top – but that is a Good Thing for many reasons. 🙂

Our experience in various parts of graphics and pre-press has given us a sense of direction about what not only Scribus needs, but what to avoid like faux bold and italic . Sometimes avoiding the same architectural and “feature” errors we’ve suffered as users in the past is just as important as ultra coding foo.

One other thing which is important to understand that we do work very harmoniously as a team. We share the same core values of respecting our users and each other’s unique talents and capabilities. We choose, compliments before criticism, cooperation instead of flaming and division. This, I think, is transmitted through in the way the community surrounding Scribus has grown. Note the lack of flame wars on our mail list. That is something I think we can be proud of and if we are protective of that – so be it.

However, get closer and you will see that Scribus is far from a “closed shop”. Surrounding the core team is a larger circle of folks whose contributions are not only valuable, but necessary. One look at Help > About, the mailing list or a look at the Wiki is evidence enough for me.

To the contrary, we do want more coders, more translators, more packagers and folks to help with testing bugs. Jump in! The water is just fine.