Need for a style separator in Writer

English
, , , , ,
#1

Writer desperately needs a style separator similar to Word to enable two or more styles to appear on the same line. Without this Writer is almost useless for legal documents.

For example in patents and also contract writing there are often precedents to follow. BUT the use by lawyers and the courts of the Navigator (“Navigation pane” in Word) means that merely changing the font is not acceptable for a well indexed document using the navigator. Two examples are given following where // represents the style separator:

Clause 27 Breaches // (1) Any failure to make payment 
heading 2          // default (normal)
[0005]   // Problems resolved by the Invention // This inventions resolves the problem….
heading 3//…………...heading 2                    // default (normal)

Particularly for patents you are forced to use Word to achieve the referencing of the headings and paragraph numbers as separate items, also keeping spaces to a minimum following the editing/formatting conventions.
The above patent example results in the navigator indicating:

[0005] 
Problems resolved by the Invention

Big Q is whether there is a workaround for 2 styles and 3 styles on the same line where one or more of the styles is used as a heading. The ¶¶ Word symbol for there in-line style separator needs to be achieved for Writer to be functional for legal documents and also business presentations such as company outlines and quarterly reports. This is because the various headings also act to create the pdf bookmarks list used commonly as a table of contents in sizeable business and scientific documents posted online.

When will a programmer achieve ¶¶ functionality?

Edited by Jim K to add proper spacing.

#2

@legaleagle: Please do not check the community wiki box. See guidelines for asking. Also, enhancement requests are off-topic for this site.

#3

Apart from bounding a sequence of words for the sake of defining a limited TOC entry, would character styles (which don’t exist as such in M$ Word) satisfy the requirement/need?

1 Like
#4

Two or more character styles can appear on the same line. In contrast, paragraph styles apply unsurprisingly to the entire paragraph.

One solution is to create a frame for each separate style. Go to Insert → Frame to create the first one. Format the frame to remove borders and extra spacing, and anchor As Character. Then copy and paste to create additional frames.

Sample ODT File

frame for each pagagraph style

navigator

#11

Creating frames is not a solution, given that documents must be shared with other entities that do not allow the usage of frames in a document. The only real solution to this Ask is for TDF to mimic the functionality of MS Word’s Style Separator. Period. Also, commentators should be encouraged to eschew phrases like “one solution is…” and “workaround.” Multiple solutions and workarounds are not features, they are useless suggestions that people don’t won’t and, literally, in some cases are not able to use.

#12

Creating frames will also cause problems in the sequence of headings potentially leading to a TOC where entries are ordered in a rather erratic way (numbers don’t increase monotonically).

Presently, inline headings are not offered in Writer but this has been requested as an improvement. Since development is based on volunteers, implementation of the feature may not be offered within the deadline of your document.

Meanwhile, you have to resort to workarounds. Workarounds are not “useless”; they are temporary (and in this case, contorted) procedure to compensate for the missing feature.

Inline headings can be simulated in present Writer, but are you willing to use it? I warn you: the known workaround is based on heavy usage of styles, fields and cross-references. Are you familiar with styles? Or are you conditioned by Word’s compulsory direct formatting induced procedures?

The workaround is tricky. To make it easier for “people” (which skills?), a template of the workaround can be stored as an AutoText entry, making it only a few keystrokes away. Then this template is customised for the specific heading (essentially entering the real heading).

If you accept to go forward, ask a dedicated question about inline headings because the workaround needs a lengthy explanation which don’t really fit in the current topic.

#5

Merely changing styles is understood. But for achieving heading references in the navigator - so that the pdf bookmark index is complete for a final document - it is necessary to have the capability inserting 2 different headings in the one line.
The sample odt is much appreciated and I will use for internal documents.
Unfortunately it is usually a formatting rule in legal document preparation not to use text boxes as these can be easily moved to the wrong place or accidentally deleted. The M$Word ¶¶style separator complies with the plain text rules for production of evidence, hence I need a writer equivalent for transacted documents. Apparently my search for an effective equivalent has not borne fruit y

#6

“These can be easily moved to the wrong place or accidentally deleted.” Any text can be easily moved or deleted. The frames are anchored “As Character” meaning that they behave in the same way as any other text. Did you realize that these are not MS Word text boxes, but rather LibreOffice frames?

#7

“…heading references in the navigator…” This is shown in my screenshot from the sample ODT file, correct?

#8

You can try this tutorial: https://forum.openoffice.org/en/forum/viewtopic.php?f=71&t=709. It may not solve all your problems, but who knows.

#9

Workarounds are simply not acceptable to “professional” users of Writer, or any other program, for that matter. Either LO programmers will fix this issue, of they won’t. As of this post, it does not appear to have been fixed.

#10

“Workaround” is a word for a procedure targetting a non-existent feature. Then either the goal is wrong (obviously this does not apply to legal or patent tradition) or the “workaround” is the correct way of doing things. @anon87010807 provided a solution. Sure, it can be improved but it is an excellent start.

A “professional” writer always begin by creating tools such as templates, styles and macros to specialise the application and ease his work.

If I reverse the argument, M$ Word is plaged with workarounds considering the plethora of [useful] features present in LO Writer and not in M$ W.

#13

Hi,

would the InLine Headings extension be of any help here?

#14

