Re: [Docutils-develop] biblio. fields in latex writer

[Beni C. <cb...@us...>]

eng...@ss... wrote on 2003-09-14:

> to sum up beni's requirements.
>
> 1. the title page should be standard latex:
>
Not a requirement.  I just think that the default look-and-feel should
match LaTeX's when possible.  At least for title and author.

>    * easy if we only use title,author,date.
>    * harder if some other fields are required.
>
>      could be done by building our own (fake standard)
>      titlepage supporting additional fields.
>
>      additional fields displayed
>
>      * like latexs date.
>      * as docinfo table.
>
Another choice: what material should go on the title page and what on
the next page (for report/book document classes).

> 2. the titlepage should contain the university logo
>
>    see fancyhdr documentation, and write a short docu
>    for docutils. see tools/stylesheets/style.tex for a start.
>
How is `fancyhdr` connected?  It would allow a logo on every page.
Currently I just redefined ``\maketitle`` in my stylesheet, with the
logo and hardcoded title/authors, as I wanted to position them...

> 3. a real issue for the latex writer is:
>
>    the latex writers document structure is:
>
>    * head prefix
>      stylesheet is included here
>    * title
>    * head
>    * pdf_info
>    * body prefix
>      with \begin{document}
>           \maketitle
>    * body
>    * body suffix
>
>    if the titlepage should be user modifyable we need a hook for the
>    titlepage construction. or maybe redefine maketitle in the stylesheet.
>
I think redefining maketitle is best approach, it will scale to cases
where the user changes the titlepage completely.  It also seems useful
to put the matter after \maketitle into another command that can be
redefined (``\aftertitle``).

>    and need to set latex variables for docinfo entries.
>
>    * title,author,date
>    * docinfofulltable: with author and date
>    * docinfotable: without author and date
>    * maybe docinforevision, docinfo...
>
The main tradeoff is between a "pull" style (the user gives the
structure, order and layout, using variables we have set to fill in
the fields) and a "push" style (we give the structure, the user has
hooks to style parts of it).  I think the "pull" style's flexibility
can't be matched, so I'd prefer it.

The problem is that generic fields can't be done using the pull style
(TeX has no normal list/dictionary data types to describe this ;-).
Only the finite set of known fields can be done so.  Generic fields
would have to be done in the push style - the latex writer writes sort
of a table but the real formatting is delegated to commands defined by
the stylesheet.

Moreover, as the set of known fields grows, fields that used to be
generic become special and don't appear in the pull style unless the
user explicitly handles them.  That's the typical issue with pulling
data - you lose anything not explicitly included.  Solution: the user
uses special commands to enumerate the fields he has explicitly
handled.  Perhaps the very use of a field in ``\maketitle`` should
disable the output of it as a generic field.

Also, we need to allow the stylesheet to detect which fields are
present (only from the known set).

Example of simple imaginary stylesheet::

    \renewcommand{\maketitle}{
      \begin{titlepage}
        \begin{center}
          \hfill
          {\Huge \bibfieldtitle}
          \hfill
          \ifbibfieldauthor{\LARGE \bibfieldauthor}\fi
          \hfill
        \end{center}
      \end{titlepage}
    }
    %
    \showedbibfieldtitletrue             % Could be omitted for title
    \showedbibfieldauthortrue
    \renewcommand{\genericbibfield}[2]{  % name, value
      {\large #1: #2}
    }
    \renewcommand{\aftertitle}[1]{       % generic fields.
      \vskip
      \begin{center}
        #1
      \end{center}
    }

And this doesn't completely handle single/multiple authors yet...
Probably this should be presented to the stylesheet as two fields
"author" vs. "authors" of which at most one is defined.  For "authors"
we also probably need to repeat the "push" trick: the value of this
field would have hooks for styling the separation between authors.

It's easier to program python than TeX...  Perhaps I'm loading too
much into the tex stylesheet and some of this should be off-loaded
to python.  empy comes to mind...

-- 
Beni Cherniavsky <cb...@us...>