Bug 470165 - incorrect page number format for parts in TOC
Summary: incorrect page number format for parts in TOC
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Publican
Classification: Community
Component: publican
Version: 2.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Brian Forte
QA Contact: Content Services Development
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-11-06 04:00 UTC by Christopher Curran
Modified: 2014-06-18 07:49 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-11-07 01:45:29 UTC
Embargoed:


Attachments (Terms of Use)

Description Christopher Curran 2008-11-06 04:00:40 UTC
Description of problem:
Part's have an incorrect page number format (roman numerals) in the table of contents. The page number should be in decimals for parts. Roman Numerals should only be used for the Preface, TOC and legal pages. 

This bug only seems to affect the publican-redhat package (I checked Jboss and could not find the same bug).



How reproducible:
Read the table of contents in http://documentation-stage.bne.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.2/pdf/Virtualization/Virtualization.pdf

  
Actual results:
Roman Numeral page numbers for parts

Expected results:
decimal page numbers for parts

Additional info:
The previous version of publican is not affected by this bug.

Comment 1 Jeff Fearn 🐞 2008-11-06 04:46:00 UTC
This is related to the use of preface inside of part.

It occurs in all versions of publican and for all brands.

This is due to the page.number.format template, the default code does not have any logic to differentiate the format used for a preface based on where the preface is located.

Comment 2 Brian Forte 2008-11-07 01:45:29 UTC
The behaviour ccurran describes is a consequence of the <preface> tag being used for material that isn't part of the book's front matter. Specifically, the Virtualization Guide's Book_Info.xml has a structure as follows:

<book>
    <xi:include href="font_matter_1_filename"></xi:include>
    <xi:include href="font_matter_2_filename"></xi:include>
    <part id="part_1_name">
        <title>part_1_title</title>
        <xi:include href="chapter_1_filename"</xi:include>
        <xi:include href="chapter_2_filename"</xi:include>
    </part>
    <part id="part_2_name">
        <title>part_2_title</title>
        <preface id="preface_2_title">
            <title>preface_2_title</title>
            <para>
                Introductory remarks about part 2.
            </para>
        </preface>
        <xi:include href="chapter_3_filename"</xi:include>
        <xi:include href="chapter_4_filename"</xi:include>
    </part>
    <part id="part_3_name">
        <title>part_3_title</title>
        <preface id="preface_3_title">
            <title>preface_3_title</title>
            <para>
                Introductory remarks about part 3.
            </para>
        </preface>
        <xi:include href="chapter_3_filename"</xi:include>
        <xi:include href="chapter_4_filename"</xi:include>
    </part>
    <!-- and so on -->
</book>

As jfearn notes above:

> This is due to the page.number.format template, the default code
> does not have any logic to differentiate the format used for a
> preface based on where the preface is located.

And it doesn't have that logic because prefaces are, by definition, front matter. This is, then, expected behaviour and not a bug.

The solution to ccurran's problem is to replace all the <preface> tags currently inside <part> tags in Book_Info.xml with <partintro> tags.

According to <http://oasis-open.org/docbook/documentation/reference/html/partintro.html> this tag 'contains introductory text, often an overview of the content of the Part.'

It has <part> and <reference> as parents and takes <title> and <para> as children.


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