test of math previews (was: [LyX/master] Really fix bug #9354)

[Guillaume M-M]

Le 31/05/2015 16:12, Enrico Forestieri a écrit :

On Sun, May 31, 2015 at 01:24:05PM +0200, Kornel Benko wrote:


Am Sonntag, 31. Mai 2015 um 00:53:41, schrieb Enrico Forestieri for...@lyx.org

commit ad0d0f6d69a7acd6e99f7858f08b427a28d8f8cc
Author: Enrico Forestieri for...@lyx.org
Date:   Sun May 31 00:52:49 2015 +0200

 Really fix bug #9354



This is still not working in branch for redefined macros.
(Works in master as implemented by Jürgen)

Try the attached. (The second definition of \qG is different, but the preview
is not changed)


Thanks, should be fixed now.
This has nothing to do with bug 9354, though.



In fact it does not work entirely in master. There is a regression 
(after bc47054b I believe) because compilation can now fail due to 
\renewcommandx being used without the command being defined prior to 
that (try the attached lyx-bug-renewcommandx.lyx). (Stable is fine in 
this regard after your commit 9285f338, it seems.) 
http://www.lyx.org/trac/ticket/6369


One quick solution would be to prepend all \renewcommandx\a{b} with 
\providecommand\a{}.



Here are other conclusions from my test of stable and master this week-end:

1) b3d2ffc0 introduces a regression in stable and master wrt 2.1.3. See 
the attached lyx-bug-font2.lyx. This is because legacy_lyxpreview2ppm.py 
now includes the font lmodern (L236). I do not understand this addition: 
font setting is already done in the preamble. Removing the line fixes 
the issue.


2) In master, preview incorrectly calls latex instead of pdflatex if the 
default output format is set to default. More details in the attached 
lyx-bug-microtype.lyx. (It causes the instant preview to fail, while the 
default (pdflatex) compilation with Ctrl+R succeeds.)
Stable also fails because it seems to call latex instead of pdflatex all 
the time, but it does not appear to be a regression wrt 2.1.3.


3) As reported in #6369, InstantPreview multiplies math macros 
definitions. Although the particular compilation issue has been solved, 
the duplication of macro definitions is not fixed. This has performance 
consequences. In stable and master, opening a moderately-sized math 
article (10-20 pages) with instant preview activated results in 75s of 
full CPU usage (and more when latex is called incorrectly instead of 
pdflatex), 55s during which LyX is unresponsive (and just generates the 
tex file). The instant preview tex file is 55 lines long and is 16MB 
big, mainly comprised of macro definitions (maybe there is another 
performance bottleneck, but this is probably one). So instant preview is 
still unusable for me (at least until the instant preview inset supports 
math macros---BTW the patch 
http://www.lyx.org/trac/attachment/ticket/9354/9354.diff works well 
for me).


4) Using Ctrl+Mousewheel to zoom sometimes results in a preview of the 
wrong size. LyX recreates the previews when zooming, and sometimes we 
end up with an intermediary size of preview inconsistent with the size 
of the text (race condition?).
(BTW why redoing preview from scratch when the pdf is already generated? 
Why not keeping the each preview as a pdfs, displayed on the fly by LyX 
using Cairo, when actually needed? This sounds vastly more efficient.)


3+4) Zooming with Ctrl+mousewheel is impossible with instant preview 
activated in a reasonably-sized document as a combination of 3) and 4). 
LyX freezes as soon as we touch the mouse wheel. (Both master and 
stable. Regression from 2.1.3. Same suggested solutions as 3 and 4.)


5) I find that the preferences dialog is counter-intuitive, with the 
distinction between Save, Apply and Close. I don't see the point of 
applying without saving (e.g. I think I have disabled instant preview, 
but then I find that it is reactivated the next time I run LyX). To add 
to the wish list of UI improvements...



Thank you, have a nice day.



lyx-bug-renewcommandx.lyx
Description: application/lyx


lyx-bug-font2.lyx
Description: application/lyx


lyx-bug-microtype.lyx
Description: application/lyx

Re: #7896: LyX templates folder is empty

[Stephan Witt]

Am 31.05.2015 um 09:47 schrieb LyX Ticket Tracker t...@lyx.org:

 #7896: LyX templates folder is empty
 -+
 Reporter:  vicvandijk   |   Owner:  spitz
 Type:  enhancement  |  Status:  new
 Priority:  normal   |   Milestone:  2.3.0
 Component:  dialogs  | Version:  2.0.1
 Severity:  normal   |  Resolution:
 Keywords:  os=macosx|
 -+
 Changes (by spitz):
 
 * milestone:  2.1.4 = 2.3.0
 
 
 Comment:
 
 OK. Retargeting.
 
 -- 
 Ticket URL: http://www.lyx.org/trac/ticket/7896#comment:7
 The LyX Project http://www.lyx.org/
 LyX -- The Document Processor

I don't know if that would be acceptable: one possible solution
is to create a symlink in users template directory and let it
point to the correct location inside the LyX package. I've made
an implementation of this idea and tested it successfully.

It works as long as there is only one LyX package per minor version,
if one uses e.g. 2.1.3 and 2.1.4 in parallel the symlink points to
the package of the last started LyX.

In practice I think it works flawlessly.

Attached is a patch to implement the idea.
Is this an acceptable workaround?

Stephan



0001-ticket-7896.patch
Description: Binary data

Re: #7896: LyX templates folder is empty

[Scott Kostyshak]

On Mon, Jun 1, 2015 at 4:09 AM, Jean-Marc Lasgouttes lasgout...@lyx.org wrote:
 Le 01/06/2015 09:10, Stephan Witt a écrit :

 I don't know if that would be acceptable: one possible solution
 is to create a symlink in users template directory and let it
 point to the correct location inside the LyX package. I've made
 an implementation of this idea and tested it successfully.

 It works as long as there is only one LyX package per minor version,
 if one uses e.g. 2.1.3 and 2.1.4 in parallel the symlink points to
 the package of the last started LyX.


 I think that the idea is fine.

Should the caveat be documented in INSTALL.MacOSX?

Scott

Re: #7896: LyX templates folder is empty

[Jean-Marc Lasgouttes]

Le 01/06/2015 09:10, Stephan Witt a écrit :

I don't know if that would be acceptable: one possible solution
is to create a symlink in users template directory and let it
point to the correct location inside the LyX package. I've made
an implementation of this idea and tested it successfully.

It works as long as there is only one LyX package per minor version,
if one uses e.g. 2.1.3 and 2.1.4 in parallel the symlink points to
the package of the last started LyX.


I think that the idea is fine.

JMarc

Re: 2.2

[Stephan Witt]

Am 01.06.2015 um 09:41 schrieb Jürgen Spitzmüller sp...@lyx.org:

 2015-05-31 19:33 GMT+02:00 Stephan Witt st.w...@gmx.net:
 $ ls -l dictionaries/thes/th_en_*.dat
 -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:42 
 dictionaries/thes/th_en_AU_v2.dat
 -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:41 
 dictionaries/thes/th_en_BS_v2.dat
 -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:42 
 dictionaries/thes/th_en_BZ_v2.dat
 -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:42 
 dictionaries/thes/th_en_CA_v2.dat
 -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:41 
 dictionaries/thes/th_en_GB_v2.dat
 -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:41 
 dictionaries/thes/th_en_GH_v2.dat
 -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:42 
 dictionaries/thes/th_en_IE_v2.dat
 -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:42 
 dictionaries/thes/th_en_IN_v2.dat
 -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:42 
 dictionaries/thes/th_en_JM_v2.dat
 -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:41 
 dictionaries/thes/th_en_MW_v2.dat
 -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:42 
 dictionaries/thes/th_en_NA_v2.dat
 -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:42 
 dictionaries/thes/th_en_NZ_v2.dat
 -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:41 
 dictionaries/thes/th_en_PH_v2.dat
 -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:41 
 dictionaries/thes/th_en_TT_v2.dat
 -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:41 
 dictionaries/thes/th_en_US_v2.dat
 -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:42 
 dictionaries/thes/th_en_ZA_v2.dat
 -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:42 
 dictionaries/thes/th_en_ZW_v2.dat
 $ for d in dictionaries/thes/th_en_*.dat ; do diff -u 
 dictionaries/thes/th_en_AU_v2.dat $d ; done | wc
0   0   0
 
 This costs 17 times 18 MByte space and looks wrong. Are you sure you put the 
 right stuff in?
 
 Yes, they are identical. However, you only need to ship a small subset of 
 those. We only support en_AU, en_CA, en_GB, en_US and en_NZ.

But this result in an overhead of appr. 80 MByte :(
Isn't it possible to create some alias mechanism?

Stephan

Re: 2.2

[Jürgen Spitzmüller]

2015-05-31 19:33 GMT+02:00 Stephan Witt st.w...@gmx.net:

 $ ls -l dictionaries/thes/th_en_*.dat
 -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:42
 dictionaries/thes/th_en_AU_v2.dat
 -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:41
 dictionaries/thes/th_en_BS_v2.dat
 -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:42
 dictionaries/thes/th_en_BZ_v2.dat
 -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:42
 dictionaries/thes/th_en_CA_v2.dat
 -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:41
 dictionaries/thes/th_en_GB_v2.dat
 -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:41
 dictionaries/thes/th_en_GH_v2.dat
 -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:42
 dictionaries/thes/th_en_IE_v2.dat
 -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:42
 dictionaries/thes/th_en_IN_v2.dat
 -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:42
 dictionaries/thes/th_en_JM_v2.dat
 -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:41
 dictionaries/thes/th_en_MW_v2.dat
 -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:42
 dictionaries/thes/th_en_NA_v2.dat
 -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:42
 dictionaries/thes/th_en_NZ_v2.dat
 -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:41
 dictionaries/thes/th_en_PH_v2.dat
 -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:41
 dictionaries/thes/th_en_TT_v2.dat
 -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:41
 dictionaries/thes/th_en_US_v2.dat
 -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:42
 dictionaries/thes/th_en_ZA_v2.dat
 -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:42
 dictionaries/thes/th_en_ZW_v2.dat
 $ for d in dictionaries/thes/th_en_*.dat ; do diff -u
 dictionaries/thes/th_en_AU_v2.dat $d ; done | wc
0   0   0

 This costs 17 times 18 MByte space and looks wrong. Are you sure you put
 the right stuff in?


Yes, they are identical. However, you only need to ship a small subset of
those. We only support en_AU, en_CA, en_GB, en_US and en_NZ.

Jürgen

Re: 2.2

[Jean-Marc Lasgouttes]

Le 01/06/2015 10:57, Jürgen Spitzmüller a écrit :

2015-06-01 10:45 GMT+02:00 Stephan Witt st.w...@gmx.net
mailto:st.w...@gmx.net:

But this result in an overhead of appr. 80 MByte :(
Isn't it possible to create some alias mechanism?


On Linux and Mac, you can certainly also use symlinks. Don't know about
Windows.

(In fact, these files _are_ symlinked to one th_en_US in the package I
used as source)


And what about shipping one and naming it th_en_v2.dat? I am sure we can 
work out a naming scheme that does what we want? Or name the thesaurus 
to use in the language file.


JMarc

Re: 2.2

[Jürgen Spitzmüller]

2015-06-01 11:04 GMT+02:00 Jean-Marc Lasgouttes lasgout...@lyx.org:

 And what about shipping one and naming it th_en_v2.dat? I am sure we can
 work out a naming scheme that does what we want?


Yes, that would be an option.

Jürgen



 JMarc

Re: 2.2

[Jürgen Spitzmüller]

2015-06-01 10:45 GMT+02:00 Stephan Witt st.w...@gmx.net:

 But this result in an overhead of appr. 80 MByte :(
 Isn't it possible to create some alias mechanism?


On Linux and Mac, you can certainly also use symlinks. Don't know about
Windows.

(In fact, these files _are_ symlinked to one th_en_US in the package I used
as source)

Jürgen



 Stephan

Re: 2.2

[Jürgen Spitzmüller]

2015-06-01 17:19 GMT+02:00 Kornel Benko kor...@lyx.org:

 On ubuntu there _are_ differences between th_en_US_v2.dat and
 th_en_AU_v2.idx.
 # ls -l /usr/share/mythes/th_en*.dat
 -rw-r--r-- 1 root root 18545141 máj 27  2013
 /usr/share/mythes/th_en_AU_v2.dat
 -rw-r--r-- 1 root root 18597793 sep 23  2014
 /usr/share/mythes/th_en_US_v2.dat

 The appropriate packages are mythes-en-au, mythes-en-us.
 So setting them equal does not seem OK without concern.


We only fall back if

1.) no specific dictionary for the given LANG code (such as the_en_AU) is
available
2.) if there is a _general_ dictionary (th_en, _not_ the_en_US or similar)
available

So dictionaries would only be treated as equal if we explicitly qualify
them as such.

Jürgen



 Kornel

Re: 2.2

[Kornel Benko]

Am Montag, 1. Juni 2015 um 16:52:43, schrieb Jürgen Spitzmüller sp...@lyx.org
 2015-06-01 16:46 GMT+02:00 Jean-Marc Lasgouttes lasgout...@lyx.org:
 
  Yes, for example. The approach seems a bit complicated to me, but since I
  do not have a brilliant regex-based solution in mind right now, I assume
  you got the best possible solution.
 
 
 Actually, I tried with different regexes until I was fed up and went with
 this.
 
 Jürgen
 
 
 
  JMarc

On ubuntu there _are_ differences between th_en_US_v2.dat and th_en_AU_v2.idx.
# ls -l /usr/share/mythes/th_en*.dat
-rw-r--r-- 1 root root 18545141 máj 27  2013 
/usr/share/mythes/th_en_AU_v2.dat
-rw-r--r-- 1 root root 18597793 sep 23  2014 
/usr/share/mythes/th_en_US_v2.dat

The appropriate packages are mythes-en-au, mythes-en-us.
So setting them equal does not seem OK without concern.

Kornel


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

Re: 2.2

[Jürgen Spitzmüller]

2015-06-01 16:46 GMT+02:00 Jean-Marc Lasgouttes lasgout...@lyx.org:

 Yes, for example. The approach seems a bit complicated to me, but since I
 do not have a brilliant regex-based solution in mind right now, I assume
 you got the best possible solution.


Actually, I tried with different regexes until I was fed up and went with
this.

Jürgen



 JMarc

Re: 2.2

[Jean-Marc Lasgouttes]

Le 01/06/2015 16:09, Jürgen Spitzmüller a écrit :

For example via the attached patch.


Yes, for example. The approach seems a bit complicated to me, but since 
I do not have a brilliant regex-based solution in mind right now, I 
assume you got the best possible solution.


JMarc

Re: test of math previews (was: [LyX/master] Really fix bug #9354)

[Enrico Forestieri]

On Mon, Jun 01, 2015 at 07:26:55AM +0100, Guillaume M-M wrote:
 
 In fact it does not work entirely in master. There is a regression (after
 bc47054b I believe) because compilation can now fail due to \renewcommandx
 being used without the command being defined prior to that (try the attached
 lyx-bug-renewcommandx.lyx). (Stable is fine in this regard after your commit
 9285f338, it seems.) http://www.lyx.org/trac/ticket/6369
 
 One quick solution would be to prepend all \renewcommandx\a{b} with
 \providecommand\a{}.

I think this was already addressed by Jürgen at 83a9ed4e.

 Here are other conclusions from my test of stable and master this week-end:
 
 1) b3d2ffc0 introduces a regression in stable and master wrt 2.1.3. See the
 attached lyx-bug-font2.lyx. This is because legacy_lyxpreview2ppm.py now
 includes the font lmodern (L236). I do not understand this addition: font
 setting is already done in the preamble. Removing the line fixes the issue.

It was added in order to have vector fonts, otherwise the previews
generated by the legacy method would be of very poor quality. It is
difficult to determine what a user could do in the preamble and whether
it is safe using lmodern or not. However, given that it may produce issues,
it may be better not using it, if nobody has a better idea.

 2) In master, preview incorrectly calls latex instead of pdflatex if the
 default output format is set to default. More details in the attached
 lyx-bug-microtype.lyx. (It causes the instant preview to fail, while the
 default (pdflatex) compilation with Ctrl+R succeeds.)
 Stable also fails because it seems to call latex instead of pdflatex all the
 time, but it does not appear to be a regression wrt 2.1.3.

