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 🙂