Publisher for Windows — Edit Text Style dialog improvements

[MikeA]

19 minutes ago, walt.farrell said:

However, this may only be useful when your composing a new document from scratch. If you're importing a .docx or .idml file you have no choice about getting whatever style garbage they bring along.

So I've found with the .docx files created by the Word "clone" program I use. It has no "based on no style" approach, excepting "Normal," which seems to be based only on itself and apparently can't be based on anything else. It's a perfectly good program in its own right, but using it as a source for text to be placed in Publisher might become an exercise in frustration, styles-wise. If MS-Word still supports basing any style on "no style," then I might end up having to use it after all. Ugh. (When I worked at Microsoft — not recently  — only the most die-hard "lifers" there liked what the Office team did with Word when they switched to a ribbon-bar-only UI, a disease for which there was no cure. For shame. Well, never mind...)

[Wosven]

On 4/5/2020 at 2:57 PM, Old Bruce said:

The only real and immediate advantage I have seen is that using Group styles means I cannot inadvertently apply a Group Style which could happen If I used Paragraph Style to base things on resulting in the 'wrong' style being applied. I do admit that it is quite a minor advantage.

I've got the same use as you.

I use maximum 3 family fonts by document, so I'll have by default in an APub document Base_text and Base_header. I choose 2 fonts for each one, and begin adding styles base on them. If I need more "base", I had them.

When creating text styles, the hierarchical view is very usefull, but once done, it would be more usefull to have real groups to group them depending of the part of the document they are related too, since the one that'll use them doesn't need to know about which style is parent of another one, but more which styles are used in differents parts of the document.

"Grouping" can be done using prefixes and diplaying them alphabetically, but it would be like going back to prehistory when groups didn't exists in such apps, and when you need to modify prefixes on many styles, it's a pain.

[Old Bruce]

2 minutes ago, Wosven said:

When creating text styles, the hierarchical view is very usefull, but once done, it would be more usefull to have real groups to group them depending of the part of the document they are related too, since the one that'll use them doesn't need to know about which style is parent of another one, but more which styles are used in differents parts of the document.

If I understand you, you want to have the ability to switch between Hierarchical view and then be able to order the styles into 'folders' or 'sections' instead of the present system of either alphabetical or hierarchal. If we could just drag them around into a personal order that would be great.

I can get behind that.

[Wosven]

2 minutes ago, Old Bruce said:

Hierarchical view and then be able to order the styles into 'folders' or 'sections' instead of the present system of either alphabetical or hierarchal. If we could just drag them around into a personal order that would be great.

Yes, but real groups or folders for this.

And alphabetical order is really usefull too, since for documents without different sections, and less styles that don't need grouping it's easier to search "header 1", "body" or "body_drop_cap" in an alphabetical list since there isn't many variants of them for each section.

[MikeBWD]

Thanks for your replies, looks like I just have a learning curve. Been playing with a new document and dummy text and trying to make the equivalent as a CSS approach starting to understand the differences slowwwwwly, would be a good vid tutorial to add to the others at some point.

Thanks once again 

Mike 

[Catshill]

12 hours ago, MikeBWD said:

Thanks for your replies, looks like I just have a learning curve. Been playing with a new document and dummy text and trying to make the equivalent as a CSS approach starting to understand the differences slowwwwwly, would be a good vid tutorial to add to the others at some point.

Thanks once again 

Mike 

I agree that a video tutorial using actual examples would be helpful. These forums are excellent but the advice given always benefits from a picture, animated gif or video. More work for the teacher but very beneficial for the student.

[lmarcos]

On 4/7/2020 at 8:16 PM, garrettm30 said:

There is nothing like the concept of giving a single element multiple classes.

There's at least one point in which this is not true, though it currently has glitches. It is a paragraph style with drop cap and initial words. The first letter gets the drop cap character style first and the initial words character second.

And you can have underline and bold without creating a new character style as well.

[garrettm30]

2 minutes ago, lmarcos said:

There's at least one point in which this is not true, though it currently has glitches. It is a paragraph style with drop cap and initial words. The first letter gets the drop cap character style first and the initial words character second.

That's a good observation, but it is far limited compared to CSS.

3 minutes ago, lmarcos said:

And you can have underline and bold without creating a new character style as well.

Those are just local overrides, but we are talking about styles. There is no way for a selection of text to have multiple character styles applied to it at the same time. This kind of thing is possible with CSS, and that is probably what we (those who like CSS approach) wish for the most. But it would require a major overhaul of the style system, and I don't think that is practical.

[lmarcos]

4 minutes ago, garrettm30 said:

That's a good observation, but it is far limited compared to CSS.

