Re: EmDash Problems
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
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.
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.
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.
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.
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.
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.
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.
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
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
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
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.
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
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
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