Re: fr/beamer.lyx + pdf4: encoding issue
On Wed, Sep 21, 2016 at 09:33:32PM +, Guenter Milde wrote: > On 2016-09-21, Scott Kostyshak wrote: > > 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. In 2.2.x at 40c262cb and e81f6b04; and master at 513a0bc8 and 27beb8f0. Scott signature.asc Description: PGP signature
Re: fr/beamer.lyx + pdf4: encoding issue
Dear Günter, On Wed, Sep 21, 2016 at 09:33:32PM +, 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
Re: fr/beamer.lyx + pdf4: encoding issue
Dear Scott, On 2016-09-21, Scott Kostyshak wrote: > On Wed, Sep 21, 2016 at 09:31:31AM +, 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
Re: fr/beamer.lyx + pdf4: encoding issue
On Wed, Sep 21, 2016 at 09:31:31AM +, 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. > 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? 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. > >> Please no. If we never interpret ERT, then this will stay inverted > >> forever. Inverted tests are waiting for correction, at least this was > >> what I have/had in mind. > > > I tend to agree. Something feels wrong with inverting. Unless we label > > the issue as a LyX enhancement (and create a trac ticket) because there > > is no way in LyX to produce LyX-readable content in this case that can > > be exported to several different formats. > > However, > > a) this is something waiting for correction (with low priority, because >XeTeX + TeX-fonts is "exotic"). Agreed. >Possible changes include: > >* do not check ERT for unsupported characters (after all, the user is > responsible for ERT, this "helpfull" feature stands in the way quite > regularely). However, there is no agreement, other developers prefer > checking ERT. I think I remember the same thing---that this was discussed previously and that the majority opinion was that ERT should be checked (even comments). >* 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 I don't know enough to understand this. >* fix http://www.lyx.org/trac/ticket/9744 to make > non-TeX fonts default for compiling with XeTeX. > (This would not solve the test but make the problem even less urgent.) I think this is a good point. >* Change the ERT-comment to a LyX note eventually Yes, or comment inset. > b) "inverting this test" (i.e. adding a pattern for this test to >invertedTests)¹ will > >* add the "WILL_FAIL" test feature >* add the label "suspended" >* not add the label "export" > >because the test matches the "catchall pattern" for _texF in >suspendedTests. > > >> > (2) change the inset for all beamer manuals. > > >> +1 > > > OK I will go for this. I'll wait another day or so to see if Günter > > disagrees. > > 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. If by "I won't stop you" you mean the same thing as "there are more important tasks [that I should be working on]" then I think my above paragraph explains my philosophy on that. If instead you mean that regardless of time spent, you think that an alternative solution is better, then we should continue discussing which is the best path. 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 > Actually, only the French manual has this comment in ERT, all other > instances (en, de, ja) just have the "\setbeamercovered{transparent}" > LaTeX macro. Thanks for checking this. > If you fix the
Re: fr/beamer.lyx + pdf4: encoding issue
Dear Scott and Kornel, On 2016-09-21, Scott Kostyshak wrote: > On Tue, Sep 20, 2016 at 05:51:36PM +0200, Kornel Benko wrote: >> Am Dienstag, 20. September 2016 um 10:56:29, schrieb Scott Kostyshak >>>> > On Tue, Sep 20, 2016 at 06:28:48AM +, Guenter Milde wrote: >> > > On 2016-09-20, Scott Kostyshak wrote: >> > > The documentation is for documentation, test-use is secondary and >> > > "exotic tests" don't merit changes that make the documentation >> > > more difficult to read. >> > >> > I agree this is the right policy. If I convert those comments to a LyX >> > note or comment inset, this policy is still satisfied because the inset >> > is just as readable, right? So either: >> > >> > (1) revert the commit I pushed and invert the test This is the simplest way. 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 # inputencoding="utf8-plain" with Xe/LuaTeX: characters with # Unicode point > 256 lead to errors with 8-bit fonts >> Please no. If we never interpret ERT, then this will stay inverted >> forever. Inverted tests are waiting for correction, at least this was >> what I have/had in mind. > I tend to agree. Something feels wrong with inverting. Unless we label > the issue as a LyX enhancement (and create a trac ticket) because there > is no way in LyX to produce LyX-readable content in this case that can > be exported to several different formats. However, a) this is something waiting for correction (with low priority, because XeTeX + TeX-fonts is "exotic"). Possible changes include: * do not check ERT for unsupported characters (after all, the user is responsible for ERT, this "helpfull" feature stands in the way quite regularely). However, there is no agreement, other developers prefer checking ERT. * 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 * fix http://www.lyx.org/trac/ticket/9744 to make non-TeX fonts default for compiling with XeTeX. (This would not solve the test but make the problem even less urgent.) * Change the ERT-comment to a LyX note eventually b) "inverting this test" (i.e. adding a pattern for this test to invertedTests)¹ will * add the "WILL_FAIL" test feature * add the label "suspended" * not add the label "export" because the test matches the "catchall pattern" for _texF in suspendedTests. ¹ For me, this shows that the test system is too complicated: how should I call the action so that everyone understands? >> > or >> > >> > (2) change the inset for all beamer manuals. >> +1 > OK I will go for this. I'll wait another day or so to see if Günter > disagrees. IMV there are more important tasks but I won't stop you if you like to go this way. Actually, only the French manual has this comment in ERT, all other instances (en, de, ja) just have the "\setbeamercovered{transparent}" LaTeX macro. If you fix the beamer manual *and* Additional.lyx, consider a minimal example for /autotests/export/latex/ and a pattern to invertedTests like # Non-ASCII in ERT, fails with inputenc==ASCII (e.g. XeTeX with tex-fonts) export/export/latex/nonASCII-ERT_pdf4_texF Günter
Re: fr/beamer.lyx + pdf4: encoding issue
On Tue, Sep 20, 2016 at 05:51:36PM +0200, Kornel Benko wrote: > Am Dienstag, 20. September 2016 um 10:56:29, schrieb Scott Kostyshak >> > On Tue, Sep 20, 2016 at 06:28:48AM +, Guenter Milde wrote: > > > On 2016-09-20, Scott Kostyshak wrote: > > > The documentation is for documentation, test-use is secondary and "exotic > > > tests" don't merit changes that make the documentation more difficult to > > > read. > > > > I agree this is the right policy. If I convert those comments to a LyX > > note or comment inset, this policy is still satisfied because the inset > > is just as readable, right? So either: > > > > (1) revert the commit I pushed and invert the test > > Please no. If we never interpret ERT, then this will stay inverted forever. > Inverted tests are waiting for correction, at least this was what I have/had > in mind. I tend to agree. Something feels wrong with inverting. Unless we label the issue as a LyX enhancement (and create a trac ticket) because there is no way in LyX to produce LyX-readable content in this case that can be exported to several different formats. > > or > > > > (2) change the inset for all beamer manuals. > > +1 OK I will go for this. I'll wait another day or so to see if Günter disagrees. Scott > > Do you agree that both would be satisfactory? > > > > Scott > > Kornel signature.asc Description: PGP signature
Re: fr/beamer.lyx + pdf4: encoding issue
Am Dienstag, 20. September 2016 um 10:56:29, schrieb Scott Kostyshak> On Tue, Sep 20, 2016 at 06:28:48AM +, Guenter Milde wrote: > > On 2016-09-20, Scott Kostyshak wrote: > > > > But at the same time I don't think it makes sense to deviate from the > > > original (English) version, where ERT is used. > > > > Yes. > > > > > So I think you are right that is the way to go, unless we want to > > > change all versions of the Beamer manual to a comment or note inset, > > > and that seems like more work than should be done for this trivial > > > issue. > > > > Yes. > > > > -> invert the test (pdf4_texF) > > > > > Changed to \'{e} in stable at 9f3518bc and cherry-picked to master at > > > 1c7835c0. > > > > > Thanks for the discussion. I now have a better idea of how to deal with > > > this for similar issues when they come up. > > > > I don't think this is the right way. > > > > The documentation is for documentation, test-use is secondary and "exotic > > tests" don't merit changes that make the documentation more difficult to > > read. > > I agree this is the right policy. If I convert those comments to a LyX > note or comment inset, this policy is still satisfied because the inset > is just as readable, right? So either: > > (1) revert the commit I pushed and invert the test Please no. If we never interpret ERT, then this will stay inverted forever. Inverted tests are waiting for correction, at least this was what I have/had in mind. > or > > (2) change the inset for all beamer manuals. +1 > Do you agree that both would be satisfactory? > > Scott Kornel signature.asc Description: This is a digitally signed message part.
Re: fr/beamer.lyx + pdf4: encoding issue
On Tue, Sep 20, 2016 at 06:28:48AM +, Guenter Milde wrote: > On 2016-09-20, Scott Kostyshak wrote: > > But at the same time I don't think it makes sense to deviate from the > > original (English) version, where ERT is used. > > Yes. > > > So I think you are right that is the way to go, unless we want to > > change all versions of the Beamer manual to a comment or note inset, > > and that seems like more work than should be done for this trivial > > issue. > > Yes. > > -> invert the test (pdf4_texF) > > > Changed to \'{e} in stable at 9f3518bc and cherry-picked to master at > > 1c7835c0. > > > Thanks for the discussion. I now have a better idea of how to deal with > > this for similar issues when they come up. > > I don't think this is the right way. > > The documentation is for documentation, test-use is secondary and "exotic > tests" don't merit changes that make the documentation more difficult to read. I agree this is the right policy. If I convert those comments to a LyX note or comment inset, this policy is still satisfied because the inset is just as readable, right? So either: (1) revert the commit I pushed and invert the test or (2) change the inset for all beamer manuals. Do you agree that both would be satisfactory? Scott signature.asc Description: PGP signature
Re: fr/beamer.lyx + pdf4: encoding issue
On 2016-09-20, Scott Kostyshak wrote: > On Tue, Sep 20, 2016 at 01:24:02AM +0200, Kornel Benko wrote: >> > > * change the comment from ERT to comment >> > >> > I did not think of this possibility. I like it. >> > >> > > * invert the test (we already have several cases of inverted:ERT) >> I'd say, since it is ERT, which means 'latex', use the suggested \'{e}. However, with default output (pdflatex), the ERT compiles fine, even with all other export routes except the "exotic" XeTeX+TeX-fonts (because of the special encoding-restriction of this combination)! > I was at first against this because I thought the ERT inset was meant to > be read by French readers of the LyX beamer manual, and \'{e} looks ugly > (don't we use LyX to avoid backslashes and brackets?). Yes. > But at the same time I don't think it makes sense to deviate from the > original (English) version, where ERT is used. Yes. > So I think you are right that is the way to go, unless we want to > change all versions of the Beamer manual to a comment or note inset, > and that seems like more work than should be done for this trivial > issue. Yes. -> invert the test (pdf4_texF) > Changed to \'{e} in stable at 9f3518bc and cherry-picked to master at > 1c7835c0. > Thanks for the discussion. I now have a better idea of how to deal with > this for similar issues when they come up. I don't think this is the right way. The documentation is for documentation, test-use is secondary and "exotic tests" don't merit changes that make the documentation more difficult to read. Günter
Re: fr/beamer.lyx + pdf4: encoding issue
On Tue, Sep 20, 2016 at 01:24:02AM +0200, Kornel Benko wrote: > > > * change the comment from ERT to comment > > > > I did not think of this possibility. I like it. > > > > > * invert the test (we already have several cases of inverted:ERT) > > > > Indeed but this one seems easily avoidable (I have not checked the > > others). > > > > Scott > > I'd say, since it is ERT, which means 'latex', use the suggested \'{e}. I was at first against this because I thought the ERT inset was meant to be read by French readers of the LyX beamer manual, and \'{e} looks ugly (don't we use LyX to avoid backslashes and brackets?). But at the same time I don't think it makes sense to deviate from the original (English) version, where ERT is used. So I think you are right that is the way to go, unless we want to change all versions of the Beamer manual to a comment or note inset, and that seems like more work than should be done for this trivial issue. Changed to \'{e} in stable at 9f3518bc and cherry-picked to master at 1c7835c0. Thanks for the discussion. I now have a better idea of how to deal with this for similar issues when they come up. Scott signature.asc Description: PGP signature
Re: fr/beamer.lyx + pdf4: encoding issue
Am Montag, 19. September 2016 um 16:28:28, schrieb Scott Kostyshak> On Mon, Sep 19, 2016 at 08:20:35PM +, Guenter Milde wrote: > > On 2016-09-19, Scott Kostyshak wrote: > > > > > [-- Type: text/plain, Encoding: quoted-printable --] > > > > > If I try to compile fr/beamer.lyx to PDF (XeTeX) (using the default TeX > > > fonts) I get the following LyX error: > > > > > Could not find LaTeX command for character 'é'. It is suggested to > > > change the document encoding to utf8. > > > > This is a very outdated suggestion (and should either be removed or > > updated). > > > > In most cases, it only helps to change the encoding to utf8, if you also > > define new Unicode character bindings in the user-preamble. > > > > Furthermore, with XeTeX and 8-bit TeX fonts, the encoding is ascii - no > > other encoding works with this combination! > > > > Normally, the é is converted by lib/unicodesymbols to \'{e} and all is fine. > > > > > This error is from a 'é' in a comment (in ERT): > > > %Pour illustrer le différence entre decouvert et visible: > > > > ERT is a special case - it is up to the user to ensure proper working. > > > > > Should the encoding be change? > > > > No. > > OK thanks for the explanation. > > > Alternatives: > > > > * change the comment from ERT to comment > > I did not think of this possibility. I like it. > > > * invert the test (we already have several cases of inverted:ERT) > > Indeed but this one seems easily avoidable (I have not checked the > others). > > Scott I'd say, since it is ERT, which means 'latex', use the suggested \'{e}. Kornel signature.asc Description: This is a digitally signed message part.
Re: fr/beamer.lyx + pdf4: encoding issue
On Mon, Sep 19, 2016 at 08:20:35PM +, Guenter Milde wrote: > On 2016-09-19, Scott Kostyshak wrote: > > > [-- Type: text/plain, Encoding: quoted-printable --] > > > If I try to compile fr/beamer.lyx to PDF (XeTeX) (using the default TeX > > fonts) I get the following LyX error: > > > Could not find LaTeX command for character 'é'. It is suggested to > > change the document encoding to utf8. > > This is a very outdated suggestion (and should either be removed or updated). > > In most cases, it only helps to change the encoding to utf8, if you also > define new Unicode character bindings in the user-preamble. > > Furthermore, with XeTeX and 8-bit TeX fonts, the encoding is ascii - no > other encoding works with this combination! > > Normally, the é is converted by lib/unicodesymbols to \'{e} and all is fine. > > > This error is from a 'é' in a comment (in ERT): > > %Pour illustrer le différence entre decouvert et visible: > > ERT is a special case - it is up to the user to ensure proper working. > > > Should the encoding be change? > > No. OK thanks for the explanation. > Alternatives: > > * change the comment from ERT to comment I did not think of this possibility. I like it. > * invert the test (we already have several cases of inverted:ERT) Indeed but this one seems easily avoidable (I have not checked the others). Scott signature.asc Description: PGP signature
Re: fr/beamer.lyx + pdf4: encoding issue
On 2016-09-19, Scott Kostyshak wrote: > [-- Type: text/plain, Encoding: quoted-printable --] > If I try to compile fr/beamer.lyx to PDF (XeTeX) (using the default TeX > fonts) I get the following LyX error: > Could not find LaTeX command for character 'é'. It is suggested to > change the document encoding to utf8. This is a very outdated suggestion (and should either be removed or updated). In most cases, it only helps to change the encoding to utf8, if you also define new Unicode character bindings in the user-preamble. Furthermore, with XeTeX and 8-bit TeX fonts, the encoding is ascii - no other encoding works with this combination! Normally, the é is converted by lib/unicodesymbols to \'{e} and all is fine. > This error is from a 'é' in a comment (in ERT): > %Pour illustrer le différence entre decouvert et visible: ERT is a special case - it is up to the user to ensure proper working. > Should the encoding be change? No. Alternatives: * change the comment from ERT to comment * invert the test (we already have several cases of inverted:ERT) Günter
fr/beamer.lyx + pdf4: encoding issue
If I try to compile fr/beamer.lyx to PDF (XeTeX) (using the default TeX fonts) I get the following LyX error: Could not find LaTeX command for character 'é'. It is suggested to change the document encoding to utf8. This error is from a 'é' in a comment (in ERT): %Pour illustrer le différence entre decouvert et visible: Should the encoding be change? Scott signature.asc Description: PGP signature