Note that we have to guarantee backward compatibility and using latex
when the document does not specify a default output format is a must,
otherwise instant preview may fail for existing documents.
See #9371 for details.

When using pdflatex (or other formats producing a pdf) for generating
the previews, the legacy method is used. It turns out to be much slower
than the dvipng route, so that care is taken to try to use dvi output for
all previews not failing and then trying pdflatex for those that fail.
For some reason, the failure you report escapes those checks. So, this
reason should be identified and accordingly corrected. Typically, in
open source projects one can suggest a patch to speed up the correction
of an issue.

 3) As reported in #6369, InstantPreview multiplies math macros
 definitions. Although the particular compilation issue has been solved, the
 duplication of macro definitions is not fixed. This has performance
 consequences. In stable and master, opening a moderately-sized math article
 (10-20 pages) with instant preview activated results in 75s of full CPU
 usage (and more when latex is called incorrectly instead of pdflatex), 55s
 during which LyX is unresponsive (and just generates the tex file). The
 instant preview tex file is 55 lines long and is 16MB big, mainly
 comprised of macro definitions (maybe there is another performance
 bottleneck, but this is probably one). So instant preview is still unusable
 for me (at least until the instant preview inset supports math macros---BTW
 the patch http://www.lyx.org/trac/attachment/ticket/9354/9354.diff works
 well for me).

This is not my experience. Instant preview snippets for the math manual
(which surely qualifies as a medium-sized math article) are generated in
about 10 seconds on my old and slow laptop and the instant preview tex
file is about 50Kb.

 4) Using Ctrl+Mousewheel to zoom sometimes results in a preview of the wrong
 size. LyX recreates the previews when zooming, and sometimes we end up with
 an intermediary size of preview inconsistent with the size of the text (race
 condition?).

The previous are generated asynchronously, thus, if you change the zoom while
they are still being generated, you may end up with different sizes. This
can be improved, of course. Maybe using Ctrl+Mousewheel may generate
multiple sizes at once and this causes that issue. Try using the Alt+ and
Alt- shortcuts (and wait for the previews to be generated before using
them again).

 (BTW why redoing preview from scratch when the pdf is already generated? Why
 not keeping the each preview as a pdfs, displayed on the fly by LyX using
 Cairo, when actually needed? This sounds vastly more efficient.)

There is the problem of assuring that the previews are still the same and
not actually changed. ATM there is no way to trigger a different way for
the regeneration due to zooming. Also in this case, I think that a patch
would be thoughtfully considered, but I doubt it can lead to a significant
speed up, as the most part of the time is spent in converting the pdfs
rather than regenerating them.

 3+4) Zooming with Ctrl+mousewheel is impossible with instant preview
 activated in a reasonably-sized document as a combination of 3) and 4). LyX
 freezes as soon 

Re: test of math previews

[Jean-Marc Lasgouttes]

Le 01/06/2015 08:26, Guillaume M-M a écrit :

5) I find that the preferences dialog is counter-intuitive, with the
distinction between Save, Apply and Close. I don't see the point of
applying without saving (e.g. I think I have disabled instant preview,
but then I find that it is reactivated the next time I run LyX). To add
to the wish list of UI improvements...


I second that personally. I know of no other software that has this 
behavior. But it is less confusing than the bizarre converters UI (also, 
I am not sure how to make it sane).


JMarc

Re: 2.2

[Jürgen Spitzmüller]

2015-06-01 11:23 GMT+02:00 Jürgen Spitzmüller sp...@lyx.org:

 2015-06-01 11:04 GMT+02:00 Jean-Marc Lasgouttes lasgout...@lyx.org:

 And what about shipping one and naming it th_en_v2.dat? I am sure we can
 work out a naming scheme that does what we want?


 Yes, that would be an option.


For example via the attached patch.

Jürgen




 Jürgen



 JMarc



