Dear Günter, On Wed, Sep 21, 2016 at 09:33:32PM +0000, Guenter Milde wrote:
> > I tested Additional_pdf4 and I get the error "Error 84 returned from > > iconv when converting from UCS-4LE to ascii: Invalid or incomplete > > multibyte or wide character" Does that mean the character is not in a > > LaTeX comment? > > Actually, this is a reported LyXBug: > > #9871 LyX sends invalid Unicode to iconv when converting to ASCII OK. > While the Spanish and German Additional.lyx has Umlauts/Accents in > preamble and ERT, the French one is already "fixed" using m\^eme instead > of même in ERT. Still it fails. > The Spanish Additional.lyx fails also with iconv error, if I delete the > first ERT inset... > > So I'll change invertedTests to > > #9871 LyX sends invalid Unicode to iconv when converting to ASCII > # most probably due to BabelPreamble code (language specific headings for > # theorems, problems , ... are written in the language's default encoding > # if they contain non-ASCII characters) > export/doc/(es|fr)/Additional_pdf4_texF > > and > > # Non-ASCII in ERT, fails with inputenc==ASCII (e.g. XeTeX with tex-fonts) > export/doc/(de|es)/Additional_pdf4_texF OK. > > If so, then I think they are different issues (but related), because in > > the case of a comment it is possible to use a LyX note or comment > > inset. In the other case it seems that ERT really is needed. > > Yes, for the beamer doc this is an option. > > In Additional.lyx, the first ERT inset is an example for raw LaTeX: it > cannot be converted to something else. (However, the limitations on > characters-choice within ERT should be documented. But the example should > also show that the accented character works fine if it is supported by > the document encoding!) This means we have to invert (or ignore) the > pf4_texF test as "wontfix". > > As Additional.lyx is a very complex document, it makes IMO sense to ignore > it with pdf4_texF. I see. Indeed I cannot think of an alternative. > >> # Non-ASCII in ERT, fails with inputenc==ASCII (e.g. XeTeX with tex-fonts) > >> export/export/latex/nonASCII-ERT_pdf4_texF > > > OK, do you think this deserves a trac ticket to match? > > It is rather a "wontfix". Still, a "wishlist" track ticket > "Enable other encodings than "ascii" with XeTeX and TeX fonts" > could serve as a remainder and reference target. OK. > > >> * fix "inputenc" LaTeX package to allow XeTeX and set it to binary mode > >> * write a "xeinputenc" package to allow XeTeX and set it to binary mode > > Some years ago, I could use XeTeX with inputenc and 8-bit compatibility > mode: > > \ifdefined \XeTeXrevision > \XeTeXinputencoding "bytes" > \fi > > Then inputenc was "fixed" to check for XeTeX/LuaTeX and abort unless the > encoding is "ascii" or "utf8". The "fix" uses the same wrong assertion > (XeTeX=Unicode-Fonts) like LyX did until recently... > > There is a xetex-inputenc.sty, on https://github.com/wspr/xetex-inputenc > trying to overcome the issue (but it seems to be dead). I see. I will make an issue on that git repo to update the status. > > Again, thank you for this discussion. Although the issue is minor, I > > think the ideas behind it are important and I think we're slowly > > developing a consistent philosophy that we can agree should be > > represented by our ctests. For example, I agree with you that "the > > readability of the document is more important than allowing more tests". > > Good to know. > Keep the good work, Thanks, you too. Scott
signature.asc
Description: PGP signature
