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:
Frank Mittelbach <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Mon, 13 Oct 1997 21:45:37 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (81 lines)
Phillip Helbig writes:
 > >  > Should one break the author's name up into initials and surnames, so
 > >  > that the order could be different in the main title and the running head
 > >  > and/or different than the order in which the author would have put them
 > > you mean the running head might say "Einstein, A"? all i can say is
 > > that i have not been ever asked  to do it...
 >
 > What about just the last names (no initials) in the running head?
 > Or should there be ONE command for the running head?  This might prove
 > to inflexible, since some will want all author names, some et al. and so
 > on.

it is most definitely to restrictive as there are styles that want to
construct their running head names from author info in special ways.

but the interface might have a specification possibility that allows
to give a suggestion for running head.

the specification could either say that it is up to the class
implementation to use it (if present) or ignore it always

or one could specify that it will always overwrite constructed running
heads

both would have advantages and disadvantages


 > > by the way, i think that using multiple parameters in this, and other,
 > > macros is not very friendly. why not adopt the keyval syntax, ie
 > >
 > >  \date{communicated=xxxx,revised=xxxx}
 > >
 > > which allows a more elegant way to omit arguments, and identify what
 > > you are doing. i know its just sugar, but it would make bits of what
 > > you suggest easier to read
 >
 > Two problems here (perhaps some graphics/graphicx comments are
 > appropriate here:).  The keyword syntax is different from the normal
 > LaTeX style; by FORCING the author to include everything, compatibility
 > is assured.  If optional arguments (either in [] or via omitted
 > keywords) are used then each individual .cls should complain if keywords
 > are missing.  One must also avoid individual packages adding their own
 > keywords etc without coordination with others.

i would not rule out keyword value syntax just because it isn't
standard LaTeX behavior right now. on the contrary, within the LaTeX
project we think that keyword value is the way to go for several
reasons.

That does not mean that the current keyval implementation as used for
graphix can or should be used as a general model in implementation,
but we are talking about specification not implementation here.

as to whether extensibility is a feature advantage or disadvantage:
again this is partly something that can be best evaluated once we do
have a full spec.

If such a spec includes a number of mandatory keywords, a number of
optional ones but allows classes to add additional keywords that are
supposed to be ignored by classes not implementing them then this can
be a big improved. Of course it might also produce chaos if class A
defines foo to mean X and class B defines foo to mean Y then we are
back at incompatible classes.

However i don't really think this is a very likely case. I do see such
extensibility more for inhouse stuff, eg suppose that the AMS has some
class amsA.cls and the paper is accepted for journal A. Now in
production inhouse they use amsA-prod.cls adding additional keywords
as needed. Now if this file goes back to the user for proofing he
still uses amsA as the -prod version is not distributed. here the
additional keywords are then simply ignored.

what i do think is that we need to come up with a syntax (and
keywords) that cover most of the current standard and special cases
and then this extra extensibility will most likely prove beneficial.
its probably then similar to something like bibtex where people have
added fields to their bst styles and private bib files without really
causing incompatibilities.

frank

ATOM RSS1 RSS2