Hi Mike,
On 2020-07-10 05:51, mikekaganski wrote:
(Sent from:
http://document-foundation-mail-archive.969070.n3.nabble.com/Users-f1639498.html
)
...
What you see is clearly a bug. Even two.
First is a bug of character styles' relative size.
The relative size must evaluate first relative to its inheritance: i.e.,
if
the character style B (with a relative size) inherits from character
style
A, then it needs to apply the relative size to the size defined in that
parent style A (if any). If the size in A is defined, and is absolute,
then
the result is an absolute size independent from any paragraph settings;
e.g., if A defines 14 pt, and B defines 150%, then text styled B must be
14
pt * 150% = 21 pt. This case now works correctly.
Yes. No problem there.
But if A does not define a size; or if it also defines a relative size -
then the resulting character style as a whole defines a relative size (in
case A has 40%, and B has 150%, the resulting relative size is 40% *
150% =
60%). Then the multiplier must apply to the size defined in the text
run's
superordinate. It might be another text run (the ODS defines that
character
styles may nest - so this character style may be applied to some part of
text having another character style, and then the size of that
superordinate
text run must be the base to which the multiplier must apply). Or it
might
be the paragraph - and now the paragraph should define the base for
applying
the percentage. And here we have the bug #1.
So I thought: The Paragraph style supplies the superordinate -- or, in the
case of nested Character styles within a paragraph, the Paragraph style as
modified by the longer-run Character style provides the superordinate for
any additional Character style applied to a subset of the longer run. So
your understanding is the same as mine: that the Character style /should/
modify the character attributes of the Paragraph style -- or any subsequent
superordinate. [More on this later.]
Having confirmed that Writer does not, in fact, work that way, I suspected
a problem with my understanding, while you conclude that there is a bug
(#1). More and more I'm inclined to think you are right (because nothing
else makes sense to me). As I noted to Robert, his alternate theory of
operation would explain why my understanding does not work, but it also
does not make sense.
Before filing a bug, I wanted to assure that I have understood correctly
what should happen -- and then, when we get it right, I would like to write
it for the Guide, to clarify a point that should be basic to the operation
of Writer. [However, precisely because this is so basic, I worry that a
resolution may not be a simple fix, and could take years to realize. More
on this later.]
The other bug is that there's a possibility to define Default Paragraph
Style (or any paragraph style that doesn't inherit) to have a relative
size.
How about Robert's suggestion: Tools → Options → LibreOffice Writer →
Basic Fonts ?
That *does* set an absolute size basis.
But that /seems/ to present another basic problem, which I infer is
bothering you; it is this: Since everything (Paragraph styles) descends
from "Default Style", then Why have other style sizes {"Heading", "List",
"Caption", "Index"} on that page? I /think/ [again, this is my inference,
not something I have seen], Basic Fonts is intended just to provide an
initial config, /to be discarded as soon as the user expresses a different
intent/.
For example, "Heading" is based on "Text Body", which is based on "Default
Style". Normally "Text Body" takes its font size (12pt) from "Default
Style", while (in a new document) "Heading" has a different size, taken
from that Basic Fonts page. However, if you assign "Heading" a relative
size (say, 150%), /then/ it reverts to basing the 150% on "Text Body",
/not/ the Basic Fonts page. So it goes from taking its size from the Basic
Fonts page to taking its size from the inheritance rules (just as it does
if you hit the "Standard" button). But what is unique about "Default Style"
among the styles listed in Basic Fonts, is that the user can never express
that "different intent" that invokes a different rule of inheritance,
because the inheritance rule is moot for "Default Style". That, I think, is
at the root of what bothers you here.
I wish it were not so, that inheritance rules change (if they must change
at all) without *explicit* choice of the user, but I think that is
ultimately a consequence of more basic style philosophy. [More on this
later.]
IAC, all of this is just for *Paragraph* styles; as noted earlier in this
thread, *Character* styles follow different rules, which one discovers only
from experience -- and that is the problem: Lack of explicit clarity about
style inheritance rules is a weakness which can lead to bugs. [More on this
later.]
That [ability to specify a relative font size in Paragraph style
"Default Style"] is definitely a bug, since there's nothing in any
standard, or in any setting, that would tell then which is the basis
to which the relative size is applied. And LO behaves erratically
then: say, set default paragraph style to 6 pt; see how everything
becomes small, and default is 6 pt. Now set default paragraph style
to 150%; see how everything increases, and paragraphs of default
style are 9%. So it looks like it applied the ratio to the old value
- but the paragraph style's properties still show the relative size,
not 9 pt which it should! This is the bug #2.
I found different behavior: When I set the font size of Paragraph style
"Default Style" to 6pt, everything reflected that, as you say. However,
when I set "Default Style" to 150%, its absolute font size became 18pt
(150% x 12pt on Basic Fonts page). So, with the understanding above, this
seems to work as designed. The problem, again, is whether "as designed" is
in fact the most useful approach. That brings us to this:
A note: there's no UI for nesting character styles, and so my description
about nesting them can't be tested without direct editing of ODF. See
https://bugs.documentfoundation.org/show_bug.cgi?id=115311.
That was a thought-provoking discussion, limited only by the language of
style categories used for the discussion -- and therein IMHO lies the
weakness [this is the "later" referenced several times above]:
At the beginning of this thread, I mentioned parenthetically my belief
that much of the styles complication derives from the incorporation in
Paragraph styles of character attributes, to be modified later by character
attributes in Character styles. Defining character attributes in a
Paragraph style invites complications, and maybe bugs. [Consider how many
bug reports (like the one you cite, and the ones /it/ cites) and other
words (like this thread) have been spilled over topics arising out of that
relationship. Yes, I understand that Microsoft may have started it (with
Word), but, to say no more, that thought does not allay my concern on this
design practice.]
However, even that is a special case of bundling attributes in "Paragraph"
and "Character" styles, when what we really want in essence is the visual
presentation of semantic meta-ideas (about object class, or emotion, or
other unspoken/unworded attributes) in text. In the beginning is the word,
not the paragraph. In the beginning is the idea, which the word, then the
text, then the paragraph and other structures, exist to serve. At bottom, I
think we want:
(a) nested styles to serve multiple orthogonal semantic objectives.
(b) style inheritance to reflect the internal connectedness of
different classes of semantic objectives.
Unfortunately, this is way too big a topic, maybe for this forum, and
certainly for this post which is already too long. I will try to write
something more comprehensive, separately. Meanwhile, I think we have
concluded that there is (at least?) one bug here, and I will report it.
Thanks for your excellent thoughts.
Best regards,
John
--
To unsubscribe e-mail to: users+unsubscribe@global.libreoffice.org
Problems?
https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/users/
Privacy Policy: https://www.documentfoundation.org/privacy