Re: EmDash Problems

[Jürgen Spitzmüller]

Am Montag, den 16.01.2017, 22:17 + schrieb Guenter Milde:
> Now we have 3 specs:
> 
> 1. Unicode: Break Opportunity Before and After
> 
> 2. --- ligature: Break opportunity after, no hyphenation of word
> before
>    (also with literal EM DASH and \textemdash macro with non-TeX
> fonts).
>    
> 3. \textemdash macro (and literal EM DASH with inputenc-utf8) and TeX
> fonts:
>    no break opportunity. Hyphenation of word before allowed.
> 
> What should be the LyX behaviour?

2.

Jürgen



signature.asc
Description: This is a digitally signed message part

Re: EmDash Problems

[Guenter Milde]

On 2017-01-14, Guenter Milde wrote:
> On 2017-01-14, Jürgen Spitzmüller wrote:
>> Am Freitag, den 13.01.2017, 18:56 -0500 schrieb Richard Heck:

>>> The attached files illustrate a problem that I raised, and was told
>>> not to worry about, when "---" was exchanged for \textemdash. The
>>> problem is that the latter does not break the way the former does.

Note, that line breaking is not changed with non-TeX fonts, though.

Now we have 3 specs:

1. Unicode: Break Opportunity Before and After

2. --- ligature: Break opportunity after, no hyphenation of word before
   (also with literal EM DASH and \textemdash macro with non-TeX fonts).
   
3. \textemdash macro (and literal EM DASH with inputenc-utf8) and TeX fonts:
   no break opportunity. Hyphenation of word before allowed.

What should be the LyX behaviour?

See also the example file for http://www.lyx.org/trac/ticket/10543

Günter

Re: [CONFIRMED] Display Problem in Stable with \notin, etc.

[Jean-Marc Lasgouttes]

Le 16/01/2017 à 21:29, Richard Heck a écrit :

Bisect blames:

24648404b3c85015584b1ca127e257cbecf3342d is the first bad commit
commit 24648404b3c85015584b1ca127e257cbecf3342d
Author: Jean-Marc Lasgouttes 
Date:   Sun Oct 23 20:52:01 2016 +0200

Work around issues with Qt5 and Arabic text


Thanks Richard, I'll have a look. Guillaume, any intuition why master is 
different from stable in this respect?


JMarc

[CONFIRMED] Display Problem in Stable with \notin, etc.

[Richard Heck]

Resending as a new thread so it is more visible

On 01/16/2017 02:04 PM, Scott Kostyshak wrote:
> On Mon, Jan 16, 2017 at 01:13:44PM -0500, Richard Heck wrote:
>> I am seeing display problems in stable with \notin and \noteq. The
>> latter, for example, shows (In LyX) as "/=", rather than as ≠. Similarly
>> for \notin. See the attachments.
> Just a few data points:
>
> I can reproduce the problem on current 2.2.x branch.
> I cannot reproduce on master or on 2.2.1.

Bisect blames:

24648404b3c85015584b1ca127e257cbecf3342d is the first bad commit
commit 24648404b3c85015584b1ca127e257cbecf3342d
Author: Jean-Marc Lasgouttes 
Date:   Sun Oct 23 20:52:01 2016 +0200

Work around issues with Qt5 and Arabic text
   This fixes two particular problems
   * with Qt5, it seems that QFontMetrics::width does not return the
  correct value for some Arabic text; this patch uses QTextLayout
  instead to compute a string width
   * Likewise, the undocumented layout flags TextForceRightToLeft and
  TextForceLeftToRight do not work with Arabic text; this patch uses
  unicode override characters instead.
   It might be that the two issues are related. In any case, they do not
happen with latin text where right-to-left direction is enforced. And
they do not happen with Qt4.
   Additionally, remove some dead code in GuiFontMetrics::pos2x().
   Fixes bug #10436.
   (cherry picked from commit e832d2e90f300afb1b1255a486e56d059b2dfab7)

Strange, though, that this does not cause the same problem in master.
Probably
that is due to other changes JMarc has made there.

Richard

[CONFIRMED] Display Problem in Stable with \notin, etc.

[Richard Heck]

