LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show HTML Part by Default
Condense Mail Headers

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

Print Reply
Sender:
Mailing list for the LaTeX3 project <[log in to unmask]>
Subject:
From:
Frank Mittelbach <[log in to unmask]>
Date:
Thu, 7 Oct 1999 10:19:02 +0200
In-Reply-To:
<l03130300b41a50f6a493@[130.239.20.144]>
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Parts/Attachments:
text/plain (210 lines)
Lars,

> Here are some thoughts about templates and font selection. Perhaps I
> thought about it a bit too long, because the mail got a bit
> long-winded, but I hope you'll endure it.

long-winded or not your post does contain a lot of interesting
thoughts which are worth pursuing further. but before looking at fonts
let me first discuss template types a bit further and explain how i
understand that concept (this might also answers some of the questions
James posed in a different message).

you wrote:

> \DeclareTemplateType{noparams}{0}
> \DeclareTemplate {noparams}{author-fonts}{0}{
>    medium      =n [m]   \mddefault,
>    boldface    =n [b]   \bfdefault,
>    light       =n [m]   \ltdefault,
>    upright     =n [n]   \urdefault,
>    italic      =n [it]  \itdefault,
>    slanted     =n [sl]  \sldefault,
>    smallcaps   =n [sc]  \scdefault
> }{\DoParameterAssignments}
>
> (Or perhaps author-fonts should be a type and the template should be
> named default or something. I'm not sure, but it seems odd that all
> templates without parameters (i.e., having type noparams in the above
> setting) should always be affected by the same \UseCollection
> commands.)

if we would have a template type "noparams" what is it supposed to
mean? As Lars said: "it seems odd that all templates without
parameters should always be affected by the same \UseCollection
commands". And indeed, this is not only odd it is against the
philosophy of template types!

The purpose of the template type is the following:

 loosely speaking it is supposed to ensure that an instance of some
 template type could be exchanged with another instance of the same
 template type without making the code produce rubbish or doesn't work
 any more.

 now the above example template type called "noparams" is setting font
 defaults which is something completely different than say

\DeclareTemplate{noparams}{TeX}{0}{
  uchyph                   =c [1]   \uchyph,
  hyphenpenalty            =c [50]  \hyphenpenalty,
  exhyphenpenalty          =c [50]  \exhyphenpenalty,
  lefthyphenmin            =c       \lefthyphenmin,
  righthyphenmin           =c       \righthyphenmin,
}
 {\DoParameterAssignments}

which is also a template that doesn't take mandatory parameter. So if
one would claim that both such templates are of the same type we would
claim that a class designer could replace an instance of the first
template with an instance of the second. we don't mean this do we?

so the template type is more than just the number of parameters and
their meaning: it is an informal summary of the semantics of the
code/purpose/action/effect it has. this includes the semantics of its
mandatory parameters but it also includes its overall effect. Thus a
template which is setting up the hyphenation mechanism of TeX (like
the one above) should have a template type with a dedicated name (say
"hyphenation") which has the following informal description: "templates of
my type customize the TeX hyphenation algorithm and take no mandatory
parameter". (it should probably be far more verbose, eg saying
something about the scope of the customization etc etc)

 And a template which sets up the font defaults should perhaps have a
type called "fontdefaults" and an informal description ...

This way we would not mistakenly replace an instance which sets up
fonts with an instance setting up hyphenation and vice versa but only
with instances that are "compatible in nature".

as a side remark: my experience with templates that are doing
declaration only (eg do not have mandatory arguments and no code
section worth mentioning (like those above)) is that you seldom end up
with more than a single template per type. as a result you may start
wondering about the whole concept of separating type and
template. Well the answer is that with template types that encapsulate
more complex stuff (eg a list template type) you will soon find that
there are several different templates possible that all fit this type.
but even with such declaration thingies you sometime want to provide
more than one template, for example, to offer different styles of
declaration. So instead of the template TeX (of type hyphenation no
noparams :-) above which is simply setting the low-level TeX
parameters one could also offer the following template:

\newcount\@@lefthyphenmin

\DeclareTemplate{hyphenation}{std}{0}{
  hyphen-disable-boolean   =s  {\ifnum\@@lefthyphenmin<\@M
                                  \@@lefthyphenmin\lefthyphenmin
                                  \lefthyphenmin\@M
                                \fi}
                               {\ifnum\@@lefthyphenmin>\z@
                                  \lefthyphenmin\@@lefthyphenmin
                                \fi},
  hyphen-uppercase-boolean =s  {\uchyph\@ne}{\uchyph\z@},
  hyphen-discourage-boolean=s  {\hyphenpenalty\@highpenalty
                                \exhyphenpenalty\@highpenalty}
                               {\hyphenpenalty\@lowpenalty
                                \exhyphenpenalty\@lowpenalty},
}
 {\DoParameterAssignments}

with instances like

\DeclareInstance{hyphenation}{off}{std}
    {hyphen-disable-boolean    = true}

\DeclareInstance{hyphenation}{on}{std}
    {hyphen-disable-boolean    = false,
     hyphen-uppercase-boolean  = true,
     hyphen-discourage-boolean = false}

\DeclareInstance{hyphenation}{discourage}{std}
    {hyphen-disable-boolean    = false,
     hyphen-uppercase-boolean  = true,
     hyphen-discourage-boolean = true}



=============================

confused everybody enough? hope not :-)

here is another way to look at it via some example: below is a user
declaration for a description environment.

 \DeclareDocumentEnvironment {description}
    { }
    {\UseInstance{list}{description}
       \NoValue  \NoValue  \BooleanFalse
     }
    { \EndThisList }

\DeclareInstance{list}{description}{vertical-std}{ ... }

what do we see here?

a)  An instance of type "list" is called which seems to take three
    mandatory arguments (all of which have preset values, ie \NoValue
    \NoValue and \BooleanFalse)

b)  There is this strange \EndThisList

c)  The instance description is declared using a template "vertical-std"


In fact this is an example of the list template type as described in
the Vancouver talk as follows:

    To format list structures such as \texttt{itemize} there might be a
    template type called \texttt{list} with the following
    characteristics:
    \begin{itemize}
    \item
      Starts a list structure embedding it into the surrounding formatting
    \item
      Sets up a command |\ListItem| (one argument)
      to start a new `item' of the list
    \item
      Sets up a command |\EndThisList| to finish the current list
      structure properly
    \item
      Expects three arguments with the following semantics:
      \begin{itemize}
      \item
        String to calculate width of left indentation, or |\NoValue|
      \item
        Symbol/string to be used as item label, or |\NoValue|
      \item
        Boolean to denote whether or not numbering continues
      \end{itemize}
    \end{itemize}


in other words, not only the semantics of the three arguments are part
of the template type but also the fact that each such template is
supposed to set up \EndThisList and \ListItem.

And of course this has to be the case if i want to be able to replace
the instance "description" above with an different declaration  which
might look like this:

 \DeclareInstance{list}{description}{inline}{ ... }


While the template "vertical-std" produces lists which look like
current LaTeX lists (ie vertically oriented ...) the "inline" template
would contain code that makes a run-in list ie one that is
horizontally oriented. All this would only work if both templates take
the same number of arguments (and interpret them in the same way) and
in addition also behave otherwise compatible, ie they both have to set
up \EndThisList etc --- thus the template type is the sum of all such
characteristics.

hope all this helps a little bit in understanding what we try to
provide

frank

ps who is long-winded??? :-)

ATOM RSS1 RSS2