diff --git a/src/Thesaurus.cpp b/src/Thesaurus.cpp
index b4655ac..4f4ad64 100644
--- a/src/Thesaurus.cpp
+++ b/src/Thesaurus.cpp
@@ -107,6 +107,11 @@ pairstring,string 
Thesaurus::Private::getThesaurus(string const  path, docstr
for (FileNameList::const_iterator it = idx_files.begin(); it != 
idx_files.end(); ++it) {
basename = it-onlyFileNameWithoutExt();
if (contains(basename, to_ascii(lang))) {
+   // do not use more specific dicts.
+   if (contains(basename, '_')  !contains(lang, '_'))
+   continue;
+   if (contains(basename, '-')  !contains(lang, '-'))
+   continue;
ifstream ifs(it-absFileName().c_str());
if (ifs) {
// check for appropriate version of index file
@@ -128,8 +133,23 @@ pairstring,string 
Thesaurus::Private::getThesaurus(string const  path, docstr
break;
}
}
-   if (idx.empty())
+   if (idx.empty()) {
+   // try with a more general dictionary
+   docstring shortcode;
+   if (contains(lang, '_')) {
+   split(lang, shortcode, '_');
+   LYXERR(Debug::FILES, Did not find thesaurus for LANG 
code 
+   lang  . Trying with   shortcode);
+   return getThesaurus(path, shortcode);
+   }
+   else if (contains(lang, '-')) {
+   split(lang, shortcode, '-');
+   LYXERR(Debug::FILES, Did not find thesaurus for LANG 
code 
+   lang  . Trying with   shortcode);
+   return getThesaurus(path, shortcode);
+   }
return make_pair(string(), string());
+   }
for (support::FileNameList::const_iterator it = data_files.begin(); it 
!= data_files.end(); ++it) {
if (contains(it-onlyFileName(), basename)) {
data = it-absFileName();

Re: 2.2

[Georg Baum]

Jürgen Spitzmüller wrote:

 On Linux and Mac, you can certainly also use symlinks. Don't know about
 Windows.

Some time ago I learned that the NTFS file system used on all modern windows 
versions supports true symlinks as well (I am not talking about the .lnk 
substitute). If the installer can generate them, then they could be used on 
windows as well.


Georg

Re: test of math previews (was: [LyX/master] Really fix bug #9354)

[Enrico Forestieri]

On Mon, Jun 01, 2015 at 03:50:49PM +0200, Enrico Forestieri wrote:
 On Mon, Jun 01, 2015 at 07:26:55AM +0100, Guillaume M-M wrote:
  
  2) In master, preview incorrectly calls latex instead of pdflatex if the
  default output format is set to default. More details in the attached
  lyx-bug-microtype.lyx. (It causes the instant preview to fail, while the
  default (pdflatex) compilation with Ctrl+R succeeds.)
  Stable also fails because it seems to call latex instead of pdflatex all the
  time, but it does not appear to be a regression wrt 2.1.3.
 
 Note that we have to guarantee backward compatibility and using latex
 when the document does not specify a default output format is a must,
 otherwise instant preview may fail for existing documents.
 See #9371 for details.
 
 When using pdflatex (or other formats producing a pdf) for generating
 the previews, the legacy method is used. It turns out to be much slower
 than the dvipng route, so that care is taken to try to use dvi output for
 all previews not failing and then trying pdflatex for those that fail.
 For some reason, the failure you report escapes those checks. So, this
 reason should be identified and accordingly corrected. Typically, in
 open source projects one can suggest a patch to speed up the correction
 of an issue.

I had a closer look at this issue and it turned out to be as follows.
If a snippet produces latex errors it is now not previewed at all.
Now, when using the microtype package in dvi mode, latex issues an
error about not finding the tfm file for a font, but nevertheless
goes on and produces a correct output. This error is issued only at
the beginning so that it associated with the first snippet, which is
for this reason marked as bad. Actually, the script generates a valid
preview but it is not used. All other snippets are used, so only the
first one is omitted even if it would be Ok.

There are 2 possible solutions. The first one is omitting the microtype
package for the sake of generating the previews by using the faster
dvipng method (attached patch no-microtype.diff for master).
The second one is forcing the use of pdflatex when the use of microtype
is detected. In this case the slower legacy mathod will be used for
generating the previews (attached patch yes-microtype.diff for master).

Please, vote for the one or the other. I will commit the patch getting
more votes.

I also noticed that when microtype is used in dvi mode latex takes a
lot more of time to process the same file. Maybe this is the cause of
the slowdown observed by Guillaume.

-- 
Enrico
diff --git a/lib/scripts/lyxpreview2bitmap.py b/lib/scripts/lyxpreview2bitmap.py
index 5eca959..9d46054 100755
--- a/lib/scripts/lyxpreview2bitmap.py
+++ b/lib/scripts/lyxpreview2bitmap.py
@@ -160,11 +160,17 @@ def extract_metrics_info(dvipng_stdout):
 
 def fix_latex_file(latex_file):
 documentclass_re = re.compile((documentclass\[)(1[012]pt,?)(.+))
+microtype_re = re.compile(usepackage.*\{microtype\})
 
 tmp = mkstemp()
 
 changed = 0
 for line in open(latex_file, 'r').readlines():
+match = microtype_re.match(line)
+if match != None:
+changed = 1
+continue
+
 match = documentclass_re.match(line)
 if match == None:
 tmp.write(line)
diff --git a/lib/scripts/lyxpreview2bitmap.py b/lib/scripts/lyxpreview2bitmap.py
index 5eca959..3aec16f 100755
--- a/lib/scripts/lyxpreview2bitmap.py
+++ b/lib/scripts/lyxpreview2bitmap.py
@@ -160,11 +160,17 @@ def extract_metrics_info(dvipng_stdout):
 
 def fix_latex_file(latex_file):
 documentclass_re = re.compile((documentclass\[)(1[012]pt,?)(.+))
+microtype_re = re.compile(usepackage.*\{microtype\})
 
 tmp = mkstemp()
 
+force_pdf_output = 0
 changed = 0
 for line in open(latex_file, 'r').readlines():
+match = microtype_re.match(line)
+if match != None:
+force_pdf_output = 1
+
 match = documentclass_re.match(line)
 if match == None:
 tmp.write(line)
@@ -176,7 +182,7 @@ def fix_latex_file(latex_file):
 if changed:
 copyfileobj(tmp, open(latex_file,wb), 1)
 
-return changed
+return force_pdf_output
 
 
 def convert_to_ppm_format(pngtopnm, basename):
@@ -384,6 +390,12 @@ def main(argv):
 # These flavors of latex are known to produce pdf output
 pdf_output = latex in pdflatex_commands
 
+# Omit font size specification in latex file.
+force_pdf_output = fix_latex_file(latex_file)
+if force_pdf_output and not pdf_output:
+pdf_output = True
+latex = pdflatex
+
 progress(Latex command: %s % latex)
 progress(Latex produces pdf output: %s % pdf_output)
 progress(Bibtex command: %s % bibtex)
@@ -391,10 +403,6 @@ def main(argv):
 progress(Preprocess through lilypond-book: %s % lilypond)
 progress(Altering the latex file for font size and colors)
 
-# Omit font size specification in latex file and 

Re: test of math previews (was: [LyX/master] Really fix bug #9354)

[Enrico Forestieri]

On Mon, Jun 01, 2015 at 03:50:49PM +0200, Enrico Forestieri wrote:
 On Mon, Jun 01, 2015 at 07:26:55AM +0100, Guillaume M-M wrote:
  
  1) b3d2ffc0 introduces a regression in stable and master wrt 2.1.3. See the
  attached lyx-bug-font2.lyx. This is because legacy_lyxpreview2ppm.py now
  includes the font lmodern (L236). I do not understand this addition: font
  setting is already done in the preamble. Removing the line fixes the issue.
 
 It was added in order to have vector fonts, otherwise the previews
 generated by the legacy method would be of very poor quality. It is
 difficult to determine what a user could do in the preamble and whether
 it is safe using lmodern or not. However, given that it may produce issues,
 it may be better not using it, if nobody has a better idea.

Jürgen, any idea on this one?

-- 
Enrico

Re: test of math previews

[Guillaume M-M]

Le 01/06/2015 18:16, Enrico Forestieri a écrit :

On Mon, Jun 01, 2015 at 03:50:49PM +0200, Enrico Forestieri wrote:

On Mon, Jun 01, 2015 at 07:26:55AM +0100, Guillaume M-M wrote:


2) In master, preview incorrectly calls latex instead of pdflatex if the
default output format is set to default. More details in the attached
lyx-bug-microtype.lyx. (It causes the instant preview to fail, while the
default (pdflatex) compilation with Ctrl+R succeeds.)
Stable also fails because it seems to call latex instead of pdflatex all the
time, but it does not appear to be a regression wrt 2.1.3.


Note that we have to guarantee backward compatibility and using latex
when the document does not specify a default output format is a must,
otherwise instant preview may fail for existing documents.
See #9371 for details.

When using pdflatex (or other formats producing a pdf) for generating
the previews, the legacy method is used. It turns out to be much slower
than the dvipng route, so that care is taken to try to use dvi output for
all previews not failing and then trying pdflatex for those that fail.
For some reason, the failure you report escapes those checks. So, this
reason should be identified and accordingly corrected. Typically, in
open source projects one can suggest a patch to speed up the correction
of an issue.


I had a closer look at this issue and it turned out to be as follows.
If a snippet produces latex errors it is now not previewed at all.
Now, when using the microtype package in dvi mode, latex issues an
error about not finding the tfm file for a font, but nevertheless
goes on and produces a correct output. This error is issued only at
the beginning so that it associated with the first snippet, which is
for this reason marked as bad. Actually, the script generates a valid
preview but it is not used. All other snippets are used, so only the
first one is omitted even if it would be Ok.

There are 2 possible solutions. The first one is omitting the microtype
package for the sake of generating the previews by using the faster
dvipng method (attached patch no-microtype.diff for master).
The second one is forcing the use of pdflatex when the use of microtype
is detected. In this case the slower legacy mathod will be used for
generating the previews (attached patch yes-microtype.diff for master).

Please, vote for the one or the other. I will commit the patch getting
more votes.


I do not think that treating microtype as a special case is the way to 
go. First, the issue is with the option expansion=true. Without this 
option, microtype correctly works with latex and correctly activates 
expansion with pdflatex.


This was more to illustrate the fact that it is a great new feature in 
master to compile the previews using the default output format because 
of many small details like this error. For instance, although this seems 
easy to fix now that I understood the issue (just remove the option 
expansion=true, or set the default output format to pdflatex) it really 
took me a while to figure this out (partly because it is hard to access 
the error messages for the instant preview).


As I described, I think the issue is regarding the meaning of Default 
output format: Default. For the Ctrl+R shortcut, this means pdflatex 
while for instant preview this means latex. I don't understand the 
backwards-compatibility argument here, I think that it is safer to use 
the same default format as Ctrl+R in all cases.


This looks like a small detail, but for a general user, setting 
explicitly default output format: PDF (pdflatex) does not appear as an 
obvious solution to instant preview does not work. And the error can 
always be more fatal than this error with microtype.


IF the inconsistency regarding the meaning of Default output format: 
Default is intended for performance reason and that I did not make you 
change your mind, then I vote for:

 omitting the microtype
 package for the sake of generating the previews by using the faster
 dvipng method
But again it is hard to guess that default output format: default has 
this optimisation while default output format: PDF (pdflatex) does 
not. (But at least there is the option to force the use of pdflatex by 
instant preview if really needed.)


By the way, a safer way to force not loading a package is to prepend 
\usepackage with \@namedef{v...@microtype.sty}{/12/31}. If you just 
strip the line from the preamble you can easily run into troubles. In 
addition, at some point I had it on two lines like this (note the %):

  \usepackage[protrusion=true%,expansion=false
  ]{microtype}
in which case your regexp fails if I understood correctly. I suggest 
just adding \@namedef{v...@microtype.sty}{/12/31} before the 
preamble whether we suspect that microtype is used or not, without 
testing for its presence. (Unless you see other errors this might generate.)


Again the philosophy of my comment is not please deal explicitly with 
these corner cases but it's 

Re: test of math previews (was: [LyX/master] Really fix bug #9354)

[Jürgen Spitzmüller]

2015-06-01 19:34 GMT+02:00 Enrico Forestieri for...@lyx.org:

 On Mon, Jun 01, 2015 at 03:50:49PM +0200, Enrico Forestieri wrote:
  On Mon, Jun 01, 2015 at 07:26:55AM +0100, Guillaume M-M wrote:
  
   1) b3d2ffc0 introduces a regression in stable and master wrt 2.1.3.
 See the
   attached lyx-bug-font2.lyx. This is because legacy_lyxpreview2ppm.py
 now
   includes the font lmodern (L236). I do not understand this addition:
 font
   setting is already done in the preamble. Removing the line fixes the
 issue.
 
  It was added in order to have vector fonts, otherwise the previews
  generated by the legacy method would be of very poor quality. It is
  difficult to determine what a user could do in the preamble and whether
  it is safe using lmodern or not. However, given that it may produce
 issues,
  it may be better not using it, if nobody has a better idea.

 Jürgen, any idea on this one?


lmodern must only be loaded if no other font has been loaded, i.e. if
computer modern is the active font:

\def\tempa{cmr}

\ifx\f@family\tempa\usepackage{lmodern}\else\fi

Jürgen

Re: test of math previews

[Guillaume M-M]

Le 01/06/2015 19:50, Jürgen Spitzmüller a écrit :

2015-06-01 19:34 GMT+02:00 Enrico Forestieri for...@lyx.org
mailto:for...@lyx.org:

On Mon, Jun 01, 2015 at 03:50:49PM +0200, Enrico Forestieri wrote:
 On Mon, Jun 01, 2015 at 07:26:55AM +0100, Guillaume M-M wrote:
 
  1) b3d2ffc0 introduces a regression in stable and master wrt 2.1.3. See 
the
  attached lyx-bug-font2.lyx. This is because legacy_lyxpreview2ppm.py now
  includes the font lmodern (L236). I do not understand this addition: 
font
  setting is already done in the preamble. Removing the line fixes the 
issue.

 It was added in order to have vector fonts, otherwise the previews
 generated by the legacy method would be of very poor quality. It is
 difficult to determine what a user could do in the preamble and whether
 it is safe using lmodern or not. However, given that it may produce 
issues,
 it may be better not using it, if nobody has a better idea.

Jürgen, any idea on this one?


lmodern must only be loaded if no other font has been loaded, i.e. if
computer modern is the active font:

\def\tempa{cmr}

\ifx\f@family\tempa\usepackage{lmodern}\else\fi


Jürgen




Is there any lyx file demonstrating the poor font quality? I have been 
unable to reproduce the font issue in master (after removing the line 
that forces latin modern in instant previews), even with the default 
setting of LyX that produces a PDF with bitmap fonts...


Anyway, here's a suggestion for getting those horrible bitmap fonts out 
of the way of new users, in a perfectly non-intrusive and 
backwards-compatible manner: just set Latin Modern to be the default 
choice for a new document. This would also solve the issue considered 
above. Note that I don't suggest to change the meaning of Default for 
roman fonts, but rather to force the user explicitly select Default 
over Latin Modern if he really wants to. I think it is always good 
when LyX shows the standard way. Then if the user wants poor bitmap 
fonts, that will be by choice.


(I know that I may suggest patches instead of ideas, but I do not have 
much time currently to become a new contributor to LyX, although I have 
been considering it.)

Re: test of math previews

[Enrico Forestieri]

On Mon, Jun 01, 2015 at 08:07:11PM +0100, Guillaume M-M wrote:

 I don't understand the
 backwards-compatibility argument here, I think that it is safer to use the
 same default format as Ctrl+R in all cases.

I think that the backward-compatibility argument is a serious one.
If an old document that was perfectly working does not work anymore,
one could simply decide that LyX is not the right tool to use and it
is safer using latex directly.

-- 
Enrico

Re: test of math previews

[Guillaume M-M]

Le 01/06/2015 21:16, Guillaume M-M a écrit :

Le 01/06/2015 19:50, Jürgen Spitzmüller a écrit :

2015-06-01 19:34 GMT+02:00 Enrico Forestieri for...@lyx.org
mailto:for...@lyx.org:

On Mon, Jun 01, 2015 at 03:50:49PM +0200, Enrico Forestieri wrote:
 On Mon, Jun 01, 2015 at 07:26:55AM +0100, Guillaume M-M wrote:
 
  1) b3d2ffc0 introduces a regression in stable and master wrt
2.1.3. See the
  attached lyx-bug-font2.lyx. This is because
legacy_lyxpreview2ppm.py now
  includes the font lmodern (L236). I do not understand this
addition: font
  setting is already done in the preamble. Removing the line
fixes the issue.

 It was added in order to have vector fonts, otherwise the previews
 generated by the legacy method would be of very poor quality. It is
 difficult to determine what a user could do in the preamble and
whether
 it is safe using lmodern or not. However, given that it may
produce issues,
 it may be better not using it, if nobody has a better idea.

Jürgen, any idea on this one?


lmodern must only be loaded if no other font has been loaded, i.e. if
computer modern is the active font:

\def\tempa{cmr}

\ifx\f@family\tempa\usepackage{lmodern}\else\fi


Jürgen




Is there any lyx file demonstrating the poor font quality? I have been
unable to reproduce the font issue in master (after removing the line
that forces latin modern in instant previews), even with the default
setting of LyX that produces a PDF with bitmap fonts...

Anyway, here's a suggestion for getting those horrible bitmap fonts out
of the way of new users, in a perfectly non-intrusive and
backwards-compatible manner: just set Latin Modern to be the default
choice for a new document. This would also solve the issue considered
above. Note that I don't suggest to change the meaning of Default for
roman fonts, but rather to force the user explicitly select Default
over Latin Modern if he really wants to. I think it is always good
when LyX shows the standard way. Then if the user wants poor bitmap
fonts, that will be by choice.



I am aware that it is less simple than it sounds given that often the 
user wants to switch to a document class that already has more sensible 
defaults. I will open an enhancement request if I figure out a solution, 
but I'd be happy to know whether something like this was already 
discussed on the list.

Re: test of math previews

[Enrico Forestieri]

On Mon, Jun 01, 2015 at 09:16:00PM +0100, Guillaume M-M wrote:
 
 Is there any lyx file demonstrating the poor font quality? I have been
 unable to reproduce the font issue in master (after removing the line that
 forces latin modern in instant previews), even with the default setting of
 LyX that produces a PDF with bitmap fonts...

I attach here the pdfs I get with a new document with default output set to
pdflatex and simply an 'a' in a preview inset.
The first one (lyxpreviewdCv436.pdf) when I ditch the lmodern line, the
second one (lyxpreviewxWL436.pdf) with that line in place. The previews
are then generated by converting the pdfs into pngs.
Here you can also find how the difference looks like on screen:
http://www.lyx.org/trac/attachment/ticket/9371/example-2.1.png (good)
http://www.lyx.org/trac/attachment/ticket/9371/example-2.2.png (bad)

-- 
Enrico


lyxpreviewdCv436.pdf
Description: Adobe PDF document


lyxpreviewxWL436.pdf
Description: Adobe PDF document

Re: configure.py questions

[Uwe Stöhr]

While we are at it: during my research I read several times that the 
program Pandoc produces nice results for TeX documents and that it can 
handle BibTeX. So maybe we should add support for Pandoc to configure.py.


If you agree I open an enhancement request (don't have time to implement 
this at the moment).


regards Uwe

Re: test of math previews

[Guillaume M-M]

Le 01/06/2015 22:12, Enrico Forestieri a écrit :

On Mon, Jun 01, 2015 at 08:07:11PM +0100, Guillaume M-M wrote:


I don't understand the
backwards-compatibility argument here, I think that it is safer to use the
same default format as Ctrl+R in all cases.


I think that the backward-compatibility argument is a serious one.
If an old document that was perfectly working does not work anymore,
one could simply decide that LyX is not the right tool to use and it
is safer using latex directly.




I know the importance of backwards compatibility, but I don't understand 
how it applies here.


Currently in stable:
* With default format output = Default
  * Ctrl+R - pdflatex
  * Instant preview - latex
* With default format output = PDF (pdflatex)
  * Ctrl+R - pdflatex
  * Instant preview - latex

Whereas in master:
* With default format output = Default
  * Ctrl+R - pdflatex
  * Instant preview - latex
* With default format output = PDF (pdflatex)
  * Ctrl+R - pdflatex
  * Instant preview - pdflatex

Thus, if changing the behaviour of instant preview for Default means 
breaking backwards compatibility, then backwards compatibility is 
already broken in master given that the behaviour is changed for PDF 
(pdflatex). We don't appear to believe that. This is what I meant.


But I am receptive to your idea of keeping latex for the speedup and 
disabling microtype, for the same speed reason. I like the idea of still 
having the choice via default output format (even though the feature 
will be kind of hidden).


Le 01/06/2015 22:20, Enrico Forestieri a écrit :


I attach here the pdfs I get with a new document with default output set to
pdflatex and simply an 'a' in a preview inset.
The first one (lyxpreviewdCv436.pdf) when I ditch the lmodern line, the
second one (lyxpreviewxWL436.pdf) with that line in place. The previews
are then generated by converting the pdfs into pngs.
Here you can also find how the difference looks like on screen:
http://www.lyx.org/trac/attachment/ticket/9371/example-2.1.png (good)
http://www.lyx.org/trac/attachment/ticket/9371/example-2.2.png (bad)


Sorry for the false alarm, I can indeed reproduce with these 
explanations. However this is consistent with the document settings: 
lmodern should indeed not be loaded if the fonts have already been set 
properly, as suggested by Jürgen.


Thank you

Re: test of math previews

[Enrico Forestieri]

On Mon, Jun 01, 2015 at 08:07:11PM +0100, Guillaume M-M wrote:
 
 IF the inconsistency regarding the meaning of Default output format:
 Default is intended for performance reason and that I did not make you
 change your mind, then I vote for:
  omitting the microtype
  package for the sake of generating the previews by using the faster
  dvipng method

Ok, noted.

 But again it is hard to guess that default output format: default has this
 optimisation while default output format: PDF (pdflatex) does not. (But at
 least there is the option to force the use of pdflatex by instant preview if
 really needed.)

While in principle I agree that generating the previews with the same
engine is the right thing to do, there is the problem that dvipng is
really fast while generating pngs from pdfs is much slower. If you take
away pdftocairo and then try the legacy route, you will see that it is
about 10 times slower. With pdftocairo it is only about 3 times slower.
If you are concerned about speed, I see no other way to allow a decent
implementation of instant previews.

 By the way, a safer way to force not loading a package is to prepend
 \usepackage with \@namedef{v...@microtype.sty}{/12/31}. If you just
 strip the line from the preamble you can easily run into troubles. In
 addition, at some point I had it on two lines like this (note the %):
   \usepackage[protrusion=true%,expansion=false
   ]{microtype}
 in which case your regexp fails if I understood correctly. I suggest just
 adding \@namedef{v...@microtype.sty}{/12/31} before the preamble
 whether we suspect that microtype is used or not, without testing for its
 presence. (Unless you see other errors this might generate.)

Ok, thanks for the tip.

 Again the philosophy of my comment is not please deal explicitly with these
 corner cases but it's better to take the safe route.

But you show a problem with a corner case and the safe route may be costly.

 I really like the direction of the new patches trying to make instant
 preview just work, I hope that my tests and comments help you in this
 regard.

Yes, thank you, that's really appreciated.

 You may be right that microtype may have been the reason why I had the
 impression that latex is slower than pdflatex, but this does not account for
 the 55s (on a good computer) during which LyX is frozen while generating the
 16MB tex file. I will run tests again to confirm (and also test the new
 patch) and will reply to the previous message in a short while. (BTW yes I
 have epstopdf and pdfcairo.)

Here we are not going anywhere. I say it works well for me, while you say it
doesn't work. Please, provide an example that generates a 16MB tex file for
a ~20 page document.

-- 
Enrico

Re: test of math previews

[Enrico Forestieri]

On Mon, Jun 01, 2015 at 11:01:48PM +0100, Guillaume M-M wrote:

 Le 01/06/2015 22:12, Enrico Forestieri a écrit :
 On Mon, Jun 01, 2015 at 08:07:11PM +0100, Guillaume M-M wrote:
 
 I don't understand the
 backwards-compatibility argument here, I think that it is safer to use the
 same default format as Ctrl+R in all cases.
 
 I think that the backward-compatibility argument is a serious one.
 If an old document that was perfectly working does not work anymore,
 one could simply decide that LyX is not the right tool to use and it
 is safer using latex directly.
 
 
 
 I know the importance of backwards compatibility, but I don't understand how
 it applies here.
 
 Currently in stable:
 * With default format output = Default
   * Ctrl+R - pdflatex
   * Instant preview - latex
 * With default format output = PDF (pdflatex)
   * Ctrl+R - pdflatex
   * Instant preview - latex
 
 Whereas in master:
 * With default format output = Default
   * Ctrl+R - pdflatex
   * Instant preview - latex
 * With default format output = PDF (pdflatex)
   * Ctrl+R - pdflatex
   * Instant preview - pdflatex
 
 Thus, if changing the behaviour of instant preview for Default means
 breaking backwards compatibility, then backwards compatibility is already
 broken in master given that the behaviour is changed for PDF (pdflatex).
 We don't appear to believe that. This is what I meant.

If the default output format set in the preferences is always used,
this document:
http://www.lyx.org/trac/raw-attachment/ticket/9371/pst-triangle.lyx
that previews correctly in 2.1, would fail in 2.2 if the default
output format in the preferences is set to pdflatex.
Now it can also be correctly previewed in 2.2 without explicitly setting
the default format for the document, i.e., without modifying the document.
Please, read the discussion about this topic (bug #9371).

 But I am receptive to your idea of keeping latex for the speedup and
 disabling microtype, for the same speed reason. I like the idea of still
 having the choice via default output format (even though the feature will
 be kind of hidden).

Please, look in the archives for the extensive discussion about this point.

-- 
Enrico

Re: test of math previews

[Enrico Forestieri]

On Mon, Jun 01, 2015 at 10:14:23PM +0100, Guillaume M-M wrote:
 Le 01/06/2015 21:16, Guillaume M-M a écrit :
 
 Anyway, here's a suggestion for getting those horrible bitmap fonts out
 of the way of new users, in a perfectly non-intrusive and
 backwards-compatible manner: just set Latin Modern to be the default
 choice for a new document. This would also solve the issue considered
 above. Note that I don't suggest to change the meaning of Default for
 roman fonts, but rather to force the user explicitly select Default
 over Latin Modern if he really wants to. I think it is always good
 when LyX shows the standard way. Then if the user wants poor bitmap
 fonts, that will be by choice.
 
 
 I am aware that it is less simple than it sounds given that often the user
 wants to switch to a document class that already has more sensible defaults.
 I will open an enhancement request if I figure out a solution, but I'd be
 happy to know whether something like this was already discussed on the list.

Many times...

-- 
Enrico

Re: Merging features/fix-tex2lyx-tests to master

[Uwe Stöhr]

Am 31.05.2015 um 19:06 schrieb Uwe Stöhr:


This might be a tex2lyx bug as well, depending how the reference was
created. This is not in 1) since I can reproduce the results in 1) with
current tex2lyx but not this one. Uwe, how did you create the reference
which does not contain the external inset? Did you copy the .tex file
somehwere else, or was it in the git tree?


Hi Georg,

I now find out how I managed to change this:
I executed this command:

tex2lyx -f -roundtrip test-insets.tex

This leads to a lyx.lyx file with the new inset. Attached is the diff I get.

regards Uwe
diff --git 
a/C:\\Users\\Usti\\AppData\\Local\\Temp\\TortoiseGit\\tesC832.tmp\\test-insets.lyx-945a348-left.lyx
 b/D:\\LyXGit\\Master\\src\\tex2lyx\\test\\test-insets.lyx.lyx
index 23a82b7..d312958 100644
--- 
a/C:\\Users\\Usti\\AppData\\Local\\Temp\\TortoiseGit\\tesC832.tmp\\test-insets.lyx-945a348-left.lyx
+++ b/D:\\LyXGit\\Master\\src\\tex2lyx\\test\\test-insets.lyx.lyx
@@ -759,7 +759,7 @@ We can input files too, like this
 \begin_inset CommandInset include
 LatexCommand input
 preview false
-filename DummyDocument.lyx.lyx
+filename DummyDocument
 
 \end_inset
 
@@ -783,7 +783,7 @@ filename Dummy Document.tex
 \begin_inset CommandInset include
 LatexCommand include
 preview false
-filename Dummy~Document.lyx.lyx
+filename Dummy~Document
 
 \end_inset
 
@@ -791,7 +791,7 @@ filename Dummy~Document.lyx.lyx
 \begin_inset CommandInset include
 LatexCommand include
 preview false
-filename Dummy~Document.lyx.lyx
+filename Dummy~Document.tex
 
 \end_inset
 
@@ -842,9 +842,10 @@ XFig drawings:
 
 \begin_layout Standard
 
-\begin_inset External
-   template XFig
-   filename xfigtest.fig
+\begin_inset CommandInset include
+LatexCommand input
+preview false
+filename xfigtest.pstex_t
 
 \end_inset
 
@@ -3100,12 +3101,12 @@ status collapsed
 \begin_layout Plain Layout
 
 \backslash
-raggedleft
+raggedleft 
 \end_layout
 
 \end_inset
 
- This last column is a 
+This last column is a 
 \begin_inset Quotes eld
 \end_inset
 
@@ -4493,7 +4494,7 @@ status collapsed
 \begin_layout Plain Layout
 
 \backslash
-centering
+centering 
 \end_layout
 
 \end_inset

RFC: How to output multicolumn with fixed width and decimal-separator-alignment

[Uwe Stöhr]

Dear LyXers,

in http://www.lyx.org/trac/ticket/9568 Jürgen an I had a discussion how 
to output multicolumn with  fixed width and decimal-separator-alignment. 
There are 3 possible outputs, see the attached PDF. Note that for all 3 
cases the column width is set to 4cm in LyX.


The question is which output (left, center or right) you personally prefer.

many thanks in advance and regards
Uwe


AlignmentComparison.pdf
Description: Adobe PDF document

Re: test of math previews

[Guillaume M-M]

Le 01/06/2015 23:04, Enrico Forestieri a écrit :

You may be right that microtype may have been the reason why I had the
impression that latex is slower than pdflatex, but this does not account for
the 55s (on a good computer) during which LyX is frozen while generating the
16MB tex file. I will run tests again to confirm (and also test the new
patch) and will reply to the previous message in a short while. (BTW yes I
have epstopdf and pdfcairo.)


Here we are not going anywhere. I say it works well for me, while you say it
doesn't work. Please, provide an example that generates a 16MB tex file for
a ~20 page document.



Read again: I am saying that I am running further tests and come back 
later with a reply :)


In fact I am currently having an assertion violation when activating 
full instant preview (attached), which prevents me from completing the 
test. Can anyone tell me how I get more meaningful symbols? I can try to 
send a reproducer but I am a bit short on time to make one right now. 
(And time is not pressing, it does not affect stable.)


LyX 2.2.0dev (not released yet)
  Git commit hash cb201027
Configuration
  Host type:   x86_64-unknown-linux-gnu
  Special build flags:  build=development warnings assertions 
stdlib-debug concept-checks

  C++ Compiler:g++ (4.9.2)
  C++ Compiler flags:   -Wall -Wextra -Wfloat-conversion -g -O
  C++ Compiler user flags:
  Linker flags:
  Linker user flags:
  Qt Frontend:
  Qt version:  4.8.6
  Packaging:   posix
  LyX binary dir:  /usr/local/bin
  LyX files dir:   /usr/local/share/lyx-gm




I am aware that it is less simple than it sounds given that often the user
wants to switch to a document class that already has more sensible defaults.
I will open an enhancement request if I figure out a solution, but I'd be
happy to know whether something like this was already discussed on the list.


Many times...


In that case, I will NOT open an enhancement request if there is already 
a consensus :) (but I did not find any relevant entry in the bug tracker)



In fact it does not work entirely in master. There is a regression (after
bc47054b I believe) because compilation can now fail due to \renewcommandx
being used without the command being defined prior to that (try the attached
lyx-bug-renewcommandx.lyx). (Stable is fine in this regard after your commit
9285f338, it seems.) http://www.lyx.org/trac/ticket/6369

One quick solution would be to prepend all \renewcommandx\a{b} with
\providecommand\a{}.


I think this was already addressed by Jürgen at 83a9ed4e.



For me the bug is still here at cb201027. Try again my file 
lyx-bug-renewcommandx.lyx attached to my first message.


Warning: pdflatex had problems compiling lyxpreviewM16620.tex
Warning: trying to recover from failed compilation
lassert.cpp (51): ASSERTION !empty() VIOLATED IN DocIterator.cpp:114
(  1) lyx-gm: lyx-gm() [0xc6b79b]
(  2) lyx-gm: lyx-gm() [0xc6b8b2]
(  3) lyx-gm: lyx-gm() [0x54e84f]
(  4) lyx-gm: lyx-gm() [0x7f4438]
(  5) lyx-gm: lyx-gm() [0x7a0a9e]
(  6) lyx-gm: lyx-gm() [0x7a1b4f]
(  7) lyx-gm: lyx-gm() [0x495c28]
(  8) lyx-gm: lyx-gm() [0x4d4809]
(  9) lyx-gm: lyx-gm() [0xb77b75]
( 10) lyx-gm: lyx-gm() [0xa676c4]
( 11) lyx-gm: lyx-gm() [0xabb7ae]
( 12) lyx-gm: lyx-gm() [0xabb864]
( 13) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: QMetaObject::activate(QObject*, 
QMetaObject const*, int, void**)
( 14) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QAbstractButton::clicked(bool)
( 15) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x59e533) [0x7f129d9fd533]
( 16) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x59f8e4) [0x7f129d9fe8e4]
( 17) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
QAbstractButton::mouseReleaseEvent(QMouseEvent*)
( 18) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QWidget::event(QEvent*)
( 19) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
QApplicationPrivate::notify_helper(QObject*, QEvent*)
( 20) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QApplication::notify(QObject*, 
QEvent*)
( 21) lyx-gm: lyx-gm() [0x9d1084]
( 22) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: 
QCoreApplication::notifyInternal(QObject*, QEvent*)
( 23) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, 
QWidget**, QPointerQWidget, bool)
( 24) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x2489a2) [0x7f129d6a79a2]
( 25) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
QApplication::x11ProcessEvent(_XEvent*)
( 26) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x270ba2) [0x7f129d6cfba2]
( 27) /lib/x86_64-linux-gnu/libglib-2.0.so.0: 
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x24d) 
[0x7f129ba3cc3d]
( 28) /lib/x86_64-linux-gnu/libglib-2.0.so.0: 
/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x49f20) [0x7f129ba3cf20]
( 29) 