On 01/16/2017 02:04 PM, Scott Kostyshak wrote:
> On Mon, Jan 16, 2017 at 01:13:44PM -0500, Richard Heck wrote:
>> I am seeing display problems in stable with \notin and \noteq. The
>> latter, for example, shows (In LyX) as "/=", rather than as ≠. Similarly
>> for \notin. See the attachments.
> Just a few data points:
>
> I can reproduce the problem on current 2.2.x branch.
> I cannot reproduce on master or on 2.2.1.

Bisect blames:

24648404b3c85015584b1ca127e257cbecf3342d is the first bad commit
commit 24648404b3c85015584b1ca127e257cbecf3342d
Author: Jean-Marc Lasgouttes 
Date:   Sun Oct 23 20:52:01 2016 +0200

Work around issues with Qt5 and Arabic text
   
This fixes two particular problems
   
* with Qt5, it seems that QFontMetrics::width does not return the
  correct value for some Arabic text; this patch uses QTextLayout
  instead to compute a string width
   
* Likewise, the undocumented layout flags TextForceRightToLeft and
  TextForceLeftToRight do not work with Arabic text; this patch uses
  unicode override characters instead.
   
It might be that the two issues are related. In any case, they do not
happen with latin text where right-to-left direction is enforced. And
they do not happen with Qt4.
   
Additionally, remove some dead code in GuiFontMetrics::pos2x().
   
Fixes bug #10436.
   
(cherry picked from commit e832d2e90f300afb1b1255a486e56d059b2dfab7)

Strange, though, that this does not cause the same problem in master.
Probably
that is due to other changes JMarc has made there.

Richard

Re: Display Problem in Stable with \notin, etc.

[Richard Heck]

On 01/16/2017 02:04 PM, Scott Kostyshak wrote:
> On Mon, Jan 16, 2017 at 01:13:44PM -0500, Richard Heck wrote:
>> I am seeing display problems in stable with \notin and \noteq. The
>> latter, for example, shows (In LyX) as "/=", rather than as ≠. Similarly
>> for \notin. See the attachments.
> Just a few data points:
>
> I can reproduce the problem on current 2.2.x branch.
> I cannot reproduce on master or on 2.2.1.

I do not see it in 2.2.2 either.

rh

Re: Display Problem in Stable with \notin, etc.

[Scott Kostyshak]

On Mon, Jan 16, 2017 at 01:13:44PM -0500, Richard Heck wrote:
> I am seeing display problems in stable with \notin and \noteq. The
> latter, for example, shows (In LyX) as "/=", rather than as ≠. Similarly
> for \notin. See the attachments.

Just a few data points:

I can reproduce the problem on current 2.2.x branch.
I cannot reproduce on master or on 2.2.1.

Scott


signature.asc
Description: PGP signature

Display Problem in Stable with \notin, etc.

[Richard Heck]

I am seeing display problems in stable with \notin and \noteq. The
latter, for example, shows (In LyX) as "/=", rather than as ≠. Similarly
for \notin. See the attachments.

Richard




display.lyx
Description: application/lyx

Re: [LyX/master] Add FontEncoding to language descriptions.

[Scott Kostyshak]

On Mon, Jan 16, 2017 at 11:29:02AM +, Guenter Milde wrote:
> On 2017-01-15, Scott Kostyshak wrote:
> > On Sat, Jan 14, 2017 at 10:45:09PM +0100, Günter Milde wrote:
> >> commit 809b8b62a43f7dc18fef9b28759007456c586931
> >> Author: Günter Milde 
> >> Date:   Sat Jan 14 22:43:37 2017 +0100
> 
> >> Add FontEncoding to language descriptions.
> 
> >> Add FontEncoding tag for all languages with 8-bit hyphenation patterns
> >> requiring a specific font encoding.
> ...
> 
> > I believe this commit caused the following tests to fail:
> 
> >   export/doc/attic/pl_Additional_pdf2 (Failed)
> >   export/doc/attic/pl_Additional_pdf5_texF (Failed)
> 
> > Can you take a look and see if these failures are expected (e.g. we were
> > just lucky before to compile successfully)?
> 
> Thank your for the report. Actually, we were lucky these "attic" tests
> failed, because the "real" Polish documentation did not fail but produce
> wrong output (no emphasized text)!
> 
> The reason is that the font tags lead to forced use of the font encoding
> given for the document language. 
> 
> This is the right thing for some languages (that would not work at all
> otherwise) but not for Polish, where improved hyphenation is traded
> against less font choice. The new logic of the "auto" fontenc setting
> shall balance this tradeoff. Until "auto" fontenc is implemented, I'll
> revert the patch.

