LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Heiko Oberdiek <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Wed, 30 Apr 2014 13:42:21 +0200
Content-Type:
text/plain
Parts/Attachments:
text/plain (113 lines)
On 30.04.2014 10:56, David Carlisle wrote:
> On 30/04/2014 05:15, Heiko Oberdiek wrote:

> I'd wondered about fontenc originally but didn't as fontenc only works
> on these engines and if you are doing
> 
> \ifxetex
> \usepackage{fontenc}
> \setmainfont...
> \else
> ...
> \fi

This will then break with LuaTeX, thus actually something like the
following is needed:

\usepackage{ifxetex,ifluatex}
\ifxetex
  \usepackage{fontspec}
  \setmainfont... or whatever
\else
  \ifluatex
    \usepackage{fontspec}
    \setmainfont... or whatever, maybe different from XeTeX case
  \else
    \usepackage[T1]{fontenc}% or similar
    \usepackage[utf8]{inputenc}
    \usepackage{lmodern}% or whateverX
  \fi
\fi

> then you could load inputenc package in the \else branch and the problem
> this change was trying to help of inputenc not working with xetex/luatex
> would not be an issue. But perhaps you are right and mentioning fontspec
> would help.

If a user is able to write code such as above, then he would not
really need a warning/error of inputenc at all.

But I think it is not the issue here. The typical use case would be
that the use comes from traditional LaTeX, e.g.:

  \usepackage[utf8]{inputenc}% without fontenc

or

  \usepackage[utf8]{inputenc}
  \usepackage[T1]{fontenc}
  \usepackage{textcomp}

But that will break with LuaLaTeX or XeLaTeX, because
utf8.def expects bytes instead of big chars.

Just saying, inputenc is not necessary is not helping either.
The error messages will probably be gone, because neither
XeTeX or LuaTeX are able (AFAIK) to throw an error message
or even a warning, if glyphs are not available or that
the wrong glyphs are shown, because the font encoding is
not Unicode.

> on ascii I think it hadn't occurred to me that anyone was using inputenc
> with ascii:) unlike on pdftex it's not feasible to make all the
> non-ascii chars invalid but on the grounds of not breaking existing
> documents I think you are right that we should let ascii x-ascii and
> utf8x through.
> 
> It would be possible to do as you suggest above and disable the control
> characters below 32, but I think it's more important on unicode engines
> to move away from using active characters for encoding support so I'd
> rather just treat all these as aliases for the native engine utf8 support.

Ok. Perhaps I add something to `inputenx'.

> Which would mean something like
> 
> [...]
> \@tfor\reserved@b:={utf8}{utf8x}{ascii}{x-ascii}\do{%
> [...]
> 
> which makes
> 
> ! Package inputenc Error: inputenc not required for xetex or luatex.
> (inputenc)                only UTF-8 supported.

s/not/is not/
s/supported/is supported/
s/xetex/XeTeX/
s/luatex/LuaTeX/

> See the inputenc package documentation for explanation.
> Type  H <return>  for immediate help.
> [...]
> For xelatex or lualatex do not load inputenc or use [utf8] option.

At least "the inputenc package documentation" needs something
that explains the situation, as you have done here.

> for an unsupported encoding or for utf8(x) or (x-)ascii it does
> 
> Package inputenc Warning: inputenc not required for xetex or luatex.
> (inputenc)                utf8 assumed.
> (inputenc)                The fontspec package may be required to
> (inputenc)                access suitable fonts.

Much better.

s/xetex/XeTeX/
s/luatex/LuaTeX/
s/assumed/is assumed/

Yours sincerely
  Heiko Oberdiek

ATOM RSS1 RSS2