test of math previews (was: [LyX/master] Really fix bug #9354)

[Guillaume M-M]

Le 31/05/2015 16:12, Enrico Forestieri a écrit :

On Sun, May 31, 2015 at 01:24:05PM +0200, Kornel Benko wrote:


Am Sonntag, 31. Mai 2015 um 00:53:41, schrieb Enrico Forestieri 

commit ad0d0f6d69a7acd6e99f7858f08b427a28d8f8cc
Author: Enrico Forestieri 
Date:   Sun May 31 00:52:49 2015 +0200

 Really fix bug #9354



This is still not working in branch for redefined macros.
(Works in master as implemented by Jürgen)

Try the attached. (The second definition of \qG is different, but the preview
is not changed)


Thanks, should be fixed now.
This has nothing to do with bug 9354, though.



In fact it does not work entirely in master. There is a regression 
(after bc47054b I believe) because compilation can now fail due to 
\renewcommandx being used without the command being defined prior to 
that (try the attached lyx-bug-renewcommandx.lyx). (Stable is fine in 
this regard after your commit 9285f338, it seems.) 



One quick solution would be to prepend all \renewcommandx\a{b} with 
\providecommand\a{}.



Here are other conclusions from my test of stable and master this week-end:

1) b3d2ffc0 introduces a regression in stable and master wrt 2.1.3. See 
the attached lyx-bug-font2.lyx. This is because legacy_lyxpreview2ppm.py 
now includes the font lmodern (L236). I do not understand this addition: 
font setting is already done in the preamble. Removing the line fixes 
the issue.


