(In reply to Christopher R Lee from comment #0)
> Currently, in LO 'emphasis' and 'strong emphasis' are the only built-in
> styles that give italic and bold font variants. If you want to be sure to
> get italic and bold, as well as other variants (small caps etc), you have to
> create your own new styles. User styles can make your work less easy to
> follow by other team members, and they might not be picked up by export
> filters, which are increasingly being used.

Sounds like the UX Team might have something useful to say on this topic :-)
Component -> UX-Advise
Status -> NEW

Related AskLO thread:

http://ask.libreoffice.org/en/question/47341/

This could possibly be solved together with proposed enhancement 94886?

Bold and Italic are only means for markup some text. I do not like the idea to get styles for them. Styles should express the meaning. If you inflate the list of styles, then please only if the list becomes configurable by the user.

(In reply to Regina Henschel from comment #4)
> Bold and Italic are only means for markup some text. I do not like the idea
> to get styles for them. Styles should express the meaning. If you inflate
> the list of styles, then please only if the list becomes configurable by the
> user.

I think that a usecase for this, could be the use of other font variants for bold. I'm talking about Black, Thin, Demibold, etc.

I completely support Regina's comments: a style name should never convey a formatting setting name ("bold", "20pt"), but the intend of use for the style. So, the 'emphasis' and 'strong emphasis' are correctly named, IMO, just like 'quotation' is, etc.
I agree that some names are not immediately clear to newcomers. They just have to learn. In my young years, I had to learn to read and to write. Then I had to learn about text processing and styles. Styles are not intuitive, they are computing matter and this has to be learnt (and tought) as well. I strongly think the tool can't replace a teacher. Never.

(In reply to Jean-Francois Nifenecker from comment #6)
> I completely support Regina's comments: a style name should never convey a
> formatting setting name ("bold", "20pt"), but the intend of use for the
> style. So, the 'emphasis' and 'strong emphasis' are correctly named, IMO,
> just like 'quotation' is, etc.
> I agree that some names are not immediately clear to newcomers. They just
> have to learn. In my young years, I had to learn to read and to write. Then
> I had to learn about text processing and styles. Styles are not intuitive,
> they are computing matter and this has to be learnt (and tought) as well. I
> strongly think the tool can't replace a teacher. Never.

The italic font variant is used for other purposes than to provide emphasis. See for example http://html5doctor.com/i-b-em-strong-element/. It needs to be available without prejudice to or confusion with the intended meaning of the emphasis style. As others have mentioned, other font variants are in the same situation; I don't think the user should have to create appropriate styles. I don't know if a workaround would be to rename generic uncommitted built-in styles, so the user can take advantage of the variants of the particular font(s) in use.

Note that in standard typographical practice, 'emphasis' may give italic in a passage in roman, and roman in a passage in italic; it's a switch. See for example https://fr.sharelatex.com/learn/Bold,_italics_and_underlining. In LaTeX you can obtain this effect by using *both* \textit and \emph; items like figure legends are already in italic so you just use \emph. 

It seems that the <i> element is beginning to be deprecated in html, with a recommendation to use classes to indicate the intended meaning. The present correspondence may draw attention to a related though presentational difficuly with LO. In my opinion, the tabbed windows way of presenting LO styles is an obstacle both in general and in the present context. A CSS lookalike would be better and (though not relevant here) it would show the cascading. Alternatively built-in fonts (at least) could be presented in a tabular format, so the user can see at a glance how all relevant style names are linked to variants of the font being used, with a warning if a variant is being generated artificially.

(In reply to Christopher R Lee from comment #7)
> 
> The italic font variant is used for other purposes than to provide emphasis.
> See for example http://html5doctor.com/i-b-em-strong-element/. It needs to
> be available without prejudice to or confusion with the intended meaning of
> the emphasis style.

Yes, through other styles with the appropriate naming. See 'quotation', for an actual example.

> As others have mentioned, other font variants are in the
> same situation; I don't think the user should have to create appropriate
> styles. 

Mmmm. I'm not sure I understand this fully. Do you mean a user should be given a complete set of styles with no style creation possibility?

> I don't know if a workaround would be to rename generic uncommitted
> built-in styles, so the user can take advantage of the variants of the
> particular font(s) in use.

Creating a child style from a stock one is quite easy, is it not? Then you keep the best of both worlds: the stock style preset and the user's refinements.

> 
> Note that in standard typographical practice, 'emphasis' may give italic in
> a passage in roman, and roman in a passage in italic; it's a switch. See for
> example https://fr.sharelatex.com/learn/Bold,_italics_and_underlining. 

Yes, so it is in French typography as well. Dunno about foreign typography rules. (BTW, would be nice to have that switch in LibO. Hear! Hear!)

> LaTeX you can obtain this effect by using *both* \textit and \emph; items
> like figure legends are already in italic so you just use \emph. 

Here you're talking about the quotation intend, which, in LibreOffice, has got dedicated 'quotation' styles (both for paragraphs and characters).

> 
> It seems that the <i> element is beginning to be deprecated in html, with a
> recommendation to use classes to indicate the intended meaning. The present
> correspondence may draw attention to a related though presentational
> difficuly with LO. In my opinion, the tabbed windows way of presenting LO
> styles is an obstacle both in general and in the present context. A CSS
> lookalike would be better and (though not relevant here) it would show the
> cascading. 

I very often set the styles listing in hierarchical mode for that matter.

> Alternatively built-in fonts (at least) could be presented in a
> tabular format, so the user can see at a glance how all relevant style names
> are linked to variants of the font being used, with a warning if a variant
> is being generated artificially.

Thank you for all the interesting comments and proposals. There appears to be some conceptual difficulty with the technical categorisation of font variants as character styles; this may have something to do with the fact that wysiwyg word processors (apart from the old WordPerfect) don't let the user see how markup is applied. I've proposed elsewhere that the necessary information could be supplied by means of subtle lightly-coloured background patterns.

Perhaps we could go back to the beginning by defining likely user requirements, perhaps with ideas on what users might be encouraged to require in a World uninfluenced by certain other word processors. On that subject, I was amused by the first version of Word (2007) that had the Dreadful Ribbon: they forgot to include subscript and superscript, and provided no suitable way for the user to add them.

My basic user requirement for Writer would be to be able to display all available font variants (you could include size and colour) by clicking on something. Frequently-used variants like italic and subscript could continue to have their own buttons or other means of access, but there is no reason to give them a special technical status.

I'm sure that people using Writer without special guidance or training will want to continue to use direct formatting, which gives the font variant and not the intent. There is no objection to having intent as a category of character styles with funny or incomprehensible names, but these are probably of use mainly to those of us who use(d) templates written by experts in an enterprise setting. I think we need two separate categories of character styles. The design of export filters might be simplified if direct formatting were to be interpreted in terms of styles.

For many users, the individual direct formatting buttons are OK for the 4 or 5 common variants, but there is no logical reason, except lack of toolbar space, to treat differently small caps (for example). Presently,  to get small caps you have to go to Format/Character or else make your own character style. Either way, the user is presented with a complete style definition, which may be why contributors to this thread don't count 'italic' and so on as styles.

A difficulty is that most often the user doesn't want anything to be changed except the font variant. This reveals what seems to me a fundamental weakness of Writer: character styles have a font size defined; I don't know where that cascades down from because the styles supplied (Version 4.4.3.2) are inherited from 'none'. The character style 'Rubies' (whatever that is supposed to signify) has a font size of 6 *points*. An everyday practice with word processors is to change the font size of a selection or the whole document, perhaps to fit the page, or perhaps for a reader with poor eyesight. Changing a selection using 'Format/Character' changes all characters to the new font size, and consequently it's difficult to re-locate the original character style. Changing the default paragraph style from 12 to 20 pt leaves the poor little Rubies at 6 pt and your friend can't read them.

Writer is supposed to be used with a computer, so it ought to be possible to convert (transparently to the user) direct formatting to some kind of style, and to define a style structure whereby styles can be set up to modify only the parameter the user wants to change. Clearly, font sizes in styles need to be proportional and not absolute, with rounding if necessary.

Going over the old tickets but this one is really hard to understand. The topic reads as a request to introduce a character style 'bold' (I agree with the comments that rejected this idea), then we have a discussion what the style 'emphasis' should be, and the last comment 9 totally confuses me with a lot of different arguments.

Could you please make it more clear what you expect?

Introduction

I hesitated to reply to comment # 11 because, since posting the bug report in 2015, I’ve got an even stronger impression that OO/LibO Writer doesn't seem to be a major player on the home and office scene. Big institutions such as public services are an exception because they can afford bespoke development. In the end, I thought it worthwhile to write this essay.

After retiring a decade ago (see below), I’ve been using use Writer for little more than classical office work in small voluntary organisations, where we need file compatibility between members. Colleagues usually send me .docx files, though some do relent and send .doc files. They are not happy to receive odt when I forget to convert. Like me, everyone works from home at their own expense, but no-one else seems to know about free office software that works; there are similar echoes from countries where people don't have much money. I don't normally pay for software, but may soon relent so as to lose some of my geek image.

In my opinion, the confusion referred to in comment # 11 is a consequence of long-standing structural and conceptual difficulties which, inevitably, are hard to explain clearly. The present subject is that Writer lacks clear attribution and visualisation of the appropriate roles for templates, styles and direct formatting. The question about italic, bold and emphasis is only one small aspect of this.

As an informed long-term user of office software I may be able to give a little biased insight into what may have gone wrong with general purpose wordprocessors including LibO Writer. Basically, users should not be presented with more than one way of calling text elements and modifications such as headings, lists and font variants. Contrary to my earlier postings, I now consider that users should only rarely need to create or change styles, and that practically all calls to styles should be done in a uniform way by means of commands that act like markup or direct formatting.

Background

In the late 1970s, as a user of scientific laboratory computers in an R&D corporation, I had to help out with the office computers because corporate IT tended to obstruct both activities. Wordprocessors (mostly Wang in our case) invariably used markup, with various means of presenting a preview. A bit later, WordPerfect under MS-DOS became very popular among users; it was wysiwyg, but with the screen divided to show the plain text with markup. Migration of WordPerfect to Windows, which succeeded MS-DOS, was a failure for (possible) reasons that were discussed.

There then followed the current quasi-monopoly situation in which the desktop wordprocessor is totally wysiwyg. You could just say 'too bad, we lost that one', except that this is linked to the quasi-monopoly on office OS; both of these de facto monopolies are bad for all concerned. A striking feature of *that* wordprocessor, and later of Writer, was and still is the extreme difficulty with constructing a template that meets requirements, and is adaptable with respect (at least) to automatic scaling as a function of the users' choice of text body font size (Bug 91160).

Corporate dossiers are assembled from contributions by hundreds or thousands of authors, who do their own typing and must use the same template. To begin with, text editors were used (Unix, DOC). Later, and for many years, the W*rd templates supplied by IT departments were buggy and terribly user unfriendly, reflecting technical difficulties that persist today. Private individuals are still being left out, as indicated by the dearth of LibO Writer templates available on the web.

Because of that and some other show-stoppers, in about 2009 I moved most of my work to the LaTeX ecosystem (scientific and general writing, drawing, editing novels for friends) and Scribus (exhibitions, picture books, routine teaching material). LaTeX uses markup. Scribus is going the same way; development version 1.5 practically enforces use of the Story Editor for text frames, so you are shown exactly how they are coded. LaTeX is big and still growing, since 1978. Overleaf, one of several cloud services (free for individuals) claims 750000 users. LaTeX and Scribus don't replace general-purpose office wordprocessing software, though they are surprisingly easy once you get used to them. My proposition is that they (particularly LaTeX) may indicate how LibO Writer might be brought up to date. I think that could be done by inventing a kind of markup that's compatible with wysiwyg.

Scope

While Writer can do many things (it’s a useful front end for LaTeX and eBooks), I'm referring only to the common situation where the user decides exactly how the main content of the page will look on screen or paper. Specifically, font variants are usually applied as such: for example, the rules say that foreign and latin words (names of biological species, chemicals, etc.) are in italic. In other cases the user (or the typographical style guide being followed) may decide whether to use italic or an available bold font variant for emphasis, or to leave it open by means of the 'emphasis' command. You'd expect to find all three options at the same place on the screen. Page size, layout, margins, etc. are in scope but not discussed here.

By contrast, eBook readers and html browsers are in another world because have a 'say' in the final appearance. I don't discuss the (important) use of Writer as a front end and hub for making such documents. In any case, I've noticed that Adobe Digital Editions and Firefox among others annoyingly ignore some basic rules, so you can never know what to expect. LaTeX and Scribus don’t work like that, nor should wordprocessors. As someone said on a forum, referring to W*rd, the software should do what you tell it, not what it thinks you want. 
How LaTeX does styles and formatting

My practical experience is with the default LaTeX document classes, run on the pdfLaTeX compiler/engine. Newer LaTeX bundles, particularly KOMA-script (https://ctan.org/pkg/koma-script) are more relevant to office suite word processing, partly because the implementation of multiple user-selected fonts is automated.

In LaTeX, the style information is included in the 'document class'. The class may also include template-related functionality such as constructing a title page from the user's plain text (out of scope here). The dozen or so common generic document classes include 'article', 'book', 'letter' and 'beamer'.

Writing and modifying classes is the province of experts (often the University guru, an academic publisher's IT team or various sources on the web). Classes are often presented to the user as templates that may be blank or show potential users what can or should be done with them (see https://www.overleaf.com/gallery). Frustratingly, Writer could be considered as having only a single general-purpose document class (template/stylesheet). This has been criticised, particularly for the heading styles.

Ordinary LaTeX users access the document class by inserting commands as markup in the plain text. (I use 'commands' as a generic term.) All classes implement all the usual commands, and front-end editors present them like direct formatting in a wordprocessor. Standard font variant commands  (copied from the TeXstudio front end) are, with the text to be modified between curlies: \emph{emphasis}, \textit{italic}, \textsl{slanted}, \textbf{bold}, \texttt{typewriter}, \textsc{small caps}, \textsf{sans serif}, \underline{underline}. The particular, font variants (for example different weights like semi-bold) can be defined in the preamble and you can create your own command to call a particular variant. Note that they are all called by the same means, whereas Writer scatters them randomly between Style and Direct Formatting.

Sometimes a user will redefine a standard command that addresses a style with simple modifications, for example by changing the bullet and spacings in \itemize (unsorted list).  However, there exists a wide variety of alternative commands and different ways of implementing standard ones. These facilities are supplied as plugins termed packages; they are called with the command \usepackage{}, which usually takes optional parameters. The babel and polyglossia packages, which set up and automate the typographic conventions of each language being used, make multi-lingual work much easier than with Writer. The great strength of LaTeX is that the basic engine is complemented but not modified by thousands of documented and curated packages. Wordprocessors have a wider range of uses but I haven't seen a correspondingly wide range of plugins or equivalent for Writer (except for output filters).

Another feature that makes LaTeX really easy to use compared to Writer is that, at document level, the user need indicate only the document class, the text body size and one or more fonts. In a wordprocessor this small amount of information could go in a tab of the document properties window. Document elements such as section or chapter titles and captions scale automatically to the text body size. Likewise, the user's local (markup; direct formatting) changes in font size are always relative to the text body, ranging from 'tiny' to 'Huge' ('huge' is less huge than 'Huge'). There are various ways of tweaking scale factors.

Until recently, LaTeX has allowed only one font to be declared as default for the structural elements of a document (headings, legends, text body, etc.). Different fonts and font variants are used only to highlight specific points. This reflects historical (mechanical) typographic practice and it was a way of discouraging academic users from using too many fonts (LaTeX started life in academic circles). A wordprocessor needs to be less dictatorial, and now the KOMA-script LaTeX bundle, like Writer, allows (with suitable dire warnings relevant to Writer's default template) any font or variant to be applied to any type of element. The big difference is that automatic but adjustable font scaling is maintained. Also, the user doesn't access a style directly, and so can't break it. I recall that in LaTeX you define headers, legends, lists, etc. via the equivalent of direct formatting, never by calling a style.

How to present styles and formatting to the wysiwyg software user

I've already proposed (Bug 91160) that Writer styles and their dependencies (including scaling) could be presented graphically in spreadsheet form. The fonts to be used (not too many) and variants should be named at the top of the sheet. At the very least we should have automatic scaling; at present if you change the size of Heading 1, Heading 2 stays the same. Unless we're an IT specialist we should not need those 14 dreadfully complicated window tabs to set up at each hierarchical level.

Markup began life in the days of teletypewriters and low resolution monochrome terminals. Nowadays it's easier to use because there's room on the screen(s) to show the pdf rendering alongside the plain text (see any LaTeX front end). However, not everyone would like that, specially when I'm proposing that every call to style and format be done via an equivalent of markup. I discussed that question in Bug 91160; with a high resolution colour screen it should be possible to reconcile wysiwyg with markup by using subtly coloured watermark-like patterns as a background to the marked-up text. Users would quickly recognise frequently-encountered combinations. You'd be able to call up a window to show what a pattern means.

Many thanks for your thorough elaboration. We definitely need the expert knowledge from professional writers, although most of us have an academic background too.

There is no doubt that Latex is a great tool and serves really well the use case of academic writing. Another example for a specific use case is Scribus, also a great tool when it comes to DTP. Both are not really easy to use for beginners because of the restricted workflow and the advanced functionality. LibreOffice (like any other office tool) fills the gap and allows, for instance, writing a letter with zero knowledge on layouting. It also aims to be an alternative to Latex and Scribus but not to the full extend. We identified two primary personas (prototypical users), Benjamin and Eve (https://wiki.documentfoundation.org/Design/HIG_foundations#Persona). And when we talk about improvements to the workflow or UX in general, we have to take both into consideration. While Eve might find into a Latex-like workflow, Benjamin wouldn't do that. 

Another aspect of Libreoffice is the tight relation to the open document format. It's always paramount to follow standards since we want to free people from a specific program. You should be able to create documents with LibreOffice and load it later in another tool but with exactly the same layout.

While you say "users should not be presented with more than one way of calling text elements and modifications..." we explicitly want to allow different ways to accomplish a task. You can define a character style "textit" with an italic font style or "textbf" with bold weight and work like in Latex. The difference is that all parties have to agree on the styles and have to carefully make use of it.

What we can do is to create a good set of factory defaults. That begins with Emphasis and Strong Emphasis for the character style over a reasonable default paragraph style based on norms, up to complete templates (where we have a lot of room to improve). And we can educate the user, which means among other aspects to give a clear feedback of the underlying formatting. Some ideas about such a "style inspector" are discussed in bug 112852 and bug 90646.

Again, many thanks for your ideas and comments. Keep on with that!