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

# 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

• From: Ian Castle <bb+lists.docbook-apps@looksystems.co.uk>
• To: Sebastian Rahtz <sebastian.rahtz@computing-services.oxford.ac.uk>
• Date: Mon, 09 Jul 2001 13:45:43 +0100

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
>
> sebastian

Typically, jadetex requires three parses of the input .tex file before

labels are stored in the .aux file.

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

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 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
ELSE
IF the label is less than 0 THEN
we still don't know the correct value so print a warning to that
effect
ELSE
we know the label so do what we need to do with it....
ENDIF
ENDIF

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....

-----------------------
@@ -538,13 +538,13 @@
\def\Pageref#1{\expandafter\@Setref\csname p@#1\endcsname{#1}}
\def\@Setref#1#2{%
\ifx#1\relax
-   \immediate\write\@mainaux{\string\pagelabel{#2}{-999}}%
+   \immediate\write\@mainaux{\string\pagelabel{#2}{qqq}}%
\protect\G@refundefinedtrue
\nfss@text{\reset@font\bfseries ??}%
\@latex@warning{Reference #2' on page \thepage \space
undefined}%
\else
-   \ifnum#1<0
+   \ifx#1{qqq}
\protect\G@refundefinedtrue
\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