Thanks for taking care of that so quickly.

Scott


signature.asc
Description: PGP signature

Re: biblatex (features/biblatex2) branch and master/child

[Jürgen Spitzmüller]

2017-01-16 15:57 GMT+01:00 PhilipPirrip :

> Oh, I see.  This should be in Tools>Preferences I guess since it's not
> document-specific (is it being saved with the document?)
> LyX could even remember the last value chosen for the bibtex inset.
>

No, it's document specific, since it depends on the selected "cite engine"
(basic and natbib and jurabib have different default styles; the fact that
they cannot deal with the other's default style was actually the reason to
introduce this feature).

And yes, it is saved as a buffer param.

Jürgen

Re: biblatex (features/biblatex2) branch and master/child

[PhilipPirrip]

On 01/15/2017 09:14 AM, Jürgen Spitzmüller wrote:

This is an old feature. If you enter "default" in the bibliography
style widget (in the BibTeX dialog), then this is replaced with this
"Default bibtex style".

I did not change this behavior, although I think the UI is sub-optimal.



Oh, I see.  This should be in Tools>Preferences I guess since it's not 
document-specific (is it being saved with the document?)

LyX could even remember the last value chosen for the bibtex inset.

Re: [LyX/master] configure.py: Make 'notepad' last in text editor list

[Paul A. Rubin]

On 01/16/2017 04:28 AM, Pavel Sanda wrote:


Guenter put X-Apps into configure script, so my understanding is that
MINT should be covered now.

Pavel

Great! Thanks to all.

Paul

Re: [LyX/master] Add FontEncoding to language descriptions.

[Guenter Milde]

On 2017-01-15, Scott Kostyshak wrote:
> On Sat, Jan 14, 2017 at 10:45:09PM +0100, Günter Milde wrote:
>> commit 809b8b62a43f7dc18fef9b28759007456c586931
>> Author: Günter Milde 
>> Date:   Sat Jan 14 22:43:37 2017 +0100

>> Add FontEncoding to language descriptions.

>> Add FontEncoding tag for all languages with 8-bit hyphenation patterns
>> requiring a specific font encoding.
...

> I believe this commit caused the following tests to fail:

>   export/doc/attic/pl_Additional_pdf2 (Failed)
>   export/doc/attic/pl_Additional_pdf5_texF (Failed)

> Can you take a look and see if these failures are expected (e.g. we were
> just lucky before to compile successfully)?

Thank your for the report. Actually, we were lucky these "attic" tests
failed, because the "real" Polish documentation did not fail but produce
wrong output (no emphasized text)!

The reason is that the font tags lead to forced use of the font encoding
given for the document language. 

This is the right thing for some languages (that would not work at all
otherwise) but not for Polish, where improved hyphenation is traded
against less font choice. The new logic of the "auto" fontenc setting
shall balance this tradeoff. Until "auto" fontenc is implemented, I'll
revert the patch.

Günter

Re: Coverity Loop Issue

[Tommaso Cucinotta]

On 07/01/2017 18:16, Tommaso Cucinotta wrote:

Let me do some test on master and double-check whether there's any regression 
when ignore-format
is off.


just a heads-up: couldn't run the autotests yet, there's some issue and key 
presses from the scripts
can't reach the LyXwindow that remains there forever, one issue was the line 
reporting the task
State in /proc/*/status, which seemingly moved from 2nd to 3rd, so now I'm 
grepping instead of
relying on a specific line no., but couldn't get to the end of troubleshooting 
yet...
(Linux 4.8.0-26 on Ubuntu 16.10).

T.

Re: [LyX/master] configure.py: Make 'notepad' last in text editor list

[Pavel Sanda]

Paul A. Rubin wrote:
> As far as standing pat, I can testify that this represents a PITA for Mint 
> users once they upgrade to 18.1 (or maybe 18.0), because the X-Apps are not 
> recognized and, depending on what else they have installed, they can end up 
> with no viewers or gimp and notepad (WINE) as viewers. I have no idea 
> whether any other distributions are going to move to X-Apps, so it may only 
> be Mint users that are affected.

Guenter put X-Apps into configure script, so my understanding is that 
MINT should be covered now.

Pavel