https://bugs.freedesktop.org/show_bug.cgi?id=48459

--- Comment #3 from Bob Harvey <[email protected]> ---
Right-oh

An 'Inline' or 'Inset' or 'Run-in' heading is one in which there is no newline
at the end of the heading.  The succeeding paragraph text ('running text') runs
on in smaller type on the same line.  The heading is still a separate
'paragraph' for logical purposes, e.g. creation of TOC or style selection or
numbering, but the text does not start on the next line down.   This would
frequently be used for low-order headings, heading level 3 or 4 downwards, in
complex documents.

If the text height of the heading is sufficiently large then the succeeding
paragraph may flow onto two or more lines on the right of the heading, in a
layout similar to a 'Drop Caps' where the first letter of a paragraph is formed
as a massive decorative 'drop capital' with the rest of the paragraph flowing
around it.  This could be used to simulate a drop cap, although it would not be
a true one because the first word of the paragraph would be incomplete by one
letter, leading to errors in word count and perhaps indexing.  I hesitate to
suggest a true 'Drop Cap' word style, though it would be fun.


It seems to me that this could be done by allowing any paragraph style (and
hence any heading style) to include a boolean indicating whether the paragraph
ends with a line break or not.   This is not unlike specifying the white space
below a paragraph, but with the addition of it being null.  Or, rather, very
short: I imagine some mechanism to specify alignment  minimum white space after
the heading and before the running text would be needed.  This sounds
suspiciously like another very specialist tab to me: the default or body text
style could be preset with two or three 'inline starting point' tabs to allow
the page to look nice, and the running text start points to line up down the
page regardless of heading lengths.

Note, too, that the vertical alignment of the main 'running text' and of the
inital 'run-in heading' is non-obvious.  they might want to be be bottom
aligned (base aligned) in simple cases, but where the heading is made very
large they will need to be top aligned.  I suspect this will want to be user
selected too.

Don't forget too that design decisions here might interact with Bug 48457 for
'marginal' or 'outset' headings.



Stealing from the OpenOffice bug request you mention (which still seems jolly
accessible to me, don't really understand the problem) here is an example:
------------------------------------------
Example for run-in headings:

RUN-IN HEADING  Bla bla bla bla bla
bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla
bla bla bla bla bla.

Bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla
bla bla bla bla bla.

OTHER RUN-IN HEADING  Bla bla bla.

MORE RUN-IN HEADINGS  Bla bla bla 
bla bla bla bla bla bla bla bla bla
bla bla bla bla bla.
-------------------------------------------

Similarly, someone else said:
"Lack of r.i.h. is an absolute showstopper for creating IEEE- and
MIL-STD-961E-format documents. W*** accomplishes this by allowing you to set
the
paragraph mark between heading and para text to "hidden". Recent W*** versions
use a "style separator" with same effect; the paragraph as printed is formatted
with Heading X up to the style separator, and with e.g. Body Text after the
separator."



===============================
The original OO bug included an opposite but related proposal, where chapter
number and chapter name appear on successive lines in the text, but on a single
row of the TOC.  This implies having a single heading with an embedded line
break that is suppressed in the TOC and other cross-references. (this technique
is often seen in book layouts where the chapter number and name are
centre-justified at the top of the page)

-- 
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

Reply via email to