Received: from mail.proteosys.com ([213.139.130.197]) by nummer-3.proteosys with Microsoft SMTPSVC(5.0.2195.5329); Thu, 17 Jul 2003 12:34:50 +0200 Received: by mail.proteosys.com (8.12.9/8.12.2) with ESMTP id h6HAYicH031406 for ; Thu, 17 Jul 2003 12:34:48 +0200 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.27]) by relay2.uni-heidelberg.de (8.12.9/8.12.9) with ESMTP id h6HAStGl014255; Thu, 17 Jul 2003 12:28:56 +0200 (MET DST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C34C4F.0CF4C100" Received: from listserv (listserv.uni-heidelberg.de [129.206.100.27]) by listserv.uni-heidelberg.de (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id h6GM0AXX028243; Thu, 17 Jul 2003 12:28:21 +0200 Received: from LISTSERV.UNI-HEIDELBERG.DE by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8d) with spool id 1679 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Thu, 17 Jul 2003 12:28:21 +0200 Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by listserv.uni-heidelberg.de (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id h6HAILM9001520 for ; Thu, 17 Jul 2003 12:18:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by relay.uni-heidelberg.de (8.12.9/8.12.9) with SMTP id h6HAIlmp021972 for ; Thu, 17 Jul 2003 12:18:47 +0200 (MET DST) Received: (qmail 19329 invoked by uid 65534); 17 Jul 2003 10:18:44 -0000 Received: from pD90082D0.dip.t-dialin.net (EHLO wilson.rwth-aachen.de) (217.0.130.208) by mail.gmx.net (mp027) with SMTP; 17 Jul 2003 12:18:44 +0200 In-Reply-To: <16150.26432.179873.408825@pussy.npc.de> (Joachim Schrod's message of "Thu, 17 Jul 2003 11:07:12 +0200") Organization: Aachen University of Technology (RWTH) References: <20030710081528.A12401@diabolo.informatik.rwth-aachen.de> <78ADDA01-B2DC-11D7-8AE7-0050E4455404@atlis.com> <20030711081704.A14039@diabolo.informatik.rwth-aachen.de> <16146.60345.852158.31606@pussy.npc.de> <16150.26432.179873.408825@pussy.npc.de> Return-Path: X-OriginalArrivalTime: 17 Jul 2003 10:34:52.0402 (UTC) FILETIME=[0E634520:01C34C4F] User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) X-Accept-Language: de, en X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) x-pgp-fingerprint: CA13 274E 96EF 1DB1 4992 D7D4 D523 14FB 4752 F2EF X-Face: $:ZH*7V$(*!W]7{qQLhM-f#d(Q6#shsBz8[qPwvRr(Hy{#Y3-$C\85(LKA[4'=X]Jy\),51 DU?fMKf}G[2r)>~K8Z3dWD<'R/hRsgW>Q.Fytf-:n*FG&iWyWNMM+c)(_R.k`$zrcq5%9yt"cd)Q]c 5G_W!:/8\S4ytn&NYP,OVd_|*GjEqvk:zK(,BTXvqgj4 X-Spam-Score: -32.8 () EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA x-binford: 6100 (more power) x-pgp-affinity: will accept encrypted message for GPG Content-class: urn:content-classes:message Subject: Re: XML, UTF-8 and TeX engines Date: Thu, 17 Jul 2003 11:10:49 +0100 Message-ID: A X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: XML, UTF-8 and TeX engines Thread-Index: AcNMTw6BGSQhJKpuQpW9G/K0AZtijg== From: "Torsten Bronger" To: Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 4683 This is a multi-part message in MIME format. ------_=_NextPart_001_01C34C4F.0CF4C100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Halloechen! Joachim Schrod writes: >>>>>> "WH" =3D=3D William F Hammond writes: > > WH> Joachim Schrod writes: >>> But not necessarily the most interesting. There is also the >>> possibility of experimenting with new innovative approaches to style >>> sheets, given by modular XML processors like PXP and modular >>> typesetting engines like ant. > > WH> James Clark once wrote somewhere that style sheet processing is a > WH> limited form of sgml processing, and I've never had reason to = doubt it > WH> for author-side processing. Don't underestimate the power of less > WH> restrained frameworks like David Megginson's perl module SGMLS.pm = (and > WH> its friendly interface sgmlspl.pl) for formatting XML to LaTeX. > > As much as I respect James, I can only agree with him here on a very > very abstract level. With "style sheets" above I didn't mean > transforming XML to other markup languages, I meant *directly* > typesetting XML documents, with a *very* high quality, and including > all necessary intermediate steps (insertions -- figures, tables, > footnotes, endnotes, marginal note; table of contents/figures/etc., > cross references, complex counting schemes, bibliography, index > processing, etc: just look at all LaTeX packages or Context modules). > We don't have this today. But for most of these tasks there are already fairly good specialised programs. You only have to bring them together. None of them is really excellent though: BibTeX needs a replacement that uses XML at least for the .bib files and the output. Several projects are working on it. I'm still not sure about xindy, however it seems to be one of the stronger chain links. Surprisingly enough, TeX is the most serious limitation at the moment (of course also because it's so vital). It's still the best back-end for typesetting something, however its treatment of so-called special characters, lack of true unicode support, and the distinction text/math mode is really unfortunate. > FOP, the XML style sheet communities answer to the task, is not up to > that demand; its capabilities are not enough. Absolutely true. However, the biggest part of the problem is the absence of free good complete FO processors. > [...] XSLT is a write-only language when it comes to implementing > the "intermediate steps" above, that's no improvement to TeX macro > programming. It has poor semantics (like TeX, it's even missing > elementary boolean clauses), XPath has boolean expressions, and XSLT knows "choose" and "if". > and its syntax is horrible to read and thus maintenance is > hard. Well, it's a matter of getting used to. But you're right, finding fellow developers is very difficult. > Hopefully, development on the style sheet front has not stopped > here and will continue after the XML hype is gone. XSLT 2.0 has many improvements, e.g. real user-defined functions that can return a value and that can be used in XPath expressions. But there are other new things, too, that would have made my own XSLT efforts much simpler. I still consider this template matching a wonderful thing. So I agree that much has to be done, but I hope current XSLT will be the starting point. Tschoe, Torsten. -- Torsten Bronger, aquisgrana, europa vetus ------_=_NextPart_001_01C34C4F.0CF4C100 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: XML, UTF-8 and TeX engines

Halloechen!

Joachim Schrod <jschrod@ACM.ORG> writes:

>>>>>> "WH" =3D=3D William = F Hammond <William> writes:
>
> WH> Joachim Schrod <jschrod@ACM.ORG> = writes:
>>> But not necessarily the most = interesting. There is also the
>>> possibility of experimenting with new = innovative approaches to style
>>> sheets, given by modular XML processors = like PXP and modular
>>> typesetting engines like ant.
>
> WH> James Clark once wrote somewhere that = style sheet processing is a
> WH> limited form of sgml processing, and I've = never had reason to doubt it
> WH> for author-side processing.  Don't = underestimate the power of less
> WH> restrained frameworks like David = Megginson's perl module SGMLS.pm (and
> WH> its friendly interface sgmlspl.pl) for = formatting XML to LaTeX.
>
> As much as I respect James, I can only agree = with him here on a very
> very abstract level. With "style = sheets" above I didn't mean
> transforming XML to other markup languages, I = meant *directly*
> typesetting XML documents, with a *very* high = quality, and including
> all necessary intermediate steps (insertions -- = figures, tables,
> footnotes, endnotes, marginal note; table of = contents/figures/etc.,
> cross references, complex counting schemes, = bibliography, index
> processing, etc: just look at all LaTeX packages = or Context modules).
> We don't have this today.

