Assign multiple text styles

[DieterW]

I assume I understood everything correctly, except or one thing... The way text styles are handled in Publisher IMHO is not "affinity" at all (which means well-thought concepts from scratch normally).

I would urgently think assigning multiple styles to the same text is an intuitive and important feature. At least I constantly run into the same problem where I do not see any usable solution.

Let's assume I define multiple character styles for highlighting words (e.g. different colors, line styles, etc.; of course I uses styles as the colors may change later). Then I have multiples styles for different usages (normal text, smaller text, different font for usage in text boxes or tables, etc). But I would need the highlighting for all those styles as well. FULL STOP! How should I do this efficiently?

In my understanding Group styles are not efficient at all. To be honest I still do not understand the purpose of them. Why should I define a style which I cannot assign to text, but only base other styles on it, when I can base a style on a normal style as well (which - in addition - I CAN assign to text). So, in my understanding Group styles do have a major disadvantage, but no advantage.

So, the only solution I can think of using styles is to define the styles with most changes or which are more likely to change (e.g. for highlighting), then create a copy for each of them applying the smaller font size, then again for all of them with different font, etc., i.e. means I end multiplying the number of styles, and having the issue that I have to chance multiple styles if, for example, I want to use a different font for the tables. Na, that's not the way I want to work at all. And most important, that is not the way I want to work with an Affinity product (I mean if this would be MS, ok, I mean I would not expect any other, but this is not MS... yet (and hopefully never will be ;-)).

Feature Suggestion: Being able to assign multiple text styles (especially for character styles) to the same text. The order of assigning determines the finally applied effect if multiple assigned styles change the same style parameter. The later wins. Maybe this feature could be an option to be able to work like now, but being able to work in this way if the user prefers.

I am sorry, if this topic was already discussed somewhere. I could not find anything regarding this. And also if my assumption from the beginning is wrong and I totally misunderstood how styles work...

[MikeTO]

Supporting multiple character styles is complex for both the developer and user. I understand why you'd want it, it would be useful to me, too, but it muddies up the user experience so much that it's not a great idea.

It's easy if the styles are mutually exclusive, if they have no overlapping text attributes. But what should the app do if the first character style applied makes the text 12pt and the second makes the text 10pt? The only solution would be for the app to apply the style which occurs first but it would be confusing to the user to apply a 10pt style and have it not change the text size because there's already another character style applied to some or all of that text.

[walt.farrell]

8 minutes ago, MikeTO said:

But what should the app do if the first character style applied makes the text 12pt and the second makes the text 10pt? The only solution would be for the app to apply the style which occurs first but it would be confusing to the user to apply a 10pt style and have it not change the text size because there's already another character style applied to some or all of that text.

Yes, that would be confusing. Thus, it may be better to go with DieterW's suggestion above:

10 hours ago, DieterW said:

The order of assigning determines the finally applied effect if multiple assigned styles change the same style parameter. The later wins.

 

[MikeTO]

53 minutes ago, walt.farrell said:

Yes, that would be confusing. Thus, it may be better to go with DieterW's suggestion above:

You're right, that could work, it's how CSS works.

 

[garrettm30]

The skeptic in me does not see this happening, but I could really get behind it if it were. I really like the CSS approach where multiple rules can apply to the same element, and I can imagine something like multiple character styles applied to the same selection of characters. I would organize my styles differently than I do now, and although it would allow greater complexity, I also think in certain respects it would also make text styles more clean.

For example, in my present style sheets, I usually have character styles for bold, italic, and underline, as well as the various combinations thereof. It takes seven different sometimes-nested character styles, where if it were like CSS it would only be three characters styles that could be mixed. And presently, if I need to change something about italic, I have two styles to edit; if I change something about underline, I have four styles to edit. 

 

Should Serif ever consider something like this, I think it could be implemented without harming the existing systems: just because styles could be compounded do not mean that they have to, so people who want to still use them like the current system would stil be able to.

Note that for my part I am not really recommending a full CSS approach; just the cascading aspect. It would still be different CSS in these areas:

1. It would still use the basic UI of the Text Style studio rather than written stylesheets (I would actually use the stylesheets if it were possible; but I suspect it would not be a good fit for the average user in this particular target audience).
2. The selector concept of CSS would have no place here: we should still apply styles by selecting directly and applying styles as we do now.
3. The sometimes complex rules of precedence in CSS would be overkill here. Probably just the basic concept of the order in the studio would be all that is needed. I personally don't care whether lower styles takes precedence (as in CSS) or if it is reversed, so that the highest priority are those at the top of the list. I would adapt either way.

[DieterW]