CSS has come far too complex lately for people like me who only use it now and then. And without the inspector on the web browser I would have had a hard time tracking the setting I had to override, so even if Apub is limited compared to css, it's more friendly for people like me... and I'm glad it is 😋

[MikeW]

CSS, as it is commonly created and used, is a plethora of styles, with as regards text formatting, is equivalent to paragraph and character styles. That a class can combine attributes of more than one style, modifying them at the same time if desired, is a low-level function.

I doubt that there can be such a system ever implemented in a desktop application. But if such a thing is desired, you can use a web development package, write the text in it, open that up in Word or the like and then transfer that into APub 😀

A tad more seriously, the above is akin to how the InDesign and QXP server products basically work. I don't know what is the underlying stream return when using ID Server, but at its heart, QXP uses XHTML. This XHTML can be manipulated inside of QXP to a limited extent by accessing the DOM using commands to manipluate the XHTML.

[MikeW]

36 minutes ago, garrettm30 said:

That's a good observation, but it is far limited compared to CSS.

Those are just local overrides, but we are talking about styles. There is no way for a selection of text to have multiple character styles applied to it at the same time. This kind of thing is possible with CSS, and that is probably what we (those who like CSS approach) wish for the most. But it would require a major overhaul of the style system, and I don't think that is practical.

CSS has no smarts, no intelligence. Whether some developer selected a string of text and applied simple html tags or a class, it is still local formatting. That goes to combining classes to control an entire block of text or a div. The classes still need created, just like p.styles and c.styles. Then they need applied.

 

I'm probably just not being imaginative enough as to how such a thing would be utilized in a desktop application to see the benefits. 

[garrettm30]

In HTML it is done by adding classes to each element. In DTP it is done by selecting text and clicking on a style. That part is not (in my mind) the thing to change. I still would suggest a graphical UI.

Let me illustrate a scenario that is not too far off from things I actually encounter. I have a character style called "Bold," and another character style called "Underline."

(Of course, you, MikeW, surely understand why I might prefer to create character styles for those things rather than just clicking the B or U buttons in the context bar. For others who might think I'm crazy, this is why: I want to be in control of the settings of a whole class of a formatting category all at once. If I change my body text to Georgia—whose bold face is considerably wider than the regular face—I will tone it down by changing the horizontal scaling of the "Bold" class to 95%. A couple of clicks, and now all text with that style is fixed, and I can keep changing it as often as I want, such as if I decide to use a different style rather than Georgia. For my underline style, I may think that the default underline is too thick or thin, or that its vertical position is not ideal, so I would update its style to compensate—well, in InDesign anyway; I'm still hopeful it will come to Publisher someday, but there are other underline attributes that I could change, such as underline color, so you get the idea.)

So now I have carefully tweaked what I want my "Bold" character style to look like, and I have separately tweaked what my "Underline" style looks like. But what if I have a selection of text that I want to be both bold and underline? I cannot apply both character styles in Publisher or other similar DTP apps. I can only 1) apply just one of the styles and use local overrides to achieve the equivalent of the other style, or 2) create a new style based on one of the two styles and recreate in it the attributes of the other style. The first scenario is no good to me, because then I have all of these local overrides which I tend to avoid when possible. In the second, I would probably make a new "Bold Underline" style that is based on Bold as its starting point, and then I would set the underline settings to suit. In the future, if I change the Bold settings, Bold Underline would also be updated. But if I changed the Underline text style settings, the Bold Underline would also have to be changed similarly to match. And the Italic Underline, etc.

The part of CSS that I wish were true here is that that in CSS I would not need to resort to either option. I could (assuming I named my classes as above) select my text and add both classes (≈ styles) to it:

<span class='bold underline'>Some text</span>

In DTP, I don't suggest we would go to typing everything, because I think that approach would not be the preference of most in the design crowd. Rather, the equivalent in DTP is that I would select text and, using the Text Style Studio otherwise as it is today, click my Bold style and also click my Underline style, and they would both be applied. I would end up with fewer and simpler styles than I have now. @MikeBWD Is this basically what you are missing from CSS too?

In thinking about it, I wonder whether it would not be so great of a change to allow multiple character styles to be applied to a single selection.

[dominik]

56 minutes ago, MikeW said:

CSS has no smarts, no intelligence.

I agree that CSS styles are different from APub's text styles and most likely they will never be the same.

In addition: in CSS there are so called 'pseudo elements' that have 'some' kind of logical function. See this explanation: https://www.w3schools.com/css/css_pseudo_elements.asp