2) In master, preview incorrectly calls latex instead of pdflatex if the 
default output format is set to "default". More details in the attached 
lyx-bug-microtype.lyx. (It causes the instant preview to fail, while the 
"default" (pdflatex) compilation with Ctrl+R succeeds.)
Stable also fails because it seems to call latex instead of pdflatex all 
the time, but it does not appear to be a regression wrt 2.1.3.


3) As reported in #6369, "InstantPreview multiplies math macros 
definitions". Although the particular compilation issue has been solved, 
the duplication of macro definitions is not fixed. This has performance 
consequences. In stable and master, opening a moderately-sized math 
article (10-20 pages) with instant preview activated results in 75s of 
full CPU usage (and more when latex is called incorrectly instead of 
pdflatex), 55s during which LyX is unresponsive (and just generates the 
tex file). The instant preview tex file is 55 lines long and is 16MB 
big, mainly comprised of macro definitions (maybe there is another 
performance bottleneck, but this is probably one). So instant preview is 
still unusable for me (at least until the instant preview inset supports 
math macros---BTW the patch 
 works well 
for me).


4) Using Ctrl+Mousewheel to zoom sometimes results in a preview of the 
wrong size. LyX recreates the previews when zooming, and sometimes we 
end up with an intermediary size of preview inconsistent with the size 
of the text (race condition?).
(BTW why redoing preview from scratch when the pdf is already generated? 
Why not keeping the each preview as a pdfs, displayed on the fly by LyX 
using Cairo, when actually needed? This sounds vastly more efficient.)


3+4) Zooming with Ctrl+mousewheel is impossible with instant preview 
activated in a reasonably-sized document as a combination of 3) and 4). 
LyX freezes as soon as we touch the mouse wheel. (Both master and 
stable. Regression from 2.1.3. Same suggested solutions as 3 and 4.)


5) I find that the preferences dialog is counter-intuitive, with the 
distinction between Save, Apply and Close. I don't see the point of 
applying without saving (e.g. I think I have disabled instant preview, 
but then I find that it is reactivated the next time I run LyX). To add 
to the wish list of UI improvements...



Thank you, have a nice day.



lyx-bug-renewcommandx.lyx
Description: application/lyx


lyx-bug-font2.lyx
Description: application/lyx


lyx-bug-microtype.lyx
Description: application/lyx

Re: #7896: LyX templates folder is empty

[Stephan Witt]

Am 31.05.2015 um 09:47 schrieb LyX Ticket Tracker :

> #7896: LyX templates folder is empty
> -+
> Reporter:  vicvandijk   |   Owner:  spitz
> Type:  enhancement  |  Status:  new
> Priority:  normal   |   Milestone:  2.3.0
> Component:  dialogs  | Version:  2.0.1
> Severity:  normal   |  Resolution:
> Keywords:  os=macosx|
> -+
> Changes (by spitz):
> 
> * milestone:  2.1.4 => 2.3.0
> 
> 
> Comment:
> 
> OK. Retargeting.
> 
> -- 
> Ticket URL: 
> The LyX Project 
> LyX -- The Document Processor

I don't know if that would be acceptable: one possible solution
is to create a symlink in users template directory and let it
point to the correct location inside the LyX package. I've made
an implementation of this idea and tested it successfully.

It works as long as there is only one LyX package per minor version,
if one uses e.g. 2.1.3 and 2.1.4 in parallel the symlink points to
the package of the last started LyX.

In practice I think it works flawlessly.

Attached is a patch to implement the idea.
Is this an acceptable workaround?

Stephan



0001-ticket-7896.patch
Description: Binary data

Re: 2.2

[Jürgen Spitzmüller]

2015-05-31 19:33 GMT+02:00 Stephan Witt :

> $ ls -l dictionaries/thes/th_en_*.dat
> -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:42
> dictionaries/thes/th_en_AU_v2.dat
> -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:41
> dictionaries/thes/th_en_BS_v2.dat
> -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:42
> dictionaries/thes/th_en_BZ_v2.dat
> -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:42
> dictionaries/thes/th_en_CA_v2.dat
> -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:41
> dictionaries/thes/th_en_GB_v2.dat
> -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:41
> dictionaries/thes/th_en_GH_v2.dat
> -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:42
> dictionaries/thes/th_en_IE_v2.dat
> -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:42
> dictionaries/thes/th_en_IN_v2.dat
> -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:42
> dictionaries/thes/th_en_JM_v2.dat
> -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:41
> dictionaries/thes/th_en_MW_v2.dat
> -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:42
> dictionaries/thes/th_en_NA_v2.dat
> -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:42
> dictionaries/thes/th_en_NZ_v2.dat
> -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:41
> dictionaries/thes/th_en_PH_v2.dat
> -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:41
> dictionaries/thes/th_en_TT_v2.dat
> -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:41
> dictionaries/thes/th_en_US_v2.dat
> -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:42
> dictionaries/thes/th_en_ZA_v2.dat
> -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:42
> dictionaries/thes/th_en_ZW_v2.dat
> $ for d in dictionaries/thes/th_en_*.dat ; do diff -u
> dictionaries/thes/th_en_AU_v2.dat $d ; done | wc
>0   0   0
>
> This costs 17 times 18 MByte space and looks wrong. Are you sure you put
> the right stuff in?
>

Yes, they are identical. However, you only need to ship a small subset of
those. We only support en_AU, en_CA, en_GB, en_US and en_NZ.

Jürgen

Re: #7896: LyX templates folder is empty

[Jean-Marc Lasgouttes]

Le 01/06/2015 09:10, Stephan Witt a écrit :

I don't know if that would be acceptable: one possible solution
is to create a symlink in users template directory and let it
point to the correct location inside the LyX package. I've made
an implementation of this idea and tested it successfully.

It works as long as there is only one LyX package per minor version,
if one uses e.g. 2.1.3 and 2.1.4 in parallel the symlink points to
the package of the last started LyX.


I think that the idea is fine.

JMarc

Re: 2.2

[Stephan Witt]

Am 01.06.2015 um 09:41 schrieb Jürgen Spitzmüller :

> 2015-05-31 19:33 GMT+02:00 Stephan Witt :
> $ ls -l dictionaries/thes/th_en_*.dat
> -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:42 
> dictionaries/thes/th_en_AU_v2.dat
> -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:41 
> dictionaries/thes/th_en_BS_v2.dat
> -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:42 
> dictionaries/thes/th_en_BZ_v2.dat
> -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:42 
> dictionaries/thes/th_en_CA_v2.dat
> -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:41 
> dictionaries/thes/th_en_GB_v2.dat
> -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:41 
> dictionaries/thes/th_en_GH_v2.dat
> -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:42 
> dictionaries/thes/th_en_IE_v2.dat
> -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:42 
> dictionaries/thes/th_en_IN_v2.dat
> -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:42 
> dictionaries/thes/th_en_JM_v2.dat
> -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:41 
> dictionaries/thes/th_en_MW_v2.dat
> -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:42 
> dictionaries/thes/th_en_NA_v2.dat
> -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:42 
> dictionaries/thes/th_en_NZ_v2.dat
> -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:41 
> dictionaries/thes/th_en_PH_v2.dat
> -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:41 
> dictionaries/thes/th_en_TT_v2.dat
> -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:41 
> dictionaries/thes/th_en_US_v2.dat
> -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:42 
> dictionaries/thes/th_en_ZA_v2.dat
> -rw-r--r--  1 stephan  staff  18597793 19 Apr 20:42 
> dictionaries/thes/th_en_ZW_v2.dat
> $ for d in dictionaries/thes/th_en_*.dat ; do diff -u 
> dictionaries/thes/th_en_AU_v2.dat $d ; done | wc
>0   0   0
> 
> This costs 17 times 18 MByte space and looks wrong. Are you sure you put the 
> right stuff in?
> 
> Yes, they are identical. However, you only need to ship a small subset of 
> those. We only support en_AU, en_CA, en_GB, en_US and en_NZ.

But this result in an overhead of appr. 80 MByte :(
Isn't it possible to create some alias mechanism?

Stephan

Re: 2.2

[Jürgen Spitzmüller]

2015-06-01 10:45 GMT+02:00 Stephan Witt :

> But this result in an overhead of appr. 80 MByte :(
> Isn't it possible to create some alias mechanism?
>

On Linux and Mac, you can certainly also use symlinks. Don't know about
Windows.

(In fact, these files _are_ symlinked to one th_en_US in the package I used
as source)

Jürgen


>
> Stephan

Re: 2.2

[Jean-Marc Lasgouttes]

Le 01/06/2015 10:57, Jürgen Spitzmüller a écrit :

2015-06-01 10:45 GMT+02:00 Stephan Witt >:

But this result in an overhead of appr. 80 MByte :(
Isn't it possible to create some alias mechanism?


On Linux and Mac, you can certainly also use symlinks. Don't know about
Windows.

(In fact, these files _are_ symlinked to one th_en_US in the package I
used as source)


And what about shipping one and naming it th_en_v2.dat? I am sure we can 
work out a naming scheme that does what we want? Or name the thesaurus 
to use in the language file.


JMarc

Re: 2.2

[Jürgen Spitzmüller]

2015-06-01 11:04 GMT+02:00 Jean-Marc Lasgouttes :

> And what about shipping one and naming it th_en_v2.dat? I am sure we can
> work out a naming scheme that does what we want?
>

Yes, that would be an option.

Jürgen


>
> JMarc
>

Re: #7896: LyX templates folder is empty

[Scott Kostyshak]

On Mon, Jun 1, 2015 at 4:09 AM, Jean-Marc Lasgouttes  wrote:
> Le 01/06/2015 09:10, Stephan Witt a écrit :
>>
>> I don't know if that would be acceptable: one possible solution
>> is to create a symlink in users template directory and let it
>> point to the correct location inside the LyX package. I've made
>> an implementation of this idea and tested it successfully.
>>
>> It works as long as there is only one LyX package per minor version,
>> if one uses e.g. 2.1.3 and 2.1.4 in parallel the symlink points to
>> the package of the last started LyX.
>
>
> I think that the idea is fine.

Should the caveat be documented in INSTALL.MacOSX?

Scott

Re: test of math previews

[Jean-Marc Lasgouttes]

Le 01/06/2015 08:26, Guillaume M-M a écrit :

5) I find that the preferences dialog is counter-intuitive, with the
distinction between Save, Apply and Close. I don't see the point of
applying without saving (e.g. I think I have disabled instant preview,
but then I find that it is reactivated the next time I run LyX). To add
to the wish list of UI improvements...


I second that personally. I know of no other software that has this 
behavior. But it is less confusing than the bizarre converters UI (also, 
I am not sure how to make it sane).


JMarc

Re: test of math previews (was: [LyX/master] Really fix bug #9354)

[Enrico Forestieri]

On Mon, Jun 01, 2015 at 07:26:55AM +0100, Guillaume M-M wrote:
> 
> In fact it does not work entirely in master. There is a regression (after
> bc47054b I believe) because compilation can now fail due to \renewcommandx
> being used without the command being defined prior to that (try the attached
> lyx-bug-renewcommandx.lyx). (Stable is fine in this regard after your commit
> 9285f338, it seems.) 
> 
> One quick solution would be to prepend all \renewcommandx\a{b} with
> \providecommand\a{}.

I think this was already addressed by Jürgen at 83a9ed4e.

> Here are other conclusions from my test of stable and master this week-end:
> 
> 1) b3d2ffc0 introduces a regression in stable and master wrt 2.1.3. See the
> attached lyx-bug-font2.lyx. This is because legacy_lyxpreview2ppm.py now
> includes the font lmodern (L236). I do not understand this addition: font
> setting is already done in the preamble. Removing the line fixes the issue.

It was added in order to have vector fonts, otherwise the previews
generated by the legacy method would be of very poor quality. It is
difficult to determine what a user could do in the preamble and whether
it is safe using lmodern or not. However, given that it may produce issues,
it may be better not using it, if nobody has a better idea.

> 2) In master, preview incorrectly calls latex instead of pdflatex if the
> default output format is set to "default". More details in the attached
> lyx-bug-microtype.lyx. (It causes the instant preview to fail, while the
> "default" (pdflatex) compilation with Ctrl+R succeeds.)
> Stable also fails because it seems to call latex instead of pdflatex all the
> time, but it does not appear to be a regression wrt 2.1.3.

Note that we have to guarantee backward compatibility and using latex
when the document does not specify a default output format is a must,
otherwise instant preview may fail for existing documents.
See #9371 for details.

When using pdflatex (or other formats producing a pdf) for generating
the previews, the legacy method is used. It turns out to be much slower
than the dvipng route, so that care is taken to try to use dvi output for
all previews not failing and then trying pdflatex for those that fail.
For some reason, the failure you report escapes those checks. So, this
reason should be identified and accordingly corrected. Typically, in
open source projects one can suggest a patch to speed up the correction
of an issue.

> 3) As reported in #6369, "InstantPreview multiplies math macros
> definitions". Although the particular compilation issue has been solved, the
> duplication of macro definitions is not fixed. This has performance
> consequences. In stable and master, opening a moderately-sized math article
> (10-20 pages) with instant preview activated results in 75s of full CPU
> usage (and more when latex is called incorrectly instead of pdflatex), 55s
> during which LyX is unresponsive (and just generates the tex file). The
> instant preview tex file is 55 lines long and is 16MB big, mainly
> comprised of macro definitions (maybe there is another performance
> bottleneck, but this is probably one). So instant preview is still unusable
> for me (at least until the instant preview inset supports math macros---BTW
> the patch  works
> well for me).

