Please see https://issues.apache.org/ooo/show_bug.cgi?id=39582 for the proposal in OOo. I think that this would be a very useful addition to the methods of laying out. The original issue contains good examples I think the mechanism would be similar to but marginal headings require word flow within the margin, and in-line headings do not. This is more or less a heading with no paragraph break at the end. See https://bugs.freedesktop.org/show_bug.cgi?id=48457 for similar marginal headings proposal
Bump - still unconfirmed after 6 months
Unfortunately part of the reason this has been in UNCONFIRMED for so long is because it requires us to dig through comments on someone else's bug tracker. We require clear and concise information on our bug tracker - saying "click this link and see" is not sufficient. Please provide the information here and if necessary say "see comment #n" on PROVIDE LINK) - vs. just "go browse this extensive bug report on AOO's framework. Marking as NEEDINFO. Once clear info is provided here, including pointers to what comments we should look at on the link you provided, mark as UNCONFIRMED and we'll see if we can at least get it to NEW status. Thanks for your understanding
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)
This is neccessarify for creating academic papers adhering to the very common APA style: http://blog.apastyle.org/apastyle/2009/07/five-essential-tips-for-apa-style-headings.html
OK, I've provided what was asked for, and we have some independent comment supporting it. can we move on now?
Moving on just means waiting for someone to triage - it's an enhancement request so honestly the priority on it is much lower. Right now the focus is on triaging issues for the upcoming 4.2 release. If you have time to help QA team with some triage work - the more people we have on board, the faster we can deal with these kinds of enhancement requests (at least triaging them, getting a developer to volunteer to do it is a whole different challenge).
That being said - your description is very concise. Agreed it's a valid request. Marking as: New Enhancement Medium - I don't see this benefiting a huge proportion of our user base (most use our software for basic things) but as the comment points out, it could be required for "higher end" tasks such as academic papers. Also: Might be an easy hack so adding that, I agree with the idea that there should just be a check box that by default is unchecked but which can be unchecked and it says something like "In-Line Heading" and can be applied to any style
Created attachment 92849 [details] ODT demonstrating workaround using index entries This particular issue of run-in / in-line headings can be worked around using index entries: 1. Insert run-in / in-line heading (plain text) with ensuing text e.g., "Heading level 3 Text text ..." 2. Highlight "Heading level 3". 3. Insert > Indexes and Tables > Entry... 4. Select Index of "Table of Contents" > set Level to "3" > click Insert > click Close. 5. Place cursor where the ToC is to be inserted. 6. Insert > Indexes and Tables > Indexes and Tables... 7. Index/Table tab > ensure Create from "Index marks" option is checked (default setting) > click OK. The attached document provides a four-level example, with levels 1 and 2 being standard paragraph styles Heading 1 and Heading 2, and levels 3 and 4 created using the index entry method provided. Tested using v4.1.4.2 Build ID: 0a0440ccc0227ad9829de5f46be37cfb6edcf72.
I still think this is worth persuing, even though it's been a long time. The work around is too confusing for casual users, even though it is clever
Another bump. I have used the work-around but it is not an obvious style, does not play well with the navigator, and I have to come back here to remember how to do it. This remains a needed enhancement.
Please don't bump bugs - that's not how this project works. The enhancement will be done only if a volunteer takes interest.
*** Bug 99695 has been marked as a duplicate of this bug. ***
Just came across this as I discovered the ion-line/run-in key words when building 99695 (see dup link above). My comments there have some additional info. My proposal was simply to allow the use of Character Styles in the ToC in addition to Paragraph Styles. In that way, one could create a set of specific inheriting Character Styles for various ToC (or index or bibs) levels, and it would be relatively easy to share those styles, making an effective and easy to use template much simpler. Owen's workaround is much better than others I have seen, but it would in my view still be an all round functional improvement to be able to use Character Styles in addition to Paragraph styles. If you disagree that this is a dupe we can always split it up again....
(In reply to Joel Madero from comment #7) > That being said - your description is very concise. Agreed it's a valid > request. > > Marking as: > New > Enhancement > Medium - I don't see this benefiting a huge proportion of our user base > (most use our software for basic things) but as the comment points out, it > could be required for "higher end" tasks such as academic papers. > > Also: > Might be an easy hack so adding that, I agree with the idea that there > should just be a check box that by default is unchecked but which can be > unchecked and it says something like "In-Line Heading" and can be applied to > any style Re: "most use our software for basic things" -- I don't know what the source of your data is, but with shrinking education budgets everywhere one looks, more and more students employing LO, and students writing academic papers perhaps numbering over half the potential user base for the product, I'd say you were being a touch myopic..... Re: "might be an easy hack" -- yes, and I think simply tweaking the ToC generator to accept Character Styles for indexing might even be easier.
Further to Owen's work around in comment 8, seems the desired effect can also be achieved with a pair of linked Text Frames. The first Text Frame contains the text to be used as the index or ToC is linked to a second that has the same anchor. Simply duplicate the text and formatting of the run-in in the second, they'll overlay (or use white space). Borders will need to be cleared, and spacing above/below to other paragraphs might need to be adjusted. Apply outline level to the paragraph in 1st frame--it will pick up in Index/ToC. The linked frames also work for the Side headings of original AOO bz#39582 As Text Frames (unlike Draw Text Box), they take all available formatting for the contained text. Might be a little fiddly to get the exact spacing for a given publication "style"--but ought to be functional until a dev decides to hack at things.
Text frames does look like another workaround, but in that case, bug #101765 (cursor movement between "normal" text paragraphs and those paras inside text frames) would of course facilitate this process, along with but #101773 (link a frame style to a para style, to make applying easier).
What is this bug about now? * In-line paragraphs - dupe of 46023. * Allowing character styles in ToC - interesting prospect, but then amend the title accordingly. Would also need to discuss if a document could having its "Heading N" style switched from PS to CS and back. * Two-frame structures which look like a full paragraph with a run-in heading Please decide and clarify using the bug title. In particular, whoever marked this as NEW - which suggestion did you confirm?
As the originator I still have a clear view that this suggestion is about run-in headings. Not about any of the work-arounds. I wanted the heading to be in a heading style (font, colour, size as any other heading) but without being on a separate line. So it could look like a heading, and appear in indexes and TOC, but with the body text flowing on on the same line (base line of body text font and heading font alighned, one imagines).
*** Bug 160087 has been marked as a duplicate of this bug. ***
In fact Writer should handle inline headings correctly as they are describable by html and css (as shown in duplicate bug before): Have <html> <head> <style type="text/css"> h2{ display:inline; } </style> </head> <body> <p><h2>My 1st. sub chapter</h2> And the text of its first paragraph</p> </body> </html> in an html file. Open that one in Writer and your favorite browser. Actual Results in Writer: My 1st. sub chapter And the text of its first paragraph Expected Results: My 1st. sub chapter And the text of its first paragraph
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/7a35f3dc7419d833b8f47069c4df63e900ccb880 tdf#48459 sw inline heading: apply it on the selected words It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Full commit description: tdf#48459 sw inline heading: apply it on the selected words Selected text at the beginning of a paragraph (<= 75 characters) become text frame based inline heading at applying a paragraph style (using Formatting toolbar, context menu, Ctrl-1...Ctrl-5 or Styles sidebar panel). If the whole paragraph is selected, or if no or multiple paragraphs are selected, formatting is still applied on the whole paragraphs. Using text frames for inline heading is ODF 1.0 compliant and fully back-compatible with the older Writer versions. The new inline heading frame contains direct formatting to zero the upper and bottom paragraph margin to solve interoperability issues: in MSO, margins of heading styles are zeroed by using the style separators. Note: lack of inline heading was a showstopper for creating APA-, IEEE-, MIL-STD-961E-format, legal etc. documents. Note: recent Formula frame style will be replaced by the planned Inline Heading, which will be used by the DOCX filter to export OOXML style separators instead of text frames.
@Bob Harvey and all: thanks for the bug report and feedback! Note: New issues will be filed for the following developments: adding Inline Heading frame style, DOCX export, fixing Navigator usage, order of the PDF bookmarks, adding inline heading frames for a multiselection etc.
How the presented solution related to an html document described in comment [[#20]] (2024-09-17)?
I'm reopening this issue to discuss the viability of the recently implemented solution: 1- As shown in Bug 163650, the use of frames to simulate inline headings creates problems when those headings are numbered. Because every single example I've ever came across for "inline headings" uses numbering, this issue alone renders the proposed solution invalid. 2- Specially when using multi-column layout, a normal heading could easily take more than one line, breaking the text flow and making the proposed solution non functional (the frame will take the whole paragraph width, pushing the following text to the next line and breaking the "inline" feature). 3- The proposed solution is not a proper one, but a workaround. The only way to achieve a proper solution would be a change in how Writer processes paragraphs, allowing a paragraph break without a line break (LaTeX does exactly that). I know that ODF does not, at the moment, allows the implementation of a proper solution, but workarounds should not be presented as proper solutions, even if there are no proper solutions in sight, because workarounds *always* break. And as discussed above, this particular workaround breaks quite easily. For that reason I ask the developers to consider retracting the patch. Workarounds (there are more than one for this issue) could be packaged as extensions.
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/a1dcbd1d1ce6071d48bb5df26d7839aeb21b75a8 tdf#48459 sw inline heading: add Inline Heading frame style It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Full commit description: tdf#48459 sw inline heading: add Inline Heading frame style Add the new frame style Inline Heading with default variable width and anchoring as character to support UX better – and later, – interoperability. Note: the previous commit (7a35f3dc7419d833b8f47069c4df63e900ccb880) used the Formula style for inline headings. Note: adjust check_styles.py unit test according to the extended frame style list. Follow-up to commit 7a35f3dc7419d833b8f47069c4df63e900ccb880 "tdf#48459 sw inline heading: apply it on the selected words".
Full commit description of the upcoming commit (https://gerrit.libreoffice.org/c/core/+/175835): tdf#48459 tdf#131728 sw inline heading: new frame style: fix DOCX export Export Inline Heading frame style as OOXML style separator, fixing interoperability of the newly created inline headings. Remove frame grab-bagging, use the new Inline Heading style for round-trip of DOCX documents. Note: paragraph grab-bagging is used only for the case, where no frame created for the inline heading (second or more inline heading paragraphs in the same paragraph layout). Now the DOCX import uses anchoring as character, fixing layout problems of short paragraphs with big size headings anchored *to character* previously. Follow-up to commit 7a35f3dc7419d833b8f47069c4df63e900ccb880 "tdf#48459 sw inline heading: apply it on the selected words", commit d87cf67f8f3346a1e380383917a3a4552fd9248e "tdf#131728 sw inline heading: fix missing/broken DOCX export" and commit a1dcbd1d1ce6071d48bb5df26d7839aeb21b75a8 "tdf48459 sw inline heading: add Inline Heading frame style".
(In reply to Vollbracht from comment #24) > How the presented solution related to an html document described in comment > [[#20]] (2024-09-17)? The recent patches are the the first steps to reach and exceed the (X)HTML/CSS solution (which are not compatible with OpenDocument, and which are not for *editing*, i.e. there is no UX layer above the standard). Adding (X)HTML/CSS support to them, Writer will be a *fully* compatible editor of the HTML documents with standard inline headings. I've checked the recent HTML export, and the following replacement was able to demonstrate/achieve this (using Heading 1 for inline heading): cat original.html | sed 's/<div style="min-width:0cm;min-height:0cm;"><h1 /<div style="min-width:0cm;min-height:0cm;display:inline;"><h1 style="display:inline;" /' >inline_headings.html The interesting/important thing, that the <div> of the frame, i.e. the inline heading doesn't create a rigid box/rectangle, if it exceeds the paragraph line: it allows the other text content to follow immediately the end of the text of the inline heading. This is exactly what we need, and perhaps a similar layout change in Writer would not contradict the OpenDocument standard.
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/49765a9e7be41d4908729ff7d838755276b244cb tdf#48459 tdf#131728 sw inline heading: new frame style: fix DOCX export It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to RGB from comment #25) > I'm reopening this issue to discuss the viability of the recently > implemented solution: I suggest to reopen Bug 46023 (I planned to do that) for a general, style-level, ODF-enhancement-based inline heading support. This bug is only about basic/core inline heading support. The good thing, that these are not mutually exclusive. The solution for the basic inline heading support can be part of the style-level solution, too. > > 1- As shown in Bug 163650, the use of frames to simulate inline headings > creates problems when those headings are numbered. Because every single > example I've ever came across for "inline headings" uses numbering, this > issue alone renders the proposed solution invalid. Single level numbering is supported. Multiple-level numbering would be a nice enhancement, at least, over OOXML/MSO interoperability, because it seems, MSO doesn't support multi-level numbering either (it does exactly what Writer is doing now according to my investigation). > > 2- Specially when using multi-column layout, a normal heading could easily > take more than one line, breaking the text flow and making the proposed > solution non functional (the frame will take the whole paragraph width, > pushing the following text to the next line and breaking the "inline" > feature). This means only that in corner cases, we got the same behavior, as before. As I mentioned at the end of Comment 29, it's possible, that this is only a layout problem, and we can interpret/fix Writer layout for variable-width multi-line frames anchored as characters as Firefox/Google Chrome do with display:inline <div>s, i.e. following the end of the inline heading "within" the frame, i.e. without breaking "inline" feature. It's worth to note, that with the recent fixes, DOCX import and export works, as intended: The exported DOCX document contains OOXML-compliant inline headings (style separators), opened without interoperability or layout problems in MSO. Also similar (X)HTML/CSS-compliant export is achievable with the recent workaround. > > 3- The proposed solution is not a proper one, but a workaround. The only way > to achieve a proper solution would be a change in how Writer processes > paragraphs, allowing a paragraph break without a line break (LaTeX does > exactly that). With the last patches, also on the basis of the above, this is more, than a workaround. This is already Writer core and DOCX filter enhancements, so no need to install extensions. It solves also OOXML interoperability, it will solve HTML export, PDF bookmark export etc. problems soon, and likely can be an excellent base for the future ODF/UX extensions. > > I know that ODF does not, at the moment, allows the implementation of a > proper solution, but workarounds should not be presented as proper > solutions, even if there are no proper solutions in sight, because > workarounds *always* break. And as discussed above, this particular > workaround breaks quite easily. For that reason I ask the developers to > consider retracting the patch. > > Workarounds (there are more than one for this issue) could be packaged as > extensions. Adding a boolean variable "inline" to ODF paragraph settings, automating/creating/removing/hiding the frames, fixing frame layout seem for me the simplest way to create the style-level inline heading support. But this won't solve that MSO still contains a workaround for the multiple inline headings in the same paragraph layout (based on special character styles). The bottleneck is the development, related to the highly complex Writer core, and we must choose the priority: better interoperability, i.e. full support of MSO's own workaround for inline headings, or continuing with more HTMLish/style based, standard-friendly approach. I think, it's easier to get support for interoperability.
And the standard-friendly approach will increase interoperability! I'd willingly wait a little longer if the alternative patch solution couldn't handle html/css inline headings as shown above.
Note: see fixed PDF ToC (= bookmark or outline) generation in Bug 95239 for this and for the DOCX import of style separators.
Patch https://git.libreoffice.org/core/+/a1dcbd1d1ce6071d48bb5df26d7839aeb21b75a8%5E%21 contains a copy & paste duplication error in sw/inc/strings.hrc at line 74 #define STR_POOLFRM_INLINE_HEADING NC_("STR_POOLFRM_MARGINAL", "Inline Heading") where the NC_("... is dup from a line above. This affects translation.
(In reply to Olivier Hallot from comment #34) > Patch > > https://git.libreoffice.org/core/+/ > a1dcbd1d1ce6071d48bb5df26d7839aeb21b75a8%5E%21 > > contains a copy & paste duplication error in sw/inc/strings.hrc at line 74 > > #define STR_POOLFRM_INLINE_HEADING NC_("STR_POOLFRM_MARGINAL", > "Inline Heading") > > where the NC_("... is dup from a line above. > > This affects translation. Proposed fix: https://gerrit.libreoffice.org/c/core/+/176210 @Olivier: thanks for the report!
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4f871a5a9aa1a81831bd525f31023b3915432dd7 tdf#48459 sw inline heading: fix bad NC of the new frame style It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Note: see fixed HTML export in Bug 163873, and fixed XSLT XHTML generation in Bug 163874 for this and for the DOCX import of style separators.