Styles Don't Retain Bold?

users
#21

Hi :slight_smile:
Calligra picked up on the styles correctly!
Regards from
Tom :slight_smile:

#22

I downloaded the file and examined the parameters of the Level 3 style in
the document and found that, under "Font Effects", Gray is checked. Could
this be the source of the difficulty?

#23

No because the issue is that it's inconsistent, not that it's
consistently not bolding. Also the same problem happens with other
heading styles --> just used #3 as an example.

Best,
Joel

#24

Hi :slight_smile:
Yeh, i wondered the same but it is a different issue. As Joel pointed out
you can see the Bold button on the icon-bar is not de-pressed in when the
cursor is in the middle of the "heading 3" text.
Regards from
Tom :slight_smile:

#25

jmadero wrote

Are styles supposed to retain properties like "bold." I am consistently
getting mixed results using styles.

The comments up-thread by Kevin O'Brien and Brian Barker are correct,
despite a number of disagreements. So called "direct" or "manual" (directly
applied) formatting will always override a pre-defined style definition
e.g., a character or paragraph style. In LibreOffice "direct formatting"
(which is a Microsoft Office term) is equivalent to any style definition in
content.xml, rather than styles.xml (which is where pre-defined styles are
stored).

I have already commented in the bug report raised by Joel (which has since
been closed as NOTABUG), but it seems that this principle of overriding
styles is not well understood. Both ISO/IEC 26300 (ODF, Part 1, §16) and
ISO/IEC 29500:2012 (OOXML Part 1, §17.7.2) define a hierarchy of application
for styles. In both specifications what amounts to directly applied
formatting[1] are the last to be applied and so act as an override (which is
to be expected, otherwise clicking toolbar formatting buttons AFTER applying
a style would have no effect). This can however result in apparently
surreptitious behaviour that is at the root of why style adherents tend to
loath directly applied formatting i.e., it interfers with the effective
application of pre-defined styles.

If others would like me to expand on what was occurring in the example
document in greater detail for clarity I will. In simple terms there was a
direct formatting character definition (style T9 in content.xml) setting
both the font style and font weight to normal. This definition was
overriding the equivalent settings in any subsequently applied paragraph
style definition that used a weight of bold (for example Heading 3).

[1] In OOXML these tend to be paragraph or run properties that are not from
styles, while in ODF the determination is obtained by following the
child-parent chain in style definitions.

Best wishes, Owen.

#26

Hi :slight_smile:
Ahh, of course! The direct formatting remained "on" despite pressing Enter
a few times. Seems a sensible way to do it thb. If formatting kept
flicking back to the style rather than kept going the way the user had set
it then it could become quite painful.

When i went back to the file and used;
Format - "Clear direct formatting"
the heading 3 became bold again - although the light greyness made that
difficult to see.
Regards from
Tom :slight_smile:

#27

Hi Owen,

My experience on several occasions has unfortunately been that the
Default style in Writer has hard formatting characteristics which cause
application of Heading 3 not to work correctly, and it seems hard to be
able to ascribe any particular sequence of actions to make it
reproducible. I am not a styles expert by any means, but one would
expect the default styles to "work as designed".

Alex

#28

Alex Thurgood wrote:

My experience on several occasions has unfortunately been that the
Default style in Writer has hard formatting characteristics which cause
application of Heading 3 not to work correctly, and it seems hard to be
able to ascribe any particular sequence of actions to make it
reproducible. I am not a styles expert by any means, but one would
expect the default styles to "work as designed".

Not sure if it's related, but I noticed a week or so ago that there seems to be something slightly odd in the font sizes for the default heading style definitions...

- Heading : size = 14 pt
   - Heading 1 : size = 130% (relative to parent style Heading)
   - Heading 2 : size = 115% (relative to parent style Heading)
   - Heading 3 : size = 14pt (fixed)
   - Heading 4 : size = 95% (relative to parent style Heading)
   ...

So changing the size for the Heading style also flows through to the other Heading X styles proportionately - except Heading 3 which is fixed at 14pt. I think the intention is for that to be 100% relative to the parent style.

I've also found that attempting to explicitly set a style to 100% font size actually has the effect of fixing it at the parent style's current value at the time this setting is applied, rather than inheriting the value from the parent. So that is possibly what someone has done in defining the default Heading 3 style.

This is in 4.3.0. Will check in 4.3.1 and search for / report a bug when I get a tuit of the circular variety...

Mark.

#29

I think that the percentages that Mark showed are also present in 4.3.1. At
least that is my understanding. I have worked for an article to Elsevier
today and that had some problems, with headers relating to the main header
style. However, the main issue for me is that they want to have the
manuscript files as docx or doc and do not accept anything. However, as I
been an editor of an Ashgate Book Series years a go I find that somewhat
hard to understand. At my time also plain ascii was acceptable, typesetters
did not need word or any other type of word processor file. Have times
changed? Scribus reads plain text and works better like that, so ...

Oh, well this goes to a private rant so I'll stop here.