RE: Babel invoke inputenc where inputenc is not designed for xetex or luatex

Maybe you are the maintainer?

________________________________
De : David Carlisle <[email protected]>
Envoyé : dimanche 12 mai 2024 15:51
À : outlook user <[email protected]>
Cc : [email protected] <[email protected]>
Objet : Re: Babel invoke inputenc where inputenc is not designed for xetex or luatex

in texlive 20204 (and probably all earlier versions)
any use of \usepackage[arabic]{babel}  will raise errors with
lualatex or xelatex as the arabi package files are not in UTF-8
You should raise this with the arabi package maintainer.

with lualatex:

(/usr/local/texlive/2024/texmf-dist/tex/latex/arabi/arabicore.sty
  Arabi Core switching commands v1.0  2006/01/01   (may still change)
! String contains an invalid utf-8 sequence.
l.137 \ifcase#1\or
                 ��������� � \ \or �����������^^@�^^@^^@

xelatex recovers from that but then errors on

! Package inputenc Error: inputenc is not designed for xetex or luatex.
(inputenc)                only UTF-8 supported.




I _think_ the recommended way to specify the language these days is

\documentclass{article}

\usepackage{babel}
\babelprovide{arabic}

\begin{document}

x
\end{document}

which allows babel to keep control.


On Sun, 12 May 2024 at 14:31, outlook user <[email protected]<mailto:[email protected]>> wrote:
> (inputenc)                only UTF-8 supported.
>
> See the inputenc package documentation for explanation.
> Type  H <return>  for immediate help.
>  ...
>
> l.164 \endinput

> For xelatex or lualatex save the document in UTF-8 encoding
> and do not use inputenc, or use the [utf8] option.

On version 1.16.0 from TeX Live distribution version 2023 using LUALaTeX 2023.8.28. It appears when `\usepackage{babel}` is modified to `\usepackage[arabic]{babel}`

>From what I understand LUATeX use by default UTF-8 and using inputenc will conflict with it because it tries to re-define the encoding which is locked in LUA/Xe, so will end up in a "crash". So Babel (or whatever invoke it) shouldn't do it (I think it tries to use cp1256 here, despite not asking for it) when not using PDFTeX (or whatever needs it), like on that case. And worse, some calls takes priority so re-using inputenc to ask for UTF-8 won't correct the problem because it takes the first call only