Bug 967359 - duplicated indexes in summary
duplicated indexes in summary
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: doc-High_Availability_Add-On_Overview (Show other bugs)
Unspecified Linux
unspecified Severity low
: rc
: ---
Assigned To: Steven J. Levine
: Documentation
Depends On:
  Show dependency treegraph
Reported: 2013-05-26 16:02 EDT by manuel wolfshant
Modified: 2015-02-20 11:25 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-02-20 11:25:08 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
highlight of the overlapping indexes (80.77 KB, image/jpeg)
2013-05-26 16:02 EDT, manuel wolfshant
no flags Details

  None (edit)
Description manuel wolfshant 2013-05-26 16:02:37 EDT
Created attachment 753374 [details]
highlight of the overlapping indexes

Document URL: 

Section Number and Name: 

Describe the issue: 

The first 2 parts of the introduction (1 Document conventions and 2. We Need Feedback!) have indexes which overlap with those of the first 2 chapters and make navigation via the summary links incorrect
See the attached snapshot

Suggestions for improvement: 
 Define correct indexes

Additional information:
Comment 2 Steven J. Levine 2014-07-17 15:49:36 EDT
The appearance of the numbering within prefaces/introductions is how the books build, and this is how it appears in all of the documents on the Customer portal, numbered like this: The main sections of the prefaces are numbers as 1, 2, etc.  And the main chapters are numbered as 1, 2.

I will look into finding out where to address this BZ, but it's not specific to this document.
Comment 3 manuel wolfshant 2014-07-17 19:09:20 EDT
What can I say? 25 years ago when I started to use multilevel lists, having the summary not functional because of incorrect indexes was considered an error and led to the proof reader rejecting that particular version of the document. But of course one can always go with a "good enough" policy.
Comment 4 Steven J. Levine 2014-07-18 10:33:21 EDT
I can't say that I like it myself.
Comment 5 Steven J. Levine 2014-07-28 12:08:24 EDT
With 6.6 Beta about to go out the door, for administrative reasons I'm moving this to 6.7 until I can determine where to pass this information along. It may be an RFE for publican itself -- that's my current thought -- which is not connected to any particular release.
Comment 6 Steven J. Levine 2015-02-20 11:25:08 EST
I am no longer seeing this issue in the latest builds on the Portal (there has been some work on re-doing the formatting through Publican, including streamlining what appears) so I'm closing this Bug.

Note You need to log in before you can comment on or make changes to this bug.