Specification of OpenType features in child styles

Hi all,

I do some professional typesetting, and work with documents that often use more than a hundred styles, many of them children styles, or grandchildren. Many use OpenType features.

One of the odd sticking points in LO Writer is that its OpenType features are specified right with the fonts: for example, “Warnock Pro Caption Light:onum&pnum”. I’ve read a lot about why LO needs to work this way, and I’ve got no problem with it. (I do a little programming too, so when the developers say “This is how the rendering engine needs information passed to it,” I respect that.)

I do, however, have a problem with what this does to style setup. If I create a child style that uses small caps or tabular numerals, and then later change the parent style’s font, I have to change the font in the child style too, even though that shouldn’t be necessary. For one style it’s not a big deal. But in typographically complex documents like the ones I work on, it causes some big hang-ups and possibly some design flaws.

Is there any solution to this? If not, I can’t be the only one who considers it a feature request. If LO needs to have its font information passed to its renderer as “fontname:otfeature1&otfeature2&…”, that’s fine; it seems those strings might be able to be “assembled under the hood” before being passed on, and font choice be allowed to stick from parent to child style, separate from OpenType features. I’m surprised to only find one forum topic on the issue, from five years ago, and there isn’t much there… what’s new?

Works for me in LO under Fedora 38.

Note that inheritance is rather tricky. There is a shortcoming in the style configuration dialog: it can’t visually show “transparent” state of any attribute, i.e. when the attribute gets its value from the parent style. Don’t trust a value identical to the parent: if you ever modified the parameter then explicitly set it to the same vamue as in the parent, it is still an override. When you change the value in the parent, the override will prevent any change.

The only way to revert to “transparent” (=inherit) state is to press Reset to Parent. This flushes all attributes in the tab. Consequently you have to force again those which were intentionally changed.

From my experience with styling, if you need so many styles, you have not abstracted enough the structure of your document. With complex documents, you should make do with ~20 paragraph styles, 10-20 character styles, less than 5 frame styles, perhaps 2 list styles. The number of pages styles is harder to estimate because in the most complex case, you need 3 styles (first, left and right) per part. My sophisticated documents use ~15 but this is not an issue because most of them are automatically applied as parameters in Text Flow properties of paragraph styles.

The best approach to styling is semantic styling. Styles don’t designate the visual effects you expect (“artistic approach” leading to excessive number of styles) but are meta-annotations in the text. Style names reflects author’s significance of paragraphs, words, … or their importance in the development of the argumentation. There are not hundreds of different semantic values in any text. If you have 10, this is already a difficult text to understand from a linguistic point of view. Of course, you need to duplicate these values in paragraph and character styles because a word in a paragraph may stand out of its context (different expressiveness of the word compared to the paragraph).

As an example of this meta-annotation, take headings. They are traditionally styled Heading n which don’t tell anything about font face, size, spacing. The paragraph is just flagged as part of the document outline which will allow to do “interesting” things with these paragraphs, such as collecting them in a TOC.

Of course, I don’t count the Heading n family in the 10 semantic values I mentioned above, otherwise I must double the figure.

Once you have defined your semantics-driven styles, you give them distinctive typographical attributes so that you hint the reader about author’s message.

Take inspiration on built-in styles: their names suggest usage:

  • Heading n for outline, Title and Subtitle
  • Text Body for discourse
  • Numbering n for numbered lists (need customisation)
  • Header and Footer
  • Footnotes
  • Emphasis and Strong Emphasis usually italic and bold respectively
  • Definition, Example
  • First Page for cover page

Except perhaps for Landscape, they never allude to their visual settings. They already define an intent.

The advantage of the semantic approach is to allow to change in a single operation the appearance of all “objects” belonging to the same semantic class.


On the tab ‘Organizer’ it is showed under ‘Contains’ what is customized in the style

1 Like

ajlittoz, I really appreciate your thorough answer! I’m very familiar with semantic styling – it’s just that the documents I do have many required typographic nuances, such as children of headers with different leading specified, or different letterspacing options among small caps.