This is not my experience. Instant preview snippets for the math manual
(which surely qualifies as a medium-sized math article) are generated in
about 10 seconds on my old and slow laptop and the instant preview tex
file is about 50Kb.

> 4) Using Ctrl+Mousewheel to zoom sometimes results in a preview of the wrong
> size. LyX recreates the previews when zooming, and sometimes we end up with
> an intermediary size of preview inconsistent with the size of the text (race
> condition?).

The previous are generated asynchronously, thus, if you change the zoom while
they are still being generated, you may end up with different sizes. This
can be improved, of course. Maybe using Ctrl+Mousewheel may generate
multiple sizes at once and this causes that issue. Try using the Alt+ and
Alt- shortcuts (and wait for the previews to be generated before using
them again).

> (BTW why redoing preview from scratch when the pdf is already generated? Why
> not keeping the each preview as a pdfs, displayed on the fly by LyX using
> Cairo, when actually needed? This sounds vastly more efficient.)

There is the problem of assuring that the previews are still the same and
not actually changed. ATM there is no way to trigger a different way for
the regeneration due to zooming. Also in this case, I think that a patch
would be thoughtfully considered, but I doubt it can lead to a significant
speed up, as the most part of the time is spent in converting the pdfs
rather than regenerating them.

> 3+4) Zooming with Ctrl+mousewheel is impossible with instant preview
> activated in a reasonably-sized document 

Re: 2.2

[Jürgen Spitzmüller]

2015-06-01 11:23 GMT+02:00 Jürgen Spitzmüller :

> 2015-06-01 11:04 GMT+02:00 Jean-Marc Lasgouttes :
>
>> And what about shipping one and naming it th_en_v2.dat? I am sure we can
>> work out a naming scheme that does what we want?
>>
>
> Yes, that would be an option.
>

For example via the attached patch.

Jürgen



>
> Jürgen
>
>
>>
>> JMarc
>>
>
>
diff --git a/src/Thesaurus.cpp b/src/Thesaurus.cpp
index b4655ac..4f4ad64 100644
--- a/src/Thesaurus.cpp
+++ b/src/Thesaurus.cpp
@@ -107,6 +107,11 @@ pair 
Thesaurus::Private::getThesaurus(string const & path, docstr
for (FileNameList::const_iterator it = idx_files.begin(); it != 
idx_files.end(); ++it) {
basename = it->onlyFileNameWithoutExt();
if (contains(basename, to_ascii(lang))) {
+   // do not use more specific dicts.
+   if (contains(basename, '_') && !contains(lang, '_'))
+   continue;
+   if (contains(basename, '-') && !contains(lang, '-'))
+   continue;
ifstream ifs(it->absFileName().c_str());
if (ifs) {
// check for appropriate version of index file
@@ -128,8 +133,23 @@ pair 
Thesaurus::Private::getThesaurus(string const & path, docstr
break;
}
}
-   if (idx.empty())
+   if (idx.empty()) {
+   // try with a more general dictionary
+   docstring shortcode;
+   if (contains(lang, '_')) {
+   split(lang, shortcode, '_');
+   LYXERR(Debug::FILES, "Did not find thesaurus for LANG 
code "
+  << lang << ". Trying with " << shortcode);
+   return getThesaurus(path, shortcode);
+   }
+   else if (contains(lang, '-')) {
+   split(lang, shortcode, '-');
+   LYXERR(Debug::FILES, "Did not find thesaurus for LANG 
code "
+  << lang << ". Trying with " << shortcode);
+   return getThesaurus(path, shortcode);
+   }
return make_pair(string(), string());
+   }
for (support::FileNameList::const_iterator it = data_files.begin(); it 
!= data_files.end(); ++it) {
if (contains(it->onlyFileName(), basename)) {
data = it->absFileName();

Re: 2.2

[Jürgen Spitzmüller]

2015-06-01 16:46 GMT+02:00 Jean-Marc Lasgouttes :

> Yes, for example. The approach seems a bit complicated to me, but since I
> do not have a brilliant regex-based solution in mind right now, I assume
> you got the best possible solution.
>

Actually, I tried with different regexes until I was fed up and went with
this.

Jürgen


>
> JMarc
>

Re: 2.2

[Jean-Marc Lasgouttes]

Le 01/06/2015 16:09, Jürgen Spitzmüller a écrit :

For example via the attached patch.


Yes, for example. The approach seems a bit complicated to me, but since 
I do not have a brilliant regex-based solution in mind right now, I 
assume you got the best possible solution.


JMarc

Re: 2.2

[Kornel Benko]

Am Montag, 1. Juni 2015 um 16:52:43, schrieb Jürgen Spitzmüller 
> 2015-06-01 16:46 GMT+02:00 Jean-Marc Lasgouttes :
> 
> > Yes, for example. The approach seems a bit complicated to me, but since I
> > do not have a brilliant regex-based solution in mind right now, I assume
> > you got the best possible solution.
> >
> 
> Actually, I tried with different regexes until I was fed up and went with
> this.
> 
> Jürgen
> 
> 
> >
> > JMarc

On ubuntu there _are_ differences between th_en_US_v2.dat and th_en_AU_v2.idx.
# ls -l /usr/share/mythes/th_en*.dat
-rw-r--r-- 1 root root 18545141 máj 27  2013 
/usr/share/mythes/th_en_AU_v2.dat
-rw-r--r-- 1 root root 18597793 sep 23  2014 
/usr/share/mythes/th_en_US_v2.dat

The appropriate packages are mythes-en-au, mythes-en-us.
So setting them equal does not seem OK without concern.

Kornel


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

Re: 2.2

[Jürgen Spitzmüller]

2015-06-01 17:19 GMT+02:00 Kornel Benko :

> On ubuntu there _are_ differences between th_en_US_v2.dat and
> th_en_AU_v2.idx.
> # ls -l /usr/share/mythes/th_en*.dat
> -rw-r--r-- 1 root root 18545141 máj 27  2013
> /usr/share/mythes/th_en_AU_v2.dat
> -rw-r--r-- 1 root root 18597793 sep 23  2014
> /usr/share/mythes/th_en_US_v2.dat
>
> The appropriate packages are mythes-en-au, mythes-en-us.
> So setting them equal does not seem OK without concern.
>

We only fall back if

1.) no specific dictionary for the given LANG code (such as the_en_AU) is
available
2.) if there is a _general_ dictionary (th_en, _not_ the_en_US or similar)
available

So dictionaries would only be treated as equal if we explicitly qualify
them as such.

Jürgen


>
> Kornel
>

Re: test of math previews (was: [LyX/master] Really fix bug #9354)

[Enrico Forestieri]

On Mon, Jun 01, 2015 at 03:50:49PM +0200, Enrico Forestieri wrote:
> On Mon, Jun 01, 2015 at 07:26:55AM +0100, Guillaume M-M wrote:
> > 
> > 2) In master, preview incorrectly calls latex instead of pdflatex if the
> > default output format is set to "default". More details in the attached
> > lyx-bug-microtype.lyx. (It causes the instant preview to fail, while the
> > "default" (pdflatex) compilation with Ctrl+R succeeds.)
> > Stable also fails because it seems to call latex instead of pdflatex all the
> > time, but it does not appear to be a regression wrt 2.1.3.
> 
> Note that we have to guarantee backward compatibility and using latex
> when the document does not specify a default output format is a must,
> otherwise instant preview may fail for existing documents.
> See #9371 for details.
> 
> When using pdflatex (or other formats producing a pdf) for generating
> the previews, the legacy method is used. It turns out to be much slower
> than the dvipng route, so that care is taken to try to use dvi output for
> all previews not failing and then trying pdflatex for those that fail.
> For some reason, the failure you report escapes those checks. So, this
> reason should be identified and accordingly corrected. Typically, in
> open source projects one can suggest a patch to speed up the correction
> of an issue.

I had a closer look at this issue and it turned out to be as follows.
If a snippet produces latex errors it is now not previewed at all.
Now, when using the microtype package in dvi mode, latex issues an
error about not finding the tfm file for a font, but nevertheless
goes on and produces a correct output. This error is issued only at
the beginning so that it associated with the first snippet, which is
for this reason marked as bad. Actually, the script generates a valid
preview but it is not used. All other snippets are used, so only the
first one is omitted even if it would be Ok.

There are 2 possible solutions. The first one is omitting the microtype
package for the sake of generating the previews by using the faster
dvipng method (attached patch no-microtype.diff for master).
The second one is forcing the use of pdflatex when the use of microtype
is detected. In this case the slower legacy mathod will be used for
generating the previews (attached patch yes-microtype.diff for master).

Please, vote for the one or the other. I will commit the patch getting
more votes.

I also noticed that when microtype is used in dvi mode latex takes a
lot more of time to process the same file. Maybe this is the cause of
the slowdown observed by Guillaume.

-- 
Enrico
diff --git a/lib/scripts/lyxpreview2bitmap.py b/lib/scripts/lyxpreview2bitmap.py
index 5eca959..9d46054 100755
--- a/lib/scripts/lyxpreview2bitmap.py
+++ b/lib/scripts/lyxpreview2bitmap.py
@@ -160,11 +160,17 @@ def extract_metrics_info(dvipng_stdout):
 
 def fix_latex_file(latex_file):
 documentclass_re = re.compile("(documentclass\[)(1[012]pt,?)(.+)")
+microtype_re = re.compile("usepackage.*\{microtype\}")
 
 tmp = mkstemp()
 
 changed = 0
 for line in open(latex_file, 'r').readlines():
+match = microtype_re.match(line)
+if match != None:
+changed = 1
+continue
+
 match = documentclass_re.match(line)
 if match == None:
 tmp.write(line)
diff --git a/lib/scripts/lyxpreview2bitmap.py b/lib/scripts/lyxpreview2bitmap.py
index 5eca959..3aec16f 100755
--- a/lib/scripts/lyxpreview2bitmap.py
+++ b/lib/scripts/lyxpreview2bitmap.py
@@ -160,11 +160,17 @@ def extract_metrics_info(dvipng_stdout):
 
 def fix_latex_file(latex_file):
 documentclass_re = re.compile("(documentclass\[)(1[012]pt,?)(.+)")
+microtype_re = re.compile("usepackage.*\{microtype\}")
 
 tmp = mkstemp()
 
+force_pdf_output = 0
 changed = 0
 for line in open(latex_file, 'r').readlines():
+match = microtype_re.match(line)
+if match != None:
+force_pdf_output = 1
+
 match = documentclass_re.match(line)
 if match == None:
 tmp.write(line)
@@ -176,7 +182,7 @@ def fix_latex_file(latex_file):
 if changed:
 copyfileobj(tmp, open(latex_file,"wb"), 1)
 
-return changed
+return force_pdf_output
 
 
 def convert_to_ppm_format(pngtopnm, basename):
@@ -384,6 +390,12 @@ def main(argv):
 # These flavors of latex are known to produce pdf output
 pdf_output = latex in pdflatex_commands
 
+# Omit font size specification in latex file.
+force_pdf_output = fix_latex_file(latex_file)
+if force_pdf_output and not pdf_output:
+pdf_output = True
+latex = "pdflatex"
+
 progress("Latex command: %s" % latex)
 progress("Latex produces pdf output: %s" % pdf_output)
 progress("Bibtex command: %s" % bibtex)
@@ -391,10 +403,6 @@ def main(argv):
 progress("Preprocess through lilypond-book: %s" % lilypond)
 progress("Altering the latex file for font size and colors")
 

Re: test of math previews (was: [LyX/master] Really fix bug #9354)

[Enrico Forestieri]

On Mon, Jun 01, 2015 at 03:50:49PM +0200, Enrico Forestieri wrote:
> On Mon, Jun 01, 2015 at 07:26:55AM +0100, Guillaume M-M wrote:
> > 
> > 1) b3d2ffc0 introduces a regression in stable and master wrt 2.1.3. See the
> > attached lyx-bug-font2.lyx. This is because legacy_lyxpreview2ppm.py now
> > includes the font lmodern (L236). I do not understand this addition: font
> > setting is already done in the preamble. Removing the line fixes the issue.
> 
> It was added in order to have vector fonts, otherwise the previews
> generated by the legacy method would be of very poor quality. It is
> difficult to determine what a user could do in the preamble and whether
> it is safe using lmodern or not. However, given that it may produce issues,
> it may be better not using it, if nobody has a better idea.

Jürgen, any idea on this one?

-- 
Enrico

Re: 2.2

[Georg Baum]

Jürgen Spitzmüller wrote:

> On Linux and Mac, you can certainly also use symlinks. Don't know about
> Windows.

Some time ago I learned that the NTFS file system used on all modern windows 
versions supports true symlinks as well (I am not talking about the .lnk 
substitute). If the installer can generate them, then they could be used on 
windows as well.


Georg

Re: test of math previews (was: [LyX/master] Really fix bug #9354)

[Jürgen Spitzmüller]

2015-06-01 19:34 GMT+02:00 Enrico Forestieri :

> On Mon, Jun 01, 2015 at 03:50:49PM +0200, Enrico Forestieri wrote:
> > On Mon, Jun 01, 2015 at 07:26:55AM +0100, Guillaume M-M wrote:
> > >
> > > 1) b3d2ffc0 introduces a regression in stable and master wrt 2.1.3.
> See the
> > > attached lyx-bug-font2.lyx. This is because legacy_lyxpreview2ppm.py
> now
> > > includes the font lmodern (L236). I do not understand this addition:
> font
> > > setting is already done in the preamble. Removing the line fixes the
> issue.
> >
> > It was added in order to have vector fonts, otherwise the previews
> > generated by the legacy method would be of very poor quality. It is
> > difficult to determine what a user could do in the preamble and whether
> > it is safe using lmodern or not. However, given that it may produce
> issues,
> > it may be better not using it, if nobody has a better idea.
>
> Jürgen, any idea on this one?
>

lmodern must only be loaded if no other font has been loaded, i.e. if
computer modern is the active font:

\def\tempa{cmr}

\ifx\f@family\tempa\usepackage{lmodern}\else\fi

Jürgen

Re: test of math previews

[Guillaume M-M]

Le 01/06/2015 18:16, Enrico Forestieri a écrit :

On Mon, Jun 01, 2015 at 03:50:49PM +0200, Enrico Forestieri wrote:

On Mon, Jun 01, 2015 at 07:26:55AM +0100, Guillaume M-M wrote:


2) In master, preview incorrectly calls latex instead of pdflatex if the
default output format is set to "default". More details in the attached
lyx-bug-microtype.lyx. (It causes the instant preview to fail, while the
"default" (pdflatex) compilation with Ctrl+R succeeds.)
Stable also fails because it seems to call latex instead of pdflatex all the
time, but it does not appear to be a regression wrt 2.1.3.


Note that we have to guarantee backward compatibility and using latex
when the document does not specify a default output format is a must,
otherwise instant preview may fail for existing documents.
See #9371 for details.

When using pdflatex (or other formats producing a pdf) for generating
the previews, the legacy method is used. It turns out to be much slower
than the dvipng route, so that care is taken to try to use dvi output for
all previews not failing and then trying pdflatex for those that fail.
For some reason, the failure you report escapes those checks. So, this
reason should be identified and accordingly corrected. Typically, in
open source projects one can suggest a patch to speed up the correction
of an issue.


I had a closer look at this issue and it turned out to be as follows.
If a snippet produces latex errors it is now not previewed at all.
Now, when using the microtype package in dvi mode, latex issues an
error about not finding the tfm file for a font, but nevertheless
goes on and produces a correct output. This error is issued only at
the beginning so that it associated with the first snippet, which is
for this reason marked as bad. Actually, the script generates a valid
preview but it is not used. All other snippets are used, so only the
first one is omitted even if it would be Ok.

There are 2 possible solutions. The first one is omitting the microtype
package for the sake of generating the previews by using the faster
dvipng method (attached patch no-microtype.diff for master).
The second one is forcing the use of pdflatex when the use of microtype
is detected. In this case the slower legacy mathod will be used for
generating the previews (attached patch yes-microtype.diff for master).

Please, vote for the one or the other. I will commit the patch getting
more votes.


I do not think that treating microtype as a special case is the way to 
go. First, the issue is with the option "expansion=true". Without this 
option, microtype correctly works with latex and correctly activates 
expansion with pdflatex.


This was more to illustrate the fact that it is a great new feature in 
master to compile the previews using the default output format because 
of many small details like this error. For instance, although this seems 
easy to fix now that I understood the issue (just remove the option 
expansion=true, or set the default output format to pdflatex) it really 
took me a while to figure this out (partly because it is hard to access 
the error messages for the instant preview).


As I described, I think the issue is regarding the meaning of "Default 
output format: Default". For the Ctrl+R shortcut, this means pdflatex 
while for instant preview this means latex. I don't understand the 
backwards-compatibility argument here, I think that it is safer to use 
the same default format as Ctrl+R in all cases.


This looks like a small detail, but for a general user, setting 
explicitly "default output format: PDF (pdflatex)" does not appear as an 
obvious solution to "instant preview does not work". And the error can 
always be more fatal than this error with microtype.


IF the inconsistency regarding the meaning of "Default output format: 
Default" is intended for performance reason and that I did not make you 
change your mind, then I vote for:

> omitting the microtype
> package for the sake of generating the previews by using the faster
> dvipng method
But again it is hard to guess that "default output format: default" has 
this optimisation while "default output format: PDF (pdflatex)" does 
not. (But at least there is the option to force the use of pdflatex by 
instant preview if really needed.)


By the way, a safer way to force not loading a package is to prepend 
\usepackage with "\@namedef{v...@microtype.sty}{/12/31}". If you just 
strip the line from the preamble you can easily run into troubles. In 
addition, at some point I had it on two lines like this (note the %):

  \usepackage[protrusion=true%,expansion=false
  ]{microtype}
in which case your regexp fails if I understood correctly. I suggest 
just adding "\@namedef{v...@microtype.sty}{/12/31}" before the 
preamble whether we suspect that microtype is used or not, without 
testing for its presence. (Unless you see other errors this might generate.)


Again the philosophy of my comment is not "please deal explicitly with 
these 

Re: test of math previews

[Guillaume M-M]

Le 01/06/2015 19:50, Jürgen Spitzmüller a écrit :

2015-06-01 19:34 GMT+02:00 Enrico Forestieri >:

On Mon, Jun 01, 2015 at 03:50:49PM +0200, Enrico Forestieri wrote:
> On Mon, Jun 01, 2015 at 07:26:55AM +0100, Guillaume M-M wrote:
> >
> > 1) b3d2ffc0 introduces a regression in stable and master wrt 2.1.3. See 
the
> > attached lyx-bug-font2.lyx. This is because legacy_lyxpreview2ppm.py now
> > includes the font lmodern (L236). I do not understand this addition: 
font
> > setting is already done in the preamble. Removing the line fixes the 
issue.
>
> It was added in order to have vector fonts, otherwise the previews
> generated by the legacy method would be of very poor quality. It is
> difficult to determine what a user could do in the preamble and whether
> it is safe using lmodern or not. However, given that it may produce 
issues,
> it may be better not using it, if nobody has a better idea.

Jürgen, any idea on this one?


lmodern must only be loaded if no other font has been loaded, i.e. if
computer modern is the active font:

\def\tempa{cmr}

\ifx\f@family\tempa\usepackage{lmodern}\else\fi


Jürgen




Is there any lyx file demonstrating the poor font quality? I have been 
unable to reproduce the font issue in master (after removing the line 
that forces latin modern in instant previews), even with the default 
setting of LyX that produces a PDF with bitmap fonts...


Anyway, here's a suggestion for getting those horrible bitmap fonts out 
of the way of new users, in a perfectly non-intrusive and 
backwards-compatible manner: just set Latin Modern to be the default 
choice for a new document. This would also solve the issue considered 
above. Note that I don't suggest to change the meaning of "Default" for 
roman fonts, but rather to force the user explicitly select "Default" 
over "Latin Modern" if he really wants to. I think it is always good 
when LyX shows the standard way. Then if the user wants poor bitmap 
fonts, that will be by choice.


(I know that I may suggest patches instead of ideas, but I do not have 
much time currently to become a new contributor to LyX, although I have 
been considering it.)

Re: test of math previews

[Enrico Forestieri]

On Mon, Jun 01, 2015 at 08:07:11PM +0100, Guillaume M-M wrote:

> I don't understand the
> backwards-compatibility argument here, I think that it is safer to use the
> same default format as Ctrl+R in all cases.

I think that the backward-compatibility argument is a serious one.
If an old document that was perfectly working does not work anymore,
one could simply decide that LyX is not the right tool to use and it
is safer using latex directly.

-- 
Enrico

Re: test of math previews

[Guillaume M-M]

Le 01/06/2015 21:16, Guillaume M-M a écrit :

Le 01/06/2015 19:50, Jürgen Spitzmüller a écrit :

2015-06-01 19:34 GMT+02:00 Enrico Forestieri >:

On Mon, Jun 01, 2015 at 03:50:49PM +0200, Enrico Forestieri wrote:
> On Mon, Jun 01, 2015 at 07:26:55AM +0100, Guillaume M-M wrote:
> >
> > 1) b3d2ffc0 introduces a regression in stable and master wrt
2.1.3. See the
> > attached lyx-bug-font2.lyx. This is because
legacy_lyxpreview2ppm.py now
> > includes the font lmodern (L236). I do not understand this
addition: font
> > setting is already done in the preamble. Removing the line
fixes the issue.
>
> It was added in order to have vector fonts, otherwise the previews
> generated by the legacy method would be of very poor quality. It is
> difficult to determine what a user could do in the preamble and
whether
> it is safe using lmodern or not. However, given that it may
produce issues,
> it may be better not using it, if nobody has a better idea.

