Dear Scott,
On 2016-09-21, Scott Kostyshak wrote:
> On Wed, Sep 21, 2016 at 09:31:31AM +0000, Guenter Milde wrote:
> Dear Günter,
> Thank you for your detailed reply!
>> >> > (1) revert the commit I pushed and invert the test
>> This is the simplest way.
> Agreed. But since similar issues will come up I think it is good to
> spend time talking about the ideal solution.
Yes, this is why I am still on it...
>> Especially, because we already have a similar case:
>> diff --git a/development/autotests/invertedTests
>> b/development/autotests/invertedTests
>> index 8dab991..8ee6a85 100644
>> --- a/development/autotests/invertedTests
>> +++ b/development/autotests/invertedTests
>> @@ -100,6 +100,7 @@ Sublabel: ert
>> # Non-ASCII in ERT, fails with inputenc==ASCII (e.g. XeTeX with tex-fonts)
>> export/doc/(de|es|fr)/Additional_pdf4_texF
>> +export/doc/fr/beamer_pdf4_texF
> 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
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
> 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.
...
>> IMV there are more important tasks but I won't stop you if you like to go
>> this way.
> I agree there are more important tasks. But again let's separate the
> discussion. One question is what are acceptable solutions. A separate
> question is what takes more time to implement. If we agree that there
> are two acceptable solutions and I choose to spend time on one of them,
> for me that is OK. In some sense I think this is the nice thing (and
> perhaps also the bad thing?) about open source: I don't have to spend
> time on the most urgent issues. I can spend time on something because it
> is fun or interesting or it is an annoying itch. I try to balance this
> and I do also spend a lot of time on things that are not that fun for me
> but that I think are more important.
I agree with this.
> To summarize my argument, I would say: I do not think that changing the
> ERT comment into a LyX note or a comment inset makes the document less
> readable. I am tempted to say it makes it *more* readable because a
> comment inset signals better to the reader than ERT that the contents
> are a comment, but I think I am searching too much here. In any case, my
> opinion is that one additional test has a small benefit, and I do not
> think there is a cost to the reader of the document. So:
> small benefit - 0 cost > 0
OK.
>> # 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.
>> * 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).
.....
> 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,
Günter
