Date: prev next · Thread: first prev next last
2020 Archives by date, by thread · List index

Hi Mike,

On 2020-07-10 05:51, mikekaganski wrote:
(Sent from:
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 

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

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 

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 
        (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,

To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
Privacy Policy:


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.