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.
Created attachment 185685 [details] Inline heading by CSS in HTML Do you look for something like display:inline as known from CSS in HTML? (See attachment)
(In reply to Regina Henschel from comment #1) > Created attachment 185685 [details] > Inline heading by CSS in HTML > > Do you look for something like display:inline as known from CSS in HTML? > (See attachment) I think the closest would be display:inline-block but it is not exactly the same. My proposal describes modifications to the raw CSS behaviour. In CSS, boxes are drawn independent from each other once their z-ordering has been determined. Here, I'd like some sort of merging between the two boxes (if this makes sense). If however you think that implementing some equivalent to display:inline[-block] is easier, why not? I nevertheless want to point out that the feature must remain consistent with the notion of text flow (or rather reading order). If "inline" implementation is based on frame engine, wrap mode must be forced to After so that no subsequent text is place at left of heading. Similarly, no subsequent text must be found above the heading. These two constraints coarsely guide where the block is positioned, with the additional factor that baselines must be aligned as much as possible. Your suggestion even allows the "drop caps" effect but user must be particularly careful in style configuration if such a layout is desired.
(In reply to Regina Henschel from comment #1) Note that in CSS, marking an object with display: inline makes it not-a-block-object, so that all those style aspects regarding block objects don't apply to it. In other words, it's like saying "this paragraph is not really a paragraph, it's basically like an HTML span or other inline elements..
(In reply to ajlittoz from comment #0) First let me ask about the motivation. I can see two kinds: 1. Limitation of the text adopted for indices/tables/bookmarks; 2. Implementation of inline lists (and this would require some more description which you have not provided) Is there something else? Now, about how such paragraphs would work: > - Line break is suppressed. > - Space below of run-in style is ignored Don't you mean constrained to 0? > - Bottom border is suppressed (though it is expected users won't request > borders) How is that expected? Wouldn't the user expect a border below the part of the inline paragraph on the bottom line? Or perhaps, for there to be a border if continuing paragraph doesn't have one? Also, what about different line spacing values for this paragraph and the next one? Or multiple inline paragraphs on the same line? > - In case of justification, last line justification is suppressed to revert > to left (adapt for RTL) What if the inline paragraph is RTL, and the next paragraph is LTR? For that matter, what if you have inline paragraphs on the same line with Left, Center and Right alignment? > - Left indent is used as usual because it defines the starting position of > the line No it doesn't, at least not necessarily. Suppose I have two LTR inline-paragraphs within the same line. The first one is right-aligned, the second one is left-aligned. And, for that matter, what happens with the overlaps? How do you order overflow from these two paragraphs on the next line? ... and what do you do when you have 3, or 4, inline paragraphs on the same 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). As discussed above, not true. > - By definition of run-in, the base line is the same for the run-in > paragraph and the subsequent one. What if the "run-in" is in English, with baseline at the bottom, while the next paragraph is in Devangari, with baseline at the top? > 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. > - Top border is suppressed. That would be unexpected by the user. If they specified spacing above or a border, they expect to have them. This is not like the run-in paragraph's style, for which you can assume the user knows in advance not all properties are to be respected. > - 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. As discussed above, you can't assume where on the first line the run-in paragraph is to be placed. > - 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. > Such a run-in paragraph style keeps all the other properties of paragraph > styles So, here's the thing. Actually, what you describe necessarily must loses essentially all properties of a paragraph: * Spacing (and probably indentation) * Border * Direction * Alignment * (Tabs - probably) * Drop Caps - by your suggestion There's almost nothing remaining that's not character properties, except perhaps list item association, and even that's not trivial because of positioning and spacing. With this in mind, I don't think these can properly be described as inline paragraphs.
Finally, I believe this is a dupe of 46023, since it suggests a specific kind of implementation rather than a different feature.
Let's close this one as dupe of bug 46023 ajlittoz if you disagree just reopen the bug report. thanks *** This bug has been marked as a duplicate of bug 46023 ***
(In reply to Roman Kuznetsov from comment #6) > Let's close this one as dupe of bug 46023 Be aware that comments in bug 46023 open questions but don't answer them. Here I have nearly the same questions but try to address them. Thus if bug 46023 is considered the "master entry" to the enhancement, it contains less information.