Issue 27377

Summary: Character formatting not retained in entries of TOC, table lists, etc.
Product: Writer Reporter: ftack <ftack>
Component: formattingAssignee: AOO issues mailing list <issues>
Status: CONFIRMED --- QA Contact:
Severity: Normal    
Priority: P3 CC: bscho, cno, deligeo, gschintgen, issues, kozodaevroman, mathias, mhzuchini, olaf.stetzer, pet.ebe, rainerbielefeld_ooo_qa, rgb.mldc, simonjwiles, stephan.gromer, tomasz, vulcain
Version: OOo 1.1.1Keywords: needhelp, oooqa, rfe_eval_ok, usability
Target Milestone: ---   
Hardware: All   
OS: All   
Issue Type: ENHANCEMENT Latest Confirmation in: ---
Developer Difficulty: ---
Attachments:
Description Flags
A quick example
none
Yet another illustration of issue 27377
none
Some workaround for this issue none

Description ftack 2004-04-02 12:50:40 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.
Comment 1 rgb 2004-04-02 13:18:04 UTC
In sciences, formating is very important. Is very hard write a scientific
document without use scientific notation in headers or captions!
Comment 2 michael.ruess 2004-04-02 13:56:27 UTC
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.
Comment 3 ftack 2004-06-17 16:31:49 UTC
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.
Comment 4 mhzuchini 2004-06-17 17:08:14 UTC
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.
Comment 5 rgb 2004-06-29 11:52:36 UTC
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.
Comment 6 ftack 2004-07-09 08:58:05 UTC
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.
Comment 7 rgb 2004-09-09 10:51:30 UTC
No target milestone yet? This is a VERY important limitation in writer!!!! I
can't use the program professionally until this is fixed!!!!!
Comment 8 rgb 2004-10-08 17:42:33 UTC
Created attachment 18248 [details]
A quick example
Comment 9 rgb 2004-10-08 17:50:25 UTC
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.
Comment 10 ftack 2004-10-12 12:14:03 UTC
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.
Comment 11 ftack 2004-10-12 12:14:52 UTC
Created attachment 18302 [details]
Yet another illustration of issue 27377
Comment 12 eric.savary 2004-10-21 10:56:42 UTC
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.
Comment 13 eric.savary 2004-10-21 10:57:40 UTC
*** Issue 35902 has been marked as a duplicate of this issue. ***
Comment 14 sumana 2004-11-02 18:53:54 UTC
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.
Comment 15 sumana 2004-11-02 18:56:29 UTC
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.
Comment 16 lohmaier 2004-11-02 23:17:56 UTC
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)
Comment 17 ftack 2005-01-27 17:28:14 UTC
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.
Comment 18 dmpop 2005-01-27 18:50:04 UTC
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.
Comment 19 eric.savary 2005-06-07 10:26:11 UTC
*** Issue 50401 has been marked as a duplicate of this issue. ***
Comment 20 madmaxmarchhare 2005-06-08 00:01:55 UTC
I've casted my votes for this, too, especially after the thanks I was given in 
issue 50401.
Comment 21 m2brew 2005-06-23 17:28:42 UTC
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.    
Comment 22 eric.savary 2006-01-24 13:20:37 UTC
*** Issue 61085 has been marked as a duplicate of this issue. ***
Comment 23 h.ilter 2006-06-09 13:29:14 UTC
*** Issue 61087 has been marked as a duplicate of this issue. ***
Comment 24 eric.savary 2006-09-06 14:40:01 UTC
*** Issue 69333 has been marked as a duplicate of this issue. ***
Comment 25 deligeo 2007-08-24 16:48:54 UTC
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.
Comment 26 burninleo 2007-12-19 13:01:34 UTC
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.
Comment 27 bernd_schoeler 2007-12-21 00:36:29 UTC
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.
Comment 28 deligeo 2007-12-21 13:42:20 UTC
 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
Comment 29 michael.ruess 2008-03-17 12:42:51 UTC
*** Issue 87074 has been marked as a duplicate of this issue. ***
Comment 30 mhzuchini 2008-04-17 18:00:53 UTC
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.
Comment 31 deligeo 2008-04-22 17:57:22 UTC
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!
Comment 32 gromer 2008-06-27 21:58:49 UTC
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.

Comment 33 gromer 2008-06-28 00:20:48 UTC
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!
Comment 34 eric.savary 2008-09-29 10:23:30 UTC
*** Issue 94408 has been marked as a duplicate of this issue. ***
Comment 35 ftack 2008-10-08 15:08:45 UTC
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.
Comment 36 eric.savary 2008-12-05 15:52:02 UTC
*** Issue 96956 has been marked as a duplicate of this issue. ***
Comment 37 mhzuchini 2009-01-02 02:39:20 UTC
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!
Comment 38 eric.savary 2009-03-30 11:44:08 UTC
*** Issue 100672 has been marked as a duplicate of this issue. ***
Comment 39 olaf_stetzer 2009-04-01 10:13:43 UTC
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.  
Comment 40 burninleo 2009-04-01 10:52:12 UTC
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.
Comment 41 eric.savary 2009-04-01 17:25:55 UTC
*** Issue 100758 has been marked as a duplicate of this issue. ***
Comment 42 mhzuchini 2009-05-13 13:54:50 UTC
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.
Comment 43 cno 2009-05-13 14:16:04 UTC
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 ...
Comment 44 Mathias_Bauer 2009-05-13 14:33:09 UTC
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". ;-)
Comment 45 eric.savary 2009-05-15 23:18:39 UTC
*** Issue 101975 has been marked as a duplicate of this issue. ***
Comment 46 jannollo 2010-03-09 13:48:15 UTC
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?
Comment 47 eric.savary 2010-04-26 14:29:33 UTC
*** Issue 111155 has been marked as a duplicate of this issue. ***
Comment 48 cactuscomputing 2010-04-27 16:41:22 UTC
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.
Comment 49 Regina Henschel 2010-06-29 23:03:43 UTC
*** Issue 112801 has been marked as a duplicate of this issue. ***
Comment 50 simon_w 2010-07-15 15:35:23 UTC
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.
Comment 51 m_z 2010-08-21 14:18:54 UTC
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!
Comment 52 Unknown 2010-10-23 06:13:06 UTC
Created attachment 72304
Comment 53 xanio 2010-10-27 12:52:22 UTC
This issue is really painful. I had to create index manually (5 pages long) and
update it by hand everytime my work changed.
Comment 54 xanio 2010-10-27 13:35:13 UTC
And please, remove attachment Protonix (text/html): it's a spam.
Comment 55 siersciuch 2011-01-07 00:57:03 UTC
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
Comment 56 siersciuch 2011-01-07 01:02:44 UTC
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
Comment 57 siersciuch 2011-01-07 01:25:30 UTC
Created attachment 75491 [details]
Some workaround for this issue
Comment 58 rgb 2011-11-26 20:15:09 UTC
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.
Comment 59 xanio 2013-10-01 11:58:13 UTC
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.
Comment 60 Rainer Bielefeld 2014-04-22 04:44:23 UTC
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.
Comment 61 Marcus 2017-05-20 10:45:34 UTC
Reset the assignee to the default "issues@openoffice.apache.org".