I have not tested it but it seems to be worth a try. If it encapsulates the known tricky steps inside an easy to apply macro without direct formatting, that’s good.

EDIT
I experimented a bit with it. Seems to add the missing feature in a user-friendly way. Technically, it is slightly different from the known “classic” method. It may somehow introduce a few restrictions on the formatting possibilities (advanced uses). If care is not taken on the “small” dummy headings (necessary to create consistent numbering, this is the basis for the trick), you can end up with a buggy TOC.

I have no idea how the TOC is collected (since implementation is different from the standard trick; a macro?) but it works.

A useful extension while waiting for a full-fledged feature.

EDIT 2023-12-04

While working on another question, I came to an “easy” solution (or yet another workaround ?) for this allowing to have as many run-in headings as you like in a single line.

  1. the whole paragraph is styled for the final part of it (the argumentation), frequently Body Text
  2. select the sequence of words belonging in the heading at this level
  3. Insert>TOC & Index>Index Entry
  4. choose TOC for Index: and set the target level in Index level:
  5. Insert
  6. use an adequate character style to highlight and format your inline heading

Repeat for each run-in heading at beginning of the paragraph.

Don’t forget to tick Index entries box when generating the TOC.

The procedure above handles correctly the TOC. However, such index entries are not considered real headings and cannot be cross-referenced with heading-targeted fields. They can’t be automatically numbered neither with outline numbering sequence nor with a custom list style.

#15

It actually is what it does :slight_smile:

#16

The Heading N paragraph styles are preserved but turned into invisible smallish things. Thus the TOC can be generated in a normal way.
The user only sees entries made up with a new character style which settings are copied from the original Heading N style.
If the user wants to change some heading text, she must use the “revert” toolbutton which resets the whole thing and gives the original styles settings back (they are kept as special hidden styles).

#17

I saw the 2pt Heading n paragraphs but they are empty. The actual heading is at start of next paragraph. It is not cross-referenced in any way. So I couldn’t find how it is captured to build the TOC. If I change the wording and right-click on TOC to update it (without rerunning the extension), everything is fine. Is there some kind of listener macro? That’s some magic for me. From what I know, headings are captured from Heading n paragraphs. Here they are empty after conversion from “standard” to “run-in” but everything is correct. That’s a decent job and I’d like to know how it is done.

#18

No, they’re not empty :smiley:
For a quick check: modify the Heading N paragraph so that it recovers its height and automatic colour.

BTW, here’s the ILH (inline heading) creation process

A. Preparation

  1. Create a new paragraph style with the same parameters as the Heading N style selected (through inheritance). This style is named ILH_heading_<N> and hidden. It is used for the undo mechanism.
  2. Create a new character style with the same character settings as the Heading style selected. This style is named ILH_heading_<N> and hidden. It is used for the to-be inlined characters formatting.
  3. Create a new character style for hiding the inline markers. This style is named ILH_mark_N and hidden.

B. Process

  1. Save the current visible cursor position.
  2. Browse the document from the beginning until the end
    Whenever a selected level heading is met:
    a. Get its text
    b. Change the Heading N style properties so that it is small (2pt) and invisible (white foreground).
    c. Insert the heading text on the next line with special marks at both ends (these will allow to undo/remove all inlined text) and give it the ILH_heading_N char style (this way, the Heading N paragraph aspect is reproduced).
  3. Return to the saved cursor position.

That’s it. There’re some more details (reproducing chapter numbering, adding text separators) but you get the picture. And of course, UI l10n support…

Since the actual Heading N paragraphs (now invisible) still hold the original text and keep their level value, they’re correctly referenced in TOC and crossrefs. No magic here, sorry :wink:

The undo mechanism/button simply:

  1. Suppresses the text between marks (including marks).
  2. Resets the Heading N paragraph style to its original settings, by copying them from the ILH_heading_N hidden para style.
  3. Removes all ILH_ styles.
#20

Thanks, I missed the white foreground trick because my experiment used short headings which didn’t visually moved a lot the paragraph mark. Globally this is exactly the known trick for run-in headings with the added possibility of Undo.

Since you seem to be the author of the extension, may I suggest an improvement?
Setting foreground colour to white may keep the real heading visible if background colour is not white. Foreground should be the same as background. However, I don’t know how to create a universal solution because background colour depends on page style (or section) and there is no reason for these background colours to be the same. And a style can have only one fixed colour. Unless you add direct formatting for this. I usually don’t like DF but your headings are completely handled by your macros and this could be acceptable.
A second minor point is the pathological case of overly long headings, though they don’t really make sense with run-in headings (all the more since real heading is entered in 2pt size). These overlong headings need more than one line. This results in noticeable extra spacing added to spacing above of next paragraph. Unfortunately, unlike other attributes, Hidden is kept during TOC collection and can’t be used to hide the real heading (while caring to keep at least a not hidden space to avoid complete elimination of heading for numbering purpose). So I have no idea how to handle this.

#21

Hi AJ,

thanks for the suggestions and comments (as accurate as usual). I’ll keep them for inclusion in future versions.

I have already thought about the hidden paragraph style colour. The only way I can see is what you describe: overload the heading style font colour to fit the current document/section background.

As for overly long headings, I guess this is somewhat difficult to handle.

Best

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.