User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101
            Thunderbird/24.4.0
MIME-Version: 1.0
References: <201404302117.s3ULHiFB000725@freefriends.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <53616EC3.1010308@nag.co.uk>
Date:         Wed, 30 Apr 2014 22:44:35 +0100
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
Sender: Mailing list for the LaTeX3 project <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
From: David Carlisle <davidc@NAG.CO.UK>
Organization: NAG
Subject: Re: preview of latex2e 2014 release
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <201404302117.s3ULHiFB000725@freefriends.org>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

On 30/04/2014 22:17, Karl Berry wrote:
> David,
>
> Sorry, but it's not clear to me: is the only change for inputenc to
> complain in the case of xetex and luatex?  I hope so.  If that's the
> case, then it's all relatively minor; if you're changing behavior
> with pdftex/etex, that's another matter entirely.

no change to the engines!

The main point of the change is to make

\usepackage[utf8]{inputenc}

_work_ with xetex/lluatex (by doing nothing) rather than failing with
some horrible internal error as the internal loops trip over the
multibyte encoding.


>
> At any rate, as a matter of principle, MHO: I agree with Heiko that
> at this late date, it would be much better to make the new checks be
> warnings rather than errors.  Otherwise documents which produced
> output before will no longer do so.  This seems to go against the
> fundamental mandate of "be backward compatible" for latex2e.

The major change is the other way, making documents that failed to work
on xetex/luatex work. the case heiko mentioned [ascii]{inputenc} was
only stopped as basically we didn't think of it, the code has already
been fixed in svn.

the error message or warning given for all the other 8bit encodings are
cases that as far as I can see do not work anyway in xetex/luatex.
The change is that you get a message telling you to use utf8 rather than
it just failing on some internal code.


>
> I'm not sure if this is happening, but if it is: I feel even more
> strongly about not "invalidating" any new characters under any
> circumstances whatsoever.  That is also just breaking users for no
> good reason, as far as I can see.

I'm not sure what you mean but it isn't doing that. the situation is
that inputenc was not written for and never worked with xetex or luatex.
the advice (which has to be given very often) to people who get weird
errors with documents using inputenc with xetex is that they remove that
package. the change is to not get weird errors and to make the case that
can work (utf8) work without error at all.
>
> Finally: we are only a few weeks from putting this out into the
> world. It seems to me that anything beyond a warning if xetex/luatex
> are being used is too invasive a change to be contemplating at this
> point.

as I say the main point of the change is that if you use [utf8] you
_only_ get a warning, and the document is processed using the native
utf8 support instead of the package assuming utf8 will be seen as
multiple tex characters and so produce multiple spurious internal errors
and no document at all.

> Most users who will be affected by the new code will not see it until
> much later.  If you must legislate inputenc user behavior (you can
> tell by my phrasing that I am not in favor of the idea, not at all),
> I think it would be much better to do it after the release, when the
> only users who will be affected are those who are asking for the
> bleeding edge, and when you can quickly make a follow-up release to
> fix those users, as needed.
>
> When Frank told me about plans to make a new latex2e release for
> TL14, this is not the kind of thing I was imagining would be coming
> up.
>
> Sorry for the rather vehement message, but ... I'm scared.
>
> k
>

Hope you are less scared now?

David