On 2015-11-24, Georg Baum wrote:
> Guenter Milde wrote:
>> Dear Lyxers,
>> thanks to Uwe for removing the non-ASCII character from ERT in
>> doc/fr/Additonal.lyx in 98746f3bda2df7d3/lyxgit.
>> Unfortunately, the export to XeTeX
>> lyx-svn -e pdf4 Additional.lyx
>> still fails (error log below).
...
>> Error 84 returned from iconv when converting from UCS-4LE to ascii:
>> Ungültiges oder unvollständiges Multi-Byte- oder Wide-Zeichen
> This means that LyX gave invalid unicode to iconv when converting to ASCII.
Indeed, LyX passes some 8-bit non-ASCII characters.
This is also true if exporting to 8-bit TeX and the inputenc is set to
ASCII - a valid and sensible use-case we should care for:
* characters in Document>Settings>PDF-Info
(solved for XeTeX), for inputenc==ASCII, there is no easy solution short of
telling the user to use LICR macros (ä -> \"a etc.).
* characters in additions by the Theorems (AMS) module.
! Undefined control sequence.
\theoremname ->\inputencoding
{latin9}Th�or�me
It seems the following code in the *.module file uses "language default"
input encoding independent of the setting:
BabelPreamble
\addto\captions$$lang{\renewcommand{\theoremname}{_(Theorem)}}
EndBabelPreamble
> I think this would be worth investigating, not because export to XeTeX of
> this document is important, but because this bug may appear in other, more
> important circumstances as well
It does: inputenc == ASCII
> French does only need the latin1 subset of
> unicode, which is covered 100% by lib/unicodesymbols. Therefore, LyX should
> be able to export to pure ASCII. Even if that is not possible for some
> reason, it should tell the user (the "uncodable character" warning), and it
> should never ever send invalid unicode to iconv.
True.
> IMHO it would be a good idea to create a bug report (not demanding working
> XeTeX export, but for fixing the iconv error).
Günter
