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
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:
Fri, 5 Nov 1999 20:58:55 +0100
In-Reply-To:
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Parts/Attachments:
text/plain (48 lines)
Achim Blumensath writes:

 > Here are two (random) things I've thought of:
 >
 > a) General structure.  IMHO LaTeX should be much more modular so you can
 > replace parts you don't like with your own implementation. It could be
 > divided into the kernel containing just the programming environment
 > like xparse, etc., and a lot of modules, one for each aspect of actual
 > typesetting (lists, math, fonts, headings, pagestyle,...).
 >
 > The structure of a class file would be
 >
 >   preamble
 >   including modules
 >   declaring instances of templates defined in the modules

this is sort of what we have in mind. perhaps even more separated on the class
file level in the sense that a class file of the new type might in fact come
as (probably two files):

 a) a layout specification file which declares the layout which means loading
 template modules and declaring instances

 b) an interface file which maps those instances to document-level design.

 c) perhaps a third file which does nothing but essentially loads part a) and
    b)

this way the part a) can be also used by applications which use LaTeX as a
backend and perhaps prefer a different document syntax

at the same time part b) then declares class compatibility, ie two classes
sharing the same file b) can process the same documents.

 > The advantage would be that you could
 >
 >  o make cosmetic changes by writing a new class which uses other
 >    values to instantiate the templates, and
 >
 >  o make fundamental changes by writing a new module with different
 >    implementation of templates.

right. if this properly formalized one can also make use of graphical
interfaces (or rather build them) which allow to declare or modify a class by
changing it through such an interface, eg, a la Scientific Word class editor

frank

ATOM RSS1 RSS2