<div dir="ltr"><div><div>Hi all,<br><br></div>I was too busy with my own work so that I almost have not tested TL 2018. I found that my LaTeX documents do not work and since I have all releases starting at 2014, I have just switched back and had no time to examine it further.<br><br></div>Now I probably know the reason. I often use constructions as \futurelet\next\dosomething or \everypar{\setinitial} with \def\setinitial#1{... do something with the first character ...}. For these macros everything must be a character with category 11 or 12, not an active character. The inputenc package in case of UTF8 will give me just a part of the character. For this reason I use encTeX where active characters are not needed. As I am thinking about it just now, it seems to be easily solvable. The encoding files for encTeX can start with \csname UseRawInputEncoding\endcsname which will revert the encoding for new LaTeX and insert harmless \relax in all other cases. The same encTeX files are also used in the plain TeX so \csname seems to me as most portable.<br><br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature">Zdeněk Wagner<br><a href="http://ttsm.icpf.cas.cz/team/wagner.shtml" target="_blank">http://ttsm.icpf.cas.cz/team/wagner.shtml</a><br><a href="http://icebearsoft.euweb.cz" target="_blank">http://icebearsoft.euweb.cz</a></div></div>
<br><div class="gmail_quote">2018-07-25 11:36 GMT+02:00 David Carlisle <span dir="ltr"><<a href="mailto:d.p.carlisle@gmail.com" target="_blank">d.p.carlisle@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 25 July 2018 at 09:18, Zdenek Wagner <<a href="mailto:zdenek.wagner@gmail.com">zdenek.wagner@gmail.com</a>> wrote:<br>
<br>
><br>
> pdflatex is an 8-bit SW, it is not Unicode-aware. It is achieved by active<br>
> characters which break a lot of things. Almost all my older files ceased to<br>
> work with pdflatex and TL2018 .<br>
>><br>
<br>
</span>That's very surprising, you could have reported at least one to the team!<br>
<br>
Since the release I have only seen one report of a user file that<br>
generated an error<br>
(and that was silently mos-interpreting non ascii input in older<br>
releases so the error wasn#t really a bad thing)<br>
<br>
If you have an example of a conforming document that failed to work<br>
after the 2018 release let us know<br>
at the very least we can add to the documentation to say what to do,<br>
if that is not covered by the existing documentation.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
David<br>
</font></span></blockquote></div><br></div>