Jürgen, any idea on this one?


lmodern must only be loaded if no other font has been loaded, i.e. if
computer modern is the active font:

\def\tempa{cmr}

\ifx\f@family\tempa\usepackage{lmodern}\else\fi


Jürgen




Is there any lyx file demonstrating the poor font quality? I have been
unable to reproduce the font issue in master (after removing the line
that forces latin modern in instant previews), even with the default
setting of LyX that produces a PDF with bitmap fonts...

Anyway, here's a suggestion for getting those horrible bitmap fonts out
of the way of new users, in a perfectly non-intrusive and
backwards-compatible manner: just set Latin Modern to be the default
choice for a new document. This would also solve the issue considered
above. Note that I don't suggest to change the meaning of "Default" for
roman fonts, but rather to force the user explicitly select "Default"
over "Latin Modern" if he really wants to. I think it is always good
when LyX shows the standard way. Then if the user wants poor bitmap
fonts, that will be by choice.



I am aware that it is less simple than it sounds given that often the 
user wants to switch to a document class that already has more sensible 
defaults. I will open an enhancement request if I figure out a solution, 
but I'd be happy to know whether something like this was already 
discussed on the list.

Re: test of math previews

[Enrico Forestieri]

On Mon, Jun 01, 2015 at 09:16:00PM +0100, Guillaume M-M wrote:
> 
> Is there any lyx file demonstrating the poor font quality? I have been
> unable to reproduce the font issue in master (after removing the line that
> forces latin modern in instant previews), even with the default setting of
> LyX that produces a PDF with bitmap fonts...

I attach here the pdfs I get with a new document with default output set to
pdflatex and simply an 'a' in a preview inset.
The first one (lyxpreviewdCv436.pdf) when I ditch the lmodern line, the
second one (lyxpreviewxWL436.pdf) with that line in place. The previews
are then generated by converting the pdfs into pngs.
Here you can also find how the difference looks like on screen:
http://www.lyx.org/trac/attachment/ticket/9371/example-2.1.png (good)
http://www.lyx.org/trac/attachment/ticket/9371/example-2.2.png (bad)

-- 
Enrico


lyxpreviewdCv436.pdf
Description: Adobe PDF document


lyxpreviewxWL436.pdf
Description: Adobe PDF document

Re: configure.py questions

[Uwe Stöhr]

While we are at it: during my research I read several times that the 
program "Pandoc" produces nice results for TeX documents and that it can 
handle BibTeX. So maybe we should add support for Pandoc to configure.py.


If you agree I open an enhancement request (don't have time to implement 
this at the moment).


regards Uwe

Re: Merging features/fix-tex2lyx-tests to master

[Uwe Stöhr]

Am 31.05.2015 um 19:06 schrieb Uwe Stöhr:


This might be a tex2lyx bug as well, depending how the reference was
created. This is not in 1) since I can reproduce the results in 1) with
current tex2lyx but not this one. Uwe, how did you create the reference
which does not contain the external inset? Did you copy the .tex file
somehwere else, or was it in the git tree?


Hi Georg,

I now find out how I managed to change this:
I executed this command:

tex2lyx -f -roundtrip test-insets.tex

This leads to a lyx.lyx file with the new inset. Attached is the diff I get.

regards Uwe
diff --git 
"a/C:\\Users\\Usti\\AppData\\Local\\Temp\\TortoiseGit\\tesC832.tmp\\test-insets.lyx-945a348-left.lyx"
 "b/D:\\LyXGit\\Master\\src\\tex2lyx\\test\\test-insets.lyx.lyx"
index 23a82b7..d312958 100644
--- 
"a/C:\\Users\\Usti\\AppData\\Local\\Temp\\TortoiseGit\\tesC832.tmp\\test-insets.lyx-945a348-left.lyx"
+++ "b/D:\\LyXGit\\Master\\src\\tex2lyx\\test\\test-insets.lyx.lyx"
@@ -759,7 +759,7 @@ We can input files too, like this
 \begin_inset CommandInset include
 LatexCommand input
 preview false
-filename "DummyDocument.lyx.lyx"
+filename "DummyDocument"
 
 \end_inset
 
@@ -783,7 +783,7 @@ filename "Dummy Document.tex"
 \begin_inset CommandInset include
 LatexCommand include
 preview false
-filename "Dummy~Document.lyx.lyx"
+filename "Dummy~Document"
 
 \end_inset
 
@@ -791,7 +791,7 @@ filename "Dummy~Document.lyx.lyx"
 \begin_inset CommandInset include
 LatexCommand include
 preview false
-filename "Dummy~Document.lyx.lyx"
+filename "Dummy~Document.tex"
 
 \end_inset
 