The first part of your post gets the closest to the problem I’m having, and I hope other readers take it seriously: the lack of visible changes to a child style is a problem in itself. Scribus solves this by bolding the names of edited values in child styles, so when a parameter’s been changed, you can tell – even if it happens to have the same value as its parent. It’s a nice feature.

To all readers: The problem I’m having is that LO does not separate font name from OpenType feature specifications in its interface, forcing anybody using child or grandchild styles to specify the font again if the child style is just a feature change – which therefore makes changing the entire typeface of a document a big problem requiring a lot of repetitive steps. (If I change from Warnock to Freight, but my child styles require small caps or lining numerals, I have to go into every child style that specifies something like this and change the font to Freight there too. If I miss one, my clients will discover it.)

Most of the discussion on the Web about this has focused on how LibreOffice needs font strings to read Fontname:OpenTypefeatures. I propose we get past this stumbling block by introducing a feature in the Style Configuration dialogue that allows us to specify font separately from OpenType features; LO could concatenate the strings needed to render fonts “behind the scenes,” “under the hood.” That way I could make a child style that 1) specifies, say, only small-caps, 2) change the font of the parent style, and 3) see the child style work without having to edit it.

I see a difficulty in your proposal: fonts don’t use the same “keyword” for a designated OpenType feature. I don’t think there is a standard for feature naming or, rather, I’m not aware of such.

I have experimented again and this is where the “trickiness” in style configuration comes in.

In the child style, use the Featurebutton to set the OpenType attributes. If you enter them directly into the font name entry box, you simultaneously create an override for the font. You lose.

When you use this Feature button, changing the font in the parent style will propagate to the child. However, this does not work for the OpenType features. The string added to the font name (which is what is passed to the font renderer) is taken as a whole. I.e. it is a complete override per se; it does not work feature per feature.

As an example, I played with Text Body and Text Body Indent which a child of the former. I set Liberation Serif in Text Body. I only added OT features in Text Body Indent. Then I changed for Free Serif in Text Body. This propagated to Text Body Indent which kept its previous OT features which don’t make sense with Free Serif. I added non-conflicting OT features in Text Body and they were not propagated to the child.

Conclusion: there is still a lot of work to do.

1 Like

Exactly – you’ve hit the nail on the head.

The string added to the font name (which is what is passed to the font renderer) is taken as a whole. I.e. it is a complete override per se; it does not work feature per feature.

This is exactly the problem. And, as you saw when you tried it, using the Feature button is no different than typing them in directly. It’s just a UI feature that assembles strings.

I remember before the developers added a Feature button, and typing the features in was the only way to do it. Now, though, we have a Feature button. Is it very much different to add the functionality I’m trying to figure out?

By the way, not just for ajlittoz but for anyone reading, there is a standard for many – at least the most common – OpenType feature keywords. Microsoft publishes it here, and Adobe has a reference page on using them in CSS here.

Not exactly. It is very subtle. If I type the arguments directly at end of font name, I can no longer inherit the font face from the parent.

Oh, my mistake. It sounds like you can get font changes in parents to appear in children styles without overriding the children’s OT specifications. That’s exactly what I’m looking for to happen! I’ll have to try this out in Windows when I’m back at my Windows computer. Maybe this is a platform issue.

And yes, the Features dialogue shouldn’t cause trouble between parents and children.

Update for any readers:

I don’t know how ajlittoz did it – maybe this is a platform-specific issue. On Mac OS X and LO Writer, setting OT features using the Features dialogue is no different from typing them directly into the font box; both ways seem to function identically, appending the OT feature calls to the font name. Altering the font of a parent style once a child has OT features specified does not result in the new font appearing in the child style – the child style keeps the font that it was inheriting at the time the user picks the OT features, even if the user never selects anything else in the Font tab besides OT features.

When I get back to my Windows machine I’ll try it there too, but this is the behavior I’ve always seen…

Is anybody else facing this problem?