Writer: clarification needed about character attributes

[ajlittoz]

(continued 2) … the possibility to mark a sequence with more than one character style (as can be done in Quark XPress®), e.g. a sequence may be marked up as “comment” and I want to put “emphasis” on a word without losing the “comment” markup. Presently I solve the issue with another character style merging both original ones (not satisfactory).

Similarly, I’d like to be able to negate an attribute: Emphasis is usually coded “bold”, but if base style of paragraph style is already “bold”, typographic rules say this emphasis should revert to “Roman”. Can’t be done today in Writer apart from creating a “complementary” style.

Despite these shortcomings, I haven’t experienced the random non-updates, probably because I struggle to avoid direct formatting. As I wrote, it is not very user-friendly while typing but it is rewarding on editing.

[LukeKendall]

That’s a very helpful answer, thank you.
It’s depressing however, as it means there’s a severe and ongoing usability problem, as well as a subtle and largely invisible trap for most users.
If the bug in being able to find text by attribute were fixed (Find & Replace, using Format, makes F&R unreliable), then a workaround might be to Find All italics, then simply choose one’s Character Emphasis style and apply that.
Does that sound practical?
Or does Writer’s “layered attribute” (?) model of text mean that finding text by the visible attribute the user is able to detect, can never be reliable?

[ajlittoz]

I use sparingly Find & Replace probably due to my careful use of styles. I just looked to the F&R dialog to refresh my memory. The Format button opens a font selection dialog. When you choose Italic in there, you’re in fact telling LO Writer to look for a font variant. If you applied your italics with direct formatting, i.e. Ctrl+I, toolbar button or munu equivalent, I’m note sure of what gets recorded in the XML or internal representation.

Styling with a style involving a teal italic font should not create problem et be relatively reliable. Direct formatting works even for font without the specific variant (when rendering, the font engine “manufactures” an italic or bold synthetic version of the font). The XML encoding is probably not the same, meaning the search strategy doesn’t consider the same “keys” as the previous case.

The erratic behaviour you encounter may be due to a change of strategy in the middle of a search …

[ajlittoz]

(continued) when F&R sees a direct formatting. Then, it does not revert to the initial “pure” strategy and begins to get confused. That pure speculation of mine.

Maybe the layered style architecture is also a factor. That’s why I keep away from direct formatting to get one layer out of the game. Consider direct formatting is OK for experimenting but should never be used for production-quality documents.

[LukeKendall]

Thanks. When the italic font exists for the regular font you’re using, I think it’s reasonable to expect that searching for the italic font will find occurrences of text that Writer shows (via text display and the Font toolbar), to be that italic font. I think that expectation is reasonable regardless of whether the italic font text was produced via a style or via direct formatting.

Given other bugs, I believe Writer does not properly “understand” or operate on its own representation. Hopefully these issues can be addressed. I can do my part by providing one or two more bug reports to help.

I understand what you’re saying about the problems of direct formatting, caused IMHO by Writer’s model and UI and documentation. I doubt I could convince the devs to redesign the model, but hopefully they can fix the bugs in its implementation, and I can do my small part to help with the documentation where I see it lacking, too.

Thanks for your ongoing comments and explanations - it helps!