Jump to content
wlb

Publisher: Font style hierarchy broken

Recommended Posts

[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.

 

Screen Shot 2020-08-12 at 23.27.23.png

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.


Affinity Photo 1.9.2, Affinity Designer 1.9.2, Affinity Publisher 1.9.2;  2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.9.1.225 & Affinity Designer 1.9.1 (showing 1.9.7) for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 14.4 (18D52)

Share this post


Link to post
Share on other sites

[Even if not directly related to the topic] I think that current versions of Affinity apps (at least Publisher) have errors in applying styling attributes "Italic" and "Bold".

E.g., for Adobe Jenson Pro Light, when using the menu styling attribute "Italic" (= "I" button, or shortcut Ctrl + I) should change the "regular" member (=Light in this case) to Adobe Jenson Pro Light Italic (which it does), and when using the "Bold" attribute (= "B" button, or shortcut Ctrl + B) should change to logical bold menu member, which should be Adobe Jenson Pro Semibold (and Semibold Italic, when both "B" and "I" are applied) -- and not Adobe Jenson Pro Bold (and Bold Italic), which is what Affinity apps now seem to do.

fontstylings.jpg.e81ae03192f79892a752e044659ed9a2.jpg

I did not check whether this is broken on Windows only, and only checked a few cases (Adobe Jenson Pro, Source Sans, Helvetica Neue, and a few more). All the checked fonts operate correctly e.g. in InDesign and CorelDRAW. 

I am not sure if this is a new error or something introduced in one of the recent versions, but it is a serious flaw [and I think that this worked correctly sometimes earlier].

 

UPDATE: I checked this now on macOS and the same error is there, and also in version 1.8.3 (Publisher), so I must have just missed this: it does not seem that this has ever worked correctly in Affinity apps. I also checked that the error happens in all (at least Windows versions of the) Affinity apps. On macOS it seems that very few apps can read properly Font Style Group attribute -- even in OpenType metadata (I am not sure if it is available in legacy fonts on macOS). QuarkXPress (2018) cannot, nor can Pages. Pages at least resets the "regular" style correctly to the "regular" family member used in other parts of the same font family, so fonts are not randomly changed whenever the user presses Cmd + B twice. And I mean randomly. On Windows wrongly emboldened Jenson Light is "changed back" to actual Regular style, while on macOS it is reverted to "Caption".

594296382_Screenshot2020-08-13at15_11_24.png.a1a55a770561d10ed27b30e14fcf50b1.png

Share this post


Link to post
Share on other sites
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."

 

Share this post


Link to post
Share on other sites
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.


macOS 10.14.6, Macbook Pro Retina 15" + Eizo 27" // Affinity preferred in Separated Mode + Merged Windows

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?


macOS 10.14.6, Macbook Pro Retina 15" + Eizo 27" // Affinity preferred in Separated Mode + Merged Windows

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
17 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, 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.

As picked from FontLab (these are from Adobe FontFolio 11.1):

Avenir LT Std 35 Light = 300 (Weight class = Light)
Avenir LT Std 45 Book = 350 (Weight class = Light)
Avenir LT Std 55 Roman = 400 (Weight class = Normal)
Avenir LT Std 65 Medium = 550 (Weight class = Medium)
Avenir LT Std 85 Heavy = 700 (Weight class = Bold)
Avenir LT Std 95 Black = 750 (Weight class = Bold)

I think that width and weight classes are just another means of getting (as close as possible) match when changing styles. Affinity Publisher has a pretty strong set of choices for style mapping as in addition to width and weight based mapping, they provide the standard name-based definitions, and logical mappings like "Italic".

But what I am personally missing are solid tools for conflict handling and visual indicators showing failed style mappings, because I think that conflicts are inevitable, and there is no way of creating a fully logical and mappable style collection if a job is complex enough to require multiple styles.

A simple example:

a) Style change (body text font changed from Adobe Jenson Pro to Meta OT) done in InDesign: no character styles involved but all conflicts (failures to remap styles) are clearly shown, not just in the user interface but as missing styles shown in brackets and fully searchable and remappable not only by Find & Replace but also with Find Fonts utility and within style definition dialog boxes. User intervention is clearly required but tools for resolving the conflicts are strong. 

stylechange_id.jpg.ebbcaf01d6ddc0474ea073478bcf4a63.jpg

b) The same done in QuarkXPress 2018: as I do not know this app well I am not sure if there are means to visually show mapping problems, but failed mappings are shown in font usage, and shown with warning signs and empty style names whenever a problematic text styling gets a focus.

stylechange_qxp.jpg.4ee3f3108356fb52b57094c0a89338e3.jpg

c) The same done in Affinity Publisher: no visual signs of conflicts, even if there are wrong and illogical mappings and local styles lost for good (as they were not fixed with character styles specifying directly the font names). The only way the user can deduce that mappings have failed is noting that style definitions are in conflict with visual outlook, without any “plus” signs or other conflict indicators in the UI. You would not get warnings of unavailable fonts (and accordingly help from font mapping utility) because styles have been mapped to existing installed fonts.

stylechange_apub.jpg.5990e54f96e91ace985ba84738edcd74.jpg

Personally I would rather take the nuisance of getting warnings, visual indicators requiring user intervention, and effective tools for conflict handling rather than a complex system which attempts at fully logical and automated remapping of styles, but I can understand that many users prefer attempt at automation. But considering that creating a fully cascading and logical and mappable style definitions can be a very complex job, I am not sure user-friendliness and ease of use are proper terms to describe what is tried to be achieved here...

But it is also a matter of changing work methods so securing local formatting with character styles (with specific font names) is more or less a necessity in Affinity Publisher to avoid loss of local formatting in context of style (re)definitions, as this is often not necessary when working with apps like InDesign or QuarkXPress.

Share this post


Link to post
Share on other sites
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.

 


-- Walt

Windows 10 Home, version 20H2 (19042.685),
   Desktop: 16GB memory, Intel Core i7-6700K @ 4.00GHz, GeForce GTX 970
   Laptop (2021-04-06):  32GB memory, Intel Core i7-10750H @ 2.60GHz
, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU
Affinity Photo 1.9.2.1035 and 1.9.2.1005 Beta   / Affinity Designer 1.9.2.1035 and 1.9.2.1005 Beta  / Affinity Publisher 1.9.2.1035 and 1.9.2.1024 Beta

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...

Important Information

Please note there is currently a delay in replying to some post. See pinned thread in the Questions forum. These are the Terms of Use you will be asked to agree to if you join the forum. | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.