https://bugs.documentfoundation.org/show_bug.cgi?id=153904

            Bug ID: 153904
           Summary: [ENHANCEMENT] Allow for inline (= run-in) paragraph
                    styles
           Product: LibreOffice
           Version: unspecified
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: medium
         Component: Writer
          Assignee: [email protected]
          Reporter: [email protected]

Context:

Many graphical charters (e.g. APA or Chicago) require inline headings starting
from some depth. The same run-in layout is also used for captions in scientific
papers (see bug 127452 requesting such a feature under a different form).

The topic has already been requested by bug 46023 (WONTFIX). Bug 48459 (still
pending) contains a proposal and two workarounds.

- Bug 46023 comment 8 is based on the use of User Index and styles selection in
TOC. Unfortunately, this is incompatible with Chapter Numbering.
- Bug 46023 comment 15 suggest the use of frames. Once again, this is
incompatible with chapter numbering because text in frames resides in
independent text flows and their order relative to main flow is unspecified,
leading to numbering sequence errors.

Proposal:

My suggestion is to retain the idea to add a new option in paragraph style Text
Flow tab labelled "Inline paragraph" (close to Do not split paragraph). This
option is associated with a "spacing" distance.

Since the goal is to add new text after the end of the paragraph, the option is
validated only if alignment is left (right in RTL) or justify. The other
alignments are incompatible with run-in (right because no room is left at right
of paragraph; center because run-in becomes non-sensical).

When this option is enabled, the effect is to suppress the actions normally
associated to the end of paragraph:

- Line break is suppressed.
- In case of justification, last line justification is suppressed to revert to
left (adapt for RTL)
- Space below of run-in style is ignored
- Left indent is used as usual because it defines the starting position of the
line
- Right indent is pointless because we know we have a partial line (A run-in
paragraph is allowed to span several lines; only the last line receives special
handling).
- Bottom border is suppressed (though it is expected users won't request
borders)
- By definition of run-in, the base line is the same for the run-in paragraph
and the subsequent one.
Note: this supposes that users won't try to outsmart the feature by attempting
some "drop caps" effect as alluded in bug 48459. Run-in headings/captions and
following text usually are displayed in very close font size, the
distinguishing attribute being rather weight.

The new paragraph text is laid out immediately after the end of the run-in
paragraph at a distance defined by the "spacing" parameter of the option. Start
of paragraph actions are suppressed.

- Spacing above is suppressed.
- First line indent is ignored (because text is considered a continuation of
run-in para).
- Left indent is ignored on first line but becomes active for second and
subsequent lines.
- Right indent is used as usual.
- First line alignment is honoured just the same as the other lines
Note: for the purpose of alignment, run-in paragraph last line can be regarded
as a mini-frame and its bounding box passed as such to the layout algorithm if
possible.
- Top border is suppressed.

To avoid weird formatting, it is expected that users will configure their
paragraph styles in a compatible manner: same indents, close font size, no
borders, though any combination should be accepted even if it leads to
un-aesthetic results.

Such a run-in paragraph style keeps all the other properties of paragraph
styles, notably the possibility to be associated with a list style.
Consequently, run-in paragraphs remains compatible with chapter numbering (a
special internal list style). Some Heading n can then be turned into run-in
styles and this integrates smoothly into the TOC machinery.

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to