[Libreoffice-ux-advise] [Bug 90068] FORMATTING Proposal to make italic, bold and other font variants as built-in styles, in addition to emphasis and strong emphasis, which are not obvious to inexperienced people and have different actions, particularly in export targets like LaTeX.

bugzilla-daemon at bugs.documentfoundation.org bugzilla-daemon at bugs.documentfoundation.org
Tue Jan 23 20:52:33 UTC 2018


https://bugs.documentfoundation.org/show_bug.cgi?id=90068

Christopher R Lee <chrblee at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |UNCONFIRMED
     Ever confirmed|1                           |0

--- Comment #12 from Christopher R Lee <chrblee at gmail.com> ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


More information about the Libreoffice-ux-advise mailing list