Re: Dependencies to build LyX (from Git) on clean Ubuntu 16.04 using Qt5?

[Scott Kostyshak]

On Tue, Jan 17, 2017 at 11:54:02PM +0100, Christian Ridderström wrote:
> Hi,
> 
> Does anyone have a list of the build dependencies that need to be installed
> in order to build the latest LyX on a clean Ubuntu 16.04 using Qt5?  I.e.,
> I'm looking for the
> 
>sudo apt-get install build-essential ... XXX
> 
> and the other steps you need to do in order to be able build LyX with Qt5.

I think you can just do

  sudo apt-get build-dep lyx

Does that work?

> I've been searching the web for some build instructions and the best I
> found so far was this script:
>https://github.com/scottkosty/lyx-tester/blob/master/CreateQt5
> 
> I'm hoping not all of the dependencies in that script are needed, and that
> Qt5 can be installed rather than built.

Yes that script is for compiling Qt 5, which I don't think you want. 

Scott


signature.asc
Description: PGP signature

Convertor lyx2.1 -> lyx2.2 does not understand TikZ in math macros

[חיים רוזנר]

Hi,
I upgraded lyx 2.1 to lyx 2.2 (Win 10). I have a file with lots of tikz
environments and some math macros. The convertor took the -- line command
of tikz in the math macro and converted it to \twohyphens. This conversion
made me errors.

Attached are a minimal example from LyX 2.1 and its automatic conversion to
LyX 2.2.

Thanks for all your effort.

Haim


TwoHyphens21.lyx
Description: application/lyx


TwoHyphens22.lyx
Description: application/lyx

Dependencies to build LyX (from Git) on clean Ubuntu 16.04 using Qt5?

[Christian Ridderström]

Hi,

Does anyone have a list of the build dependencies that need to be installed
in order to build the latest LyX on a clean Ubuntu 16.04 using Qt5?  I.e.,
I'm looking for the

   sudo apt-get install build-essential ... XXX

and the other steps you need to do in order to be able build LyX with Qt5.

I've been searching the web for some build instructions and the best I
found so far was this script:
   https://github.com/scottkosty/lyx-tester/blob/master/CreateQt5

I'm hoping not all of the dependencies in that script are needed, and that
Qt5 can be installed rather than built.

Regards,
Christian

-- 
Christian Ridderström, +46-70 687 39 44

Re: EmDash Problems

[Guenter Milde]

On 2017-01-17, Enrico Forestieri wrote:
> On Tue, Jan 17, 2017 at 06:05:57PM +0100, Enrico Forestieri wrote:
>> On Tue, Jan 17, 2017 at 09:41:03AM -0500, Richard Heck wrote:
>> > On 01/17/2017 02:55 AM, Jürgen Spitzmüller wrote:
>> > > 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.
>> > 
>> > I agree with Jürgen, mostly because this is the old and expected
>> > behavior.

>> That's also my opinion.

> Meaning that we should output "---".

This means full backwards compatibility and "good looking" 8-bit LaTeX
sources at the expense of reduced configurability.

I can live with this, if we use output "---" via lib/unicodesymbols

  0x2014 "­--" "emdash" "notermination=text,force=armscii8" # EM 
DASH

with the "emdash" feature re-binding

   \DeclareUnicodeCharacter{2014}{---}

if inputenc == "utf8" || inputenc == "utf8x".

+1 consistent handling of en- and em-dashes independent of input method.

+1 power-users can configure the behaviour (if using utf8) in the user
   preamble.


For non-TeX fonts, the literal Unicode character wraps like the
"---"-ligature, so no change is required.


Günter

Re: EmDash Problems

[Jürgen Spitzmüller]

Am Dienstag, den 17.01.2017, 18:40 + schrieb Guenter Milde:
> c) use "---" in lib/unicodesymbols and 
>    procede as in a) for inputencoding utf8

+1

Jürgen

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

Re: EmDash Problems

[Enrico Forestieri]

On Tue, Jan 17, 2017 at 06:05:57PM +0100, Enrico Forestieri wrote:

> On Tue, Jan 17, 2017 at 09:41:03AM -0500, Richard Heck wrote:
> 
> > On 01/17/2017 02:55 AM, Jürgen Spitzmüller wrote:
> > > 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.
> > 
> > I agree with Jürgen, mostly because this is the old and expected
> > behavior.
> 
> That's also my opinion.

Meaning that we should output "---".

-- 
Enrico

Re: EmDash Problems

[Guenter Milde]

On 2017-01-17, Richard Heck wrote:
> On 01/17/2017 02:55 AM, Jürgen Spitzmüller wrote:
>> 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.

> I agree with Jürgen, mostly because this is the old and expected
> behavior. On the other hand, I can see why \textemdash is useful for
> some people. I hate to suggest a preference, or document setting, but?

Thank you for the fast responses.
We have a clear favourite, that is backwards compatible and should work as
expected for English and German (u.a.) use cases.


Possible implementations:

I suggest adding an "\allowbreak" after the \textemdash macro.

+1 keep configurability
+1 keep distinction of "real" EM DASH and --- (e.g. input via copy-past or
   with temporary spaces).
+1 almost backwards compatible
-1 hyphenation of the preceding word allowed wiht 8-bit fonts but not with
   Unicode fonts.

a) use "\textemdash\allowbreak" in lib/unicodesymbols and
   i)  "force=utf8"
   ii) an "emdash" feature that rebinds the EM DASH character (x2014)
 to "\textemdash\allowbreak" if the inputencoding is utf8.
 
b) redefine "\textemdash":

\let\origtextemdash\textemdash
\renewcommand{\textemdash}{\origtextemdash\allowbreak}

My preference is a)ii).   

Alternatively,

c) use "---" in lib/unicodesymbols and 
   procede as in a) for inputencoding utf8

Günter   

Re: EmDash Problems

[Enrico Forestieri]

On Tue, Jan 17, 2017 at 09:41:03AM -0500, Richard Heck wrote:

> On 01/17/2017 02:55 AM, Jürgen Spitzmüller wrote:
> > 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.
> 
> I agree with Jürgen, mostly because this is the old and expected
> behavior.

That's also my opinion.

-- 
Enrico

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

[Enrico Forestieri]

On Tue, Jan 17, 2017 at 02:51:23PM +0100, Jean-Marc Lasgouttes wrote:

> Le 17/01/2017 à 12:19, Enrico Forestieri a écrit :
> > This seems to be a Qt issue. QTextLine::naturalTextWidth() should report
> > the width of the line occupied by text. If a zero-width character is
> > present, it is correctly accounted for, except when it is the only
> > character in the line. That is to say that "/=" has the same width
> > as "=" if "/" has zero-width, but "/" by alone is reported to have
> > its real width. The metrics in math are computed char by char, so that
> > explains the behavior. The solution is to compute the width by using
> > the old method when when the font is one of ours. See attached patch.
> 
> Hello Enroci,

Hi JMcra :)

> Thanks for the analysis. You patch is a solution, but wouldn't it more in
> line with what you propose to use width(s[0]) when there is only one
> character?

Yes, but I would propose to do that in addition. Nonetheless, my feeling
is that this issue is caused by the assumptions of Qt about a given font.
For example, it refuses to draw the glyph of a character whose codepoint
corresponds to a soft hyphen, irrespective of the actual font, and other
such amenities.

> JMarc
> 

-- 
Enrico

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

[Jean-Marc Lasgouttes]

Le 17/01/2017 à 15:38, Richard Heck a écrit :

Thanks for your work on this, both of you. When you decide on a solution,
please feel free to commit to stable.


OK, thanks. While we are at it, is there some reason why I cannot get an 
answer there ?

http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg198350.html

JMarc

Re: EmDash Problems

[Richard Heck]

On 01/17/2017 02:55 AM, Jürgen Spitzmüller wrote:
> 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.

I agree with Jürgen, mostly because this is the old and expected
behavior. On the other hand, I can see why \textemdash is useful for
some people. I hate to suggest a preference, or document setting, but?

Richard

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

[Richard Heck]

