LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Javier Bezos <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Wed, 24 Nov 1999 12:48:50 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (96 lines)
> > It so happens that I'm working in a new release of a package for
> > formatting of toc entries which already provides such a kind of
> > indexes in the currently available version. However, adapting
>
>may i (we have a look) at the 2e version of this package? i don't mind it
>being in a non-distributable/working state as long as the underlying ideas
>can be looked at without too much trouble
>
>nevertheless i'm eager to see you trying to produce a template or two for it
>since only this way we can see where the template concept needs corrections

Perhaps the main difference is that both the label and the page are not
automatically placed by the corresponding command but they should
be given explicitly. I finally became conviced that something like
 ...
 { (\textit{\theconstentspage})}
 ...
was easier to understand and modify than two arguments with the
pre- and postcode:
 ...
 { (\begingroup\itshape}
 ...
 {\endgroup)}
 ...
or a command for formatting the page (with an implicit argument):

 \def\tocpagefmt#1{ (\textit{#1})}
 ...
 {\tocpagefmt}
 ...
but no doubt there are other views on that. template
provides a more readable version of the latter:

number-format = \ (\textit{#1}),

but my implementation will follow the first procedure for
comparison purposes.

Another difference is how the text is shaped: the text and leaders
are in a rectangular block, with hanging label and page (provided
the usual format is used).

The original package provides a single command which only performs
code related to how entries are placed in the toc,
leaving the format of the entry itself to some hooks where
you may use a few extra commands with the page number, the
label, the leaders, paragraph format, etc.

Of course, this approach has some disavantages, for example the
necessity of defining *all* of parameters when redefining a toc
entry; but, as I say in the documentation, it is not intended to
just readjust the current format by a casual user. Now, here
templates can help, because some few templates can provide
the basic formats (sharing the same code) and creating new
templates could be easier.

However implementing new packages could be more complex, because
a level of evaluation is added. The following trivial example
illustrates what I mean. The usual way is:

\def\defineit#1{%
  \def\it{#1}}

The template way is (very, very simplified)

\def\defineit#1{%
  \def\@it{#1}
  \def\it{\@it}}

This extra level has many implications, because we cannot
define \it literally (ie, exactly as given by the argument) and
protection becomes a critical point:

\def\defineit{%
  \def\@it{#1}
  \protected@xdef\it{\@it}}

Temporary variables also become our daily bread. Will this extra
level of complexity pays? How will it affect the memory usage?

> > it to the suggested templates is turning out to be more difficult
> > as I expected because most of things are handled in a quite
> > different way. The same applies to partial tocs. However,
>
>can you try to explain why or how partial tocs are a problem or handled quite
>differently in your approach? (not that they are yet really handled in
>xcontents at all

Mmmm... Perhaps the main difference is that xcontents doesn't handle
them at all! :-)

More thoughs when I send the package (probably next week).

\bye
Javier Bezos

ATOM RSS1 RSS2