RE: support for 'macro' formatting languages

Subject: RE: support for 'macro' formatting languages
From: Pieter Rijken <pieter.rijken@xxxxxx>
Date: Thu, 16 Dec 1999 09:48:08 +0100

> >P.S. At the moment I have added a backend to support SDML (specific
> >     document markup language, or DECDocument, it runs on OpenVMS).
> >     SDML is a macro package on top of TeX. I have documents written
> >     in SGML, from which I generate TeX, RTF, and ...SDML. In order
> >     to make optimal use of SDML, I would like to access 
> macros defined
> >     in SDML without having to modify the DSSSL scripts.
> I don't follow what you want to do here, but it would appear 
> to me that you
> have the tool in place to do the automated high level 
> transform that I would
> think you need?

Partly you're correct. At the moment it is straightforward for
me to add special constructs to the backend so that i will be
able to use the macros of DECDocument. But this needs changes
in the DSSSL file which are specific to DECDoc. Since i also
generate RTF and TeX with OpenJade i wish to keep the DSSSL as
clean as possible.

If there's no 'clean' way, i.e. a decent SGML way, then i'll just
have to clutter up *all* DSSSL files with constructs that apply
only to a certain backend.....
I was just wondering whether there is a more clean appoach, e.g.
one in which it is possible to give 'hints' in the SGML document
what macro use, or one in which one only needs 1 DSSSL file per
'macro language'.

I'm aware of the fact that DSSSL wasn't designed to cope with
'macro languages' or intermediate (high level) output and therefore
no 'clean' solution exists.
Hopefully there's an acceptable solution to this (i guess) general



Pieter Rijken                          E-mail: pieter.rijken@xxxxxx

CMG Telecommunications and Utilities B.V.
Division Advanced Technology
Nieuwekade 1-19
P.O. Box 8038                 Phone: +31 30 2339300
3503 RA Utrecht               Fax:   +31 30 2339495
The Netherlands

DISCLAIMER: This statement is not an official statement from, nor
            does it represent an official position of, CMG
            Telecommunications and Utilities B.V.


 DSSSList info and archive:

Current Thread