Basically you can address certain elements without knowing where they are and style them accordingly. This is different from simple local formatting. I do not know if this is different from 'GREP styles'. You do seem to have much more knowledge about these.

Cheers,
d.

[dominik]

18 minutes ago, garrettm30 said:

to allow multiple character styles to be applied to a single selection.

Yes. Good idea.
d.

[MikeW]

Yep, I understand the scenario. Being able to "stack" c.styles is a neat concept, but behind the scenes, those class and/or non-class elements need to be defined. And once defined, in a back-end development tool, those style sheets are "messy," and the listing can be quite long. To me, that's no different than having a bold, bold italic, bold italic underline, etc, set of character styles in a layout application.

I'll bow out now...

[garrettm30]

8 minutes ago, dominik said:

In addition: in CSS there are so called 'pseudo elements' that have 'some' kind of logical function.

With pseudo-elements you can define additional content as a matter of style that is not there in the document content (the HTML part). That can include additional text. It can be very useful at times, such as in responsive designs.

Maybe not as much in DTP, but there is a parallel. For example, let's say you have a book where each title is tagged with a paragraph style. Then you build your TOC (on the mind right now) from those chapter titles. In the TOC entry style, you can define it as a numbered list with "Chapter \#:" as the number format. So your chapter named "The First Day" would show up in the TOC as "Chapter 1: The First Day" without needing to add the "Chapter :" part manually to each entry.

The CSS :before pseudo-element is like that. 

[Seneca]

1 hour ago, garrettm30 said:

But what if I have a selection of text that I want to be both bold and underline?

I don't think I would want that as an option. But what's the difference between your approach of selecting part of text and applying say bold and then underline (2 actions) from having one character style Bold-Underline and apply it only once. You could base your Bold and Bold-Italic on the common style upstream to reduce repetition. 

[Wosven]

I'm not sure about the example adding "Chapter #" since it's possible with APub. The limitation is to not be able to create character styles for this list. 

[garrettm30]

 

21 minutes ago, Seneca said:

But what's the difference between your approach of selecting part of text and applying say bold and then underline (2 actions) from having one character style Bold-Underline and apply it only once.

 

To answer your question, the difference is that I have to create extra styles and maintain extra styles as well. I have to repeat elements of style definition, and that is not the principle I care to work from. I would rather define what I mean by bold. Then separately define underline. I am trying to base them on the "common style upstream to reduce repetition," but there is still a lot of repetition. For just these three attributes I have have to have 7 different styles in order to cover all the possible combinations:

I've tried to reduce it down as much as I could (maybe someone can propose better?), but I hope that it is at least understandable why people with a CSS background might not want seven when three could work. I had to end up defining underline four times, and if I decide to change the style definition for underline, I have to do it 4 times.

Not the end of the world, but that is why I would prefer it the cascading part of CSS. As for extra clicks on application, that is usually true anyway, because for character styles the application would not always be identical. I mean by that that the underlined portion might not be the totality of the bold portion (emphasis just to illustrate, not to shout).

Anyway, I'm just dreaming here. I know that this won't come any time soon if ever, and I won't abandon Publisher if it never does, but it doesn't hurt to think about it, and to sympathize when someone else who maybe is having a hard time thinking about style organisation differently from the way he is used to.

[Seneca]

11 minutes ago, garrettm30 said:

Anyway, I'm just dreaming here. I know that this won't come any time soon if ever, and I won't abandon Publisher if it never does, but it doesn't hurt to think about it, and to sympathize when someone else who maybe is having a hard time thinking about style organisation differently from the way he is used to.

I hope I didn't dampen your enthusiasm here, that wasn't my intention. I do have CSS background and I see your problem. But in reality working on any larger project you will end up having all these styles defined anyway. But, trying to look outside the box is great and I applaud you for that. 

Maybe multiple inheritance would prove very valuable here.

EDIT: MI will not solve this particular problem either. 

[garrettm30]

2 minutes ago, Seneca said:

I hope I didn't dampen your enthusiasm here, that wasn't my intention.

That's understood. We're just chatting, and maybe something good will come out of it, but we have fun regardless.

I'm not really pushing to advocate for this, because I don't see it as very likely, but just something I imagine as part of my ideal world if it existed. Even there, the only change I imagine is just being able to apply more than one style at a time. The talk of CSS may be clouding the issue. I imagine only the implementation that looks just like what we have today with that one exception, and the possibility would only be an option, by no means required to use or that would change the functionality for those who do not wish to use it. In that way it is kind of like group styles: appreciated by some and left alone by others.

[Seneca]

1 minute ago, garrettm30 said:

In that way it is kind of like group styles: appreciated by some and left alone by others.

Same here.