Publisher: Font style hierarchy broken

[wlb]

[Affinity Publisher 1.8.4 on MacOS]

I'm trying to set up hierarchical ("Based on") text styles for a book I am designing. But the behaviour of the Font settings is preventing it from working correctly.

When editing the Font settings of a text style "Based on" another style:

•  Font family defaults to "[No change]" (perfect for hierarchical styles), but
•  Font traits (Italic, etc.) is disabled. (See screenshot attached.)

For example, my "Based on" style is in Garamond, and I just want to create a style for Italic. I should be able to simply change the Font traits to "Italic". But the only way to enable the Font traits (so I can choose Italic), is to hard-select Font family: Garamond, then choose Font traits: Italic. Of course that works, but it breaks the cascading hierarchical style. If I later change my "Based on" style to Jenson, the lower-level style remains hard-selected to Garamond.

Is this a bug, or is there some good reason for this behaviour? Am I doing something wrong?

Thanks for any help you can offer.

 

[sfriedberg]

I'm not sure what Affinity is trying to do here.  If you do specify a font family, the Font traits dropdown will be populated with a list of weight/width/italic combinations.  But these choices are almost exactly what you can get with an inherited font family, using the Font weight and Font width dropdowns and the Italic checkbox.  I suspect, but have not confirmed, that if your font family has other "styles" besides roman and italic (as with many decorative and layered fonts) that these will show up in the Font weight dropdown.

Anyway, you can probably get exactly what you want, defining a new paragraph style with an inherited font family but a font style override, by ignoring the Font traits dropdown, and using the Font weight and Font width dropdowns and the Italic checkbox.

[R C-R]

1 hour ago, wlb said:

I should be able to simply change the Font traits to "Italic". But the only way to enable the Font traits (so I can choose Italic), is to hard-select Font family: Garamond, then choose Font traits: Italic.

I have only recently started learning how to use font styles so I may have this totally wrong but from what I can tell, when Font family is set to [No change] so Font traits is greyed out, then Italic is not greyed out. Its checkbox can then be toggled cyclically among three states, Italic: On, italic: Off, & (apparently) no change, with the dash in the checkbox indicating the 'no change' setting.

I say apparently because in the Styles settings text at the bottom of the window the "Italic:" text, otherwise set to "On" or "Off" is deleted. I have no idea why it is implemented this way or why there are not similar checkboxes for bold & bold italic.

As a side note, since some fonts do not have an italic version, the Italic: On setting won't have any effect if applied to them.

[lacerto]

(...)

[wlb]

9 hours ago, sfriedberg said:

"Font weight" presents a generic list of "weights". The list is not derived from the [No change] font, and the weights may or may not map directly to a given font. Adobe Garamond Pro has no "Thin", "Extra Light", "Light", "Medium" (for that matter), "Extra Bold", or "Black". If you select one of those, it has no effect. So you have to guess, or hope that Publisher will map to the right font.

The "Italic" checkbox seems to work, but again, you have to hope the mapping is correct.

It all feels like an extra unnecessary layer of uncertainty between me and my fonts. I would prefer to know that I'm selecting the font I want to use. Period.

But thank you for the tip. At least I can probably get the hierarchies to work by adapting to this convoluted way of doing things.

 

9 hours ago, sfriedberg said:

"Anyway, you can probably get exactly what you want, defining a new paragraph style with an inherited font family but a font style override, by ignoring the Font traits dropdown, and using the Font weight and Font width dropdowns and the Italic checkbox."

 

[thomaso]

17 hours ago, wlb said:

For example, my "Based on" style is in Garamond, and I just want to create a style for Italic. I should be able to simply change the Font traits to "Italic". But the only way to enable the Font traits (so I can choose Italic), is to hard-select Font family: Garamond, then choose Font traits: Italic. Of course that works, but it breaks the cascading hierarchical style. If I later change my "Based on" style to Jenson, the lower-level style remains hard-selected to Garamond.

Is this a bug, or is there some good reason for this behaviour?

In my understanding it is no bug but a feature of care. The good reason is related to the fact that the available Font traits always are related to their Family – and just unknown without a family. Not every font family offers the same traits, so if you would define your style with a certain trait that doesn't exist any more as soon you change the family then this should have to cause a conflict. The Affinity decision was obviously to prevent this conflict in advance. (yes, another approach would be to pop-up a warning message as soon a conflicting user setting occurs – but this might be annoying, too, and a new field for errors.)

Even with "simple" and quite usual traits it can become conflicting, for instance if one family has a trait named "regular" while the other has one only named "normal". For us users the difference might not matter much but for a software algorithm it can get hard to judge whether "regular" = "normal" or if "italic" = "kursiv" or "condensed" = "narrow", not to mention bold, fett, heavy etc. It's just that font trait naming isn't standardised.

[wlb]

2 hours ago, thomaso said:

Even with "simple" and quite usual traits it can become conflicting, for instance if one family has a trait named "regular" while the other has one only named "normal". For us users the difference might not matter much but for a software algorithm it can get hard to judge whether "regular" = "normal" or if "italic" = "kursiv" or "condensed" = "narrow", not to mention bold, fett, heavy etc. It's just that font trait naming isn't standardised.

That is exactly the point for me.

For an extreme example, with the font Avenir, the "Font traits" (= actual font name) for the Avenir "Font family" are: Light, Light Oblique, Book, Book Oblique, Roman, Medium, Medium Oblique, Black, Black Oblique, Heavy, and Heavy Oblique. If I explicitly specify the Avenir Font Family, then "Font traits" is quickly and correctly populated with these font names.

But if I select "[No change]" hoping to build a reliable style hierarchy using the actual fonts that I've explicitly activated for the purpose, I'm presented with the following so-called "Font weights": Thin, Extra-Light, Light, Normal, Medium, Semi-bold, Bold, Extra-bold, and Black! No correspondence whatever. Font weights has no relevance for this font.

Ok. Oblique probably maps to the Italic checkbox. But how is anyone to know how Publisher maps these weights to the actual fonts? Normal could easily be either Avenir Roman or Medium. Since Avenir Book is lighter than Avenir Roman, will that be mapped to Light? And actual Light mapped to Thin? Who even decides this?

The only way I can be sure I am using the font I want is to explicitly specify the font family, and that immediately breaks the cascading hierarchy of styles.

Perhaps this does protect an inexperienced user from messing up their document. But a professional should be able to manage these risks. Please let me break my own hierarchical styles if I foolishly change the Font family from Avenir to Garamond in Base.

I know this sounds like I'm 🤯 (I am), but I'm still 😍 with Affinity.

I'm doing my first full book project in Publisher, as an attempt to leave InDesign behind. I'm learning the Affinity way as I go along, but I'm also encountering baffling software design choices. As a new (but experienced) user, I hope that these descriptions of my pain points might be helpful for the developers that have put together this amazing set of applications.

Maybe I'm still not understanding something. But thanks for listening.

[wlb]

3 hours ago, thomaso said:

In my understanding it is no bug but a feature of care. The good reason is related to the fact that the available Font traits always are related to their Family – and just unknown without a family. Not every font family offers the same traits, so if you would define your style with a certain trait that doesn't exist any more as soon you change the family then this should have to cause a conflict.

The so-called "Font traits" are not really "traits". They are actually the names of the active fonts in the Font family. From what I have seen, it is nothing more than that.

[thomaso]

19 minutes ago, wlb said:

But if I select "[No change]" hoping to build a reliable style hierarchy using the actual fonts that I've explicitly activated for the purpose, I'm presented with the following so-called "Font weights": Thin, Extra-Light, Light, Normal, Medium, Semi-bold, Bold, Extra-bold, and Black! No correspondence whatever. Font weights has no relevance for this font.

(Actually I don't know what "font traits" means, so I only see/judge its menu). I assume the "Font weights" will cause a simulated look whereas "Font traits" use + display the really existing weights: Only the latter have according files for the font (what you detect as "names"). That's why, as mentioned before, Affinity appears to prevent you in purpose from selecting a trait unless it knows a family – no trait without family – to avoid conflicts, which might begin when you change the 'parent' style's family, which possibly doesn't have the according trait you had set before in its 'child' style.

In your initial post you mentioned explicit "italic". Did you follow the hints of R C-R and tried using the "italic" checkbox instead, not the menu?

[Fixx]

I wish Publisher can handle basic traits (I have not really checked if there are problems and how often). But also in InDesign bold/italic handling often breaks when function should be clearcut.

[lacerto]

(...)

[walt.farrell]

7 hours ago, wlb said:

But if I select "[No change]" hoping to build a reliable style hierarchy using the actual fonts that I've explicitly activated for the purpose,

In general you cannot implement something like that (in any application) because there is no way to ensure that the new font you choose for the top level in the hierarchy will have the traits you specified in the lower levels. Changing the font at the top level requires reviewing all the lower levels to determine if they are set correctly and will work as you expect. Serif has merely chosen to make that review explicitly required, by not allowing you to specify the traits unless you also specify the font.

 

[Fixx]

20 hours ago, walt.farrell said:

In general you cannot implement something like that (in any application) because there is no way to ensure that the new font you choose for the top level in the hierarchy will have the traits you specified in the lower levels.

You can but you cannot be sure it catches all traits in given font. Usually this is solved by marking problem parts with hilight colour and opening font replacement dialog (it also can be saved to font manager window for later solving). That behaviour is ok and useful.

[sfriedberg]

Heh, I just ran into a variation on this problem over the weekend.  Two fonts from the same foundry are organized into font families in radically different ways.  Foundry S-Core, fonts Core Sans N and Core Serif N.  There are about 7 weights of each, both roman and italic.  One font is sorted into a single family with all weights.  The other is sorted into many two-font families, each for one weight with roman and italic.  The latter organization makes it impossible to get a bold without specifying a different family explicitly.