Received: from webgate.proteosys.de (mail.proteosys-ag.com [62.225.9.49]) by lucy.proteosys (8.11.0/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id f06JpUp01580 for ; Sat, 6 Jan 2001 20:51:30 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f06Jpg730311 . for ; Sat, 6 Jan 2001 20:51:42 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0781A.100ACD00" Received: from mail.Uni-Mainz.DE (mailserver1.zdv.Uni-Mainz.DE [134.93.8.30]) by mailgate2.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f06JpP006463 for ; Sat, 6 Jan 2001 20:51:25 +0100 (MET) Received: from mailgate1.zdv.Uni-Mainz.DE (mailgate1.zdv.Uni-Mainz.DE [134.93.8.56]) by mail.Uni-Mainz.DE (8.9.3/8.9.3) with ESMTP id UAA15820 for ; Sat, 6 Jan 2001 20:51:24 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from mail.listserv.gmd.de (mail.listserv.gmd.de [192.88.97.5]) by mailgate1.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f06JpNM25763 for ; Sat, 6 Jan 2001 20:51:23 +0100 (MET) Received: from mail.listserv.gmd.de (192.88.97.5) by mail.listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <5.E48D90C6@mail.listserv.gmd.de>; Sat, 6 Jan 2001 20:51:23 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 478232 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Sat, 6 Jan 2001 20:51:20 +0100 Received: from ix.urz.uni-heidelberg.de (mail.urz.uni-heidelberg.de [129.206.119.234]) by relay.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id UAA26542 for ; Sat, 6 Jan 2001 20:51:19 +0100 (MET) Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by ix.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id UAA27296 for ; Sat, 6 Jan 2001 20:51:19 +0100 Received: from csc.albany.edu (sarah.albany.edu [169.226.1.103]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f06JpIU25087 for ; Sat, 6 Jan 2001 20:51:19 +0100 (MET) Received: from pluto.math.albany.edu (pluto.math.albany.edu [169.226.23.44]) by csc.albany.edu (8.9.3/8.9.3) with ESMTP id OAA20445 for ; Sat, 6 Jan 2001 14:50:41 -0500 (EST) Received: (from hammond@localhost) by pluto.math.albany.edu (8.9.3/8.9.3) id OAA03845 for LATEX-L@URZ.UNI-HEIDELBERG.DE; Sat, 6 Jan 2001 14:50:40 -0500 (EST) Return-Path: Content-class: urn:content-classes:message Subject: Re: GELLMU progress Date: Sat, 6 Jan 2001 20:50:40 +0100 Message-ID: <200101061950.OAA03845@pluto.math.albany.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "William F. Hammond" Sender: "Mailing list for the LaTeX3 project" To: "Multiple recipients of list LATEX-L" Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 3642 This is a multi-part message in MIME format. ------_=_NextPart_001_01C0781A.100ACD00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hans Aberg writes: > >... > >I would also like to see somebody translate it to TEI and then = compare > >the HTML and LaTeX formattings obtained chez Rahtz from TEI with the > >native GELLMU formattings. Actually, I am more interested in getting a copy for Info trees than in a TEI copy. (And there is now an SGML version of Texinfo thanks to Daniele Giacomini that formats to Texinfo.) I guess I thought that TEI fans might bite. I also believe that a DocBook version would prove useful inasmuch as Docbook is used by the Linux Documentation Project. > If you are in the need of various translations, have you tried using = Flex > (lexical analyzer generator) and Bison (parser generator, or > compiler-compiler), see Are you saying that it's easier to code translations from XML using lex and yacc descendants rather than using standard XML tools such as sgmlspl, jade, or xt? I find that hard to believe. (Of course, the situation before 1996 was different.) [snip] > -- I use them together with C++, which is convenient as the latter has > standard string classes. Although I've written in C, I've never gotten into C++. Are there good regular expression libraries for C++? > One approach is to parse objects into something like the DOM (Document > Object Model, http://www.w3.org/), and then onto that hook a program = that > can translate into several different formats. Of course, sgmlspl, jade, xt, and other standard sgml/xml tools provide good frameworks for translating into as many different formats as one likes by writing, respectively, Perl, DSSSL, and XSLT. (Possibly also it would be viable to use David Carlisle's xmltex followed by Eitan Gurari's tex4ht in which case one writes TeX.) The power of sgmlspl (though not the speed) can match that of any method except possibly when one wants to descend into CDATA segments. But then if one finds one's self tempted^{1} to do that (as one might, for example, in typesetting with TeX or LaTeX the name of TeX or LaTeX or even the ASCII character '~' from an XML document type that does not provide these things as empties^{2}), one should instead customize one's XML document type. -- Bill Notes: 1. There is one reasonable situation where descent into CDATA *should* take place: math mode contents need to be thoroughly parsed in translation to MathML from a document type that mathematical authors will find tolerable. But there is no issue of that type in connection with http://math.albany.edu:8010/glf/lfaq.xml although, alas, one will find , , and . I wonder how some of these things would survive a double translation gellmu/article ---(hypothetical)---> TEI ----> LaTeX . 2. The default "article" document type for _regular_ GELLMU provides three character names for each of the 33 non-alphanumeric but printable ASCII characters. Each of those is at risk for some conceivable translation target. But an author may simply use one of these characters for itself when it is safe for both LaTeX and HTML. And, for example, by default the syntactic translator understands things like "\$" and "\{". If the syntactic translator's new internal verbatim (which becomes , a list-like thing) is used (by calling the front gellmu-verblist for gellmu-trans), then 32 of of these 33 names are auto-generated (';' is omitted) from literal verbatim. Something almost identical happens to literal inline material like |*~$\| if "manmac" mode is enabled . ------_=_NextPart_001_01C0781A.100ACD00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: GELLMU progress

Hans Aberg <haberg@MATEMATIK.SU.SE> = writes:

> >...
> >I would also like to see somebody translate = it to TEI and then compare
> >the HTML and LaTeX formattings obtained chez = Rahtz from TEI with the
> >native GELLMU formattings.

Actually, I am more interested in getting a copy for = Info trees than
in a TEI copy.  (And there is now an SGML = version of Texinfo thanks to
Daniele Giacomini that formats to Texinfo.)  I = guess I thought that
TEI fans might bite.  I also believe that a = DocBook version would
prove useful inasmuch as Docbook is used by the Linux = Documentation
Project.

> If you are in the need of various translations, = have you tried using Flex
> (lexical analyzer generator) and Bison (parser = generator, or
> compiler-compiler), see

Are you saying that it's easier to code translations = from XML using
lex and yacc descendants rather than using standard = XML tools such as
sgmlspl, jade, or xt?  I find that hard to = believe.  (Of course, the
situation before 1996 was different.)

[snip]
> -- I use them together with C++, which is = convenient as the latter has
> standard string classes.

Although I've written in C, I've never gotten into = C++.  Are there
good regular expression libraries for C++?

> One approach is to parse objects into something = like the DOM (Document
> Object Model, http://www.w3.org/), and then onto that = hook a program that
> can translate into several different = formats.

Of course, sgmlspl, jade, xt, and other standard = sgml/xml tools
provide good frameworks for translating into as many = different formats
as one likes by writing, respectively, Perl, DSSSL, = and XSLT.
(Possibly also it would be viable to use David = Carlisle's xmltex
followed by Eitan Gurari's tex4ht in which case one = writes TeX.)

The power of sgmlspl (though not the speed) can match = that of any
method except possibly when one wants to descend into = CDATA segments.
But then if one finds one's self tempted^{1} to do = that (as one might,
for example, in typesetting with TeX or LaTeX the = name of TeX or LaTeX
or even the ASCII character '~' from an XML document = type that does
not provide these things as empties^{2}), one should = instead customize
one's XML document type.

          &nbs= p;            = ;            = -- Bill

Notes:

1.  There is one reasonable situation where = descent into CDATA
*should* take place: math mode contents need to be = thoroughly parsed
in translation to MathML from a document type that = mathematical
authors will find tolerable.  But there is no = issue of that type in
connection with http://math.albany.edu:= 8010/glf/lfaq.xml although,
alas, one will find <tex/>, <latex/>, and = <tld/>.  I wonder how some
of these things would survive a double = translation

      gellmu/article = ---(hypothetical)---> TEI ----> LaTeX .

2.  The default "article" document type = for _regular_ GELLMU provides
three character names for each of the 33 = non-alphanumeric but
printable ASCII characters.  Each of those is at = risk for some
conceivable translation target.  But an author = may simply use one of
these characters for itself when it is safe for both = LaTeX and HTML.
And, for example, by default the syntactic translator = understands
things like "\$" and "\{".  = If the syntactic translator's new internal
verbatim (which becomes <verblist>, a list-like = thing) is used (by
calling the front gellmu-verblist for gellmu-trans), = then 32 of
of these 33 names are auto-generated (';' is omitted) = from literal
verbatim.  Something almost identical happens to = literal inline
material like |*~$\| if "manmac" mode is = enabled .

------_=_NextPart_001_01C0781A.100ACD00--