<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 1 Jul 2022 at 19:54, Zdenek Wagner <<a href="mailto:zdenek.wagner@gmail.com">zdenek.wagner@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">pá 1. 7. 2022 v 10:37 odesílatel Ulrike Fischer <<a href="mailto:news3@nililand.de" target="_blank">news3@nililand.de</a>> napsal:<br>
><br>
> Am Fri, 1 Jul 2022 10:26:29 +0200 schrieb Zdenek Wagner:<br>
><br>
> > Hi,<br>
> ><br>
> > in fact the problem is inputenc.<br>
><br>
> No it is not. \usepackage[utf8]{inputenc} works fine (but one<br>
> doesn't have to load it anymore as is it the default in pdflatex<br>
> since a few years).<br>
><br>
> The problem is with the concrete implementation of utf8 handling in<br>
> ucs/utf8x.<br>
><br>
><br>
> > If your input is in UTF8, it is better to use an engine working<br>
> > internaly in Unicode, i.e luatex or xetex.<br>
><br>
> Millions of documents use utf8 with pdflatex without problems. I run<br>
> 95% of my documents with pdflatex. They are all utf8-encode and as<br>
> I'm german my texts do contain umlauts and other non-ascii chars.<br>
> The only thing that pdflatex can't handle are combining accents.<br>
><br>
><br>
I am not that lucky, most of my old pdflatex documents fail. I often<br>
have \everypar containing a macro with one parameter for setting an<br>
initial. If I output it as {\otherfont #1} and the token is the first<br>
octet of a multioctet character, it fails. Character V as an initial<br>
needs an extra kern thus if the macro contains \if#1V and #1 is the<br>
first octet of a multioctet character, it fails. I often use<br>
\futurelet\testchar\dosomething and if \testchar becomes the first<br>
octet of a multioctet character, \dosomething fails. And it happens<br>
even without hyperref. I stopped using pdflatex a few years ago. Now I<br>
have 15 versions of TeX Live installed and when I have to recompile an<br>
old document, I go back in history and try, in which version of TL the<br>
document works. It is quite common for me that he old pdflatex<br>
documents do not work in the current TL.<br>
<br>
Zdeněk Wagner<br>
<a href="http://ttsm.icpf.cas.cz/team/wagner.shtml" rel="noreferrer" target="_blank">http://ttsm.icpf.cas.cz/team/wagner.shtml</a><br>
<br>
<br></blockquote><div><br></div><div>Your documents were presumably not specifying an encoding.</div><div><br></div><div>Since the default encoding was switched to UTF-8 we have had essentially no reports of documents breaking.</div><div>Any document that was correctly declaring  its encoding continues to work the same way, and any old document</div><div>using non-ascii characters without declaring an encoding (which was possible but never supported and produced <br></div><div>good or bad results depending on the font encoding in use) can be used with a current latex by adding</div><div>\UseRawInputEncoding</div><div><br></div><div>David</div><div><br></div><div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> --<br>
> Ulrike Fischer<br>
> <a href="http://www.troubleshooting-tex.de/" rel="noreferrer" target="_blank">http://www.troubleshooting-tex.de/</a><br>
><br>
<br>
</blockquote></div></div>