@@ -842,9 +842,10 @@ XFig drawings:
 
 \begin_layout Standard
 
-\begin_inset External
-   template XFig
-   filename xfigtest.fig
+\begin_inset CommandInset include
+LatexCommand input
+preview false
+filename "xfigtest.pstex_t"
 
 \end_inset
 
@@ -3100,12 +3101,12 @@ status collapsed
 \begin_layout Plain Layout
 
 \backslash
-raggedleft
+raggedleft 
 \end_layout
 
 \end_inset
 
- This last column is a 
+This last column is a 
 \begin_inset Quotes eld
 \end_inset
 
@@ -4493,7 +4494,7 @@ status collapsed
 \begin_layout Plain Layout
 
 \backslash
-centering
+centering 
 \end_layout
 
 \end_inset

RFC: How to output multicolumn with fixed width and decimal-separator-alignment

[Uwe Stöhr]

Dear LyXers,

in http://www.lyx.org/trac/ticket/9568 Jürgen an I had a discussion how 
to output multicolumn with  fixed width and decimal-separator-alignment. 
There are 3 possible outputs, see the attached PDF. Note that for all 3 
cases the column width is set to "4cm" in LyX.


The question is which output (left, center or right) you personally prefer.

many thanks in advance and regards
Uwe


AlignmentComparison.pdf
Description: Adobe PDF document

Re: test of math previews

[Guillaume M-M]

Le 01/06/2015 22:12, Enrico Forestieri a écrit :

On Mon, Jun 01, 2015 at 08:07:11PM +0100, Guillaume M-M wrote:


I don't understand the
backwards-compatibility argument here, I think that it is safer to use the
same default format as Ctrl+R in all cases.


I think that the backward-compatibility argument is a serious one.
If an old document that was perfectly working does not work anymore,
one could simply decide that LyX is not the right tool to use and it
is safer using latex directly.




I know the importance of backwards compatibility, but I don't understand 
how it applies here.


Currently in stable:
* With default format output = Default
  * Ctrl+R -> pdflatex
  * Instant preview -> latex
* With default format output = PDF (pdflatex)
  * Ctrl+R -> pdflatex
  * Instant preview -> latex

Whereas in master:
* With default format output = Default
  * Ctrl+R -> pdflatex
  * Instant preview -> latex
* With default format output = PDF (pdflatex)
  * Ctrl+R -> pdflatex
  * Instant preview -> pdflatex

Thus, if changing the behaviour of instant preview for "Default" means 
breaking backwards compatibility, then backwards compatibility is 
already broken in master given that the behaviour is changed for "PDF 
(pdflatex)". We don't appear to believe that. This is what I meant.


But I am receptive to your idea of keeping latex for the speedup and 
disabling microtype, for the same speed reason. I like the idea of still 
having the choice via "default output format" (even though the feature 
will be kind of hidden).


Le 01/06/2015 22:20, Enrico Forestieri a écrit :


I attach here the pdfs I get with a new document with default output set to
pdflatex and simply an 'a' in a preview inset.
The first one (lyxpreviewdCv436.pdf) when I ditch the lmodern line, the
second one (lyxpreviewxWL436.pdf) with that line in place. The previews
are then generated by converting the pdfs into pngs.
Here you can also find how the difference looks like on screen:
http://www.lyx.org/trac/attachment/ticket/9371/example-2.1.png (good)
http://www.lyx.org/trac/attachment/ticket/9371/example-2.2.png (bad)


Sorry for the false alarm, I can indeed reproduce with these 
explanations. However this is consistent with the document settings: 
lmodern should indeed not be loaded if the fonts have already been set 
properly, as suggested by Jürgen.


Thank you

Re: test of math previews

[Enrico Forestieri]

On Mon, Jun 01, 2015 at 08:07:11PM +0100, Guillaume M-M wrote:
> 
> IF the inconsistency regarding the meaning of "Default output format:
> Default" is intended for performance reason and that I did not make you
> change your mind, then I vote for:
> > omitting the microtype
> > package for the sake of generating the previews by using the faster
> > dvipng method

Ok, noted.

> But again it is hard to guess that "default output format: default" has this
> optimisation while "default output format: PDF (pdflatex)" does not. (But at
> least there is the option to force the use of pdflatex by instant preview if
> really needed.)

While in principle I agree that generating the previews with the same
engine is the right thing to do, there is the problem that dvipng is
really fast while generating pngs from pdfs is much slower. If you take
away pdftocairo and then try the legacy route, you will see that it is
about 10 times slower. With pdftocairo it is only about 3 times slower.
If you are concerned about speed, I see no other way to allow a decent
implementation of instant previews.

> By the way, a safer way to force not loading a package is to prepend
> \usepackage with "\@namedef{v...@microtype.sty}{/12/31}". If you just
> strip the line from the preamble you can easily run into troubles. In
> addition, at some point I had it on two lines like this (note the %):
>   \usepackage[protrusion=true%,expansion=false
>   ]{microtype}
> in which case your regexp fails if I understood correctly. I suggest just
> adding "\@namedef{v...@microtype.sty}{/12/31}" before the preamble
> whether we suspect that microtype is used or not, without testing for its
> presence. (Unless you see other errors this might generate.)

Ok, thanks for the tip.

> Again the philosophy of my comment is not "please deal explicitly with these
> corner cases" but "it's better to take the safe route".

But you show a problem with a corner case and the safe route may be costly.

> I really like the direction of the new patches trying to make instant
> preview "just work", I hope that my tests and comments help you in this
> regard.

Yes, thank you, that's really appreciated.

> You may be right that microtype may have been the reason why I had the
> impression that latex is slower than pdflatex, but this does not account for
> the 55s (on a good computer) during which LyX is frozen while generating the
> 16MB tex file. I will run tests again to confirm (and also test the new
> patch) and will reply to the previous message in a short while. (BTW yes I
> have epstopdf and pdfcairo.)

Here we are not going anywhere. I say it works well for me, while you say it
doesn't work. Please, provide an example that generates a 16MB tex file for
a ~20 page document.

-- 
Enrico

Re: test of math previews

[Enrico Forestieri]

On Mon, Jun 01, 2015 at 11:01:48PM +0100, Guillaume M-M wrote:

> Le 01/06/2015 22:12, Enrico Forestieri a écrit :
> >On Mon, Jun 01, 2015 at 08:07:11PM +0100, Guillaume M-M wrote:
> >
> >>I don't understand the
> >>backwards-compatibility argument here, I think that it is safer to use the
> >>same default format as Ctrl+R in all cases.
> >
> >I think that the backward-compatibility argument is a serious one.
> >If an old document that was perfectly working does not work anymore,
> >one could simply decide that LyX is not the right tool to use and it
> >is safer using latex directly.
> >
> 
> 
> I know the importance of backwards compatibility, but I don't understand how
> it applies here.
> 
> Currently in stable:
> * With default format output = Default
>   * Ctrl+R -> pdflatex
>   * Instant preview -> latex
> * With default format output = PDF (pdflatex)
>   * Ctrl+R -> pdflatex
>   * Instant preview -> latex
> 
> Whereas in master:
> * With default format output = Default
>   * Ctrl+R -> pdflatex
>   * Instant preview -> latex
> * With default format output = PDF (pdflatex)
>   * Ctrl+R -> pdflatex
>   * Instant preview -> pdflatex
> 
> Thus, if changing the behaviour of instant preview for "Default" means
> breaking backwards compatibility, then backwards compatibility is already
> broken in master given that the behaviour is changed for "PDF (pdflatex)".
> We don't appear to believe that. This is what I meant.

If the default output format set in the preferences is always used,
this document:
http://www.lyx.org/trac/raw-attachment/ticket/9371/pst-triangle.lyx
that previews correctly in 2.1, would fail in 2.2 if the default
output format in the preferences is set to pdflatex.
Now it can also be correctly previewed in 2.2 without explicitly setting
the default format for the document, i.e., without modifying the document.
Please, read the discussion about this topic (bug #9371).

> But I am receptive to your idea of keeping latex for the speedup and
> disabling microtype, for the same speed reason. I like the idea of still
> having the choice via "default output format" (even though the feature will
> be kind of hidden).

Please, look in the archives for the extensive discussion about this point.

-- 
Enrico

Re: test of math previews

[Enrico Forestieri]

On Mon, Jun 01, 2015 at 10:14:23PM +0100, Guillaume M-M wrote:
> Le 01/06/2015 21:16, Guillaume M-M a écrit :
> >
> >Anyway, here's a suggestion for getting those horrible bitmap fonts out
> >of the way of new users, in a perfectly non-intrusive and
> >backwards-compatible manner: just set Latin Modern to be the default
> >choice for a new document. This would also solve the issue considered
> >above. Note that I don't suggest to change the meaning of "Default" for
> >roman fonts, but rather to force the user explicitly select "Default"
> >over "Latin Modern" if he really wants to. I think it is always good
> >when LyX shows the standard way. Then if the user wants poor bitmap
> >fonts, that will be by choice.
> >
> 
> I am aware that it is less simple than it sounds given that often the user
> wants to switch to a document class that already has more sensible defaults.
> I will open an enhancement request if I figure out a solution, but I'd be
> happy to know whether something like this was already discussed on the list.

Many times...

-- 
Enrico

Re: test of math previews

[Guillaume M-M]

Le 01/06/2015 23:04, Enrico Forestieri a écrit :

You may be right that microtype may have been the reason why I had the
impression that latex is slower than pdflatex, but this does not account for
the 55s (on a good computer) during which LyX is frozen while generating the
16MB tex file. I will run tests again to confirm (and also test the new
patch) and will reply to the previous message in a short while. (BTW yes I
have epstopdf and pdfcairo.)


Here we are not going anywhere. I say it works well for me, while you say it
doesn't work. Please, provide an example that generates a 16MB tex file for
a ~20 page document.



Read again: I am saying that I am running further tests and come back 
later with a reply :)


In fact I am currently having an assertion violation when activating 
full instant preview (attached), which prevents me from completing the 
test. Can anyone tell me how I get more meaningful symbols? I can try to 
send a reproducer but I am a bit short on time to make one right now. 
(And time is not pressing, it does not affect stable.)


LyX 2.2.0dev (not released yet)
  Git commit hash cb201027
Configuration
  Host type:   x86_64-unknown-linux-gnu
  Special build flags:  build=development warnings assertions 
stdlib-debug concept-checks

  C++ Compiler:g++ (4.9.2)
  C++ Compiler flags:   -Wall -Wextra -Wfloat-conversion -g -O
  C++ Compiler user flags:
  Linker flags:
  Linker user flags:
  Qt Frontend:
  Qt version:  4.8.6
  Packaging:   posix
  LyX binary dir:  /usr/local/bin
  LyX files dir:   /usr/local/share/lyx-gm




I am aware that it is less simple than it sounds given that often the user
wants to switch to a document class that already has more sensible defaults.
I will open an enhancement request if I figure out a solution, but I'd be
happy to know whether something like this was already discussed on the list.


Many times...


In that case, I will NOT open an enhancement request if there is already 
a consensus :) (but I did not find any relevant entry in the bug tracker)



In fact it does not work entirely in master. There is a regression (after
bc47054b I believe) because compilation can now fail due to \renewcommandx
being used without the command being defined prior to that (try the attached
lyx-bug-renewcommandx.lyx). (Stable is fine in this regard after your commit
9285f338, it seems.) 

One quick solution would be to prepend all \renewcommandx\a{b} with
\providecommand\a{}.


I think this was already addressed by Jürgen at 83a9ed4e.



For me the bug is still here at cb201027. Try again my file 
lyx-bug-renewcommandx.lyx attached to my first message.


Warning: pdflatex had problems compiling lyxpreviewM16620.tex
Warning: trying to recover from failed compilation
lassert.cpp (51): ASSERTION !empty() VIOLATED IN DocIterator.cpp:114
(  1) lyx-gm: lyx-gm() [0xc6b79b]
(  2) lyx-gm: lyx-gm() [0xc6b8b2]
(  3) lyx-gm: lyx-gm() [0x54e84f]
(  4) lyx-gm: lyx-gm() [0x7f4438]
(  5) lyx-gm: lyx-gm() [0x7a0a9e]
(  6) lyx-gm: lyx-gm() [0x7a1b4f]
(  7) lyx-gm: lyx-gm() [0x495c28]
(  8) lyx-gm: lyx-gm() [0x4d4809]
(  9) lyx-gm: lyx-gm() [0xb77b75]
( 10) lyx-gm: lyx-gm() [0xa676c4]
( 11) lyx-gm: lyx-gm() [0xabb7ae]
( 12) lyx-gm: lyx-gm() [0xabb864]
( 13) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: QMetaObject::activate(QObject*, 
QMetaObject const*, int, void**)
( 14) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QAbstractButton::clicked(bool)
( 15) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x59e533) [0x7f129d9fd533]
( 16) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x59f8e4) [0x7f129d9fe8e4]
( 17) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
QAbstractButton::mouseReleaseEvent(QMouseEvent*)
( 18) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QWidget::event(QEvent*)
( 19) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
QApplicationPrivate::notify_helper(QObject*, QEvent*)
( 20) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QApplication::notify(QObject*, 
QEvent*)
( 21) lyx-gm: lyx-gm() [0x9d1084]
( 22) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: 
QCoreApplication::notifyInternal(QObject*, QEvent*)
( 23) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, 
QWidget**, QPointer&, bool)
( 24) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x2489a2) [0x7f129d6a79a2]
( 25) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
QApplication::x11ProcessEvent(_XEvent*)
( 26) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x270ba2) [0x7f129d6cfba2]
( 27) /lib/x86_64-linux-gnu/libglib-2.0.so.0: 
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x24d) 
[0x7f129ba3cc3d]
( 28) /lib/x86_64-linux-gnu/libglib-2.0.so.0: 
/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x49f20) [0x7f129ba3cf20]
( 29)