> >My original proposal of doing such a declaration for the next LaTeX
> >release was violently opposed.
> An important difference between the suggestions is that you suggested that
> LaTeX should have a built-in uselessness (that prevented running it on
> non-e-TeX): you want to remove functionality. Certainly not before 2004,
> but nonetheless uselessness.
I haven't read David's suggestions like that. I too consider it sensible to
allow work for l3 be based on better/additional primitives which as a result
means that a l3 kernel will not run below TeX as an engine.
> What Frank suggests is rather to point out
> that an existing bug does go away if one uses e-TeX; this effectively adds
> functionality. Having inputenc always scream about it is probably to overdo
> it, but Frank seem to have in mind that enabling LICR objects for math
> should be done using a separate package inpmath.
i have implemented it as a separate package, for the sake of playing with
it. I haven't made up my mind what it should be. it could be
a) a separate package
b) a package option to inputenc
in any case it is *not* fixing a bug with the current inputenc, or the current
LICR since the current model used the IBM approach: if you can't fix it call
it a feature.
in other words: LICR commands currently are simply not allowed in
so all :-) the package (or whatever it becomes) does is provide new
functionality for those people who want it. (well new in the sense that it
works better for latin based languages than Vladimir's textmath, which also
provides that feature but with kerning problems)
right now if you use
you'll get a LaTeX error message telling you that this is not allow with an
additional package or with an option like "mathsupported" it will become a
possibility, but with a warning if you do not use a program that contains the
ps a new implementation using eTeX primitive is available from