Issue 29920

Summary: Alignment error in table of content with 2 columns
Product: Writer Reporter: dennybeyer <denny.beyer>
Component: codeAssignee: AOO issues mailing list <issues>
Status: ACCEPTED --- QA Contact:
Severity: Trivial    
Priority: P3 CC: forpublicpurposes, glutanimate, issues, port, rgb.mldc
Version: OOo 1.1.1Keywords: needmoreinfo
Target Milestone: ---   
Hardware: PC   
OS: All   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Attachments:
Description Flags
Mistake in TOC alignment in left column but not in right column
none
Different sample file showcasing the same bug none

Description dennybeyer 2004-06-06 18:12:01 UTC
In my table of Contents I entries are as followed: E# T E T # 
The first Tab (between E# and E) sets up the starting position for the heading.
The second one sets the right alignment and fills the space with dots (as
default). Everything works fine with one column (as normal), but doesn't when I
increase columnnumber in TOC - dialog to two. Then the Pagenumber is right
behing the text in the left column. In the right column everything stays as it
supposed to look like. Testet with StarOffice 7 Sp2 (Win98) / OOO1.1.1 (linux)

thanks ....
Comment 1 michael.ruess 2004-06-07 10:32:42 UTC
ES, please have a look.
Comment 2 eric.savary 2004-06-07 11:53:28 UTC
Please attach a sample document
Comment 3 dennybeyer 2004-06-07 13:37:38 UTC
Created attachment 15715 [details]
Mistake in TOC alignment in left column but not in right column
Comment 4 dennybeyer 2004-06-15 09:14:05 UTC
Tests with OOo 1.1.2rc3 shows the same behavior!
Comment 5 dennybeyer 2004-06-16 09:08:04 UTC
same behavior in OOo680m41! 
Comment 6 eric.savary 2004-06-16 13:36:08 UTC
ES->HB: Any chance we can avoid this with the new numbering features?
Comment 7 openoffice 2004-06-16 17:00:09 UTC
accepted
Comment 8 dennybeyer 2006-05-20 14:00:53 UTC
Defect still exists in OOo 2.0.2 !
Comment 9 Christian 2012-10-19 09:29:45 UTC
Defect still exists in AOO 3.4.1.
Comment 10 Christian 2012-10-19 10:32:01 UTC
Most convenient work arounds IMHO:

If you emphasize on few vertical alignments:

Don't use right aligned tabs in the index in this situation. Instead, align the page numbers at p.e. 8 cm.
Drawback: the page numbers are no longer right aligned. However, neither are the chapter numbers!

Otherwise:

Use space(s) between chapter number and chapter text, instead of a tab.
Comment 11 rgb 2012-10-27 13:50:36 UTC
(In reply to comment #10)
> Drawback: the page numbers are no longer right aligned. However, neither are
> the chapter numbers!

You can apply a character style to the numbers that use Linux Libertine/Biolinum G fonts(1) and the "algn" Graphite parameter. For example, on the font name for the character stile use

Linux Biolinum G:algn=3

and then apply that style to the # and E# entries on the TOC: you'll have the numbers aligned to the right, even if you don't use a right aligned tab. 

Still a workaround, but a very good one!

(1) http://numbertext.org/linux/
Comment 12 Glutanimate 2012-10-27 17:48:34 UTC

I am experiencing the same issue with LO 3.6.2.2 . See here for my bug report on LO's bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56431

(In reply to comment #11)
> (In reply to comment #10)
> > Drawback: the page numbers are no longer right aligned. However, neither are
> > the chapter numbers!
> 
> You can apply a character style to the numbers that use Linux
> Libertine/Biolinum G fonts(1) and the "algn" Graphite parameter. For
> example, on the font name for the character stile use
> 
> Linux Biolinum G:algn=3
> 
> and then apply that style to the # and E# entries on the TOC: you'll have
> the numbers aligned to the right, even if you don't use a right aligned tab. 
> 
> Still a workaround, but a very good one!
> 
> (1) http://numbertext.org/linux/

Thank you for this workaround. I tried it out, but only got this: http://i.imgur.com/pTNsh.png

After modifying the font of the "#" entry character style the page numbers are separated from the entries as if there was a space inbetween. They aren't, however, aligned to the right. Is there something I am doing wrong? Here's the sample file I used: http://dropcanvas.com/c54wl
Comment 13 rgb 2012-10-27 19:52:20 UTC
(In reply to comment #12)
> 
> Thank you for this workaround. I tried it out, but only got this:
> http://i.imgur.com/pTNsh.png
> 
> After modifying the font of the "#" entry character style the page numbers
> are separated from the entries as if there was a space inbetween. They
> aren't, however, aligned to the right. Is there something I am doing wrong?
> Here's the sample file I used: http://dropcanvas.com/c54wl

There is something definitively wrong with your document: If I start from scratch with an empty document and create a two column TOC it works as intended, no need for workaround, but I cannot find a way to fix your document. Also, your document takes ages to load: I have really complex documents with more than 300 pages that load on a matter of seconds, but yours is really slow... sorry, but I have no clue. 

Maybe you can try to start from scratch and use the default heading level (heading 1 to 10).
Comment 14 Glutanimate 2012-11-07 03:55:44 UTC
(In reply to comment #13)

> There is something definitively wrong with your document: If I start from
> scratch with an empty document and create a two column TOC it works as
> intended, no need for workaround, but I cannot find a way to fix your
> document. Also, your document takes ages to load: I have really complex
> documents with more than 300 pages that load on a matter of seconds, but
> yours is really slow... sorry, but I have no clue. 
> 
> Maybe you can try to start from scratch and use the default heading level
> (heading 1 to 10).

As I posted on the forum: Whatever I do, it doesn't work for me. I just created a new document from scratch, using a completely different template (one that LO is shipped with) and still the same result (see attached file).
Comment 15 Glutanimate 2012-11-07 03:57:12 UTC
Created attachment 79874 [details]
Different sample file showcasing the same bug

I would also like to point you to this thread over at forum.openoffice.org, where multiple users have confirmed the same bug:

http://forum.openoffice.org/en/forum/viewtopic.php?f=7&t=57002
Comment 16 port 2014-08-21 20:46:06 UTC
This appears to have been an issue for a decade (10 years!) now and I have experienced it for at least six of those.  In the past, if you worked with it long enough (changing, deleting, modifying settings...even just to put it back the way it was) you could eventually get it to function properly.  It was annoying, but possible.  With the release of OpenOffice 4.1.0 and 4.1.1, it appears even this "work-around" is no longer effective.  Yes, the bug has few votes, but it seems reasonable to also consider the length of time a bug has gone unresolved in deciding how to prioritize it.  Following is some additional diagnostic information applicable to the latest versions (OO 4.1.0 and 4.1.1):

Part of the problem may be due to confusion in the code regarding how to deal with tab stops since it is possible to set tab stops for the various levels on the Entries tab OR by way of the paragraph style associated with each of the various levels (as set on the Styles tab).  Reviewing how a change in one affects the other or which takes precedence may help expose the root problem.

There may also be a problem with appropriate application of the paragraph style associated with the level (which may be related to the above).  This is hinted at by the following temporary work-around that corrects the problem with the left column:
a) Do NOT protect against manual changes;
b) Edit the paragraph style such as Contents 1 (assuming it is assigned to Level 1) and set up the proper left and right tabs;
c) Click in any level 1 entry in the left column (Contents 1 should appear highlighted in the Styles and Formatting box);
d) Double-click on any other paragraph style in the Styles and Formatting box (which will change the entry to that style);
e) Double-click on the Contents 1 style in the Styles and Formatting box (which will change the entry back to Contents 1).

Once done, you will see the entry is properly formatted and all tabs appear as they should.  This can be done for all entries and the Table of Contents will then look exactly as it should.  The problem is, once an edit or update is done to the table, the left column will revert to the incorrect layout and the style actually shown will no longer match the Contents 1 style with respect to the tab settings.  It is a long and arduous task (depending on the size of the ToC) and won't remain, but it will make the ToC look exactly like it is supposed to...at least for a little while.

A complicating factor is the inability to specify a tab stop that is right-aligned on the Entry tab.  There may be good reason for this, if everything else worked properly.  However, at present, it prevents manually setting a right-aligned tab at the proper location which could be an effective work-around that would stay.  If it were possible to set a tab stop position and also right align it, there is good evidence to suggest it would deliver the desired end result (though it would require manual adjustment if there were changes to margins, column widths, or gutter width, so it could not be considered a solution).

In the meantime, the only work-around available that will remain effective over time appears to be to set a left-aligned tab near the right margin.  This will generally cause all columns to lay out properly, but with the caveat that the page numbers will not be right aligned.  It's not great and looks a bit sloppy, but the appearance is better than the alternative.
Comment 17 Marcus 2017-05-20 10:45:06 UTC
Reset the assignee to the default "issues@openoffice.apache.org".