Actually I already made the suggestion (cannot find the post though) a long time ago to implement CSS functionality, as this is a well thought, widely known and all-you'll-ever-need concept. Maybe this was a bit too ambitious, at least it was completely ignored 😉. But nevertheless it would be a good idea to follow the CSS principles here too.

The basis is already there: If you apply a combination of paragraph/character style/local format Publisher shows you the applied styles and formats in the heading of the Text Style studio. For more complex formatting you can click the arrow on the left side to see full details on applied styles and format to the selected text (see image).

With my suggestion all applied styled could be listed here and the order tells you which one is prioritized (last as with CSS). Of course, we could also wish for a format inspector similar to the CSS inspectors of some browsers. That would tell you in detail which style applies which formats and which formats are ignored (normally striked-through) because they are overwritten by other styles. But let's save this for version 3 or 4 😁.

Regarding usage I would suggest to keep the current behavior: clicking on a style applies it, and only this, thus removing other styles (of same category, i.e. a new character style replaces other character styles only). To apply an additional style without removing the current one(s) you would CTRL+Click a text style. This would ensure that nobody needs to change the way working with Publisher as everything works as it does now.

[DieterW]

garrettm30 brother in soul 😉. That is exactly what I am talking about.

[sfriedberg]

I am dealing with an explosion of character styles related to math subscripts and superscripts, for precisely the reasons outlined in the original post.  Because it's not just subscript and superscript, it's also sub-subscript, super-subscript, super-superscript and sub-superscript.  And then it's "Math Greek", "Math italic" and "Math numeric" for each of those.   So I've got 18 character styles to juggle, when it should be no more than 9.

[m.d.]

Hi, is there any progress in this respect? I also miss the option to apply multiple character styles for many reasons, and it seems V2 didn't bring anything new either.

[MikeTO]

46 minutes ago, m.d. said:

Hi, is there any progress in this respect? I also miss the option to apply multiple character styles for many reasons, and it seems V2 didn't bring anything new either.

Hi and welcome to the forums.

I'd like this feature, too, but I don't see it happening anytime soon. It's easy with CSS because the styles are applied in the order of the tags. But in a page layout app, the tag or control code order is invisible and we can't change their order. Users would be forever complaining that they applied two styles that defined the same attributes to the same range of text and the results they got depended on the order they applied them in but they actually wanted the other order. And it would be harder to remove a character style - currently we click No Style but that would remove both. So to remove one of two styles, you'd have to select the range of text and deselect the style. But if you missed something like a trailing space then there would still be a character style applied to it, potentially leading to a future issue.

There are solutions but they make the user interface too complex. I believe the LibreOffice team discussed how to do this but I don't think anything came of it.

[m.d.]

Hi,

Actually, for character styles, I believe it makes more sense to have a style just for a given feature, like bold, italic, superscript, specific colour, tracking, etc. And then it would work fine. What is mentioned in the older posts here (and in some other threads), users are rather complaining that they must create complicated character styles with many combinations of features. Inherently, it is a mess, and honestly, the benefit of using styles then might be questionable.

With removing the styles, you are right, but if you now achieve the same format using the style that combines more features, it is the same (by clicking No style you remove everything). Moreover, when manual formatting turns out to be a more efficient option than present styles in some cases, removing that might lead to the issues you describe with even higher probability.

So, it would be great if the Serif developers considered that. I am aware that this behaviour is not common in other software products (and I work with many); but for Affinity, I believe some new routes may be discovered. Possibly, adding a special kind of text style for these purposes might be a solution, which wouldn't disturb the users who are happy with the traditional character styles.

[DieterW]

My thoughts are... anything would be better than the current solution...

I would go one step further than m.d.: Why not giving us the opportunity to apply multiple text styles as is, with all the issues there are (like wrong order, which cannot be changed in the first step). As an experimental feature, which must be activated in the settings. As m.d. mentioned, in most cases users would not apply multiple text styles with the same feature, I would say the vast majority of supporters here desperately are looking for a way to mix different features. I mean, really, this is soooo annoying...

Regarding MikeTO comments:

I do not fully understand the argument regarding the hidden control structure. There must be some form of data structure of applied styles and features. On top of the text style pane there is a box listing all applied styles and features. I assume there must be an order for this too within the data structure, or at least it should be possible to add it. At first it should be the order of application of the style/feature. I also assume that it should be possible to provide a way to change this order (instead of the current box at top, there could be a simple list of applied styles/features which can be reordered or entries deleted). That is more or less what would help greatly and satisfy most needs (with enough potential for fine-tuning later ). I am sure some issues remain, but we are looking at a 90% "there" and 10% "still not there" situation IMHO.

Regarding the issue of missing a trailing space, etc I see no difference to the situation now. In addition, I think the majority of Affinity users is aware of this and could handle it.

Edited February 16 by DieterW
additions for better clarity