Separate OpenType features from font configuration

[zeneto]

Since LO 5.3, we can use OpenType features (like smcpor onum) when configuring the font. This is done by adding feature codes to the name of the font in LO dialogs (as this guide explains).

Problem is: this approach locks the OpenType configuration to the font configuration, making character styles a mess.

Example: I want to make a character style, say, Small Caps, which makes real smallcaps (not fake ones like LO default) by using smcp OpenType feature. Because smcp needs to be added to font configuration, I have to select a font to the style, but this character style should not carry any font configuration, because it could be applied to text in any font. It should carry only the smcp feature.

Suggestion: In LO dialogs, separate “font” and “smart font codes” configuration (I use “smart font” because these codes are also used for Graphite technology). With this separation, character styles could use smart font features reasonably.

[dajare]

I was thrilled when OpenType support came to LibO! I can understand the impulse behind the question. But: (1) feature requests are off-topic here; (2) Not every/any font actually supports smcp (or bold, etc., for that matter). My templates/styles all have fonts specified in any case – not the case for you, then?

[ajlittoz]

I think the argument makes sense, even if the parameter name like smcp differs from font to font. The argument is in line with the concept of styles, notably character styles, and should be strongly highlighted in the feature request.

[dajare]

And, before logging a feature request, OP should probably read through fdo#58941 for the lengthy comments about the problem of UI for supporting OpenType features. | @zeneto - you might also be interested in the Typography Toolbar extension which isn’t exactly what you want – but it works in LibO Writer 6.0+ (still) (at least on Ubuntu!) and might be some use: you can toggle OpenType features on any font from the toolbar.

[zeneto]

That extension addresses a different problem: toggle OpenType features from toolbar (as you said). Problem here is toggle OpenType features “structurally”, via styles, separately from font. I thought this could be done without changing ODF, but thinking and reading more I see I was wrong: to persist OpenType feature separately from font configuration, an ODF change is needed (in fdo#58941 someone pointed this in ODF 1.3 discussion…)

[zeneto]

My point here was a minimal change in LO to improve OpenType handling via styles. But, as I pointed out, a “minimal” solution doesn’t seem to be possible.

[LibreTraining]

Not a good idea to separate these OpenType feature settings from the underlying font.
It would just create confusion when nothing happens because the font does not support the feature.

The best interface I have seen for OpenType support is in QuarkXpress.
The OpenType features are usually hidden and are accessed from a spinner.
The application actually reads the font file and only activates the available features.
Unavailable features are grayed-out.
So the user knows what is available.

Example for Minion Pro

Example for Liberation Sans

[ajlittoz]

I understand your concern about “no-op” if the feature is absent. That sounds reasonable for user-friendliness or from developer point of view. However, from a power-user point of view, all these effects should be available through character styles, just as bold presently is. This leads “naturally” to OP’s request. Of course, the risk of “no-op” remains with its user confusion.