Apache OpenOffice (AOO) Bugzilla – Issue 27377
Character formatting not retained in entries of TOC, table lists, etc.
Last modified: 2017-05-20 10:45:34 UTC
A Table of Contents or another Index/Table does not retain character formatting of the original entries. For example, when a Heading 1 formatted paragraph contains an italicised entry (a scientific name of a plant, for example), that formatting is not applied in the corresponding entry of the TOC.
In sciences, formating is very important. Is very hard write a scientific document without use scientific notation in headers or captions!
MRU->BH: I'll comment this in favour for ES. We should think about taking hard character attributes from the Headings into the TOC. In the described cases this should really make sense in my opinion.
I am sorry to see this issue assinged a priority of 4. This issue seriously cripples the functionality of automatic TOC and cross references for technical writers. They have no other option than manually reformat the offending entries in the TOC, since cross-references to headings cannot be edited, they have no other option than inserting the text manually.
I agree with ftack: it's very difficult to write a technical paper without this feature. And, let's remember, there are a huge number of OO users that come from universities, schools and other educational institutions, where this issue can impose very hard penalties.
Now, I'm using OOo mainly at my work in the university, but can't use it for technical papers. In fact, I can't use it for internal reports, because of this issue. Is one of the main reasons because I'm still binded to latex.
Obviously, also the use of indexing is crippled because of this issue. An index entry for sulphurioc acid, for example, H<SUB>2</SUB>SO<SUB4>4</SUB> shows up in the index without superscripts. Italicized plant names with an upright author show up with the italic removed.
No target milestone yet? This is a VERY important limitation in writer!!!! I can't use the program professionally until this is fixed!!!!!
Created attachment 18248 [details] A quick example
Just an example. I think that by watching this example is easy to understand that is not possible to present a professional work under these conditions.
I have added another example. That one uses references to repeat a piece of text elsewhere in the document. Please note that there is no way for the user to manually format the automatically inserted text, so the only 'workaround' consists in not using the automation feature. Indeed, this issue shouldn't be taken too light. Because of custom formatting being lost, automation features such as references and TOC's are in fact crippled. One could argue that the current issue should be classified as a "DEFECT" rather than an ENHANCEMENT in the 2004 era of word processing. Please consider this issue seriously as it constitutes an unfortunate limitation.
Created attachment 18302 [details] Yet another illustration of issue 27377
ES->BH: this issue would be indeed worth a P3. But then it should be fixed "before release" and we can't do that because implementing this supposes a new concept for TOCs and I guess file format changes + compatibility problems.
*** Issue 35902 has been marked as a duplicate of this issue. ***
Agree with all above. very important issue for OO's best markets... if the target milestone can't be changed, at least it shoudl be recognized as a Defect rather than an improvement.
also, my specific issue was with exporting to pdf... the formatting applied with styles came undone whenever I export to pdf, text formatted with paragraph styles as italic or bold prints comes out in the pdf as unformatted. E.g. the italics and bold in my table of contents or in headers or in headings comes out plain all other formatting remains true -font, size, etc. i was told that this was the same issue. but in any case, they're both important.
please understand that * an issue can only be fixed when there are ressources to fix it * an issue is a defect or enhancement based on technical prerequisites, not because of the impact on the user. * please keep issues seperated. The problem with PDF export has nothing to do with this one. The problem is that the fonts used are not available in a bold/italic version and that windows "fakes" italics/bold for this font. OOo cannot do this on its own in version 1.x. This will be possible with OOo 2.0 - see issue 17352 regarding sub/superscript: you can use the unicode characters for subscript or superscript (given that you have a font installed that contains these characters): H₂SO₄ (not sure whether issuezilla can hanle this U+2082 is subscript 2, U+2084 is subscript 4)
I am currently preparing a technical paper. I used the Indexes and tables feature to include a List of Figures and a List of Tables. Unfortunately, I had to remove the automatic table when I realised my subscripts were lost. This issue really cripples various uses of Indexes and Tables and fields in technical papers, so please give it enough attention.
Although I've never used OOo for writing technical papers or similar tasks, I realise that the described issue is a crucial one. I've casted my votes for it.
*** Issue 50401 has been marked as a duplicate of this issue. ***
I've casted my votes for this, too, especially after the thanks I was given in issue 50401.
This is a HUGE issue! The lack of text format preservation makes the powerful and convenient automatic indexing feature much less useful. Why leave such a GREAT feature incomplete? As a chemist, this is particularly important to me, but it affects anyone who uses the index feature, so I think this should be a high priority. I drool in anticipation over the fix.
*** Issue 61085 has been marked as a duplicate of this issue. ***
*** Issue 61087 has been marked as a duplicate of this issue. ***
*** Issue 69333 has been marked as a duplicate of this issue. ***
I am voting for this issue based on the ground that it IS a "show-stopper" for usage of OO in the scientific community. I understand that resources are limited and OO is a huge program by now but it is my humble opinion that "defect" like behaviors should be addressed ASAP. Don't get me wrong I recon OO to be an exceptional program overall.
I am disturbed that this malfunction is known since 2004 and has not been fixed yet! I am usually not concerend by this issue, working on sociological sciences - but I had to deal with a chemical text recently and could not beliefe that we had to manually format the content table to show the correct titles there. I especially vote for a option that allows to turn "use hard formats from the headings" on and off.
I’m voting for this issue as well. This really is an important missing function. Especially when you have page heads with automatically inserted chapter names where editing the inserted text is impossible. Inserting those chapter names manually is hardly a feasible workaround.
It is my understanding that to get this fixed, there are dependencies that need to be satisfied. In other words other stuff need to be fixed in the way OO works internally prior to this issue being corrected. Could we at the very least identify those dependencies here? And have a progress report on them? Maybe a milestone ( even in the distant future?) It is really frustrating to have seemingly no progress evident in such a fully qualified BUG. Anybody from within the OO herd?? Happy new Year to all
*** Issue 87074 has been marked as a duplicate of this issue. ***
I understand human resources is a must. When I posted, on a OO forum in 2004, that I was having problems with TOC formatting, 'ftack' immediately reported it as a bug. But, unfortunately, it's been moved to an "enhancement". Again, I understood the lack of human resources and I'm not complaining. I just disagree with this label. It's a bug and, IMHO, should be treated as a bug. Marcio.
i took a look at the roadmap for future releases. No mention of this *bug* whatsoever. I share the view of the previous poster, and after 4 years of this issue creeping around I am wondering what does it take to get this fixed? At the very least dignify our questions with an answer! This is really frustrating... Similar situation for bug 11174... come on people give us a break!
It seems that simple, basic functionalities which are relevant for the scientific and/or advanced user are constantly being ignored. Note that this issue dates back until 2004 (OOo 1.1.1) and is still an issue in 2.4.1. The same happens to this issue (http://qa.openoffice.org/issues/show_bug.cgi?id=48179) in impress. I wished people would realize that a large number of people will get into contact with OOo at universities during their thesis etc. Now guess what they will think about it compared to the competitor product? Don't add new fancy stuff to OOo but fix the real issues first.
As a temporary workaround I would like to hint to this apparently useful Macro: http://www.oooforum.org/forum/viewtopic.phtml?t=21559&highlight=toc I haven't tested it thoroughly, yet, but it proofs that a solution is fairly easy possible. Please implement!
*** Issue 94408 has been marked as a duplicate of this issue. ***
I concur with the somewhat harsh comments given. This is an issue that cripples automation features in OOo and it should not have been around for four years. It is a feature that worked already in the first MS Word version for Windows almost 20 years ago.
*** Issue 96956 has been marked as a duplicate of this issue. ***
I'm disappointed... OO 3.0 and this bug still remains... and this bug poses strong limitations to scientific writing... Best regards and let's look forward on 2009!
*** Issue 100672 has been marked as a duplicate of this issue. ***
I am disappointed too when I realized how old this bug is and how many duplicates where submitted already (the last one by me). Is there an official statement on when this will be taken care of? I have the feeling that this is a more general issue. What kind of formatting should be untouched when aplying a new paragraph style? E.g. When I have a nromal text containing sub-/superscripts and I want to apply a new style I want the sub-/superscripts to maintain unmodified. This is the case when no "hidden" other formatting is applied to a paragraph yet. One example: When I write a paragraph I can apply a new formatting style and it really works and sub/superscripts are maintained. On the other hand when I copy/paste a parapgraph from another document, where the font is different, I may only apply the formatting I want by first delete all formatting attributes from that paragraph. Some things like sub/superscripts however should remain - but they don't. It would be just suffiecient if applying paragraph styles can be entirely separated from charachter attributes like sub-/superscript underline bold italic.
Hi! I gues you are completely right. OpenOffice Calc provides a function to exacly slect which attribute to insert (formulas, values, strings, ...) - I guess something similar would be useful in the Writer. Back to the TOC issue, I think that bolds and underlines may be a bit more difficult as there is a paradigm that structural formats shall be distinguished from visual formats (like <b> vs. <strong>). Sub-/Superscript on the other side is no format (in the logical sense) but it changes the very meaning of the text: m2 is not the same like m². However, while "bold" only is a visual description for many users, it may be a meaning-changing convention in natural sciences (e.g. in a chemical formula). Maybe it would be enough to preserve hard formats in the TOC and only remove character formats applied by style. If someone then gets bold entries in the TOC due to manual format - not perfect usability, but this user will learn... However, I guess this will not solve the problem on inserting passages and should be handled separately. The clipboard will usually not tell if "Times 12pt, bold" is just the style used for the source document or if it is a hard format. Or even worse: If it is a hard format used throughout the whole file. However preserving sub-/superscript when inserting without formats would be helpful. But this seems to be another issue.
*** Issue 100758 has been marked as a duplicate of this issue. ***
I'm wondering: how many votes should we cast for this issue to have at least a target milestone? Perhaps 34 votes (at the time I'm writing) do not show how huge this problem affect all OO users. I'm a brazilian professor and I'm "try" to show the advantages of using OO when students do their final dissertation. But, since the bug exists, only 4 students from a total of about 200 of them became convinced to use OO... I think, unfortunately, that we are running out of reasons to show advantages of using OO.
Hi mhzuchini, This problem at least does not affect one user - me - and maybe there are more ;-) But I agree with you that it would be a welcome enhancement, and necessary for certain (groups of) users. So I hope your argument will contribute to a faster implementation. If only ...
Thanks to Cor for bringing this to my attention. Indeed the number of duplicates alone indicates that this issue deserves a better target. For the time being I change it to "3.x". That doesn't exclude 3.2. To avoid further ignorance I snatch it away from the big dark oblivion called "requirements". ;-)
*** Issue 101975 has been marked as a duplicate of this issue. ***
Wow, I'm really amazed. This issue has been raised almost six years ago and not only hasn't it been solved - it has not even been addressed. I couldn't see any objections to it or problems with it, it just seems to be ignored by those that have the knowledge to solve the problem. I, like many others, use openoffice for scientific works and having to set the formatting in the TOC manually can really be quite irritating. Maybe at least somebody who knows could tell what needs to be done to get some attention?
*** Issue 111155 has been marked as a duplicate of this issue. ***
It's impacting our customers, and all we can say is use MS word when you want to print a document in the content store. As jannollo says this was originally opened in April 2004.
*** Issue 112801 has been marked as a duplicate of this issue. ***
wow - visiting this page for the first time hoping for a resolution is a bit disheartening! The specific case which drove me here concerns the "Chapter name" field, which I was hoping to use in a page header for a book I'm trying to typeset. To explicitly concur with my fellow commenters on this issue, this functionality is effectively useless as long as this issue remains outstanding. I would have thought that respecting super- and sub-script notation was a no- brainer here, so to speak, and that italics should be straightforward enough -- they should simply be inverted in the case that the styling of the target is already italicized. These typographic styles carry semantic force -- without them, it simply doesn't mean the same thing -- so I agree with those who hold that this is a bug, not a feature-request.
I’m voting for this issue as well. In sciences, formating is very important! This issue (ToC) and the issue 106199 (Alphabetical index entry), should be solved together. Consider also the issue 90841 (problem 2). There are contexts in which control of the formatting is essential!
Created attachment 72304
This issue is really painful. I had to create index manually (5 pages long) and update it by hand everytime my work changed.
And please, remove attachment Protonix (text/html): it's a spam.
I was forced to find some WORKAROUND of this really painful issue: I insert different zero-width unicode marks before the text with special formatting (subscript, superscript, italic) and another (in reversed order) after the text, for example (unicode characters put in square brackets): L<sub>C, peak</sub> will be: L[\u206E][\u206D]C, peak[\u206D][\u206E] Put this text anywhere in the header and then create index. After updating index of course formatting will be lost, but you simply do this: 1) open Find-Replace dialog (^F) 2) into "Find" put this: \x206E\x206D.?\x206D\x206E 3) into "Replace" put this: $0 4) press "More options" and check "Regular Expressions" 5) goto "Format" and pick some properties (for example subscript; I also use some background color to make all "hot points" before my markers visible) ==>"subscript and other format properties will appear under "replace" input line. 6) press "Replace All" 7) Voila! As you see, you can use many combinations of invisible zerowidth UTF chars for different styles, you can also play with ".?" part of RegEx. The list of zero width and invisible chars can be seen here: "Menu>Insert>Special Character". These are for default Arial Font: (U+) 200E, 200F, 202A..E, 206A..F. You can copy-paste them, so after highiliting it (select and set some background color) you can use it quite easily. These chars are used by UTF to perform advanced formatting od the text. Especially pair of 206E-206D ... 206D-206E shouldn't make any problems unless you use arabic typeset. Hope this will help somebody. r, sierściuch
Created attachment 75491 [details] Some workaround for this issue
As a "workaround" to this issue you can use the amazing Linux Libertine G or Linux Biolinum G fonts: http://numbertext.org/linux/ These fonts use Graphite smart font technology an have a substitution table called "tex mode": if you set the paragraph styles used for the heading AND the corresponding TOC entry to use that substitution table the problem is solved by simply using the common tex notation for sub/superscripts. To obtain this result, on the paragraph styles set the font as Linux Libertine G:texm=1 or Linux Biolinum G:texm=1 then enter the text on your heading like this: H_2O or SO_4^2^- and you will get the sub/superscripts without further actions. This also works with small caps Latin alphabet. See font documentation for more possibilities.
Oh come on guys. It's been a very long time since this bug was reported for the first time. Subscripts and superscripts in TOC are a must for scientists so this issue makes OOO useless for them.
I think it was not a good Idea to mark any "I am not satisfied with field contents viewing" Bug report as a DUP of this one. That blocks any progress here, also for subscript / superscript where it is common sense that this character formatting should be retained in TOC and similar.
Reset the assignee to the default "issues@openoffice.apache.org".