https://bugs.documentfoundation.org/show_bug.cgi?id=32363
--- Comment #49 from László Németh <[email protected]> --- 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? -- You are receiving this mail because: You are the assignee for the bug.
