Issue 39582 - add support for run-in headings (next paragraph starts at the same line)
Summary: add support for run-in headings (next paragraph starts at the same line)
Status: CONFIRMED
Alias: None
Product: Writer
Classification: Application
Component: formatting (show other issues)
Version: OOo 1.1.3
Hardware: All All
: P3 Trivial with 11 votes (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords: oooqa, rfe_eval_ok
: 44075 53478 63425 (view as issue list)
Depends on:
Blocks:
 
Reported: 2004-12-26 07:47 UTC by uheinkel
Modified: 2013-08-07 14:41 UTC (History)
6 users (show)

See Also:
Issue Type: ENHANCEMENT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description uheinkel 2004-12-26 07:48:04 UTC
is it possible to have a formatting feature like FrameMakers run-in head
paragraph formatting? That means, the next parapgraph starts in the same line as
the previous one.
This feature is very useful when creating indexes with entries comming from
different paragraphs but have to be listed in the index on one line.
Comment 1 michael.ruess 2004-12-27 10:32:25 UTC
reassigned to "requirements".
Comment 2 lohmaier 2005-08-18 20:56:11 UTC
*** Issue 44075 has been marked as a duplicate of this issue. ***
Comment 3 lohmaier 2005-08-18 20:56:33 UTC
*** Issue 53478 has been marked as a duplicate of this issue. ***
Comment 4 lohmaier 2005-08-18 20:59:09 UTC
confirming, setting keywords
Comment 5 bobharvey 2006-04-04 08:19:03 UTC
When is a paragraph not a paragraph.  One gentleman at: 
http://www.oooforum.org/forum/viewtopic.phtml?p=138114#138114 points out that a 
rival prodcut can do this, and that there are US government standards require 
it.


But in a separate thread another forum user wanted to lay out his pages with a 
chapter number on one line, and the chapter name on the next, but have both 
form a single TOC entity.  This seems related to me.  Run-ins require a 
paragraph without a line break, flowing TOC entries require a line break within 
a paragraph.  
http://www.oooforum.org/forum/viewtopic.phtml?t=34376


I think that both problems could be addressed together, if the relationship 
between paragraph end and line break was "broken" 
Comment 6 rbrogers 2006-04-04 13:52:26 UTC
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.
Comment 7 tooo 2006-04-04 19:21:58 UTC
Please note that run-in heads are somehow similar to side headingss (see Issue
53523). At least both styles of headings require the following paragraph to
start on the same (horizontal) line. The difference between run-in headings and
side headings is the vertical alignment of the paragraph representing the
heading and the following paragraph.
Comment 8 lohmaier 2006-04-04 20:12:45 UTC
*** Issue 63425 has been marked as a duplicate of this issue. ***
Comment 9 tooo 2006-04-05 06:42:56 UTC
From the example given in Issue 63425, it is rather a duplicate of Issue
53523 (side headings). The summary "Allow paragraph breaks within a line" of
course applies to this Issue 39582 (run in headings) as well as Issue
53523 (side headings).

Maybe it should be clarified, whether this Issue 39582 is only about run in
headings or whether it is in general about tow (or more?) paragraphs aligned on
one line. 

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.


Examples of side headings can be found in Issue 53523.
Comment 10 jeanweber 2009-08-04 21:17:28 UTC
Has there been any progress on this issue?
Comment 11 Joe Smith 2009-11-18 23:02:52 UTC
I would like to request support for inline lists:

    Earth's oceans: (1) Arctic Ocean, (2) Atlantic Ocean, (3) Indian Ocean,
    (4) Pacific Ocean, (5) Southern Ocean.

I don't see any requests for supporting such lists, but this issue would cover
both situations if it were addressed through a general way to mark any paragraph
as "inline".

Should I file a separate issue?
Comment 12 peterjschroeder 2011-01-22 04:00:09 UTC
It's been over 6 years, and still no update on this?
Comment 13 urmasd 2012-04-09 17:14:06 UTC
Because everybody knowledgeable enough to make such serious code changes had left the project long ago.
Comment 14 orcmid 2012-04-09 19:02:17 UTC
Or, put another way, the paragraph begins with a heading as its initial text.

I always liked that capability.  It is particularly handy when doing numbering of paragraphs as individual sub-sub-...-sub-sections.  It also works when the section number is all there is to the heading.  Many technical and formal documents benefit from that scheme.  I do it on web pages (by manual means though).

I think the key question, in pursuing this, is to figure out whether and how ODF 1.2 supports such a provision or whether it requires a style extension of some form.  Currently, headings and paragraphs are independent paragraph-level formats.  

THINKING OUT LOUD - INSTANT DESIGN
  
This is an useful feature, but ODF 1.2 has no way of representing such an arrangement at the present time.

A potentially really-bad idea is to embed a <text:h> inside of the <text:p> (or vice versa).  This is not allowed in ODF 1.2.  There are weird ways to do this indirectly using frames, but it is not clear how well that works and it would be difficult to make easy for users and to recognize the hack on incoming documents (and in interchange with other formats).  

One could introduce an OpenOffice extension to ODF 1.2 extended documents that would degrade properly when not understood.  Something like <ooo:run-in-heading> could be a new element allowed in paragraqph content.  It could be done in such a way that consumers that did not recognize the extension would simply treat the text within the element as text of the paragraph, properly formatted but not recognized as heading.  (That is, it could be reduced to treatment as a <text:span> and it might always have a <text:span> within it to accomplish exactly that.  This might show the last of any auto-numbering, but it might not update properly when the document is edited where the run-in feature is not understood. 

THEN WHAT?

Assuming that a workable method comes up, the next question is how resilient is it when documents formed using the chosen technique are opened by other ODF-supporting software that has never seen it before.  

This is a factor in conversion for interchange with other formats, including PDF, Microsoft Office Word, HTML, etc.  

Also, there are many interdependencies with places where headings have an impact, such as in cross-references, the autonumbering, the reflection of current headings in headers and footers and tables of content, etc.

BOTTOM LINE

Great feature.  Obvious appeal.  Simple to ask for.  Not so simple to provide in a robust way.  The use of a carefully-crafted extension element that fails smoothly is the best prospect.
Comment 15 orcmid 2012-04-09 19:07:41 UTC
(In reply to comment #5)
> But in a separate thread another forum user wanted to lay out his pages with a 
> chapter number on one line, and the chapter name on the next, but have both 
> form a single TOC entity.  This seems related to me.  Run-ins require a 
> paragraph without a line break, flowing TOC entries require a line break within 
> a paragraph.  
> http://www.oooforum.org/forum/viewtopic.phtml?t=34376
> I think that both problems could be addressed together, if the relationship 
> between paragraph end and line break was "broken" 

There is no ODF prohibition of line breaks in headings and that should work in the TOC lines as well.  It is the same provision that allows hard line breaks to be included in the body of paragraphs without starting a new paragraph.

If this doesn't work in a particular place in OpenOffice, a bug should be reported on the specific case.
Comment 16 orcmid 2012-04-09 19:09:55 UTC
(In reply to comment #5)
> But in a separate thread another forum user wanted to lay out his pages with a 
> chapter number on one line, and the chapter name on the next, but have both 
> form a single TOC entity.  This seems related to me.  Run-ins require a 
> paragraph without a line break, flowing TOC entries require a line break within 
> a paragraph.  
> http://www.oooforum.org/forum/viewtopic.phtml?t=34376
> I think that both problems could be addressed together, if the relationship 
> between paragraph end and line break was "broken" 

There is no ODF prohibition of line breaks in headings and that should work in the TOC lines as well.  It is the same provision that allows hard line breaks to be included in the body of paragraphs without starting a new paragraph.

If this doesn't work in a particular place in OpenOffice, a bug should be reported on the specific case.
Comment 17 orcmid 2012-04-09 19:19:26 UTC
(In reply to comment #11)
> I would like to request support for inline lists:
>     Earth's oceans: (1) Arctic Ocean, (2) Atlantic Ocean, (3) Indian Ocean,
>     (4) Pacific Ocean, (5) Southern Ocean.
> I don't see any requests for supporting such lists, but this issue would cover
> both situations if it were addressed through a general way to mark any
> paragraph
> as "inline".
> Should I file a separate issue?

I think that having a paragraph style that indicates no break after the paragraph content might accomplish this.  both headings and paragraphs have paragraph styles so it could work generally.  Such a provision would make whatever follows a run-on.

This might be easier than adding a special run-in-heading element, while having all the benefits.  There are still interoperabilty issues.  In this case, if the style were not understood, the material would appear as separate paragraphs.  It would also take some effort to craft an in-line list using such a provision.

It is feasible at the ODF level.  Usability and how handy it is in the way OpenOffice provides editing of such situations remains an interesting consideration.
Comment 18 orcmid 2012-04-09 19:45:38 UTC
(In reply to comment #17)
> (In reply to comment #11)
> > I would like to request support for inline lists:
> >     Earth's oceans: (1) Arctic Ocean, (2) Atlantic Ocean, (3) Indian Ocean,
> >     (4) Pacific Ocean, (5) Southern Ocean.
> I think that having a paragraph style that indicates no break after the
> paragraph content might accomplish this. 
> [ ... ] There are still interoperabilty issues.  In this case, if
> the style were not understood, the material would appear as separate
> paragraphs.  It would also take some effort to craft an in-line list using such
> a provision.
> It is feasible at the ODF level.  Usability and how handy it is in the way
> OpenOffice provides editing of such situations remains an interesting
> consideration.

AFTERTHOUGHTS: When headings and paragraphs are run-together this way, it might also be important to adjust the spacing before, spacing after, and keep-together provisions to avoid weird breakage.  That would also help control the level of mess when any no-break-after style is not recognized.
Comment 19 Joe Smith 2012-10-19 21:37:57 UTC
I came across another situation where this feature would have come in really handy.

Clearly, much work would be needed to implement the inline layout but the file format wouldn't need a major upset. As far as I can see, it could be as simple as a new paragraph style attribute, something like text:layout-mode="inline". Since <text:h> headings already use a paragraph style, the attribute would be available to both headings and text.

The attribute could safely be ignored by older processors, in which case the inline material would be laid out as a block. Not nice, but existing documents would never expect inline text, so it's no worse than the current situation, or previous ODF enhancements,