Menu
▾
▴
docutils-develop
|
From: Beni C. <cb...@us...> - 2003-09-10 09:46:32
|
Why doesn't the latex writer use ``\author`` and friends, when the info is present in bibliographic fields (I verified that the docinfo transfrom understood my fields correctly)? It outputs all fields as a table of bold field name: value, (as for any field list) which does improve consistency when you use fields latex doesn't support but it looks bad when I use ``document_class: book`` and the title page contains only a lone title, with the author as a field list on the next page. -- Beni Cherniavsky <cb...@us...> |
|
From: <gr...@us...> - 2003-09-10 14:24:07
|
On Wed, 10 Sep 2003, Beni Cherniavsky wrote:
> Why doesn't the latex writer use ``\author`` and friends, when the
> info is present in bibliographic fields (I verified that the docinfo
> transfrom understood my fields correctly)? It outputs all fields as a
> table of bold field name: value, (as for any field list) which does
> improve consistency when you use fields latex doesn't support but it
> looks bad when I use ``document_class: book`` and the title page
> contains only a lone title, with the author as a field list on the
> next page.
you answered it yourself, so what should i do ?
::
if docinfo length == 1 and docinfo contains author:
use latex docinfo
else
use docutils docinfo
actually the code contains self.latex_docinfo switch which is not a
constant making it a option would be an option (language is fun).
cheers
--
BINGO: Very funny, Scotty. Now beam down my clothes.
--- Engelbert Gruber -------+
SSG Fintl,Gruber,Lassnig /
A6170 Zirl Innweg 5b /
Tel. ++43-5238-93535 ---+
|
|
From: Beni C. <cb...@us...> - 2003-09-10 15:40:52
|
gr...@us... wrote on 2003-09-10:
> On Wed, 10 Sep 2003, Beni Cherniavsky wrote:
>
> > Why doesn't the latex writer use ``\author`` and friends, when the
> > info is present in bibliographic fields (I verified that the docinfo
> > transfrom understood my fields correctly)? It outputs all fields as a
> > table of bold field name: value, (as for any field list) which does
> > improve consistency when you use fields latex doesn't support but it
> > looks bad when I use ``document_class: book`` and the title page
> > contains only a lone title, with the author as a field list on the
> > next page.
>
> you answered it yourself, so what should i do ?
>
> ::
>
> if docinfo length == 1 and docinfo contains author:
> use latex docinfo
> else
> use docutils docinfo
>
Perhaps (but also include date, latex seems to support only title,
author and date). Even better IMO would be to somehow abuse Latex to
make all other bibliographic fields parts of the title page. One idea
is to stuff them all into into the \author{} but I'm not sure what
constructs will work there (e.g. ``\\`` doesn't work, you need
``\and``). A more robust approach would be to use ``\nopagebreak``
after ``\maketitle``, stuff the other bib. fields into the same page,
and add add ``\pagebreak`` if document_class in 'book', 'report'.
Can anybody share some experience with abusing latex's titlepage,
before I start experimenting (I also need my university's logos at the
top :-()? A third option is to omit ``\maketitle`` altogether
generating our own titlepage.
--
Beni Cherniavsky <cb...@us...>
|
|
From: Beni C. <cb...@us...> - 2003-09-10 16:33:21
|
Beni Cherniavsky wrote on 2003-09-10:
> Even better IMO would be to somehow abuse Latex to make all other
> bibliographic fields parts of the title page. One idea is to stuff
> them all into into the \author{} but I'm not sure what constructs
> will work there (e.g. ``\\`` doesn't work, you need ``\and``). A
> more robust approach would be to use ``\nopagebreak`` after
> ``\maketitle``, stuff the other bib. fields into the same page, and
> add add ``\pagebreak`` if document_class in 'book', 'report'. Can
> anybody share some experience with abusing latex's titlepage, before
> I start experimenting (I also need my university's logos at the top
> :-()? A third option is to omit ``\maketitle`` altogether
> generating our own titlepage.
>
Checked, ``\maketitle`` doesn't respect an immediately following
``\nopagebreak``. But I found what we want:
\begin{titlepage}
text
\end{titlepage}
The `titlepage' environment creates a title page, i.e. a page
with no printed page number or heading. It also causes the
following page to be numbered page one. Formatting the title page
is left to you. The `\today' command comes in handy for title
pages.
Note that you can use the `\maketitle' (*note \maketitle::.)
command to produce a standard title page.
-- info latex --index titlepage
I believe the only sensible way is to make our own titlepage with it.
For document classes other than report and book, the `titlepage` env
should be omitted and the same(?) output should be generated on the
same page (are there other differences between the styles?). I'll now
try to look at the latex sources for the default title pages...
--
Beni Cherniavsky <cb...@us...>
|
|
From: Beni C. <cb...@us...> - 2003-09-10 18:57:25
|
Beni Cherniavsky wrote on 2003-09-10: > I believe the only sensible way is to make our own titlepage with it. > For document classes other than report and book, the `titlepage` env > should be omitted and the same(?) output should be generated on the > same page (are there other differences between the styles?). I'll now > try to look at the latex sources for the default title pages... > They have some frightening code (as expected ;), mostly because: 1. All(?) classes support making a separate title page or putting it at the top of the first page (default depends on class but you can override with the ``titlepage``/``notitlepage`` options). However only `article` and `report` actually implement ``\maketitle`` and they seem to implement it in the same way... 2. They support bogus ``\and`` instead of ``\\`` and ``\thanks`` instead of ``\footnote`` which we don't need. Removing this cruft, our titlepage would not be so complex. I can rip most of it from the LaTeX sources to preserve look-and-feel. I think that we should keep the look-and-feel of LaTeX's titlepages, with authors and date without any "Author:" and "Date:" prefixes and with other bib. fields in smaller font (but bigger than in document) after some vertical space, with field names but not in bold (otherwise they would draw too much attention from the titlepage). What do you think? -- Beni Cherniavsky <cb...@us...> P.S. is allowing comma/semicolon-separated authors so useful? Why can't we have a bullet list as the only, unambiguous, language-indendent, way to specify multiple authors? It certainly feels like cruft, the rules for checking first ';' and then ',' (and these are language-dependant, which is not even mentioned in the spec) are so complex to even remember... |
|
From: <eng...@ss...> - 2003-09-11 12:46:21
|
On Wed, 10 Sep 2003, Beni Cherniavsky wrote: > Beni Cherniavsky wrote on 2003-09-10: > > > I believe the only sensible way is to make our own titlepage with it. > > For document classes other than report and book, the `titlepage` env > > should be omitted and the same(?) output should be generated on the > > same page (are there other differences between the styles?). I'll now > > try to look at the latex sources for the default title pages... > > > They have some frightening code (as expected ;), mostly because: > > 1. All(?) classes support making a separate title page or putting it > at the top of the first page (default depends on class but you can > override with the ``titlepage``/``notitlepage`` options). However > only `article` and `report` actually implement ``\maketitle`` and > they seem to implement it in the same way... > > 2. They support bogus ``\and`` instead of ``\\`` and ``\thanks`` > instead of ``\footnote`` which we don't need. Removing this cruft, > our titlepage would not be so complex. I can rip most of it from > the LaTeX sources to preserve look-and-feel. > > I think that we should keep the look-and-feel of LaTeX's titlepages, > with authors and date without any "Author:" and "Date:" prefixes and > with other bib. fields in smaller font (but bigger than in > document) after some vertical space, with field names but not in bold > (otherwise they would draw too much attention from the titlepage). > > What do you think? looks silly sometimes, e.g. title, author, date are from latex one other line is a docutils docinfo. and this would not mean > I think that we should keep the look-and-feel of LaTeX's titlepages, maybe additional info could be put on the backside of the titlepage. (or we could put it into the stylesheet. problem is how to put the stylesheet does not know the fieldnames) cheers -- BINGO: globally simplify cutting edge leadership --- Engelbert Gruber -------+ SSG Fintl,Gruber,Lassnig / A6170 Zirl Innweg 5b / Tel. ++43-5238-93535 ---+ |
|
From: Beni C. <cb...@us...> - 2003-09-11 13:06:05
|
eng...@ss... wrote on 2003-09-11:
> > I think that we should keep the look-and-feel of LaTeX's titlepages,
> > with authors and date without any "Author:" and "Date:" prefixes and
> > with other bib. fields in smaller font (but bigger than in
> > document) after some vertical space, with field names but not in bold
> > (otherwise they would draw too much attention from the titlepage).
> >
> > What do you think?
>
> looks silly sometimes, e.g. title, author, date are from latex
> one other line is a docutils docinfo.
>
I now think date should not be LaTeX's, it's no more special than
organization or contact... However, title and author, in my
(not-so-humble in this case ;) opinion should be shown simply by
central location and font size, as LaTeX does. They are, after all,
the two most important things about a document. It's not accidental
that LaTeX paid special attention to only a few things.
> and this would not mean
> > I think that we should keep the look-and-feel of LaTeX's titlepages,
>
> maybe additional info could be put on the backside of the titlepage.
Perhaps (for classes with a titlepage). It also avoids the danger of
overloading the front page. It'd be nice to leave it open to the
user.
> (or we could put it into the stylesheet. problem is how to put the
> stylesheet does not know the fieldnames)
>
That's most probably the best approach. We can expose the fieldnames
(all of them, duplicating ``\title`` and friends which would remain
only for benefit of programs that catalogue latex documents, etc.) as
macros; this way the stylesheet could use them or not. An
inconvenient point is that the stylesheet must know which fields are
present and which aren't; if we reverse it and make the writer emit
commands that the stylesheet should define, e.g.::
\showtitle{title}
\showauthor{author}
...
\showgeneric{Foo}{bar}
etc., then the writer is forcing the order of the fields - is this an
issue?
--
Beni Cherniavsky <cb...@us...>
|
|
From: <eng...@ss...> - 2003-09-15 05:52:51
|
to sum up beni's requirements.
1. the title page should be standard latex:
* 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.
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.
in the newest docu also an example on redefining the
maketitle is contained.
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.
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...
cheers
--
BINGO: Think outside the box
--- Engelbert Gruber -------+
SSG Fintl,Gruber,Lassnig /
A6170 Zirl Innweg 5b /
Tel. ++43-5238-93535 ---+
|
|
From: Beni C. <cb...@us...> - 2003-09-15 16:03:44
|
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...>
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X