Re: fr/beamer.lyx + pdf4: encoding issue

2016-09-22 Thread Scott Kostyshak
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

2016-09-21 Thread Scott Kostyshak
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

2016-09-21 Thread Guenter Milde
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

2016-09-21 Thread Scott Kostyshak
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

2016-09-21 Thread Guenter Milde
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

2016-09-20 Thread Scott Kostyshak
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

2016-09-20 Thread Kornel Benko
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

2016-09-20 Thread 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

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

2016-09-20 Thread Guenter Milde
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

2016-09-19 Thread Scott Kostyshak
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

2016-09-19 Thread Kornel Benko
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

2016-09-19 Thread 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


signature.asc
Description: PGP signature


Re: fr/beamer.lyx + pdf4: encoding issue

2016-09-19 Thread Guenter Milde
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