Bug 470165

Summary: incorrect page number format for parts in TOC
Product: [Community] Publican Reporter: Christopher Curran <ccurran>
Component: publicanAssignee: Brian Forte <bforte>
Status: CLOSED NOTABUG QA Contact: Content Services Development <ecs-dev-list>
Severity: medium Docs Contact:
Priority: medium    
Version: 2.0CC: mmcallis, publican-list, r.landmann
Target Milestone: ---Keywords: Documentation
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-11-06 20:45:29 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Christopher Curran 2008-11-05 23:00:40 EST
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-05 23:46:00 EST
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-06 20:45:29 EST
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.