User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101
            Thunderbird/24.5.0
MIME-Version: 1.0
References: <535FB8BC.2040409@nag.co.uk>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID:  <536078C4.5040103@googlemail.com>
Date:         Wed, 30 Apr 2014 06:15:00 +0200
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: Heiko Oberdiek <heiko.oberdiek@GOOGLEMAIL.COM>
Subject: Re: preview of latex2e 2014 release
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <535FB8BC.2040409@nag.co.uk>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

On 29.04.2014 16:35, David Carlisle wrote:
> We are planning a new release of LaTeX2e in the next day or so to CTAN
> (hopefully in time to get into texlive 2014 test releases).
> 
> If anyone wants to have a look at any of the updated files before they
> go to CTAN there is a _temporary_ dropbox location where the files may
> be found at
> 
> https://www.dropbox.com/sh/ms53wpmpo36ycpb/xLSAYzzhs2

Taking these files I have made a pre-release for latex-tds:

https://dl.dropboxusercontent.com/u/71873949/tmp/latex-tds/base.tds.zip
https://dl.dropboxusercontent.com/u/71873949/tmp/latex-tds/cyrillic.tds.zip
https://dl.dropboxusercontent.com/u/71873949/tmp/latex-tds/graphics.tds.zip
https://dl.dropboxusercontent.com/u/71873949/tmp/latex-tds/tools.tds.zip

The documentation is regenerated using links and bookmarks.
The files in the .zip files are organized according to the TDS standard.

> Note that this is a "raw" distribution with no pre-built format, not
> intended for production work, and will only be available for a few days.

Same here.

> distrib/doc/ltnews21.pdf

| inputenc package updates The inputenc package
| allows different input encodings for LaTeX documents to
| be specified, importantly the utf8 option to specify the
| Unicode UTF-8 encoding. A common mistake has been
| to use this option with Unicode-based TeX engines
| LuaTeX and XeTeX, however inputenc does not work
| (and is not needed) with those systems. The package
| has been modified so that if used with LuaTeX or
| XeTeX, then it just issues a warning if utf8 is specified,
| and stops with an error for any other encoding
| requested.

Encodings ascii.def and x-ascii.def
-----------------------------------
A use case for these encodings is that a document should not
contain problematic non-ASCII characters. Thus inputenc
cries, if a 8-bit character or control characters is present.
Since a valid document only contains 7-bit characters, this
works very well with LuaTeX and XeTeX.
IMHO, inputenc must not throw an error. Instead:
* It should disable the 7-bit control characters of package
  inputenc as without LuaTeX/XeTeX.
* The other characters in the Unicode range with codes > 127
  are way too many for inputenc to handle. (Each character
  would have been made active and defined to throw an error.)
  IMHO the best approach is to ignore these characters.
* Instead of a warning, an info message is enough, at most
  a warning, which says character with character codes > 127
  are not handled by inputenc for LuaTeX/XeTeX.

Encodings utf8.def and utf8x.def
--------------------------------
The current version knows `utf8.def` and ignores it with
a warning. However, there are documents that are using
utf8x.def of package ucs. The same arguments are valid here:
* The document source is in UTF-8, more or less needed for
  XeTeX/LuaTeX.
* Thus an error would be wrong and a warning is enough.
  That should also be the case for utf8x.def
If someone uses a document for the old engines:

    \documentclass{article}
    \usepackage[utf8]{inputenc}
    \usepackage[T1]{fontenc} % or without
    \begin{document}

and gets a warning, that utf8 is not required for LuaTeX/XeTeX,
then he run into trouble (both with/without
\usepackage[utf8]{inputenc}):
  The characters with codes >127 are not mapped to the
proper LICRs, but are using the slots of the font encoding
OT1 or T1 (for example) with the consequences that characters
are missing or wrong. Thus a hint in the warning of inputenc
should be added, that package fontspec might be useful.

Yours sincerely
  Heiko Oberdiek