https://issues.apache.org/ooo/show_bug.cgi?id=29920
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #16 from [email protected] --- 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. -- You are receiving this mail because: You are on the CC list for the issue. You are watching all issue changes.
