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 f3AJrt406695 for ; Tue, 10 Apr 2001 21:53:55 +0200 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f3AJrtH01111 . for ; Tue, 10 Apr 2001 21:53:55 +0200 Received: from mail.Uni-Mainz.DE (mailserver1.zdv.Uni-Mainz.DE [134.93.8.30]) by mailgate1.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f3AJrsV19222 for ; Tue, 10 Apr 2001 21:53:54 +0200 (MET DST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C1F7.F94C8B80" 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 VAA29231 for ; Tue, 10 Apr 2001 21:53:54 +0200 (MEST) 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 f3AJrrV19218 for ; Tue, 10 Apr 2001 21:53:53 +0200 (MET DST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from mail.listserv.gmd.de (192.88.97.5) by mail.listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <7.17F6B23B@mail.listserv.gmd.de>; Tue, 10 Apr 2001 21:53:08 +0200 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 494562 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Tue, 10 Apr 2001 21:53:50 +0200 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 VAA26138 for ; Tue, 10 Apr 2001 21:53:49 +0200 (MET DST) 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 VAA51212 for ; Tue, 10 Apr 2001 21:53:49 +0200 Received: from sender.ngi.de (sender.ngi.de [212.79.47.18]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f3AJrmf01646 for ; Tue, 10 Apr 2001 21:53:48 +0200 (MET DST) Received: from istrati.zdv.uni-mainz.de (manz-3e3575ec.pool.mediaWays.net [62.53.117.236]) by sender.ngi.de (Postfix) with ESMTP id B7B7E96E3D for ; Tue, 10 Apr 2001 21:44:01 +0200 (CEST) Received: (from latex3@localhost) by istrati.zdv.uni-mainz.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id VAA01575; Tue, 10 Apr 2001 21:51:26 +0200 In-Reply-To: References: Return-Path: X-Mailer: VM 6.75 under Emacs 20.4.1 X-Authentication-Warning: istrati.zdv.uni-mainz.de: latex3 set sender to frank@mittelbach-online.de using -f Content-class: urn:content-classes:message Subject: Re: Justification/std template Date: Tue, 10 Apr 2001 20:51:26 +0100 Message-ID: <15059.25662.475497.225339@istrati.zdv.uni-mainz.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Frank Mittelbach" 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: 4034 This is a multi-part message in MIME format. ------_=_NextPart_001_01C0C1F7.F94C8B80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Lars =3D?iso-8859-1?Q?Hellstr=3D81=3DF6m?=3D writes: > My point was that by providing some kind of "compability template" = for > galley-related stuff one could make the transition from the LaTeX2e = to > LaTeX2e* much easier. i'm not sure that this is the way to go. but then i'm not at all sure = about the galley prototype at all (in comparison to most of the rest (even = though they are too prototypes only)) i rather think somebody (and not necessarily me, since i might just run = in circles) needs to take a heart and do some further thinking about = capturing those problems with the paragraph galleys. In the mean time one might in fact have a set of simpler templates that = model some of the galley interfaces, eg a "justification" template that = accepts the same arguments like those in xhj but does only this in a more direct = manner. > Today it is hard to start using galley simply because > you have to redo _everything_ in your layout that galley is involved > in---thus you face an enormous amount of work even though each part = of it > may have become much simpler. If one could redo e.g. the frontmatter = using > the galley interfaces and then select the compability template (which = would > essentially have galley try its best to imitate the old interfaces) = for the > reminder of the document, then I suspect that more people would = consider > trying it out. that might be an option if we find a way to sort of confine galley = lowlevel stuff to certain parts of the document but I don't see that really = working since the model is so different from lowlevel TeX. Thus you will not = find it easy or possible to switch between these models. > It's basically the old "how do we get enough people to switch to XXX" > problem that I think needs to be addressed. true, but galley as such seems to me a difficult candidate to chose a = path, mainly (as I said) because I'm less anyway. my current path of thinking (which is a good bit future) is to finish of = all major parts first, some of which will me usable standalone perfectly and = if those eventually form a more or less consistent base then perhaps even = spend some money on converting major packages to properly work with that = kernel. that would then form a kernel + "enough" packages that a large amount of document could be processed without the need for development = "beforehand" and would also serve as a good model for building further extensions. just a thought though (yet) speaking of stand alone packages: the frontmatter stuff that i'm = intending to finish for Gutenberg 2001 in May (as a prototype :-) is of that nature, = it would be usable with just 2 (or perhaps 3) basic modules, ie = template.sty (or a successor incorporating your suggestions), xtools.sty (which is a = compressed version of l3expl code suff like property lists queues etc in @ = notation) end perhaps a variant of xhj as a standalone version. frank ------_=_NextPart_001_01C0C1F7.F94C8B80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Justification/std template

Lars =3D?iso-8859-1?Q?Hellstr=3D81=3DF6m?=3D = writes:

 > My point was that by providing some kind of = "compability template" for
 > galley-related stuff one could make the = transition from the LaTeX2e to
 > LaTeX2e* much easier.

i'm not sure that this is the way to go. but then i'm = not at all sure about
the galley prototype at all (in comparison to most of = the rest (even though
they are too prototypes only))

i rather think somebody (and not necessarily me, since = i might just run in
circles) needs to take a heart and do some further = thinking about capturing
those problems with the paragraph galleys.

In the mean time one might in fact have a set of = simpler templates that model
some of the galley interfaces, eg a = "justification" template that accepts the
same arguments like those in xhj but does only this = in a more direct manner.

 > Today it is hard to start using galley = simply because
 > you have to redo _everything_ in your = layout that galley is involved
 > in---thus you face an enormous amount of = work even though each part of it
 > may have become much simpler. If one could = redo e.g. the frontmatter using
 > the galley interfaces and then select the = compability template (which would
 > essentially have galley try its best to = imitate the old interfaces) for the
 > reminder of the document, then I suspect = that more people would consider
 > trying it out.

that might be an option if we find a way to sort of = confine galley lowlevel
stuff to certain parts of the document but I don't = see that really working
since the model is so different from lowlevel TeX. = Thus you will not find it
easy or possible to switch between these = models.

 > It's basically the old "how do we get = enough people to switch to XXX"
 > problem that I think needs to be = addressed.

true, but galley as such seems to me a difficult = candidate to chose a path,
mainly (as I said) because I'm less anyway.

my current path of thinking (which is a good bit = future) is to finish of all
major parts first, some of which will me usable = standalone perfectly and if
those eventually form a more or less consistent base = then perhaps even spend
some money on converting major packages to properly = work with that kernel.

that would then form a kernel + "enough" = packages that a large amount of
document could be processed without the need for = development "beforehand" and
would also serve as a good model for building further = extensions.

just a thought though (yet)

speaking of stand alone packages: the frontmatter = stuff that i'm intending to
finish for Gutenberg 2001 in May (as a prototype :-) = is of that nature, it
would be usable with just 2 (or perhaps 3) basic = modules, ie template.sty (or
a successor incorporating your suggestions), = xtools.sty (which is a compressed
version of l3expl code suff like property lists = queues etc in @ notation) end
perhaps a variant of xhj as a standalone = version.

frank

------_=_NextPart_001_01C0C1F7.F94C8B80--