But for most of these tasks there are already fairly = good
specialised programs.  You only have to bring = them together.  None
of them is really excellent though: BibTeX needs a = replacement that
uses XML at least for the .bib files and the = output.  Several
projects are working on it.  I'm still not sure = about xindy, however
it seems to be one of the stronger chain = links.

Surprisingly enough, TeX is the most serious = limitation at the
moment (of course also because it's so vital).  = It's still the best
back-end for typesetting something, however its = treatment of
so-called special characters, lack of true unicode = support, and the
distinction text/math mode is really = unfortunate.

> FOP, the XML style sheet communities answer to = the task, is not up to
> that demand; its capabilities are not = enough.

Absolutely true.  However, the biggest part of = the problem is the
absence of free good complete FO processors.

> [...] XSLT is a write-only language when it comes = to implementing
> the "intermediate steps" above, that's = no improvement to TeX macro
> programming. It has poor semantics (like TeX, = it's even missing
> elementary boolean clauses),

XPath has boolean expressions, and XSLT knows = "choose" and "if".

> and its syntax is horrible to read and thus = maintenance is
> hard.

Well, it's a matter of getting used to.  But = you're right, finding
fellow developers is very difficult.

> Hopefully, development on the style sheet front = has not stopped
> here and will continue after the XML hype is = gone.

XSLT 2.0 has many improvements, e.g. real user-defined = functions
that can return a value and that can be used in XPath = expressions.
But there are other new things, too, that would have = made my own
XSLT efforts much simpler.  I still consider = this template matching
a wonderful thing.  So I agree that much has to = be done, but I hope
current XSLT will be the starting point.

Tschoe,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus

------_=_NextPart_001_01C34C4F.0CF4C100--