On 01/17/2017 08:51 AM, Jean-Marc Lasgouttes wrote:
> Le 17/01/2017 à 12:19, Enrico Forestieri a écrit :
>> This seems to be a Qt issue. QTextLine::naturalTextWidth() should report
>> the width of the line occupied by text. If a zero-width character is
>> present, it is correctly accounted for, except when it is the only
>> character in the line. That is to say that "/=" has the same width
>> as "=" if "/" has zero-width, but "/" by alone is reported to have
>> its real width. The metrics in math are computed char by char, so that
>> explains the behavior. The solution is to compute the width by using
>> the old method when when the font is one of ours. See attached patch.
>
> Hello Enroci,
>
> Thanks for the analysis. You patch is a solution, but wouldn't it more
> in line with what you propose to use width(s[0]) when there is only
> one character?

Thanks for your work on this, both of you. When you decide on a solution,
please feel free to commit to stable.

Richard

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

[Jean-Marc Lasgouttes]

Le 17/01/2017 à 12:19, Enrico Forestieri a écrit :

This seems to be a Qt issue. QTextLine::naturalTextWidth() should report
the width of the line occupied by text. If a zero-width character is
present, it is correctly accounted for, except when it is the only
character in the line. That is to say that "/=" has the same width
as "=" if "/" has zero-width, but "/" by alone is reported to have
its real width. The metrics in math are computed char by char, so that
explains the behavior. The solution is to compute the width by using
the old method when when the font is one of ours. See attached patch.


Hello Enroci,

Thanks for the analysis. You patch is a solution, but wouldn't it more 
in line with what you propose to use width(s[0]) when there is only one 
character?


JMarc

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

[Enrico Forestieri]

On Mon, Jan 16, 2017 at 03:36:07PM -0500, Richard Heck wrote:

> 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

This seems to be a Qt issue. QTextLine::naturalTextWidth() should report
the width of the line occupied by text. If a zero-width character is
present, it is correctly accounted for, except when it is the only
character in the line. That is to say that "/=" has the same width
as "=" if "/" has zero-width, but "/" by alone is reported to have
its real width. The metrics in math are computed char by char, so that
explains the behavior. The solution is to compute the width by using
the old method when when the font is one of ours. See attached patch.

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

I did not investigate why that is not a problem in master.

-- 
Enrico
diff --git a/src/frontends/qt4/GuiFontMetrics.cpp 
b/src/frontends/qt4/GuiFontMetrics.cpp
index f17ac37..b6761c9 100644
--- a/src/frontends/qt4/GuiFontMetrics.cpp
+++ b/src/frontends/qt4/GuiFontMetrics.cpp
@@ -181,13 +181,18 @@ int GuiFontMetrics::width(docstring const & s) const
// For some reason QMetrics::width returns a wrong value with Qt5
// int w = metrics_.width(toqstr(s));
 #endif
-   QTextLayout tl;
-   tl.setText(toqstr(s));
-   tl.setFont(font_);
-   tl.beginLayout();
-   QTextLine line = tl.createLine();
-   tl.endLayout();
-   int w = int(line.naturalTextWidth());
+   int w;
+   if (font_.styleName() == "LyX") {
+   w = metrics_.width(toqstr(s));
+   } else {
+   QTextLayout tl;
+   tl.setText(toqstr(s));
+   tl.setFont(font_);
+   tl.beginLayout();
+   QTextLine line = tl.createLine();
+   tl.endLayout();
+   w = int(line.naturalTextWidth());
+   }
 #ifdef CACHE_METRICS_WIDTH
strwidth_cache_.insert(s, new int(w), s.size() * sizeof(char_type));
 #endif

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

[Jean-Marc Lasgouttes]

Le 16/01/2017 à 22:09, Jean-Marc Lasgouttes a écrit :

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?


I can confirm that using QFontMetrics::width instead of the width 
returned by QTextLayout does the trick, but that makes me a bit nervous :)


What happens basically is that \not has 0 width, but QTextLayout does 
not seem to respect that. Several workarounds exist

- have a different FontMetrics::width for maths
- in mathed_string_dim, use width(char_type) repeatedly instead of 
width(docstring)

- or do a shortcut for cases where the string only has one character.

All these things would work, but they are fragile as long as we do not know:
- why they work
- why is master immune to the problem

Guillaume, could it just be that the definition of \not needs to be 
adjusted like it has been in master?


JMarc