On 04.12.16 16:09, Guenter Milde wrote:
> On 2016-12-03, mn wrote:
>
>> There might be some incorrect or unexpected behavior when switching
>> output engines in LyX, because Xetex does not support input-encoding
>> settings:
>
>> To reproduce:
>> Start a document, go to setup:
>
>> - first try something for pdflatex and
>> define under language: input encodig to other (here it was utf8)
>> (then close dialog, reopen dialog and)
>
> Which encoding did you select?
>

Switched from "language default" to "Custom: utf8"

>> - switch to fonts, set these to any combination of luatex/Xetex.
>
> Did you mean "tick the 'use non-TeX fonts'" button which activates the
> "fontspec" package for use of Unicode-encoded fonts?
>

Yes, switch to "Use non-TeX fonts (via XeTeX/LuaTeX)"

> With "use non-TeX fonts", both the input encoding and the font
encoding are
> set to "utf-8", overriding any setting under Settings>Language>Encoding.
>
>> Try to compile the document.
>
>> It will complain that inputenc is not suitable for the chosen engine.
>
> Not here. It just compiles.
>

I just retook the steps I outlined above again and had the same error again.

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

See the inputenc package documentation for explanation.
Type  H <return>  for immediate help.
 ...

l.158 \endinput

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

###

But I found that my usual way of invoking MinionPro for default roman
for pdflatex is apparently the culprit:

The preamble-code
\usepackage[textosf,mathlf]{MinionPro}

seems to trigger the behavior outlined above.

Although I fail to see why.
None of the related .sty-files pull in inputenc?

>> But then going back to doc-settings and just trying to unset the
>> other(utf8)-option back to default is inaccessible (greyed out).
>> To do anything about that you have to first also unset your
>> font-settings back to choices for pdflatex.
>
> Did changing the input encoding setting under Language>Encoding help
to make
> your document compile again? Which setting was required? Did it work with
> "non-TeX fonts" later?
>

Yes. For both tests when it failed and also when I noticed this behavior
in another document: unsetting first "Use non-TeX-fonts" and then
changing input encoding back to default, then rechecking "Use
non-TeX-Fonts" produced a PDF that compiled with XeTeX and looked as
expected.

Together with the apparent trigger mentioned above I currently do not
understand why un/checking inputenc:utf8 in LyX's gui has any influence
on this situation if it is ignored by LyX for XeTeX in he way you decribed.

>> This is wrong imho.
>
>> I think LyX should keep these settings for the usage case "switching
>> engines" but gracefully ignore inputenc settings for Xetex.
>
>> This was presumably intended to keep users from messing with inputenc
>> once Xetex was the chosen output engine for a document, but it is
>> confusing when you only find out later that you might have to use Xetex
>> instead of pdflatex.
>
> There is an important distinction between "use XeTeX/LuaTeX" and "use
> Unicode fonts" that even major LaTeX packages get wrong.
>
> Also, the custom counsel "use XeTeX" or "use LuaTeX" given to users with
> font problems or script problems is misleading. Switching the engine does
> not help without switching the fonts, too. Usually, this implies use
of the
> "fontspec" package, in LyX by ticking the "use non-TeX fonts" button.
>
> You can use XeTeX or LuaTeX and 8-bit TeX fonts (and there are rare but
> valid use cases).
>
> However, because even the creators of the basic "inputenc" package did
> get this wrong and added a test, XeTeX can no longer be used with
> inputenc when the input encoding is set to something other than "ascii".
> Therefore, LyX overrides the user-choice in Settings>Language>Encoding
> with XeTeX and 8-bit TeX-fonts. This can lead to errors when the document
> contains characters that LyX cannot convert to ascii.

Thanks for the explanation.
greetings
Mike

Reply via email to