[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 Oct 13 12:38:42 PDT 2015
https://bugs.documentfoundation.org/show_bug.cgi?id=90068
--- Comment #9 from Christopher R Lee <chrblee at gmail.com> ---
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.
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the Libreoffice-ux-advise
mailing list