If a title (a "heading1", for example) is something like this: This is a very very very long long long title split over several lines. the title field will reflect the whole paragraph, but in my heading I want, instead of that, the following : A long title... That is, a reduced version. In latex, you can assign a brief "alias" to a very long title (something like \Chapter[brief title]{The very long complete title}), so if you use a fancy header, the alias and not the actual title is displayed in the header. In OOo, the title field display the whole paragraph, correctly aligned with line breaks when needed, but there is no way to set an "alias", which is an important limitation to the design of complex documents.
Sure, that would be an interesting possibility, though we may need to extend ODF at some point. This is slightly more than an easy hack... any taker for this?
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Dear bug submitter! Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs. To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem. Yours! Florian
RGB: I'm sorry if my question is dumb since I am not an expert of Writer, but what do you mean by the title field? Does this issue persist in current versions, and if so, can you provide a clear example?
(In reply to Philippe Cloutier from comment #7) > RGB: I'm sorry if my question is dumb since I am not an expert of Writer, > but what do you mean by the title field? Does this issue persist in current > versions, and if so, can you provide a clear example? A Heading field. At some point (this report is from 2010) it changed name: Insert → Field → More fields → under Document select Heading. Anyway, for some reason this report was closed on 2012 (back in the day I was not paying attention to online stuff). I'm reopening it because it's still relevant, I think.
Can you elaborate on the possible uses of the "short title field"? I want to understand whether this bug and 170459 are duplicates of each other, or whether you're asking for something slightly different. Specifically, what do you mean by "using a fancy header"? Also please say whether you're suggesting a plain-text alias, or formatted content.
The "fancy header" is not important for the discussion, it's just a LaTeX package that you use to set up your page headers. Writer offers a field to reference a heading (chapter or section title, for example) into the page headers, but it always copy the exact same text you wrote on the heading. LaTeX offers an option where you set not only the heading text, but also an alternative text to show on the header and the TOC. Sometimes you write a a long, descriptive chapter or section title, but it results too long for using on your headings (or the TOC, maybe), and that's where the "short title" comes in handy.
(In reply to RGB from comment #10) > but > it results too long for using on your headings (or the TOC, maybe), and > that's where the "short title" comes in handy. It should be "too long for using on your headers" (English can be confusing...)
*** Bug 170459 has been marked as a duplicate of this bug. ***
We surely cannot introduce an option where the user can specify alternate text for a paragraph, which is then shown on the ToC. What we can do is to protect manual changes and allow to only update the page numbers. My take here is WF.
(In reply to RGB from comment #10) > LaTeX offers an option where you set not only the > heading text, but also an alternative text to show on the header and the > TOC. And by "text" we mean content that may be formatted, right? i.e. how rich are we (or are you) asking for the alternative content to be? Anything one could put in a paragraph? Just plain text? Something in between? (In reply to Heiko Tietze from comment #13) > We surely cannot introduce an option where the user can specify alternate > text for a paragraph, which is then shown on the ToC. We surely can and that is this feature request. > What we can do is to > protect manual changes and allow to only update the page numbers. I don't see how that sentence is relevant to this bug...
(In reply to Heiko Tietze from comment #13) > We surely cannot introduce an option where the user can specify alternate > text for a paragraph, which is then shown on the ToC. What we can do is to > protect manual changes and allow to only update the page numbers. > > My take here is WF. I have seen several books that use an alternative text to indicate chapter names in the headers (an example I have at hand: "El Quijote") so it's a common practice. I strongly disagree with your comment on protecting manual changes, because that completely defeats the idea of a TOC.
Possible solutions: 1. Finish you document, create the ToC last of all, and modify manually 2. Insert a hidden paragraph with the ToC-specific heading and a non-heading with the same style to show in the document 3. Copy the ToC and paste as plain text 4. Write the heading as text in the simulated ToC and manually add a reference to the page number There are for sure many more solutions that are less convoluted as alternate text for a paragraph. The ToC consists of paragraphs that have some outline level - you can set this property at any PS. And as a consequence we need to offer alternate text for all PS. The few cases when this might be desirable do not justify to confuse every user at almost every time. Despite from the fact that such a feature needs to become standardized. As a solution I suggest to go with bug 169210, to allow updating only page numbers.
(In reply to Heiko Tietze from comment #16) > 1. Finish you document, create the ToC last of all, and modify manually * "Manually" is not a valid solution for something like a ToC. Even though we enable manual modification, our commitment must be to automated ToC generation. Including with alternative entry text. * After you finish, you notice you need to make changes. Or the person getting the document wants to make changes. i.e. there is no "last of all" > 2. Insert a hidden paragraph with the ToC-specific heading and a non-heading > with the same style to show in the document And if you automate something like that, you get the ask of this bug. > 3. Copy the ToC and paste as plain text Suffers from the same problem as (1.) > 4. Write the heading as text in the simulated ToC and manually add a > reference to the page number Suffers from the same problem as (1.) > There are for sure many more solutions that are less convoluted as alternate > text for a paragraph. The ToC consists of paragraphs that have some outline > level - you can set this property at any PS. And as a consequence we need to > offer alternate text for all PS. Yes, we do. Of course, that doesn't mean the user has to define alternate text for each paragraph. > The few cases when this might be desirable > do not justify to confuse every user at almost every time. Ok, so here is what we really need to talk about: Can this be achieved without confusing users _at all_? I am pretty sure that it can. > As a solution I suggest to go with bug 169210, to allow updating only page > numbers. Again, that does not solve anything - it still means one has to write the ToC manually. On the contrary, resolving this will open the way to users not having to make manual modifications at all, and perhaps even us eventually being able to drop that affordance. It may also be worth mentioning that this would be an improvement over what MS Office offers. They are still stuck with "fix your ToC on your own" since the 1990s.
(In reply to Heiko Tietze from comment #16) > Possible solutions: > > 1. Finish you document, create the ToC last of all, and modify manually > 2. Insert a hidden paragraph with the ToC-specific heading and a non-heading > with the same style to show in the document > 3. Copy the ToC and paste as plain text > 4. Write the heading as text in the simulated ToC and manually add a > reference to the page number Those are not solutions, but workarounds; and only for the TOC, they don't address the problem with the Chapter Field and its use in headers. For the matter, you can drag&drop headings from the Navigator and build your own pseudo-TOC by hand, but that's not the point. For reference, here is how LyX(1) implements this feature in its UI. 1. Start a heading (either a chapter, section, etc). 2. With the cursor on the heading, Insert → Short Title. That's it. A special field is created with, by default, a copy of the actual heading text inside it so you can edit it and get an alternative text. If you don't insert that field the actual heading is used for both, the TOC and the header content. If you insert the field then what you write on it is used instead. If the cursor is not on the header, the menu entry is hidden. On pure LaTeX, you can do even more, getting an alternative text for the headers but not for the TOC by using \chaptermark{Chapter title for header} \sectionmark{Section title for header} at any point. Indeed, you can use these codes to change the header content mid chapter, if you need such level of control. I have no idea how to implement all this on Writer, I'm not a software developer, but from an user perspective something that would be nice to have is a special text field that, if needed, you can insert on a heading and whose content takes preference over the actual heading content. --- (1) https://www.lyx.org/
(In reply to RGB from comment #18) > would be nice to have... That's my point. It would be nice to have for you (and a few other people) but is not crucial for functioning - and over-complicates the configuration. Saying that I'm not opposing any good idea to bring short title into work.
(In reply to Heiko Tietze from comment #19) > (In reply to RGB from comment #18) > > would be nice to have... > That's my point. It would be nice to have for you (and a few other people) > but is not crucial for functioning - and over-complicates the configuration. > Saying that I'm not opposing any good idea to bring short title into work. You don't know if we are "a few." And sure, I don't know if we are many either. Nobody knows. Nobody can claim that their "use case" is universal. I only know, thanks to the books I own and the fact that at least LaTeX implements it, that it's not an uncommon feature. That's why I filled out this enhancement request.
There are two solutions: the first is to create new page styles for the abbreviated titles, which is good for a long Chapter 1, which always starts on a new page (more information: https://help.libreoffice.org/latest/en-US/text/swriter/guide/header_pagestyles.html). The other solution is more general and likely comfortable, too: using a hidden short heading after the long heading – and if you need the short version on the first page, too, repeating that before the long heading, too. The header/footer show the abbreviated heading, which is invisible in the body text and in the ToC. A working test document is attached. – To show the hidden abbreviated headings referred in the header using style-ref, enable Tools→Options→LibreOffice Writer→Formatting Aids→Hidden characters; – To hide the short heading: select the whole heading with its paragraph mark, then enable Hidden in Format→Character→Font Effects. Note: the test document works with OpenOffice.org 3.2.1, LibreOffice 7.3.7.2. and the recent development version, too. Note: Because this method is not trivial at all, I suggest to extend the help about abbreviated headings in the header/footer. Moreover, the Help lacks of information: the Hidden effect is missing on the Font Effect pane and its Help page: https://help.libreoffice.org/latest/en-US/text/shared/01/05020200.html?DbPAR=SHARED#bm_id3153514). It was part of OpenOffice.org, LibreOffice 7.3.7.2, and it is part of the recent master again. @RGB & all: Thanks for the bug report and comments! Special thanks to Dávid Pénzes, who, as the composer of the Neveléstudomány (scientific journal of ELTE University, Budapest, which university was the conference venue of LiboCon 2025), has been asking me for advice on this for a very long time, but at that time I hadn't yet discovered this solution.
Created attachment 205474 [details] abbreviated_chapter_heading_in_the_header.odt: the solution using the hidden font effect
Created attachment 205475 [details] abbreviated_chapter_heading_in_the_header.pdf: PDF export of the previous test document
Created attachment 205477 [details] abbreviated_heading_in_the_header.png: screenshot of the hidden short headings with enabled visibility To show the hidden abbreviated headings referred in the header (see also https://help.libreoffice.org/latest/en-US/text/swriter/guide/header_with_chapter.html?DbPAR=WRITER#bm_id3155919 using Chapter (or using style-ref,) enable Tools→Options→LibreOffice Writer→Formatting Aids→Hidden characters).
(In reply to László Németh from comment #21) > – To show the hidden abbreviated headings referred in the header using > style-ref, enable Tools→Options→LibreOffice Writer→Formatting Aids→Hidden > characters; The solution works not only with the Styles (loext::style-ref) fields, but using the ODF-compliant Insert→Field→More Fields→Document→Heading: https://help.libreoffice.org/latest/en-US/text/swriter/guide/header_with_chapter.html?DbPAR=WRITER#bm_id3155919 using Chapter (or using style-ref,) enable Tools→Options→LibreOffice Writer→Formatting Aids→Hidden characters The attached test document uses the Document→Heading fields, not Styles fields. (Note: loext:style-ref is a relatively new, not standardized interoperability feature, developed by Skyler Grey (Collabora). It is a ~generalization of the Document→Heading fields. Using that is not back-compatible with OpenOffice.org or with the older LibreOffice versions, but it allows more freedom, for example, it can refer the last heading on the page, not only the first one. More information: https://www.youtube.com/watch?v=rVFG7qq-6xM and Bug 86790.)
Created attachment 205478 [details] abbreviated_chapter_heading_in_the_header.odt: the solution using the hidden font effect (the previous test document, with fixed description in it)
(In reply to László Németh from comment #21) > > The other solution is more general and likely comfortable, too: using a > hidden short heading after the long heading – and if you need the short > version on the first page, too, repeating that before the long heading, too. > The header/footer show the abbreviated heading, which is invisible in the > body text and in the ToC. > Except for the fact that BOTH headings will be present on the PDF index. I've been using Writer for almost 30 years, since the days of StarOffice, so the workarounds you mention are not new to me and all of them have issues. Anyway, LaTeX is still there, I suppose.
(In reply to László Németh from comment #21) > There are two solutions: the first is to create new page styles for the > abbreviated titles, which is good for a long Chapter 1, which always starts > on a new page (more information: > https://help.libreoffice.org/latest/en-US/text/swriter/guide/ > header_pagestyles.html). I don't understand this suggested solution. How would creating a new page style result in the ToC entry for my heading to have different text than the heading itself? And what does that have to do with pagination? > The other solution is more general and likely comfortable, too: using a > hidden short heading after the long heading – and if you need the short > version on the first page, too, repeating that before the long heading, too. > The header/footer show the abbreviated heading, which is invisible in the > body text and in the ToC. > > A working test document is attached. The test document is somewhat confusing, because all of the text is lorem ipsum gibberish that is hard to distinguish. But, be that as it may - the text in the ToC entries is the same text as in text body. Ah, I think perhaps you were focusing on page headers or footers. Remember what RGB said: That is just a use case of abbreviated text. The point is to be able to use a short version of the heading paragraph's text, wherever it is that you need to use it. The popular uses are in ToCs and in page headers or footers. I'm not sure I understand the second solution, even if we only thing about page headers, even after your expalanation. The different kinds of "Hidden" things - "Hidden characters", "Hidden text", "Hidden paragraphs" - each with their own toggle in Tools > Options - are thoroughly confusing. People should certainly not be treating alternative text as "hidden" actual text, and rely on using the UI for hiding things to achieve such an effect. Anyway, bottom line: it doesn't WORKSFORME, so un-resolving...
(In reply to RGB from comment #27) > > Except for the fact that BOTH headings will be present on the PDF index. > > I've been using Writer for almost 30 years, since the days of StarOffice, so > the workarounds you mention are not new to me and all of them have issues. > Anyway, LaTeX is still there, I suppose. (The interesting thing, I was also looking for a workaround, but I couldn't find one before. Maybe I didn't use the short heading *after* and *before* the long one?) I cannot reproduce the problem with the PDF index (bookmarks/outline), see the newly attached PDFs: it seems, the ToC export works correctly in LibreOffice and OpenOffice.org, too, using File->Export As->Export As PDF with Export outles. If your PDF export is still bad, can I ask for a detailed description, how is it possible to create it? I have some coding experience with the PDF outlines (fixing it when some of the headings are there inside text frames, see Bug 95239), so maybe we will be able to create a solution without any issues.
Created attachment 205484 [details] abbreviated_chapter_heading_in_the_header_with_PDF_bookmarks.pdf: export with PDF bookmarks
Created attachment 205485 [details] abbreviated_chapter_heading_in_the_header_ooo.pdf: OpenOffice.org export of the test document with PDF bookmarks
(In reply to Eyal Rozenberg from comment #28) > (In reply to László Németh from comment #21) > > There are two solutions: the first is to create new page styles for the > > abbreviated titles, which is good for a long Chapter 1, which always starts > > on a new page (more information: > > https://help.libreoffice.org/latest/en-US/text/swriter/guide/ > > header_pagestyles.html). > > I don't understand this suggested solution. How would creating a new page > style result in the ToC entry for my heading to have different text than the > heading itself? And what does that have to do with pagination? This bug was about marginals, header and footer. A new page style has own header and footer, so it's possible to use plain text in the header for the short chapter name. It's not hard to do it manually, if your document contains only a few long chapter names, and they start on new pages. Otherwise macro automation can use this workaround. This method would be a complete solution for the Neveléstudomány journal, where only the articles that start on a new page can have a very long title, which must be shortened for the header.) > > > The other solution is more general and likely comfortable, too: using a > > hidden short heading after the long heading – and if you need the short > > version on the first page, too, repeating that before the long heading, too. > > The header/footer show the abbreviated heading, which is invisible in the > > body text and in the ToC. > > > > A working test document is attached. > > The test document is somewhat confusing, because all of the text is lorem > ipsum gibberish that is hard to distinguish. But, be that as it may - the > text in the ToC entries is the same text as in text body. I think, this is the correct. The problem was the header/footer, where there was no place for the long text. > > Ah, I think perhaps you were focusing on page headers or footers. Remember > what RGB said: That is just a use case of abbreviated text. The point is to > be able to use a short version of the heading paragraph's text, wherever it > is that you need to use it. The popular uses are in ToCs and in page headers > or footers. I suggest to focus only on the page header/footer in this issue, because we have more multiple similar problems, than a single problem with multiple use cases. > > I'm not sure I understand the second solution, even if we only thing about > page headers, even after your expalanation. The different kinds of "Hidden" > things - "Hidden characters", "Hidden text", "Hidden paragraphs" - each with > their own toggle in Tools > Options - are thoroughly confusing. People > should certainly not be treating alternative text as "hidden" actual text, > and rely on using the UI for hiding things to achieve such an effect. > > Anyway, bottom line: it doesn't WORKSFORME, so un-resolving... Ah, it doesn't work for me either using numbered chapter names: it seems, hiding the paragraphs with Font Effect doesn't effect the numbering (maybe it's worth to check conditionally hidden paragraphs, too). It's possible to fix the numbering removing the numbers before the hidden chapter names (pressing backspace at the start of the paragraph), but the number removed from the header, too. For the numbered headings, I have a working solution using in my development code for Bug 163894, but only with shortening the long headers using partial formatting with the referred character style (e.g. "Lorem ipsum dolores..." -> "Lorem ipsum", without ellipsis. A promising preview is attached...
Created attachment 205486 [details] styleref example referring custom character style "Chapter1"
Created attachment 205487 [details] and its pdf print in an own tdf#163894 development version of Writer
(In reply to László Németh from comment #32) > This bug was about marginals, header and footer. > ... > ... > I suggest to focus only on the page header/footer in this issue, because we > have more multiple similar problems, than a single problem with multiple use > cases. We could do that, in principle. But: * That is not what OP opened this issue about. * There is already a dupe - my bug - which is about having different text in the ToC. so, is it really beneficial to limit the scope of this issue and split off the dupe?
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/cd9da3e6d7b0537625eedd0aa740b4e66dd3551e tdf#32363 sw DOCX: add unit test/documentation for shortening headings It will be available in 26.8.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.
Created attachment 205622 [details] tdf32363.docx: STYLEREF with character styles: the interoperable way to shorten titles in header/footer test document and detailed documentation for Writer
Created attachment 205623 [details] shortening.png: Writer screenshots, showing usage of STYLEREF with character styles (with enabled visibility of the hidden extra text: ellipsis, complete replacement of the titles for header/footer)
The new Styles field with character styles gives an interoperable way for shortening the titles in header/footer, including ellipsis and arbitrary text, see the documentation in the attached tdf32363.docx. (The only difference, that MSO cannot handle ellipsis/arbitrary text with this method: https://learn.microsoft.com/en-us/answers/questions/5228103/can-i-shorten-styleref-text-and-add-ellipsis-in-th – but it can preserve the information for Writer – one of the proposed MSO workaround is to use white 1 pt text...) About the ToC: this is clearly a separated problem, by the way in LaTeX, too, where \chaptermark/\sectionmark are for the header/footer-only shortening, and the extra argument of \chapter/\section for both ToC and header/footer: https://texfaq.org/FAQ-runheadtoobig For shortening titles for the ToC in Writer, it can be a better solution to use inline frames with the new style separator interoperability features, than editing the ToC manually or adding an extra heading with white, 1 pt characters after the long heading, and removing the long heading from the ToC by direct paragraph formatting. To use the style separator interoperability approach easily, create new "Long" chapter styles based on the existing Heading 1, Heading 2 etc. with disabled outline level, and use that for the long headings. To set the short headings, select the first part of the long title, and choose Heading 1 (e.g. by pressing Ctrl-1). The selected text moved to an inline frame with the requested heading style immediately, and updating the ToC, it will contain the short titles only. Example document is attached. The listed solutions are ISO OOXML/ODF/loext: ODF compliant solutions, can be base of some more high-level solutions (Writer UI extension, add-on, full style separator interoperability), so I think, it's possible to close this issue. Please, file a new issue for the other possible future solutions. Note: I have examined several other solutions, for example conditional paragraphs in Writer (they don't work in header/footer correctly), SET variables (it works in Writer, but not so comfortable and not interoperable yet), STYLEREF with \* MERGEFORMAT/CHARFORMAT to show the hidden text in MSO header/footer (it doesn't work in MSO).
Created attachment 205625 [details] ToC example with inline frames (inserted by the new style separator interoperability feature)
Created attachment 205626 [details] tdf32363.pdf: documentation – PDF output of the test document tdf32363.docx
Comment on attachment 205625 [details] ToC example with inline frames (inserted by the new style separator interoperability feature) [Found a bug: header/footer fields cannot handle headings inside frames, yet]
Created attachment 205627 [details] shortening_titles_in_ToC_and_header.odt: Working example with two different shortenings for ToC and header/footer inline frames for the ToC, and Styles field with custom character styles for header/footer
Created attachment 205628 [details] shortening_titles_in_ToC_and_header.pdf: PDF output of the previous example
Built-in workarounds are still workarounds, specially when they are "second order built-in workarounds" (this one uses the previously introduced "inline headings" workaround)... Anyway, I give up.
(In reply to Eyal Rozenberg from comment #35) > so, is it really beneficial to limit the scope of this issue and split off > the dupe? We have three potential targets: header/footer, ToC and PDF ToC (yes, PDF ToC is a different target for some users), all are separated for the development, and likely for a potential WYSIWYG UI, too. We have multiple requirements: the heading is too long for 1) the *1-line* header/footer 2) to much for the *narrow* PDF ToC, and 3) we need in-line Heading 4–5 for our APA-like typography etc. Indeed, the original LaTeX example modifies the ToC, too, not only the header, so I added also ToC to my last example, shortening titles_in_ToC_and_header.pdf, demonstrating all the LaTeX functionality in Writer: different shortening for the ToC and for the header/footer. An important issue here, that OOXML and ODF have completely different document layout model. It seems, in OOXML/MSO, the WYSIWYG solution for the header/footer problem is use sections, which have own header/footer, and they don't need to start on a new page, i.e. they are applicable for lower level heading, too, not only for the page-starter ones.
(In reply to RGB from comment #45) > Built-in workarounds are still workarounds, specially when they are "second > order built-in workarounds" (this one uses the previously introduced "inline > headings" workaround)... Anyway, I give up. Yes, I agree, that we have still workarounds. WYSIWYG applications don't follow the SGML logic, that is why is very hard to map a structured description (https://en.wikipedia.org/wiki/LaTeX#Typesetting_system) to a WYSIWYG application. allotropia started to implement loext: style separators (still incomplete), while I've added a workaround to solve the ToC/PDF ToC issues with ODF-compliant inline frames (also I've added the first PDF ToC unit tests to LibreOffice), which seemed to me broken by design: inline frames are div-like objects, i.e. they cannot be multi-line without breaking the in-line heading – but I realized, this is not true for the DIV implementations of the browser, that is why the (X)HTML export of the inline frame-based workaround for the style separators is OK now... We simply can't solve everything at once, especially if we don't know all the problems, and especially not in all depth. (See my previous comment about the different needs for the PDF ToC, not too mention the interoperability requirements, which are still the main driving force for our developments.) For me, this bug report was a great help in understanding the problem better. The next step would be to thoroughly test the proposed solutions to find and file new bugs. It's OK to ask for more LaTeX-like solutions, too. (I thought of mapping the short titles to RDF metadata of the headings, which is the ODF-compliant way of metadata annotation. Later we could define canonical RDF IDs, like for field prefix and suffix, and extend the document layout/fields to handle them. The only problem with this “clean” solution, that LibreOffice is a WYSIWYG editor, which allows much more, than LaTeX, because we always know the layout. Using *only* recent LaTeX solution for the short titles, you never know, that shortening will really work or not. You need a LaTeX processor, too, and fix your LaTeX again and again based on the actual layout, which work flow is not ideal sometimes.)
Laszlo, this won't fly. I understand that you've developed a clever hack, and I applaud the ingenuity. But this isn't what users want or need. We need something that: 1. Has bona fide UI in LibreOffice for affecting, e.g. on the context menu, or the main menu, or from a dialog etc. 2. Does not involve users typing the extra text as some sort of hidden prefix or suffix of their paragraph. They will only type that in some text box, or separated area. 3. Does not rely on character styles. First, because it can't get messed up if one then copies and pastes the paragraph as plain text; or if one reapplies the default paragraph style; and second, because content-wise, it's a lie: The shorthand version is not some starting or ending text within the paragraph. 4. Will not require some special consideration by tools parsing the ODT. This bug is not fixed. Now, it's possible that it won't get fixed for a while - or ever; who knows. But that's life. In the mean time, people who absolutely have to make this happen will either use the hack.
Hi Eyal, (In reply to Eyal Rozenberg from comment #48) > Laszlo, this won't fly. I understand that you've developed a clever hack, Not at all. Continuing the great interoperability developments by Skyler Grey and Michael Stahl, I've improved the ISO OOXML interoperability in Writer, allowing to use STYLEREF with character styles in Writer, too, which is one of the de facto and de jure standardized way in MS Word/DOCX to shorten the headings in header/footer: https://c-rex.net/samples/ooxml/e1/Part4/OOXML_P4_DOCX_STYLEREFSTYLEREF_topic_ID0EN3M1.html Also using inline text frames/DIV elements is a W3C CSS compatible way for inline headings (which was a huge surprise for me: web browsers can put the following text *inside* the box of the inline heading, when that is 2-line long, i.e. not completely inline any more). Calling Styles field usage a clever hack means calling MS Word, ECMA-376, ISO OOXML, loext: ODF, and the next ISO ODF version a clever hack. You can, but you miss the point. We don't need clever hacks, when MS Word has already had the standard way to shorten titles, only better interoperability. (By the way, which is near impossible, seeing the amazing richness of what MSO has built into the field code language of Word at the request of its customers, from generating US postal codes to referring not only the text content and numbering of the text, but its styles, too.) > and I applaud the ingenuity. But this isn't what users want or need. We need Thanks. The credit goes to the creators of MS Office, or whoever they were looking for the solution from. > something that: > > 1. Has bona fide UI in LibreOffice for affecting, e.g. on the context menu, > or the main menu, or from a dialog etc. > 2. Does not involve users typing the extra text as some sort of hidden > prefix or suffix of their paragraph. They will only type that in some text > box, or separated area. You mean creating a hybrid markup language–WYSWYG word processor or something else? I like the idea to innovate new type of software – I was really glad of Tomaž Vajngerl's Search Commands (made originally on Collabora's hack days), and I'm very sad, that is still not enabled by default, and it is still not extended to be equivalent of the MSO's Search (and I like that you like it, too: https://bugs.documentfoundation.org/show_bug.cgi?id=150810 :) > 3. Does not rely on character styles. First, because it can't get messed up > if one then copies and pastes the paragraph as plain text; or if one > reapplies the default paragraph style; and second, because content-wise, Relying on character styles is the standard office suite way. Reapplying paragraph styles doesn't remove the direct character formatting. Clearing direct formatting doesn't remove the direct formatting by character styles. > it's a lie: The shorthand version is not some starting or ending text within > the paragraph. Inline headings are mostly starting part of the paragraphs. Header/footer mostly need the same, extended with an ellipsis. Otherwise I agree, that depending on the requirements, we need to support arbitrary shortening, too. The question when are standard office suite methods not enough? Manual modification of the ToC (default functionality in Word and Writer), starting a new section for every shortened headings (Word) or using STYLEREF with character styles (Word, now in Writer, too). > 4. Will not require some special consideration by tools parsing the ODT. The devil is in the details. For example, I didn't check how ODF-compliant it is that hidden headings appear in the header. It could just be a bug. Maybe it was a clever hack to interpret the standard for shortening titles and fixing the deep-level interoperability issue that Writer doesn't support section-level headers (because ODF has got page styles). > > This bug is not fixed. Now, it's possible that it won't get fixed for a > while - or ever; who knows. But that's life. In the mean time, people who > absolutely have to make this happen will either use the hack. The main problem here, that this is not a bug, but an enhancement request. Moreover, it is without specification and without any real precedence. LaTeX is not a precedence for a word processor. I closed this issue after showing, that we have already had similar workarounds or solutions, than in our real precedence, MS Word. For me, the real WYSIWYG solutions would be the better manual modification of the ToC (updating only the numbers after the modifications optionally, like in MSO), and manual modification of the long text in the header/footer. No need to create some metadata fields, etc., simply editing the text content of the header/footer. If you don't want to file a new bug for it, closing this issue, I suggest to modify this issue to something "allow direct formatting of the actual field content in the header/footer, similar to the manual modification of the ToC". The document format can use a STYLEREF-like solution, or a new loext: extension in the background. It would be funny and quite comfortable, word processor-compliant, i.e. WYSIWYG to shorten/rewrite the long titles in the header/footer directly... Likely the only solution which would satisfy everyone. This is not a bug, but an enhancement request. The problem, that The bug was fixed: it's possible to What is the bug?
(Sorry, the end of my previous comment is this sentence: "Likely the only solution which would satisfy everyone.". The text that follows was hidden from me by the very poor textarea interface of my browser... What is the UX? :)