OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: DOCBOOK-APPS: Problem with preface and jadetex

Sebastian Rahtz wrote:
> Kevin Dunn writes:
>  > At the beginning of the Preface, change
>  >
>  > {1}\def\PageNumberRestart%
>  > {1}\def\PageNumberFormat%
>  > {0}\def\StartIndent%
>  >
> ...
>  > Question for Sebastian: can Jadetex be made to handle roman
>  > numerals in the TOC? In 3.7 it complains when it finds a roman page
>  > number there.
>  >
> if PageNumberFormat is set to "0", then its a stylesheet error,
> surely? that does not make any sense, and I am not surprised that
> jadetex whinges.
> sebastian

Typically, jadetex requires three parses of the input .tex file before
the table of contents are generated (to resolve the forward references).

Each entry that appears in the table of contents is labelled. These
labels are stored in the .aux file.

Before/during the first parse, the aux file will be empty (will not

At the end of the first parse the labels will have been generated.
However, the final values of these labels will be not be known. A dummy
value of "-999" is used.

At the end of the second parse the value of these labels is calculated.
Looking at the .aux file will show this - it is easier to understand if
you use the "id" attribute to give each docbook element an id.

Finally, the third parse will use these final label values to popluate
the table of contents.

The problem occurs in the Setref macro.

It is the following logic (as I understand it)..

IF the label hasn't been calculated THEN
    write -999 as the value of the label
    IF the label is less than 0 THEN
       we still don't know the correct value so print a warning to that
       we know the label so do what we need to do with it....

Since jadetex 3.7 introduced support for roman numerals, the
implementation of this breaks. The problem is that the tex primitive
"ifnum" is used to test the value of the label to see if it is less than
0. This requires integer values to work. Roman numbers e.g. "i" do not
count as integers, so "ifnum" falls over horribly....

The following patch attempts to change the implementation of this logic.
It is against version 3.8 of jadetex (yes version THREE POINT EIGHT see

It makes the assumption that the only negative value of a label will be
"-999" - I'm not sure if this is a correct assumption thought - as in
the dim and distance past I seem to remember seeing other numbers....

diff -Naur jadetex-3.8-orig/jadetex.dtx jadetex-3.8/jadetex.dtx
--- jadetex-3.8-orig/jadetex.dtx  Mon Jul  9 11:47:12 2001
+++ jadetex-3.8/jadetex.dtx Mon Jul  9 13:42:18 2001
@@ -538,13 +538,13 @@
 \def\Pageref#1{\expandafter\@Setref\csname p@#1\endcsname{#1}}
-   \immediate\write\@mainaux{\string\pagelabel{#2}{-999}}%
+   \immediate\write\@mainaux{\string\pagelabel{#2}{qqq}}%
    \nfss@text{\reset@font\bfseries ??}%
    \@latex@warning{Reference `#2' on page \thepage \space
-   \ifnum#1<0
+   \ifx#1{qqq}
     \nfss@text{\reset@font\bfseries ??}%
     \@latex@warning{Reference `#2' on page \thepage \space undefined}%

Consider this experimental.... I think my explanation of the problem is
correct - but there could well be a better way of solving it that is
more robust/generalised - for example, make sure that "arabic" numbers
are written out into the table of contents, and only writing out the
correct format when needed... So comments, improvments please!



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC