[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 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 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 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 http://sf.net/projects/jadetex). 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}} \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 are written out into the table of contents, and only writing out the correct format when needed... So comments, improvments please! Regards, Ian.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC