from:"m"


Le 23/06/2015 02:36, Guillaume M-M a écrit :

Le 23/06/2015 02:34, Guillaume M-M a écrit :

Another segfault in the stable branch involving previews (and master as
well). When Instant preview is on and one copies a formula, it randomly
crashes. In the attached, select the math inset and hold Ctrl+C until it
segfaults. Sometimes it happens on the first press. This is pretty
annoying because it's not a corner case at all. There is a very simple
math macro, but it does not crash with preview off.

The positive side is that I am getting a glimpse that having instant
previews that actually work is very pleasing :)


Stack trace:

Stable:

0x76360a48 in std::basic_string, std::allocator
 >::basic_string(std::basic_string,
std::allocator > const&) () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6

Master:

0x0044e2e2 in ?? ()


Does not take cd046f0e into account. Let me test again.





Still there at cd046f0e (master). But here's the trace I get when it 
crashes right at the first Ctrl+C:



(  1) src/lyx: src/lyx() [0x9c14e8]
(  2) src/lyx: src/lyx() [0x9c257b]
(  3) src/lyx: src/lyx() [0x9c2fc3]
(  4) src/lyx: src/lyx() [0xa2c091]
(  5) src/lyx: src/lyx() [0x9bfe57]
(  6) src/lyx: src/lyx() [0x5ef49a]
(  7) /lib/x86_64-linux-gnu/libc.so.6: 
/lib/x86_64-linux-gnu/libc.so.6(+0x352f0) [0x7f15240122f0]
(  8) src/lyx: std::basic_string, 
std::allocator >::basic_string(std::basic_stringstd::char_traits, std::allocator > const&)

(  9) src/lyx: src/lyx() [0x7fb7da]
( 10) src/lyx: src/lyx() [0x7f1f9e]
( 11) src/lyx: src/lyx() [0x819460]
( 12) src/lyx: src/lyx() [0x7e25e0]
( 13) src/lyx: src/lyx() [0x819474]
( 14) src/lyx: src/lyx() [0x79d36c]
( 15) src/lyx: src/lyx() [0x7acfd1]
( 16) src/lyx: src/lyx() [0x65e239]
( 17) src/lyx: src/lyx() [0x644f58]
( 18) src/lyx: src/lyx() [0x647093]
( 19) src/lyx: src/lyx() [0x4b07c4]
( 20) src/lyx: src/lyx() [0x54e75e]
( 21) src/lyx: src/lyx() [0x54f840]
( 22) src/lyx: src/lyx() [0x54f929]
( 23) src/lyx: src/lyx() [0x6b0cda]
( 24) src/lyx: src/lyx() [0x993d06]
( 25) src/lyx: src/lyx() [0x872032]
( 26) src/lyx: src/lyx() [0x53fd7e]
( 27) src/lyx: src/lyx() [0x9f260e]
( 28) src/lyx: src/lyx() [0xa0a048]
( 29) src/lyx: src/lyx() [0x9d603f]
( 30) src/lyx: src/lyx() [0x9c5eb5]
( 31) src/lyx: src/lyx() [0x5edd5a]
( 32) src/lyx: src/lyx() [0x9c83d3]
( 33) src/lyx: src/lyx() [0xa1dd25]
( 34) src/lyx: src/lyx() [0xa2073c]
( 35) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QWidget::event(QEvent*)
( 36) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QFrame::event(QEvent*)
( 37) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
QAbstractScrollArea::event(QEvent*)

( 38) src/lyx: src/lyx() [0xa20f14]
( 39) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
QApplicationPrivate::notify_helper(QObject*, QEvent*)
( 40) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
QApplication::notify(QObject*, QEvent*)

( 41) src/lyx: src/lyx() [0x9d760a]
( 42) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: 
QCoreApplication::notifyInternal(QObject*, QEvent*)
( 43) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x26e023) [0x7f1525333023]
( 44) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x26e4c2) [0x7f15253334c2]
( 45) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
QApplication::x11ProcessEvent(_XEvent*)
( 46) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x270ba2) [0x7f1525335ba2]
( 47) /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) 
[0x7f1523b13c3d]
( 48) /lib/x86_64-linux-gnu/libglib-2.0.so.0: 
/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x49f20) [0x7f1523b13f20]
( 49) /lib/x86_64-linux-gnu/libglib-2.0.so.0: 
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_iteration+0x2c) 
[0x7f1523b13fcc]
( 50) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: 
QEventDispatcherGlib::processEvents(QFlags)
( 51) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x270c66) [0x7f1525335c66]
( 52) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: 
QEventLoop::processEvents(QFlags)
( 53) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: 
QEventLoop::exec(QFlags)

( 54) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: QCoreApplication::exec()
( 55) src/lyx: src/lyx() [0x9c33a9]
( 56) src/lyx: src/lyx() [0x5f7e85]
( 57) src/lyx: src/lyx() [0x43a64e]
( 58) /lib/x86_64-linux-gnu/libc.so.6: 
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0) [0x7f1523ffda40]

( 59) src/lyx: src/lyx() [0x43a539]

Re: test of math previews


Le 23/06/2015 02:34, Guillaume M-M a écrit :

Another segfault in the stable branch involving previews (and master as
well). When Instant preview is on and one copies a formula, it randomly
crashes. In the attached, select the math inset and hold Ctrl+C until it
segfaults. Sometimes it happens on the first press. This is pretty
annoying because it's not a corner case at all. There is a very simple
math macro, but it does not crash with preview off.

The positive side is that I am getting a glimpse that having instant
previews that actually work is very pleasing :)


Stack trace:

Stable:

0x76360a48 in std::basic_string, std::allocator
 >::basic_string(std::basic_string,
std::allocator > const&) () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6

Master:

0x0044e2e2 in ?? ()


Does not take cd046f0e into account. Let me test again.

Re: test of math previews

Another segfault in the stable branch involving previews (and master as 
well). When Instant preview is on and one copies a formula, it randomly 
crashes. In the attached, select the math inset and hold Ctrl+C until it 
segfaults. Sometimes it happens on the first press. This is pretty 
annoying because it's not a corner case at all. There is a very simple 
math macro, but it does not crash with preview off.


The positive side is that I am getting a glimpse that having instant 
previews that actually work is very pleasing :)



Stack trace:

Stable:

0x76360a48 in std::basic_stringstd::char_traits, std::allocator 
>::basic_string(std::basic_string, 
std::allocator > const&) () from 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6


Master:

0x0044e2e2 in ?? ()


lyx-preview-sigsegv3.lyx
Description: application/lyx

Re: test of math previews

Three bugs in the current stable (93c0512b). The third one has an easy 
fix (and also a very trivial partial fix if you want to move forward 
with the release). The first two could be postponed after the release, 
or maybe they are trivial as well to Enrico. Found the first two while 
testing my solution to the third one.


1) SIGSEGV with previews (no math macros involved). I believe this is 
the one I mentioned in a previous message. See the attached 
lyx-preview-sigsegv.lyx for instructions.



2) Closing a file whose previews are being generated results in an error 
dialog "Could not remove the temporary directory 
/tmp/lyx_tmpdir.LXSnBrW17125" and the following output on the terminal:


Warning: Could not remove temporary directory

Could not remove the temporary directory 
/tmp/lyx_tmpdir.LXSnBrW17125/lyx_tmpbuf0
Warning: Warning in extract_resolution! Unable to open 
"lyxpreviewQ17125_legacy.log"

Warning: ,IOError(2, 'No such file or directory')
Warning: check_latex_log: Unable to open "lyxpreviewQ17125_legacy.log"
Warning: ,IOError(2, 'No such file or directory')
Warning: Warning in legacy_extract_metrics_info! Unable to open 
"lyxpreviewQ17125_legacy.log"

Warning: ,IOError(2, 'No such file or directory')
Error: Failed to extract metrics info from lyxpreviewQ17125_legacy.log

So there's some additional cleanup to do now when closing a file.


3) Previews have the incorrect size with layouts that offer font sizes 
other than 1[0-2]pt (lyx-preview-fontsize.lyx). The legacy method offers 
a function that retrieves the actual font size and calculates the actual 
dpi. Attached is a patch (extract_resolution.diff) that imports this 
function in the new script.


(It's possible to just replace:
documentclass_re = re.compile("(documentclass\[)(1[012]pt,?)(.+)")
with:
documentclass_re = re.compile("(documentclass\[)([0-9]+pt,?)(.+)")
but this does not take into account custom classes, options, preambles, 
etc. If this path is retained, here's the result of $grep FontSize 
*.layout:


achemso.layout: FontSize10|11|12
acmsiggraph.layout:  FontSize   9|10|11|12
agutex.layout:  FontSize10|11|12
amsart.layout:  FontSize   8|9|10|11|12
amsbook.layout: FontSize   8|9|10|11|12
apa6.layout:FontSize  10|11|12
apa.layout: FontSize  6|8|10|12
broadway.layout:FontSize12
dtk.layout: FontSize  default # only 10pt in fact of A5
elsarticle.layout:  FontSize10|11|12
elsart.layout:#  FontSize "default"   # controlled by class
entcs.layout:   FontSize   11
extarticle.layout:  FontSize  8|9|10|11|12|14|17|20
extbook.layout: FontSize  8|9|10|11|12|14|17|20
extletter.layout:   FontSize  8|9|10|11|12|14|17|20
extreport.layout:   FontSize  8|9|10|11|12|14|17|20
foils.layout:   FontSize  17|20|25|30
hollywood.layout:   FontSize  12
IEEEtran-CompSoc.layout:  FontSize  12
IEEEtran.layout:  FontSize  9|10|11|12
iopart.layout:  FontSize10|12
jasatex.layout: FontSize10|11|12
latex8.layout:   FontSize 10
ltugboat.layout:FontSize  default # only 11pt
memoir.layout:  FontSize 9|10|11|12|14|17
powerdot.layout:  FontSize 
size=8|size=9|size=10|size=11|size=12|size=14|size=17|size=20

sciposter.layout:   FontSize  14|17|20|25|30|36
seminar.layout: FontSize8|9|10|11|12|14|17
siamltex.layout:FontSize   8|9|10|11|12
sigplanconf.layout:  FontSize   9|10|11
slides.layout:  FontSize   |
svmono.layout:  FontSize10
svmult.layout:  FontSize""

In particular, Powerdot has a special syntax, but the default font size 
is too big anyways (magnification=2000) so it's better to compute the 
font size from the log file, and this is precisely what 
extract_resolution already does.)


lyx-preview-sigsegv.lyx
Description: application/lyx


lyx-preview-fontsize.lyx
Description: application/lyx
diff --git a/lib/scripts/lyxpreview2bitmap.py b/lib/scripts/lyxpreview2bitmap.py
index 9775b0e..f9ee3b3 100755
--- a/lib/scripts/lyxpreview2bitmap.py
+++ b/lib/scripts/lyxpreview2bitmap.py
@@ -77,7 +77,7 @@
 
 import getopt, glob, os, re, shutil, string, sys
 
-from legacy_lyxpreview2ppm import legacy_conversion_step1
+from legacy_lyxpreview2ppm import legacy_conversion_step1, extract_resolution
 
 from lyxpreview_tools import bibtex_commands, check_latex_log, copyfileobj, \
  error, filter_pages, find_exe, find_exe_or_terminate, \
@@ -159,7 +159,6 @@ def extract_metrics_info(dvipng_stdout):
 
 
 def fix_latex_file(latex_file, pdf_output):
-documentclass_re = re.compile("(documentclass\[)(1[012]pt,?)(.+)")
 def_re = re.compile(r"(\\newcommandx|\\global\\long\\def)(\\[a-zA-Z]+)")
 
 tmp = mkstemp()
@@ -167,14 +166,9 @@ def fix_latex_file(latex_file, pdf_output):
 c

Re: test of math previews

2015-06-20 Thread Guillaume M-M


Le 20/06/2015 15:58, Enrico Forestieri a écrit :

On Sat, Jun 20, 2015 at 08:14:03AM +0100, Guillaume M-M wrote:

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

On Fri, Jun 19, 2015 at 04:50:43PM +0100, Guillaume M-M wrote:


Lastly I see that you prevent loading the microtype package by redefining
\usepackage as you described earlier in the thread. While your redefinition
of \usepackage seems to be very careful, I still think that passing the
option draft to microtype is more reliable in case the user actually uses
macros from microtype (in addition there's no need to test whether the user
loads microtype).


I am concerned with the fact that in dvi mode the microtype package
considerably slows down the processing and prefer to not allow it.


Yes, and the draft option disables the microtype features completely
according to the manual. That's also why I mentioned it. But it's your call.


In this case I will reconsider. Please, let me perform some checks first.


Please, try again with master and report back. The required changes to
address these glitches are straightforward and maybe Richard will allow
backporting them to stable.



I simply applied your patch 98a5072a to stable directly (quicker to
recompile).


You were missing the amendment at b610c13f that solves the issue with
lyx-bug-undefined5.lyx.


Well yes unfortunately b610c13f did not exist when I pulled and 
recompiled. But I think I should also test master when I have more time.





lyx-bug-undefined3.lyx: macros inside nested macro definitions (!) are not
taken into account.


I knew you would have been able to spot another corner case :)
This should also be solved at cabc7c4b.


lyx-bug-undefined4.lyx: a combination of two bugs I think. In particular,
our friend \renewcommandx again. More detailed comments in the files.


Here it was going as follows. The script detected a postscript special
in the second preview snippet and thus decided to use the legacy route
through dvips for obtaining the preview instead of directly using dvipng.
In order to do that, the affected snippets are extracted from the original
latex file. Now, in the original file the second snippet was correctly
using \renewcommandx because the macro was already defined in the first
snippet, but now it was incorrect, of course. Also solved at cabc7c4b.


lyx-bug-undefined5.lyx: the arguments are only scanned on the first
occurrence of a macro.


This had already been taken into account at b610c13f.

For your convenience I am attaching the overall set of patches for
the stable branch. Please, let me know if you are able to find some
other remaining glitches :)



Thank you for the convenience.

I have no other issue to report for stable, Enrico wins :)

Re: test of math previews

2015-06-20 Thread Guillaume M-M


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

On Fri, Jun 19, 2015 at 04:50:43PM +0100, Guillaume M-M wrote:


Le 07/06/2015 12:49, Enrico Forestieri a écrit :

On Sat, Jun 06, 2015 at 08:07:12PM +0100, Guillaume M-M wrote:


lyx-preview-macros2-failure.lyx shows two cases where a macro is forgotten

>from the list. The third inset works and is meant as a control. All 3 work

without the patch.


Here I was forgetting to also scan nested insets.


lyx-preview-macros2-lassert.lyx triggers an assertion when preview is
activated. Does not assert without the patch.


Here I did not account for the fact that also the macros defined in the
symbols file are spotted. However, they do not have a valid DataMacro
and this was causing the assert.

Note that there is another bug here, but it is not a regression as it
seems to be like that since ever (I checked with lyx versions since 1.3).
The bug is that when using a symbol defined in the symbols file and this
symbol requires a certain package, this requirement is not taken into
account when generating the tex file for preview and thus latex fails.


Notice that my "thourough test" is basically loading my current paper with
preview on.


I think that your paper is a very valid test case for macros ;)

The attached patch solves all of the above problems (and also the segfault
you report separately) for me. I am also attaching the patch for #9354
accordingly updated. Please test both and report the issues you find.
If your paper pass the tests, I think they are good for stable ;)



Hello again,


Hi Guillaume,


I tested the latest stable that seems to include the patches. As I already
told Enrico, sorry for the delay as I did not have much free time until now.

Thank you very much, this is really quick now. Thanks also for the timer for
generating previews. Also I only had 1 segmentation error, which I could not
reproduce unfortunately. It happened after changing from "Instant preview:
On" to "No maths" and zooming. But probably it's part of the bigger issues
with math macros, and again I could not reproduce.


Yes, I also think this is not specifically related to previews.


Here are two examples that still fail.

lyx-bug-undefined.lyx: the macro used in the argument of another macro is
not defined. I had many bugs of this style, so let's hope that this one is
representative, otherwise I'll come back with more errors.


Yes, I think it is. I was not taking into account that macros could also
occur in the arguments of other macros. Should be fixed in master now.


lyx-bug-renewcommandx4.lyx: here we have again an error where renewcommandx
is used while the macro is not defined beforehand. If it is really too error
prone to keep track of what has already been defined then it is easy to work
around by using \definecommandx:
   \def\definecommandx#1{\providecommand#1{}\renewcommandx#1}
This seems to work at least for the way newcommandx is used in lyx previews
(but maybe you have other reasons for distinguishing the cases newcommandx
and renewcommandx that I don't understand).


This was due to a stupid typo and should also be fixed in master.
As regards your proposal, I don't like defining commands only to immediately
redefining them. And the fix was quite straightforward.


Good. We are down to 14 failing previews. (examples at the end)




Lastly I see that you prevent loading the microtype package by redefining
\usepackage as you described earlier in the thread. While your redefinition
of \usepackage seems to be very careful, I still think that passing the
option draft to microtype is more reliable in case the user actually uses
macros from microtype (in addition there's no need to test whether the user
loads microtype).


I am concerned with the fact that in dvi mode the microtype package
considerably slows down the processing and prefer to not allow it.


Yes, and the draft option disables the microtype features completely 
according to the manual. That's also why I mentioned it. But it's your call.





I don't want to be too much of a PITA so here's a patch to
lyxpreview2bitmap.py that integrates my above two suggestions and solves the
above two problems. (The bug in lyx-bug-undefined.lyx has to be addressed
separately.) Parsing a file using regexps is always delicate so I think it's
good that with my patch there are fewer of these. I do not think that I
missed any subtlety in the existing code, but in any case you don't need to
accept it as is.


In this particular case the regexp was simply wrong.


Also, lyx-preview-macros-2-lassert.lyx no longer lasserts but on opening the
preview is not generated because \Coloneqq is not defined. This looks like
the bug that you are referring to in your message where packages for symbols
are not properly loaded. But, notice that the preview is correctly generated
on a second time, when entering and leaving the math inset.

Re: test of math previews

2015-06-19 Thread Guillaume M-M


Le 07/06/2015 12:49, Enrico Forestieri a écrit :

On Sat, Jun 06, 2015 at 08:07:12PM +0100, Guillaume M-M wrote:


lyx-preview-macros2-failure.lyx shows two cases where a macro is forgotten
from the list. The third inset works and is meant as a control. All 3 work
without the patch.


Here I was forgetting to also scan nested insets.


lyx-preview-macros2-lassert.lyx triggers an assertion when preview is
activated. Does not assert without the patch.


Here I did not account for the fact that also the macros defined in the
symbols file are spotted. However, they do not have a valid DataMacro
and this was causing the assert.

Note that there is another bug here, but it is not a regression as it
seems to be like that since ever (I checked with lyx versions since 1.3).
The bug is that when using a symbol defined in the symbols file and this
symbol requires a certain package, this requirement is not taken into
account when generating the tex file for preview and thus latex fails.


Notice that my "thourough test" is basically loading my current paper with
preview on.


I think that your paper is a very valid test case for macros ;)

The attached patch solves all of the above problems (and also the segfault
you report separately) for me. I am also attaching the patch for #9354
accordingly updated. Please test both and report the issues you find.
If your paper pass the tests, I think they are good for stable ;)



Hello again,


I tested the latest stable that seems to include the patches. As I 
already told Enrico, sorry for the delay as I did not have much free 
time until now.


Thank you very much, this is really quick now. Thanks also for the timer 
for generating previews. Also I only had 1 segmentation error, which I 
could not reproduce unfortunately. It happened after changing from 
"Instant preview: On" to "No maths" and zooming. But probably it's part 
of the bigger issues with math macros, and again I could not reproduce.


Here are two examples that still fail.

lyx-bug-undefined.lyx: the macro used in the argument of another macro 
is not defined. I had many bugs of this style, so let's hope that this 
one is representative, otherwise I'll come back with more errors.


lyx-bug-renewcommandx4.lyx: here we have again an error where 
renewcommandx is used while the macro is not defined beforehand. If it 
is really too error prone to keep track of what has already been defined 
then it is easy to work around by using \definecommandx:

  \def\definecommandx#1{\providecommand#1{}\renewcommandx#1}
This seems to work at least for the way newcommandx is used in lyx 
previews (but maybe you have other reasons for distinguishing the cases 
newcommandx and renewcommandx that I don't understand).


Lastly I see that you prevent loading the microtype package by 
redefining \usepackage as you described earlier in the thread. While 
your redefinition of \usepackage seems to be very careful, I still think 
that passing the option draft to microtype is more reliable in case the 
user actually uses macros from microtype (in addition there's no need to 
test whether the user loads microtype).


I don't want to be too much of a PITA so here's a patch to 
lyxpreview2bitmap.py that integrates my above two suggestions and solves 
the above two problems. (The bug in lyx-bug-undefined.lyx has to be 
addressed separately.) Parsing a file using regexps is always delicate 
so I think it's good that with my patch there are fewer of these. I do 
not think that I missed any subtlety in the existing code, but in any 
case you don't need to accept it as is.


Also, lyx-preview-macros-2-lassert.lyx no longer lasserts but on opening 
the preview is not generated because \Coloneqq is not defined. This 
looks like the bug that you are referring to in your message where 
packages for symbols are not properly loaded. But, notice that the 
preview is correctly generated on a second time, when entering and 
leaving the math inset. So maybe it's easier to fix than it seemed. But 
indeed it's not a regression.



Best regards
Guillaume



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


lyx-bug-renewcommandx4.lyx
Description: application/lyx
diff --git a/lib/scripts/lyxpreview2bitmap.py b/lib/scripts/lyxpreview2bitmap.py
index a7d7623..fe9bea1 100755
--- a/lib/scripts/lyxpreview2bitmap.py
+++ b/lib/scripts/lyxpreview2bitmap.py
@@ -159,65 +159,35 @@ def extract_metrics_info(dvipng_stdout):
 
 
 def fix_latex_file(latex_file, pdf_output):
-documentclass_re = re.compile("(documentclass\[)(1[012]pt,?)(.+)")
-def_re = re.compile(r"(\\newcommandx|\\global\\long\\def)(\\[a-zA-Z])(.+)")
-usepackage_re = re.compile("usepackage")
-userpreamble_re = re.compile("User specified LaTeX commands")
-enduserpreamble_re = re.compile("makeatother")
+documentclass_re = re.compile("(\

Re: test of math previews

2015-06-06 Thread Guillaume M-M


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

On Sat, Jun 06, 2015 at 03:23:48PM +0200, Kornel Benko wrote:


Am Samstag, 6. Juni 2015 um 13:13:22, schrieb Enrico Forestieri 

+void InsetMathHull::usedMacros(MathData const & md, MacroNameSet & macros) 
const
+{
+   for (size_t i = 0; i < md.size(); ++i) {
+   MathMacro * mi = const_cast(md[i].nucleus()->asMacro());
+   if (mi) {
+   macros.insert(mi->name());
+   usedMacros(mi->definition(), macros);


I would change the order, to get the used macro first.


No, that is correct. The top level macro has to appear in the last position.

I failed to understand why that was not working but, most probably, it has
to do with the fact not all data is copied over to a cloned buffer.
However, I found a different way for collecting only the macros used
in a given math inset, so I did not investigate it further.

The attached patch for stable works for me and avoids the size explosion
when a very lot of macros are defined in a document. I count on Guillaume
to give it a thourough test. If he doesn't find glitches I will feel
confident about proposing to apply it for 2.1.4.



Obvious one to test for


lyx-preview-macros-2-sigsegv.lyx
Description: application/lyx

Re: test of math previews

2015-06-06 Thread Guillaume M-M


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

On Sat, Jun 06, 2015 at 03:23:48PM +0200, Kornel Benko wrote:


Am Samstag, 6. Juni 2015 um 13:13:22, schrieb Enrico Forestieri 

+void InsetMathHull::usedMacros(MathData const & md, MacroNameSet & macros) 
const
+{
+   for (size_t i = 0; i < md.size(); ++i) {
+   MathMacro * mi = const_cast(md[i].nucleus()->asMacro());
+   if (mi) {
+   macros.insert(mi->name());
+   usedMacros(mi->definition(), macros);


I would change the order, to get the used macro first.


No, that is correct. The top level macro has to appear in the last position.

I failed to understand why that was not working but, most probably, it has
to do with the fact not all data is copied over to a cloned buffer.
However, I found a different way for collecting only the macros used
in a given math inset, so I did not investigate it further.

The attached patch for stable works for me and avoids the size explosion
when a very lot of macros are defined in a document. I count on Guillaume
to give it a thourough test. If he doesn't find glitches I will feel
confident about proposing to apply it for 2.1.4.



:)

lyx-preview-macros2-failure.lyx shows two cases where a macro is 
forgotten from the list. The third inset works and is meant as a 
control. All 3 work without the patch.


lyx-preview-macros2-lassert.lyx triggers an assertion when preview is 
activated. Does not assert without the patch.


Notice that my "thourough test" is basically loading my current paper 
with preview on.


lyx-preview-macros-2-failure.lyx
Description: application/lyx


lyx-preview-macros-2-lassert.lyx
Description: application/lyx

Re: test of math previews

2015-06-05 Thread Guillaume M-M


Le 05/06/2015 08:14, Enrico Forestieri a écrit :

On Thu, Jun 04, 2015 at 07:32:03PM -0400, Richard Heck wrote:

On 06/04/2015 07:13 PM, Guillaume M-M wrote:


Bad news, it seems to forget that macros can use macros. With the attached
file the preview is as follows:

\begin{preview}
\global\long\def\b{\a}

$\b$
\end{preview}


I suspect this is why all macros are included.


Most probably. This leaves us pretty stuck with the problem caused by
having hundreds of macros. I will not commit any change to stable until
we find a good solution. After all, this is what already happens now
and it is not a regression. I think the complaint is due to the fact
that now also the previews get zoomed and this may cause relevant delays,


Enrico mentions a "complaint". There seems to be a misunderstanding. The 
freeze on zoom is a regression in stable, while the time explosion was 
already there. This is only a factual report of the issues trying to be 
the most helpful. The reports are the outcome of my tests of the preview 
mechanism following Enrico's request of having his patch at 
<http://www.lyx.org/trac/ticket/9354> tested.


In truth, I have no interest in full preview, only in the solution to 
#9354, and my tests concluded that there are no immediate issues with 
his patch, while I managed to find other issues---many thanks to Enrico 
and Jürgen for fixing them promptly. Fixing #9354 (preview inset does 
not work with math macros) in 2.1.4 would make the preview mechanism 
useful again in my context, avoiding the performance issues. (Especially 
because I cannot ask my collaborators to compile from git.) Apart from 
that, only this regression regarding the zoom/preview interaction 
remains regarding the stable branch (to summarise the thread, since you 
probably want to move forward with 2.1.4).


After this thread dies off, I may record the remaining important issues 
in the bug tracker, but again please do not regard such reports as 
complaints!





but I hope one is not zooming all the time.  And it starts to be a problem
when you have hundreds of macros, not a very common case, IMHO.



Indeed, to be precise, the freeze time does not seem to be linear in the 
number of macros (otherwise with ~35 macros and 700 insets one would 
have to wait ~5s for LyX to unfreeze, but I could observe that it was 
probably less than 0.5s in reality). However, the math manual is the 
other extreme because it only contains one macro, so it is not an 
accurate test either.

Re: test of math previews


Le 04/06/2015 22:29, Enrico Forestieri a écrit :

On Thu, Jun 04, 2015 at 06:33:28PM +0100, Guillaume M-M wrote:


1) the explosion in size mentioned above. This affects both stable and
master. (This is also responsible for a regression wrt 2.1.3 because of
zooming triggers preview as already discussed.)


Using vim I duplicated your document 26 times, thus creating a document
with a total of 676 different macros (attached). When generating the
previews, a 12Mb file was created, so the issue is real, at least for those
using hundreds of macros in a document, not the vast majority, I bet ;)

The attached patch against stable reduced the size of the tex file to
a perfectly manageable size of about 60Kb.

Richard, I think that this is pretty safe for stable. It simply omits
the macro definition if it is not used in the math inset. At worst,
it is added unnecessarily if for example \beta appears in the inset
and the macro name is \b, \be, or \bet.

As regards master, we have still to solve the other problem mentioned
in this thread before we can proceed.



Good news, I can confirm that it is much quicker, even unnoticeable.

Bad news, it seems to forget that macros can use macros. With the 
attached file the preview is as follows:


\begin{preview}
\global\long\def\b{\a}

$\b$
\end{preview}

Good news, opening the file lyx-bug-lassert-preview-startup.lyx no 
longer makes a crash (probably it just hides the bug).




lyx-preview-macros.lyx
Description: application/lyx

Re: test of math previews


Le 04/06/2015 20:17, Scott Kostyshak a écrit :

On Thu, Jun 4, 2015 at 3:05 PM, Enrico Forestieri  wrote:

On Thu, Jun 04, 2015 at 02:44:56PM -0400, Scott Kostyshak wrote:

On Thu, Jun 4, 2015 at 2:34 PM, Scott Kostyshak  wrote:

On Thu, Jun 4, 2015 at 2:31 PM, Enrico Forestieri  wrote:

On Thu, Jun 04, 2015 at 06:33:28PM +0100, Guillaume M-M wrote:


2) an assertion violation that happen on copy-paste with preview (does not
happen without preview). This is a regression in master, does not happen in
the stable branch.


I can reproduce the assertion. Bisect points at 73460423 and it was
backported to stable at 6ac04e21 where it asserts in the same way.


Ah thank you for catching this and bisecting. I will revert in branch
and master.


Can someone please confirm that I should indeed revert?
I took a look at lyx-preview-explosion.lyx and I can indeed reproduce
the assertion. My guess though is that the referenced commits expose a
different bug that has to do with previews and macros. But in the end
from a user perspective it is a regression. Thus, I think I should
revert.


Wouldn't it be better trying to understand why it asserts such that it
can be avoided?


Yes much better. However, we are close to release so I was thinking to
revert in the meantime. And second, I don't understand the underlying
code involving macros at all so it would be up to someone else to do
that. From what I remember of previous issues regarding preview +
macro, this is a complicated issue over my head.

Scott



The attached file produces a similar lassert when preview is on. No 
copy-paste involved, just open the file. (Sorry for not refining the 
example more, I think it's already small enough.)


Can leave lyx in a crash-on-startup state, forcing to remove by hand the 
line \preview from preferences. Affects master at cda4589f, and stable 
at 7013445b plus the following patch that removes the line added by 
6ac04e21:


diff --git a/src/Text3.cpp b/src/Text3.cpp
index 3359e35..0d256c2 100644
--- a/src/Text3.cpp
+++ b/src/Text3.cpp
@@ -1269,7 +1269,7 @@ void Text::dispatch(Cursor & cur, FuncRequest & cmd)
bv->buffer().errors("Paste");
cur.clearSelection(); // bug 393
cur.finishUndo();
-   bv->buffer().updatePreviews();
+// bv->buffer().updatePreviews();
break;
}



lyx-bug-lassert-preview-startup.lyx
Description: application/lyx

Re: test of math previews


Le 04/06/2015 17:39, Enrico Forestieri a écrit :

On Thu, Jun 04, 2015 at 01:42:51AM +0100, Guillaume M-M wrote:

Le 02/06/2015 23:50, Enrico Forestieri a écrit :


Try using gdb for getting a backtrace after setting a breakpoint at
lassert.cpp:53. If this is due to some recent change, you could try
bisetting for finding the relevant commit.


The assert failure went away after recompiling. If I remember correctly when
I had the problem I had been playing with the configure options (for the
sake of trying), notably --enable-monolithic-build. Would you like me to try
to reproduce the issue, or am I expected to run into such troubles if I play
with the build options?


This should not depend on the build options, unless you use the
--enable-concept-checks and --enable-stdlib-debug options, I think.
It is hard to tell the cause if it is not reproducible. It could be
due to some race condition or whatever.


Could reproduce systematically, so did not look like a race condition. 
See the lassert from my previous message, could be related since it 
seems to happen similarly when the children are spawned. My flags are 
now build=development warnings assertions stdlib-debug concept-checks.




Here is another file that doesn't work for me (lyx-bug-renewcommandx2.lyx).
With it we get the erroneous latex code:

"""
\begin{preview}
\renewcommandx\A[1][usedefault, addprefix=\global, 1=B]{A#1}

$\A$
\end{preview}

\begin{preview}
\newcommandx\A[1][usedefault, addprefix=\global, 1=B]{A#1}
$\A$
\end{preview}
"""


Actually, I cannot reproduce this. Even entering and then leaving the
math inset works for me. But I can make it fail by changing the macro
parameter. The reason of the failure is the same as for the previous
case, though.


Yes, I no longer have it (at cda4589f), but can trigger it similarly by 
switching Instant Preview from "No Maths" to "On".

Re: test of math previews


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.



The attached files demonstrate two bugs:

1) the explosion in size mentioned above. This affects both stable and 
master. (This is also responsible for a regression wrt 2.1.3 because of 
zooming triggers preview as already discussed.)


2) an assertion violation that happen on copy-paste with preview (does 
not happen without preview). This is a regression in master, does not 
happen in the stable branch.


Details:

1) Instant preview is activated. The preview tex file generated first 
time on opening redefines all the macros before each math inset. In this 
example there are 26 macros and 26 math insets. For my actual paper in 
preparation (quite modest, 18 pages with wide margins), the preview tex 
file lists 370 macros and 769 math insets. Given this data one can 
verify that its complete preview file is at least 284000 non-empty lines 
with a size of approx 15MB. I tried to make an example file in the same 
order of magnitude in order to demonstrate the performance impact, but 
bug 2) prevented me from doing that. You could argue that I could reduce 
the number of macros by half if I specialise my macro file to my current 
paper, but this defeats the purpose of having a global macro file, while 
not improving the situation much.



2) to trigger the assertion violation in master:
  0. enable instant preview
  1. select the whole document
  2. copy
  3. paste at the end

(Built from git commit hash 77ab3017)

\batchmode
%% LyX 2.2.0dev created this file.  For more info, see http://www.lyx.org/.
%% Do not edit unless you really know what you are doing.
\makeatletter
\def\input@path{{/home/gm/Bureau//}}
\makeatother
\documentclass[english]{article}
\usepackage[T1]{fontenc}
\usepackage[latin9]{inputenc}
\usepackage{amstext}

\makeatletter
%% User specified LaTeX commands.
% Added by lyx2lyx
\@ifundefined{rangeHsb}{\usepackage{xcolor}}

\makeatother

\usepackage{babel}

\def\lyxlock{}


\usepackage[active,delayed,showlabels,lyx]{preview}


\begin{document}
\begin{preview}
\global\long\def\A{\textit{this is the macro A }}

\global\long\def\B{\textit{this is the macro B }}

\global\long\def\C{\textit{this is the macro C }}

\global\long\def\D{\textit{this is the macro D }}

\global\long\def\E{\textit{this is the macro E }}

\global\long\def\F{\textit{this is the macro F }}

\global\long\def\G{\textit{this is the macro G }}

\global\long\def\H{\textit{this is the macro H }}

\global\long\def\I{\textit{this is the macro I }}

\global\long\def\J{\textit{this is the macro J }}

\global\long\def\K{\textit{this is the macro K }}

\global\long\def\L{\textit{this is the macro L }}

\global\long\def\M{\textit{this is the macro M }}

\global\long\def\N{\textit{this is the macro N }}

\global\long\def\O{\textit{this is the macro O }}

\global\long\def\P{\textit{this is the macro P }}

\global\long\def\Q{\textit{this is the macro Q }}

\global\long\def\R{\textit{this is the macro R }}

\global\long\def\S{\textit{this is the macro S }}

\global\long\def\T{\textit{this is the macro T }}

\global\long\def\U{\textit{this is the macro U }}

\global\long\def\V{\textit{this is the macro V }}

\global\long\def\W{\textit{this is the macro W }}

\global\long\def\X{\textit{this is the macro X }}

\global\long\def\Y{\textit{this is the macro Y }}

\global\long\def\Z{\textit{this is the macro Z }}
$\A$
\end{preview}

\begin{preview}
\global\long\def\A{\textit{this is the macro A }}

\global\long\def\B{\textit{this is the macro B }}

\global\long\def\C{\textit{this is the macro C }}

\global\long\def\D{\textit{this is the macro D }}

\global\long\def\E{\textit{this is the macro E }}

\global\long\def\F{\textit{this is the macro F }}

\global\long\def\G{\textit{this is the macro G }}

\global\long\def\H{\textit{this is the macro H }}

\global\long\def\I{\textit{this is the macro I }}

\global\long\def\J{\textit{this is the macro J }}

\global\long\def\K{\textit{this is the macro K }}

\global\long\def\L{\textit{this is the macro L }}

\global\long\def\M{\textit{this is the macro M }}

\global\long\def\N{\textit{this is the macro N }}

\global\long\def\O{\textit{this is the macro O }}

\global\long\def\P{\textit{this is the macro P }}

\global\long\def\Q{\textit{this is the macro Q }}

\global\long\def\R{\textit{this is the macro R }}

\global\long\def\S{\textit{this is the ma

Re: test of math previews

2015-06-03 Thread Guillaume M-M


Le 02/06/2015 23:50, Enrico Forestieri a écrit :



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.)


Try using gdb for getting a backtrace after setting a breakpoint at
lassert.cpp:53. If this is due to some recent change, you could try
bisetting for finding the relevant commit.



The assert failure went away after recompiling. If I remember correctly 
when I had the problem I had been playing with the configure options 
(for the sake of trying), notably --enable-monolithic-build. Would you 
like me to try to reproduce the issue, or am I expected to run into such 
troubles if I play with the build options?






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)


I don't know whether there is an entry in the bug tracker, but this issue
surfaces regularly either here or on the users list.



For the curious who missed the discussion from 2009, a relevant part is 
here  (it was 
quite hard to find because the discussion was moved over to the dev list 
during the discussion and this branch is not listed in the summary by day).


It was best summarised by Pavel Sanda: "so isn't this rather request on 
latex devs to use latin modern as default for their classes?". I 
understand now that the only way of improving the new-user experience 
that is not ruled out by the arguments already given would be to find or 
invent some class/layout combination that would show the best defaults 
to a new user if any such notion of best defaults exists. (But I am 
leaving it there, this is not the problem at hand.)





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.


Strange, I don't see it anymore after 83a9ed4e.




With lyx-bug-renewcommandx.lyx from my initial message, although the 
preview now works on opening, it fails if one enters the math inset and 
leaves it. Because then we get the following erroneous code (missing 
\newcommandx):


"""
\begin{preview}
$\A$
\end{preview}
"""


Here is another file that doesn't work for me 
(lyx-bug-renewcommandx2.lyx). With it we get the erroneous latex code:


"""
\begin{preview}
\renewcommandx\A[1][usedefault, addprefix=\global, 1=B]{A#1}

$\A$
\end{preview}

\begin{preview}
\newcommandx\A[1][usedefault, addprefix=\global, 1=B]{A#1}
$\A$
\end{preview}
"""


Lastly, with lyx-bug-renewcommandx3.lyx (attached) we get the following 
erroneous code for the first preview after opening:


"""
\begin{preview}
\global\long\def\A{A}
$\A$
\end{preview}

\begin{preview}
\newcommandx\A[1][usedefault, addprefix=\global, 1=B]{A#1}
$\A$
\end{preview}
"""


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


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

Re: Will LyX 2.2 fix the OS X slow scrolling problem?

2015-06-03 Thread Rainer M Krug

Scott Kostyshak  writes:

> On Wed, Jun 3, 2015 at 10:46 AM, Jean-Marc Lasgouttes
>  wrote:
>> Le 03/06/2015 02:26, Jerry a écrit :
>>>
>>> Will LyX 2.2 fix the OS X slow scrolling problem?
>>>
>>> Someone mentioned some time back that there is an experimental fix
>>> for the slow scrolling problem on OS X LyX but that it needs testing.
>>> I am willing to test. However, even further back while testing for
>>> another problem, I experienced difficulty building from source and
>>> the problems were not resolved (for me) so I abandoned those earlier
>>> efforts.
>>
>>
>> Hi Jerry,
>>
>> Current master code (that will become 2.2) should indeed improve greatly the
>> MacOS experience: faster, with proper kerning and retina support.
>>
>>> If someone can either provide a binary or provide some dumb-guy-level
>>> instructions for checkout and building, I would be happy to take it
>>> from there. I already have git installed and can do a basic
>>> checkout.
>>
>>
>> I'll let Stephan answer on what is the easiest way to build from scratch on
>> Mac OS.
>
> I know almost nothing about Homebrew, but would it make sense to have
> a homebrew script?

Oh - LyX is in homebrew cask, i.e. the OS X installer. So I don't know
if they would include a LyX recipe.

Rainer

>
> Scott
>

-- 
Rainer M. Krug
email: Rainerkrugsde
PGP: 0x0F52F982


signature.asc
Description: PGP signature

Re: Will LyX 2.2 fix the OS X slow scrolling problem?

2015-06-03 Thread Rainer M Krug

Scott Kostyshak  writes:

> On Wed, Jun 3, 2015 at 10:46 AM, Jean-Marc Lasgouttes
>  wrote:
>> Le 03/06/2015 02:26, Jerry a écrit :
>>>
>>> Will LyX 2.2 fix the OS X slow scrolling problem?
>>>
>>> Someone mentioned some time back that there is an experimental fix
>>> for the slow scrolling problem on OS X LyX but that it needs testing.
>>> I am willing to test. However, even further back while testing for
>>> another problem, I experienced difficulty building from source and
>>> the problems were not resolved (for me) so I abandoned those earlier
>>> efforts.
>>
>>
>> Hi Jerry,
>>
>> Current master code (that will become 2.2) should indeed improve greatly the
>> MacOS experience: faster, with proper kerning and retina support.
>>
>>> If someone can either provide a binary or provide some dumb-guy-level
>>> instructions for checkout and building, I would be happy to take it
>>> from there. I already have git installed and can do a basic
>>> checkout.
>>
>>
>> I'll let Stephan answer on what is the easiest way to build from scratch on
>> Mac OS.
>
> I know almost nothing about Homebrew, but would it make sense to have
> a homebrew script?

Yes - but you need somebody to make one and to maintain it.

Cheers,

Rainer

>
> Scott
>

-- 
Rainer M. Krug
email: Rainerkrugsde
PGP: 0x0F52F982


signature.asc
Description: PGP signature

Re: test of math previews

2015-06-02 Thread Guillaume M-M


Le 02/06/2015 23:56, Enrico Forestieri a écrit :

On Tue, Jun 02, 2015 at 11:47:45PM +0100, Guillaume M-M wrote:


Le 02/06/2015 23:38, Enrico Forestieri a écrit :

On Tue, Jun 02, 2015 at 12:04:20AM +0200, Enrico Forestieri wrote:

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


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.


Unfortunately, this does not work if options are also used. LaTeX is
tricked into thinking that the package was already loaded but the used
options are not acknowledged and errors are thrown.
I have now followed a different and safe way for dealing with this issue
by redefining \usepackage and simply omitting microtype when in dvi mode.
This takes care of your example above (and also of other more contrived ones).



You are right! I just sent a message suggesting to pass the draft option to
microtype which should suffice according to the manual, unfortunately our
messages crossed each other.


BTW, that would still not work. \PassOptionToPackage only works if the
package is loaded without options.



I did the test, I wrote the following in the preamble:

\PassOptionsToPackage{draft}{microtype}
\usepackage[protrusion=true,expansion=true,tracking=true,kerning=true,spacing=true]{microtype}

and managed to compile in postscript and dvi without encountering any 
error (while it fails without the \PassOptions line).

Re: test of math previews

2015-06-02 Thread Guillaume M-M


Le 02/06/2015 23:38, Enrico Forestieri a écrit :

On Tue, Jun 02, 2015 at 12:04:20AM +0200, Enrico Forestieri wrote:

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


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.


Unfortunately, this does not work if options are also used. LaTeX is
tricked into thinking that the package was already loaded but the used
options are not acknowledged and errors are thrown.
I have now followed a different and safe way for dealing with this issue
by redefining \usepackage and simply omitting microtype when in dvi mode.
This takes care of your example above (and also of other more contrived ones).



You are right! I just sent a message suggesting to pass the draft option 
to microtype which should suffice according to the manual, unfortunately 
our messages crossed each other.

Re: test of math previews


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) /lib/x86_64-linu

Re: test of math previews


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

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 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

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

2015-06-01 19:34 GMT+02:00 Enrico Forestieri 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

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. (Unles

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

2015-05-31 Thread 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: LyX 2.1.4

2015-05-30 Thread Guillaume M-M


Dear Enrico,

It's quite strange, to me #9354 does not appear fixed at all! I just 
left a detailed comment in .


If I missed something please tell me what so that I can be more helpful 
in future testings.



Best regards
Guillaume

Le 30/05/2015 15:00, Enrico Forestieri a écrit :

On Fri, May 29, 2015 at 11:12:51AM -0400, Richard Heck wrote:



I'd like to start the 2.1.4 release process by freezing strings, etc. Any
fixes that need to go in before I do that?


What about http://www.lyx.org/trac/ticket/8258 ?

I have also attached a patch at http://www.lyx.org/trac/ticket/9371
that, by only touching the python scripts, would solve:
http://www.lyx.org/trac/ticket/6369
http://www.lyx.org/trac/ticket/9354
http://www.lyx.org/trac/ticket/9508
http://www.lyx.org/trac/ticket/9510

Re: math macro crashes again (bug 9490)

2015-05-15 Thread Guillaume M-M


On 05/15/15 10:04, Jean-Marc Lasgouttes wrote:

Le 14/05/15 22:31, Guillaume M-M a écrit :

My typical use case is to change the macro while keeping the same
arguments. In the absolute, it is easy to see that this can be useful
occasionally at least. Indeed, in the absence of macro-unfolding, the
alternative is to copy and paste the arguments one by one from the old
macro to the new macro. With unfolding, one just edits the name of the
macro, benefiting from name completion, etc.


I see it better now. It does not make much sense though that this is
possible with a macro and not with \frac.


I agree.




But, also, once one is aware of unfolding, one can start using it more
systematically, because one can define similar, but different, macros,
and switch between them when it is needed. (I can give you practical
examples if you want...) I currently do not know how to achieve
something similar without unfolding.


I would do that by putting different definitions of the same macro in
different branches. But this may not be exactly what you are after.


No indeed, I am speaking of something else. For instance we can use 
copy/paste on one equation because only a few details have to be 
changed. Or simply we can change our mind during the typesetting of a 
proof: writing an article does not go in a straight line.





In fact, I do not care so much about macro unfolding itself than the
possibility of changing the macro in-place (with name completion). Am I
missing anything?


I do not think you are missing something. Obviously, changing macro
would be possible as long as the parameters of the macros have the same
structure. But switching from a two parameters macro to a one parameter
one is trickier.


About toggling, they had this discussion before some years ago:
<http://marc.info/?l=lyx-devel&m=122071560319193&w=1>. I admit that I
don't use repeated unfolding so much. In addition, I do not use macro
folding because the macros folds itself automatically once the name is
changed. (But if other power users of unfolding and folding are reading
this they will surely speak up, right?)

I hope this clarifies.


Well it indeed clarifies that macro-unfold is a very weird concept :)


For these implementation details I agree---but if the question is "how 
do we change the name of a macro in a way that has the same features 
(e.g. completion) as inserting the macro in the first place", then the 
idea of unfolding is quite natural.


Sorry for not being familiar enough with the source code to make more 
constructive suggestions.



Guillaume

Re: math macro crashes again (bug 9490)

2015-05-14 Thread Guillaume M-M


On 05/14/15 20:37, Jean-Marc Lasgouttes wrote:

Le 14/05/2015 21:00, Georg Baum a écrit :

Jean-Marc Lasgouttes wrote:


I think I do not understand yet what an argumentproxy really is. Could
you explain that to me (again??)?


It is a dummy inset that can be used like a MathInset from outside, but
forwards every work to the math macro cell that it represents. This
allows
to store the expanded cells in a standard MathData, and it also allows to
manage the cells like any other math inset if they are detached from the
macro (well it would allow that if the bug we are currently discussing
would not exist).


Is there one per macro use or one per argument?


Would it make sense for the macro inset to hold a copy of the argument
proxy instead of a pointer? And then this copy would be somehow updated
as needed.


It is the other way round: The proxy holds a pointer to the math macro.


Could we make a copy of the macro, then?



What is math macro unfolding exactly?


In folded mode, the macro itself is not drawn unless you enter it,
then the
name is drawn in light grey at the top left corner. In unfolded mode, the
macro name is drawn like ERT, and you can change it.


I had to grep the code to understand how to unfold a macro. And now that
I have tried it, I am not so sure why it is useful. Moreover it uses
bindings that are not accessible with my french kbd. Why doesn't this
use inset-toggle? Why isn't macro-fold a toggle?

JMarc




Dear Jean-Marc,


"Macro power user" here, as Georg wrote...

My typical use case is to change the macro while keeping the same 
arguments. In the absolute, it is easy to see that this can be useful 
occasionally at least. Indeed, in the absence of macro-unfolding, the 
alternative is to copy and paste the arguments one by one from the old 
macro to the new macro. With unfolding, one just edits the name of the 
macro, benefiting from name completion, etc.


But, also, once one is aware of unfolding, one can start using it more 
systematically, because one can define similar, but different, macros, 
and switch between them when it is needed. (I can give you practical 
examples if you want...) I currently do not know how to achieve 
something similar without unfolding.


In fact, I do not care so much about macro unfolding itself than the 
possibility of changing the macro in-place (with name completion). Am I 
missing anything?


About toggling, they had this discussion before some years ago: 
<http://marc.info/?l=lyx-devel&m=122071560319193&w=1>. I admit that I 
don't use repeated unfolding so much. In addition, I do not use macro 
folding because the macros folds itself automatically once the name is 
changed. (But if other power users of unfolding and folding are reading 
this they will surely speak up, right?)


I hope this clarifies.


Best
Guillaume

Re: math macro crashes again (bug 9490)

2015-05-14 Thread Guillaume M-M


On 05/14/15 19:46, Georg Baum wrote:

Guillaume M-M wrote:


Thank you for looking at these bugs. I reported 9418 and 9490, and I use
macro unfolding quite often. Before discovering this feature, I would
occasionally edit the lyx file externally (!) to change certain macros.
Given that the original bug was about a crash occurring during
unfolding, the second solution is a bit like curing a pain by
amputation...


Sure. However, as I understand it now, this feature is not implemented in a
way that fits with the math inset infrastructure. I do not have the time for
a complete rewrite, and I honestly don't know what to do. At least I know
now that the fold/unfold feature is actually used.


I would really appreciate a long-term solution to the math macro bugs.
It would be useful to know whether many other people had segmentation
faults because of macros, because I suspect that these crashes have been
under-reported due to how hard they were to reproduce.


I believe that not so many people are macro power users. I would guess that
we would get many more reports otherwise.


Georg





Do you think that it would solve all the crashes currently happening due 
to macros, or would your solution only prevent crashes happening while 
unfolding?


Personally I would rather suffer from the occasional crash than losing 
unfolding... :)



Guillaume

Re: Problem whith Shaded menu

2015-05-14 Thread Guillaume M-M


On 05/14/15 16:25, hatim ali wrote:

Dear lyx team
Thank you for good job.
I used lyx 2.2 with ubuntu.
When i start lyx then dropdown any menu like File, Edit, Insert, i got
shaded commands, i mean the first 3 or 4 command in the list ( enable )
but others was disbale ( shaded - unable to click).
To resolve this problem, must change lyx interface language from
Preferences... > save, then retern to default languge then save.


Best regards



Dear Ali,

Could this be your problem? 
https://bugs.launchpad.net/ubuntu/+source/lyx/+bug/1430059


If so, then it is a bug with indicator-appmenu. I proposed a patch two 
weeks ago and we are waiting for the developer to look at it. In the 
meanwhile you'll find a workaround to disable the appmenu.



Best
Guillaume

Re: math macro crashes again (bug 9490)

2015-05-13 Thread Guillaume M-M


On 05/13/15 21:34, Georg Baum wrote:

Hi,

after a lot of debugging I understand now what happens in
http://www.lyx.org/trac/ticket/9490. As you may recall, the last math macro
crash I fixed (9418) was caused by a broken ArgumentProxy::mathMacro_
pointer. At that time, I assumed that the only place where an ArgumentProxy
can occur is as an element of MathMacro::d->expanded_ (which is also
indicated by the comment in ArgumentProxy::draw(). Under this assumption,
the fix for 9418 would have fixed all cases of invalid mathMacro_ pointers.

However, this assumption is not true. In MathData::detachMacroParameters(),
elements of MathMacro::d->expanded_ can be extracted and put into the same
vector as the macro itself. Unfortunately, if you insert an element into a
vector, the existing elements may be copied => pointers may become invalid.
The fix for 9419 does not work for this case, since the ArgumentProxy
instances in question are already extracted from the macro and stored in the
local variable detachedArgs.

It would be relatively easy to do a local fix in
MathData::detachMacroParameters(). However, since the detached ArgumentProxy
instances stay alive after leaving MathData::detachMacroParameters(), this
is not enough.

I tried to keep a record of each ArgumentProxy child in a new member of the
MathMacro itself. Then ArgumentProxy::setOwner() can be called reliably
whenever a copy of a MathMacro is made. This works fine, but exposes another
problem: When following the recipe of bug 9490, a MathMacro instance is
deleted in Undo::Private::doTextUndoOrRedo() while an ArgumentProxy pointing
to it is still alive.

What to do now? I don't know. I see the following options:

- Change the base class of MathData to RandomAccessList as proposed by Abdel
in the discussion of 9419. This would solve the invalid pointer problems,
but not the problem showed by the undo stack, and I fear that more hidden
problems like this one exist. To me it is now more clear than during the
discussion of 9418 that the "self-contained" property of a MathInset is
really really important and assumed implicitly all over the place. The
ArgumentProxy is not self-contained, and this is the root of all evil.

- Get rid of MathData::detachMacroParameters(). This would be a feature
regression: Unfolding a math macro would no longer be possible. Is this an
important feature?

- Rewrite ArgumentProxy to get rid of the mathMacro_ pointer (or even get
rid of the class ArgumentProxy). This is a big task.


Any other ideas? Preferences? Unless somebody has a brilliant idea I tend
towards the second item, since the first does not solve all problems, and
the last is too much work for me ATM.



Georg





Dear Georg,


Thank you for looking at these bugs. I reported 9418 and 9490, and I use 
macro unfolding quite often. Before discovering this feature, I would 
occasionally edit the lyx file externally (!) to change certain macros. 
Given that the original bug was about a crash occurring during 
unfolding, the second solution is a bit like curing a pain by amputation...


I would really appreciate a long-term solution to the math macro bugs. 
It would be useful to know whether many other people had segmentation 
faults because of macros, because I suspect that these crashes have been 
under-reported due to how hard they were to reproduce.


Thank you again for the hard work.


Best,
Guillaume

Re: LyX is broken on Ubuntu 15.04

2015-05-03 Thread Guillaume M-M

Hi Jean-Marc,

On 05/01/15 23:46, Jean-Marc Lasgouttes wrote:

Hi Guillaume,

I am in vacation this week, but I will look at what I can do next week. What
would be helpful is a description of what indicator happens expects. The menu
code in LyX has mostly been done in an empirical way.

In the meanwhile I looked a bit further, but I'll leave it there. See
<https://bugs.launchpad.net/ubuntu/+source/lyx/+bug/1430059>.

Apparently, dbusmenu is going to be deprecated anyway
<http://askubuntu.com/a/139925>. So I am happy if the previous behaviour
is just restored, as with the patch (for indicator-appmenu) that I proposed.

Your workaround is intriguing. Is there a general notion of global menu bar in
Qt? Currently we have special code for MacOS, it could maybe be expanded to
cover unity too.

You can have a look at g/qmenumodel <https://launchpad.net/qmenumodel>,
which is going to replace dbusmenu. Maybe that with qmenumodel you can
extend the code for MacOS to cover the Unity global menu. This would be
a nice feature, and maybe leave the current problems behind.

Another possibility is that we should react to some signals.

See <https://bugs.launchpad.net/ubuntu/+source/lyx/+bug/1430059>, it
seems unlikely.

Guillaume

JMarc

Le 30 avril 2015 02:12:15 CEST, Guillaume M-M a écrit :

Dear list,

The bug appeared in indicator-appmenu after the following commit:

<http://bazaar.launchpad.net/~indicator-applet-developers/indicator-appmenu/trunk.15.04/revision/267>

See
<https://bugs.launchpad.net/indicator-appmenu/+bug/1430059/comments/20>

for more details. I continued the discussion there because it is not
clear if the bug is in lyx or indicator-appmenu.

Scott, I am willing to test out any patch against master on 15.04.

In the meanwhile the workaround is to run lyx with the command line:
QT_X11_NO_NATIVE_MENUBAR=1 lyx

or to adapt /usr/share/applications/lyx.desktop as follows:
Exec=env QT_X11_NO_NATIVE_MENUBAR=1 lyx %F

Re: LyX is broken on Ubuntu 15.04

2015-04-29 Thread Guillaume M-M


On 04/30/15 01:12, Guillaume M-M wrote:

See
<https://bugs.launchpad.net/indicator-appmenu/+bug/1430059/comments/20>
for more details. I continued the discussion there because it is not
clear if the bug is in lyx or indicator-appmenu.


moved:
<https://bugs.launchpad.net/ubuntu/+source/lyx/+bug/1430059/comments/20>

(also in /ubuntu/+source/indicator-appmenu/)

Re: LyX is broken on Ubuntu 15.04

2015-04-29 Thread Guillaume M-M


On 04/25/15 07:18, Scott Kostyshak wrote:

Reported to lyx-users here:
https://www.mail-archive.com/lyx-users@lists.lyx.org/msg100825.html

Reported and confirmed by multiple users here:
https://bugs.launchpad.net/ubuntu/+source/lyx/+bug/1430059

I've reproduced this with both self-compiled and from the repos.

The reason for why the menus are greyed out is not because the LFUNs
are disabled. In fact, if you run the command on the minibuffer it
works just fine. The problem is that Menu::updateView() is not even
being called when I click on the menu categories. For example, usually
(when this bug does not appear, e.g. on Ubuntu 14.10)
Menu::updateView() is called twice every time I click on "Document" (I
would be curious to know by the way why it is called twice and not
once). But on 15.04 it is not called at all when I click on the
"Document" menu.

I have found a (partial) work around: if you press "alt" in Ubuntu it
brings up the HUD which searches the menu of the open application. For
example, if I press alt and then "sett" it shows me "Settings
(Document)", meaning that it found an entry under Document that
matches my search string. I can then press return and it is as if I
went to Document > Settings. After I open the HUD and type a letter,
all of the menus are refreshed (Menu::updateView() was called).
However, you have to do this each time you want the menus to be
refreshed.

Does anyone feel like using Virtual Box to test out LyX on 15.04?

Scott




Dear list,


The bug appeared in indicator-appmenu after the following commit:



See 
 
for more details. I continued the discussion there because it is not 
clear if the bug is in lyx or indicator-appmenu.


Scott, I am willing to test out any patch against master on 15.04.

In the meanwhile the workaround is to run lyx with the command line:
  QT_X11_NO_NATIVE_MENUBAR=1 lyx

or to adapt /usr/share/applications/lyx.desktop as follows:
  Exec=env QT_X11_NO_NATIVE_MENUBAR=1 lyx %F


Guillaume

Re: [ANNOUNCE] LyX 2.1.3 Released

Rainer M Krug  writes:

> For Mac:
>
> I just updated LyX on homebrew cask [1] to 2.2.3

Sorry - I was ahead of my time.

Should have been 2.1.3

Rainer

>
> Cheers,
>
> Rainer
>
>
> Richard Heck  writes:
>
>> We are proud to announce the release of LyX 2.1.3.  This is the third
>> maintenance release in the 2.1.x series.
>>
>> LyX is a document processor that encourages an approach to writing based
>> on the structure of your documents and not simply their appearance. It is
>> released under a Free and Open Source Software license.
>>
>> You can download LyX 2.1.3 from http://www.lyx.org/Download/.
>>
>> LyX 2.1.3 is the result of on-going efforts to make our stable version
>> even more reliable and stable. We have fixed a number of bugs and made
>> a number of improvements. These are detailed below. We strongly encourage
>> all LyX users to upgrade to this version.
>>
>> If you think you have found a bug in LyX 2.1.3, open a bug report at
>> http://www.lyx.org/trac/wiki/BugTrackerHome. If you're not sure whether it
>> really is a bug, you can e-mail the LyX developers' mailing list (lyx-devel
>>  lists.lyx.org) and ask.
>>
>> If you have trouble using LyX or have a question, consult the
>> documentation that comes with LyX and the LyX wiki, which lives at
>> http://wiki.lyx.org/. If you can't find the answer there, e-mail the LyX
>> users' list (lyx-users  lists.lyx.org).
>>
>> We hope you enjoy using LyX 2.1.3.
>>
>> The LyX team.
>> http://www.lyx.org
>>
>>
>> What's new
>> ==
>>
>> ** Updates:
>> ***
>>
>> * DOCUMENT INPUT/OUTPUT
>>
>> - Add support for some conference poster classes (a0poster, beamerposter,
>>   sciposter) (bug 8714).
>>
>> - Add support for the sectionbox and tcolorbox packages (part of bug 8714).
>>
>> - Add support for PDF annotations (via pdfcomment package) (bug 6975).
>>
>>
>> * TEX2LYX IMPROVEMENTS
>>
>> - Support for bibliographies using the package bibtopic.
>>
>> - Support for textual references (LaTeX-command \namref from the package
>>   nameref).
>>
>> - Support for items in itemize environments that have an optional argument.
>>
>> - Support for the math font of the Iwona and Kurier font families.
>>
>> - Support for the Libertine fonts.
>>
>> - Support for a relative length as paragraph separation.
>>
>> - Support for relative lengths in horizontal and vertical spaces.
>>
>> - Support for glue lengths in horizontal and vertical spaces.
>>
>>
>> * USER INTERFACE
>>
>> - References no longer truncated in outliner (bug 9312).
>>
>> - Allow computing selected subformulas with computer algebra systems.
>>
>> - Number correctly footnotes in title layouts (part of bug 2666).
>>
>> - Ctrl+A is now bound to inset-select-all, which does a local
>>   selection (current inset) and grows at each new invokation. Try it!
>>
>> - Debug options in message pane are now sorted alphabetically.
>>
>>
>> * DOCUMENTATION AND LOCALIZATION
>>
>> - New example file "PDF-comment.lyx" describing the support for PDF
>> annotations.
>>
>> - Updated Arabic, French, German, Japanese, Portuguese, Slovak and Swedish
>>   user interface localization.
>>
>>
>> ** Bug fixes:
>> *
>>
>> * DOCUMENT INPUT/OUTPUT
>>
>> - Fix crash on exporting a recursive math macro (bug 9140). Recursive macros
>>   are invalid, so typesetting will still fail with "TeX capacity exceeded".
>>
>> - Fix baseline calculation in last paragraph (bug 9231).
>>
>> - Fix export of xfig external insets (bug 9244).
>>
>> - Fix incorrect output of ampersands when multiple keys are given for a
>>   citation (bug 9296).
>>
>> - Output package options (specified with PackageOptions layout tag)
>>   before loading any potentially affected package (bug 9355).
>>
>> - Fix export of documents that use the LaTeX-packages mhchem and wasysym
>>   (bug 9266).
>>
>> - Remove unnecessary preamble code in LaTeX export of documents using the
>>   class REVTeX 4.1 file (bug 4625).
>>
>> - Fix for improper environment with duplicate PATH variable entries.
>>   This happens on Mac OS X 10.10 (Yosemite) where launchd(8) passes
>>   such an environment to LyX when started from the dock (bug 9317).
>>
>> - Protect insets when needed in subfloat captions (bug

Re: View/compile reduced size PDF within LyX

Liviu Andronic  writes:

> On Thu, Feb 12, 2015 at 9:41 AM, Rainer M Krug  wrote:
>> Liviu Andronic  writes:
>>
>>> On Tue, Feb 10, 2015 at 12:04 AM, James  wrote:
>>>>>
>>>>
>>>> On a similar note, AFAIK most of the size reduction comes from Ghostscript
>>>> reducing the size of the raster images and those with raster components. 
>>>> The
>>>> next level of usability (beyond using a converter on a whole document) 
>>>> would
>>>> be to have an option within the figure float setting or graphic dialogue 
>>>> box
>>>> that gave a second option for "draft mode" (i.e. an option that still
>>>> included the image, but at a draft appropriate resolution if a reduction is
>>>> possible for that graphic).
>>>> Of course, there would then be a need for a method to un-select all 
>>>> graphics
>>>> with the option selected in bulk for final compilation.
>>>>
>>> IMO this would be messy (and  ineffective). Nicer  would be  a
>>> dedicated Document > Settings option that would allow to choose a
>>> specific downscaling level, and that LyX would honor at compile time.
>>> If this is feasible, this would avoid adding new converters in File >
>>> Export. But this solution is more involved than simply adding an
>>> additional converter...
>>
>> This would not be messy, if one would also have a document wide option
>> with the possibility to set all image specific values.
>>
>> This would be similar to e.g. PowerPoint (at least it was when I last
>> used it about 10 years ago...). You can set a "reduced size" for each
>> image, or for the whole document.
>>
>> Advantage: you can have graphs in full resolution, but images reduced.
>>
>> Main difference: the reduction in size would be done by the image
>> copiers.
>>
>> Now let's think further:
>>
>
>
>> In my case, I have quite often huge vector graphs (pdf), as they contain
>> hundreds of thousands of points. Now these are easy to generate in R and
>> also quite easy to view for themselves, but they can cause problems with
>> displaying (and size I guess if there are to many points). In these
>> cases, an option to convert the vector graph to an image of a given
>> resolution (the one used for the target resolution above?) would make
>> life much easier.
>>
>
> I think this sounds interesting. Maybe worth opening a feature request
> on Bugzilla.

Done - http://www.lyx.org/trac/ticket/9405

Thanks,

Rainer

>
>
> Liviu
>
>
>> Cheers,
>
>>
>
>> Rainer
>>
>>
>>>
>>> Liviu
>>
>> --
>> Rainer M. Krug
>> email: Rainerkrugsde
>> PGP: 0x0F52F982

-- 
Rainer M. Krug
email: Rainerkrugsde
PGP: 0x0F52F982


signature.asc
Description: PGP signature

Re: [ANNOUNCE] LyX 2.1.3 Released

; - Maintain paragraph settings (alignment etc.) when importing chunk layouts
>   (bug 9320).
>
> - Fix export to LyX 2.0 of chunk insets without optional argument (bug
> 9343).
>
> - Fix import of ERT beamer block titles which are preceeded by a
>   language switch.
>
> - Fix and simplify paragraph params parsing in get_containing_layout.
>
>
> * USER INTERFACE
>
> - Fix alignment rendering of multirow in LyX (bug 8976).
>
> - Fix mapping of ISO_Left_Tab key, which was erroneously assigned to Tab
>   (instead of BackTab).
>
> - Disallow to insert program listings to footnotes and margin notes
> (bug 9321).
>
> - Fix computer algebra system computations in formulas with '=' signs.
>
> - Fix rendering of \varOmega on OS X (bug 7954).
>
> - Only allow 1 paragraph in footnotes when they are part of a title
>   layout (bug 2666).
>
> - When switching classes, warn user about all unapplied document changes
>   (1. part of bug 9356).
>
> - When adding a module, warn user about all unapplied document changes
>   (2. part of bug 9356).
>
> - Do not enable the Apply button in the document dialog just because a
>   module was selected in the widget (without actual change) (bug 9365).
>
> - Fix logic of "Maintain aspect ratio" checkbox in the graphics dialog
>   (bug 9357).
>
> - Fix most frequent reason for crash while editing with open view source
>   window (bug 9336).
>
> - Fix crash when pasting citation into math formula (bug 9302).
>
>
> * INTERNALS
>
> - Fix wrong test in LyX server.
>
> - Fix possible memory corruption on copying to the clipboard.
>
> - Fix possible memory corruption during LaTeX log file parsing.
>
> - Make some math messages translatable (bug 1908).
>
>
> * DOCUMENTATION AND LOCALIZATION
>
> - Fix language settings for all IEEEtran templates (bug 9350).
>
> - The template document for REVTeX 4.1 has been rewritten.
>
>
> * LYXHTML
>
> - Fix export of \ll, \gg, \ne and \neq in math formulas (bug 9372).
>
>
>
> * TEX2LYX
>
> - Do not ignore table columns with unknown column specifiers (bug 9311).
>
> - Parse tikzpicture environment correctly (bug 9011).
>
> - Fix misparsing of \textgreek without polyglossia (bug 8553).
>
> - Parse post command argument insets (bug 8473).
>
> - Parse parsing of verbatim options containing commands (bug 9113).
>
>
>
> * BUILD/INSTALLATION
>
> - Fix some compiler warnings.
>
> - Fix a few minor issues in the RPM spec file template (bug 9349).
>
>


Footnotes: 
[1]  https://github.com/caskroom/homebrew-cask

-- 
Rainer M. Krug
email: Rainerkrugsde
PGP: 0x0F52F982


signature.asc
Description: PGP signature

Re: View/compile reduced size PDF within LyX

Liviu Andronic  writes:

> On Tue, Feb 10, 2015 at 12:04 AM, James  wrote:
>>>
>>
>> On a similar note, AFAIK most of the size reduction comes from Ghostscript
>> reducing the size of the raster images and those with raster components. The
>> next level of usability (beyond using a converter on a whole document) would
>> be to have an option within the figure float setting or graphic dialogue box
>> that gave a second option for "draft mode" (i.e. an option that still
>> included the image, but at a draft appropriate resolution if a reduction is
>> possible for that graphic).
>> Of course, there would then be a need for a method to un-select all graphics
>> with the option selected in bulk for final compilation.
>>
> IMO this would be messy (and  ineffective). Nicer  would be  a
> dedicated Document > Settings option that would allow to choose a
> specific downscaling level, and that LyX would honor at compile time.
> If this is feasible, this would avoid adding new converters in File >
> Export. But this solution is more involved than simply adding an
> additional converter...

This would not be messy, if one would also have a document wide option
with the possibility to set all image specific values.

This would be similar to e.g. PowerPoint (at least it was when I last
used it about 10 years ago...). You can set a "reduced size" for each
image, or for the whole document.

Advantage: you can have graphs in full resolution, but images reduced.

Main difference: the reduction in size would be done by the image
copiers.

Now let's think further:

In my case, I have quite often huge vector graphs (pdf), as they contain
hundreds of thousands of points. Now these are easy to generate in R and
also quite easy to view for themselves, but they can cause problems with
displaying (and size I guess if there are to many points). In these
cases, an option to convert the vector graph to an image of a given
resolution (the one used for the target resolution above?) would make
life much easier.

Cheers,

Rainer

>
> Liviu

-- 
Rainer M. Krug
email: Rainerkrugsde
PGP: 0x0F52F982

signature.asc
Description: PGP signature

Re: Double word bug - LyX is duplicating random words

2015-02-02 Thread Rainer M Krug

James Smith  writes:

> Jean-Marc Lasgouttes Sun, 01 Feb 2015 14:44:19 -0800
>
> That's terribly weird. Could this be completion playing tricks?
> Although I do not see this happening.Can you give us details (LyX
> version, platform...). We never had a report like this one.If you want
> to find all these occurrences in your document, I guess it is possible
> with advanced search and replace and regular expressions.
>
> Using a regular expression worked well a treat to find the double words. I
> had a feeling I could programmatically use the feature but didn't know how
> to implement the search like that.
>
> I have now removed all that were in the master document and will now see if
> I can trace when and how any new occurrences are introduced.
>
> For others reference, the way to find double words in the Advanced Find and
> Replace is with a user defined regular expression that contains:
>
> [[:space:]]([[:alpha:]]+)[[:space:]]\1[[:space:]]
>
> The code was found buried in the 2.1.1 User guide.
>
> Re. The actual double word bug.
> I'm updating to LyX 2.1.2 and hoping that the bug has been inadvertently
> fixed.
> But if it hasn't, now that I have been able to find the double words and
> remove them I should be able to tell if the duplication is related to new
> keystrokes or whether it is the bug is more spurious.

Please correct me if I am wrong:
I assume that if auto-correct or auto-complete is the cause, you should
see certain words being duplicated, while if it is something else, it
might be random words. 

So knowing which words they are, might be useful in finding out what
caused it?

Rainer

>
> Cheers
> James

-- 
Rainer M. Krug
email: Rainerkrugsde
PGP: 0x0F52F982


signature.asc
Description: PGP signature

Re: [PATCH] LyX HiDPI support in OS X with Qt 5

2014-10-15 Thread Rainer M Krug

Stephan Witt  writes:

> Am 14.10.2014 um 09:15 schrieb Rainer M Krug :
>
>> Let me chime in here as a non-lyx-programmer, but lyx user on a mac.
>> 
>> I am sure there is a lot of interest among mac users for this patch. I
>> also understand that it is not yet in a usable state, but when it is,
>> would it be possible to make an unofficial dmg for mac users, so that
>> this can be tested widely? As I understand, not many active developers
>> of lyx are mac users, so a dmg would enable a much wider audience to
>> test this. If it is only available as source, I don't thnik many mac
>> users would compile it, unless it is put on homebrew…
>
> Hi Rainer,
>
> you're right. I thought I'll provide an unofficial disk image with retina
> support until the release of a final retina ready version is done.

Great - sounds good.

> That was my plan already, but...

There is always a *big but* in the end ...

>
> This feature requires Qt5 and LyX gets Qt5-support with 2.2.0. That's a
> problem. Finally it's not only the question if retina-support is ready -
> that's possible in reasonable time. The question is: when is it possible
> to make a 2.2.0 release! Currently there isn't even a maintainer for it.
>
> Therefore this disk image with retina support will be something like a
> unofficial release - I'd guess many Mac users are tempted to try it out
> and then they don't want to go back - not even for production!

This might be risky. To see if the retina support is ready, one option
would be to disable e.g. the save function and make it visible in the
running instance that it is for testing the display issues *only* and *not* for
production?

Cheers,

Rainer

>
>> Scott Kostyshak  writes:
>> 
>>> On Mon, Oct 13, 2014 at 7:38 AM, Stephan Witt  wrote:
>>> 
>>>> I'm trying to verify my changes on Linux.
>>> 
>>> Thank you!
>>> 
>>>> What are others doing to build LyX with Qt5 on Linux?
>>> 
>>> You can see my build script here:
>
> Thank you for the pointers.
>
>>> 
>>> https://github.com/scottkosty/lyx-tester/blob/master/lyxbuild
>>> 
>>> If you want, you can have a completely automatic installation of
>>> dependencies and building of LyX starting from a fresh Ubuntu
>>> installation with one command:
>>> https://github.com/scottkosty/lyx-tester
>>> I only recommend that on a virtual box though. It has not been tested
>>> except for me (although I use it regularly).
>>> Note that the script will also run all the ctests, which takes a long
>>> time (I can disable this for you if you want though). Thus, if you do
>>> try this, you might want to leave it overnight.
>>> 
>>> I'd be happy to add support into the script of building Qt from source
>>> if that would help.
>>> 
>>> I've been using 14.04 since it came out. I don't know if there's
>>> anything that requires it, but let me know if you have problems and
>>> I'll take a look.
>
> I've updated my Ubuntu (running in a virtual machine) to 14.04 - but this
> didn't solve my problem. With the Qt4 from Ubuntu it looks ok, though.
>
> I cannot use your scripts to test my changes - they're not in git yet.
> But I've studied the scripts and think I don't need the full blown TeX
> environment to see the rendering of LyX file content on screen.
>
> I cannot find a precompiled Qt5 for Ubuntu 14.04 - where should I look?
>
> Stephan

-- 
Rainer M. Krug
email: Rainerkrugsde
PGP: 0x0F52F982


pgpKaosTuffZ2.pgp
Description: PGP signature

Re: [PATCH] LyX HiDPI support in OS X with Qt 5

2014-10-14 Thread Rainer M Krug

Let me chime in here as a non-lyx-programmer, but lyx user on a mac.

I am sure there is a lot of interest among mac users for this patch. I
also understand that it is not yet in a usable state, but when it is,
would it be possible to make an unofficial dmg for mac users, so that
this can be tested widely? As I understand, not many active developers
of lyx are mac users, so a dmg would enable a much wider audience to
test this. If it is only available as source, I don't thnik many mac
users would compile it, unless it is put on homebrew...

Cheers, and I am really looking forward to lyx on retina,

Rainer

Scott Kostyshak  writes:

> On Mon, Oct 13, 2014 at 7:38 AM, Stephan Witt  wrote:
>
>> I'm trying to verify my changes on Linux.
>
> Thank you!
>
>> What are others doing to build LyX with Qt5 on Linux?
>
> You can see my build script here:
>
> https://github.com/scottkosty/lyx-tester/blob/master/lyxbuild
>
> If you want, you can have a completely automatic installation of
> dependencies and building of LyX starting from a fresh Ubuntu
> installation with one command:
> https://github.com/scottkosty/lyx-tester
> I only recommend that on a virtual box though. It has not been tested
> except for me (although I use it regularly).
> Note that the script will also run all the ctests, which takes a long
> time (I can disable this for you if you want though). Thus, if you do
> try this, you might want to leave it overnight.
>
> I'd be happy to add support into the script of building Qt from source
> if that would help.
>
> I've been using 14.04 since it came out. I don't know if there's
> anything that requires it, but let me know if you have problems and
> I'll take a look.
>
> Best,
>
> Scott
>

-- 
Rainer M. Krug
email: Rainerkrugsde
PGP: 0x0F52F982

pgpbjz_r8Fft6.pgp
Description: PGP signature

Re: Backtrace from Mystery Crash

2014-06-23 Thread Rainer M Krug


Just thinking - the sizes of the binaries with and without symbols seem
to be the same. Wouldn't it be an option to always build as an
unstripped binary, so that backtraces could easily be created, and
possibly even automatically (after approval by the user, obviously) be
mailed after a crash?

Rainer

Stephan Witt  writes:

> Hi John,
>
> I've put the package with the unstripped LyX binary here:
>
> https://dl.dropboxusercontent.com/u/27842660/LyX-2.1.0-unstripped%2Bqt4-cocoa.dmg.sig
> https://dl.dropboxusercontent.com/u/27842660/LyX-2.1.0-unstripped%2Bqt4-cocoa.dmg
>
> It's made from the same tarball as the official 2.1.0 LyX I've made in April 
> 2014.
>
> Stephan
>
> Am 22.06.2014 um 16:48 schrieb jken...@ssc.wisc.edu:
>
>> Pavel:
>> 
>> Yes, I'm happy to cooperate on this in any way I can (I use LyX every
>> day, and I owe you guys big). But this crash is rare, so it might be a
>> while before it happens again.
>> 
>> John
>> 
>>> John Kennan wrote:
>>>> Yes, please attach your crash report here, if possible.
>>>> 
>>>> http://www.lyx.org/trac/ticket/9049
>>>> 
>>>> If you don't have an account and don't want to create one
>>>> you can sent it to the list, of course.
>>> 
>>> We need backtrace with debug symbol on, this is not much helpful.
>>> John, if you
>>> are willing to cooperate on this bug Stephan might be able to produce
>>> binary
>>> with debug symbols from the current 2.1.x branch for you?
>>> 
>>> Pavel
>>> 
>> 
>> 
>

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

PGP: 0x0F52F982


pgpI3tJSWAiJR.pgp
Description: PGP signature

Re: Python Graphics in LyX [was: Python bindings]

2014-06-10 Thread Rainer M Krug

"Alex Vergara Gil"  writes:

> Dear Lyxers!
>
> Studying a little of python and LyX I have reached to this feature
> that makes LyX show and process python graphics. Thanks to Rainer M
> Krug for the hints. I share this contribution for LyX under LGPL
> license, so everyone benefits from it. Good luck and happy lyxing!
>
> Alex Vergara Gil
> MSc Nuclear Physics
> SSDL, CPHR, Havana Cuba
>
> PS: If Rainer agree, pass him from acknowledgements to author list, please.

That looks beautiful. AS I have no idea how python works, co-author
would probably better.

Thanks,

Rainer


>
>
>
>

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

PGP: 0x0F52F982


pgpjlZVv0m2yJ.pgp
Description: PGP signature

Cross-posting on devel and

2014-06-02 Thread Rainer M Krug

Hi

There is recently a lot of cross-posting happening on lyx-devel and
lyx-users which I think is a bit irritating and makes following
discussions difficult (luckily, and this includes myself, most
responders to cross-posted threads ignore that one should not cross-post
and discussions are complete on both lists...).

Nevertheless, I would like to know what the policy about cross-posting
is. If cross-posting is OK, the merging of the two mailing lists should
be considered, which might be a good idea in a relatively low traffic
mailing list? The other option would be to discourage cross-posting,
possibly even blocking mails to lyx-devel which are also posted to
lyx-users?

I am not a list administrator and I don't want to start a big
discussion, so if nobody else objects, the status quo can be kept,

Cheers,

Rainer


-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

PGP: 0x0F52F982


pgp6RUxCE4ugM.pgp
Description: PGP signature

Re: [Feature Request] python binding

2014-06-02 Thread Rainer M Krug

"Alex Vergara Gil"  writes:

> From: "Richard Heck" 
> Sent: Thursday, May 29, 2014 5:05 PM
>>> I might be *completely* off, but couldn't you achieve exactly this via
>>> defining converters? I have for example a converter defined, which
>>> "converts" plantuml source fields into uml graphs, i.e. it defines the
>>> call to compile them and return the graphs which are then inserted in
>>> the document?
>> 
>> Yes, that's more or less what I was suggesting.
>> 
>> rh
>> 
>

I just add comments inline

> Let's see if I understand:

-1. You define a *file type* in LyX under 
  Preferences > File Handling > File Formats
for the file type .pygr in which "Vector graphics format" is ticked!

0. You define a converter under
  Preferences > File Handling > Converters
which calls a script which executed files with the extension .pygr and
generates, as you suggest below, an svg.

> 1. I wrote a python script that produces the graphic I want

Exactly - and you give it a specific extension .pygr for "python
script which generates a graphic" which you defined above.

> 2. I insert it in LyX somehow I don't know, perhaps defining a
> converter from .py to svg, but this needs to be inside a module or
> every python script in LyX will try to be converted into a svg!! So a
> module is also needed

Use insert graphic and select *your .pygr* file as graphic - and Lyx
will do the rest of the conversion - i.e. use your converter to convert
the .pygr to an svg and other existing converters to generate the png
for the preview and the pdf / eps / ... for the final copmpilation of
the document.

> 3. LyX is the one who knows the correct size of the graphic so in
> principle if I produce a svg should be enough but in this way I need
> to produce a new svg every time the data change

Correct - if the input data changes, you have to generate the graph again
manually, or, if the "Converter file cache" is disabled, you just have
to close the document and open it again. 

Hope this helps,

Rainer

>
> Take this simple script as example
>
> import numpy as np
> from numpy.random import randn
> import matplotlib as mpl
> import matplotlib.pyplot as plt
> np.random.seed(9221999)
> data = randn(75)
> plt.hist(data)
>
> which produce a graphic like this in spyder
>
>
>
> So basically I save this graphic to a svg and then I load it into LyX,
> but why not letting LyX doing this automatically if it already handles
> with python?? This is my question.
>
> Regards
>
> Alex

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

PGP: 0x0F52F982


pgp4Tu7FsXx7J.pgp
Description: PGP signature

Re: [Feature Request] python binding

2014-05-29 Thread Rainer M Krug

"Alex Vergara Gil"  writes:

>   From: Richard Heck 
>   Sent: Thursday, May 29, 2014 3:26 PM
>
>
>   On 05/29/2014 03:36 PM, Alex Vergara Gil wrote:
>
> Hello Lyxers
>
> I wonder why LyX is not available to process little pieces of
> python code within its own framework, like ipython notebook for
> instance??
>
>
> This feature allows us to have beautiful graphics such the one
> produced by matplotlib package. I know there already exists a
> similar binding for R through knitr module, so why not a binding
> for python too??
>
> Is there a way, like modules or whatever, to achieve the same
> functionality or at least some basic functionality of ipython notebook
> within LyX??  Can you be more precise about what you want to do? I've
> never heard of ipython notebook.  sudo aptitude install
> ipython-notebook ipython notebook
>
> and there you can write even thesis in a web environment with python
> commands being executed inlined, exporting to pdf and latex too, it is
> a wonder of our times, so why not letting LyX do this miracle too??
>
>   Sweave works by our having an output format (sweave) for such
>   documents and then our declaring Rscript as a sweave --> LaTeX
>   converter, so PDF export (say) goes via Rscript and
>   pdflatex. There's a special script in lib/scripts/ that "sets up
>   some things for LyX" first, or so it claims. It would be reasonably
>   easy to do the same sort of thing for Python, if you wanted to do
>   so. You'd just need to set up an appropriate format and then declare
>   an appropriate script as a whatever -> latex converter. Then LyX
>   will run the script and do as you wish with the embedded python
>   code.
>
>   Of course, as we've discussed on the list with respect to R, there are 
> large security issues here, too.
>
>   Richard you obviously miss the point here, or I was not very clear!
> it is not a different format, is a facility to have python scripts
> running within LyX framework, you have to see ipython notebook to
> understand what I mean, you will be surprised!!  Basically to build
> graphs, for instance (and only a piece of what can be done), you add
> the (let's call it) "knitpy" module and then place a knitpy insert,
> write some python code that produces a matplotlib graphic and then
> when lyx compiles the document, instead of the code it is shown the
> graph, it also can be done in the lyx editing window, but thats a more
> dificult request.

I might be *completely* off, but couldn't you achieve exactly this via
defining converters? I have for example a converter defined, which
"converts" plantuml source fields into uml graphs, i.e. it defines the
call to compile them and return the graphs which are then inserted in
the document?

I have never used python, but I guess a similar approach should be
possible here as well?

Cheers,

Rainer


>
> Regards
> Alex

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

PGP: 0x0F52F982


pgpK0dzVm8JCx.pgp
Description: PGP signature

Re: In TeX Live 2014, 3 example files will not export with LuaTeX/XeTeX

2014-05-23 Thread Rainer M Krug

Cyrille Artho  writes:

> Liviu Andronic wrote:
>> On Thu, May 22, 2014 at 10:12 AM, Jean-Marc Lasgouttes
>>  wrote:
>>> 22/05/2014 08:09, Cyrille Artho:
>>>
>>>> Hi Scott, Thanks for your work in keeping the packages working. I'm
>>>> still using foils (foiltex) so I'm very happy if it can be kept
>>>> working for a long time. In fact, I was not aware that it is no
>>>> longer maintained. That's too bad because I think I'm not the only
>>>> one who still uses it.
>>>>
>>>> In my personal opinion, beamer uses too many boxes and does not look
>>>> good if you use a lot of figures/images on the slides. Beamer slides
>>>> may look better for text-only slides but those slides are boring to
>>>> begin with ;-)
>>>
>>>
>>> Yes, I depend on foils to. I tried beamer for my last presentation
>>> (because I needed its slide animation features), but I really did not
>>> like it. Too much bling for my taste.
>>>
>> I also have issues with all the bling that comes with Beamer by
>> default, but with some few Beamer config tweaks all the bling can be
>> toned down significantly. This is why I came up with a series of
>> "simple" Beamer examples on the wiki:
>> http://wiki.lyx.org/Examples/Beamer

I just wanted to take a look at them, and all produce an error when
opening from LyX (LyX Version 2.1.0 (13 Apr 2014)) on a Mac.

,
| 
/var/folders/50/wcr5bjwn75q595n6x82gxj28gn/T/lyx_tmpdir.twUHvMRS5559/Buffer_convertLyXFormatXX.lyx.kSameUIi5559
| ended unexpectedly, which means that it is probably corrupted.
`

I though that the conversion by lyx2lyx is the problem, but that one
works without problems.

I attach the converted file (from [1]).

Ironically, all non-simple beamer presentations open without
error... conspiracy? :-)

Cheers,

Rainer


new.lyx
Description: Converted from beamer-simple.lyx


>>
>> Most changes are obtained very easily via simple Beamer calls in the
>> Preamble.
>>
>> Liviu
>>
>>
>>> OTOH, I reckon that foilTeX slides can be a bit ugly, and I'd welcome
>>> another option.
>>>
>>> JMarc
>>>
> Hi Liviu,
> Thanks for the links. IMHO even the "simple" style is rather heavyweight
> for the boxes (with shadows etc.). I think the trend is now towards
> cleaner, simpler layouts with no 3 D effects, and only as few
> lines/boxes/frames/background colors as absolutely needed.
> In that sense, what was done by necessity 15 years ago when doing slides in
> LyX/TeX is now again in fashion ;-)
>
> Why FoilTeX works for me (sorry if this is getting off-topic):
>
> For my own slides, I change the bullet symbol and title color in FoilTeX
> but otherwise use it without changes. Whenever possible, I avoid bullet
> lists in the first place but of course I don't always have enough time to
> get rid of enumerations. I never use "striptease slides" as the audience
> tends to squint, trying to read the grey text on white, while not listening
> to the speaker. IMHO if you use a "striptease slide", then you have failed
> in the design and should create 2 - 3 separate (but incremental) slides
> instead. Note that these may repeat a figure (with modifications) but
> should not repeat the entire text as you'd otherwise again end up with a
> wall of text.
>
> In short, beamer can make a wall of text look relatively pretty, and
> this may work for a couple of minutes, but after that one realizes
> again that walls of text are not suitable for presentations. Without
> that, the most compelling features of beamer are not needed anymore.


Footnotes: 
[1]  http://wiki.lyx.org/uploads/Examples/Beamer/Liv/beamer-simple.lyx

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

PGP: 0x0F52F982


pgpwkpIzHZ0Js.pgp
Description: PGP signature

Re: Feature: open pdf from right click on citation inset ?

2014-05-07 Thread Rainer M Krug

Jean-Marc Lasgouttes  writes:

> 07/05/2014 09:41, Rainer M Krug:
>>> I would like to be able to right click on a citation and be able to
>>> click on "open pdf". The filenames of the papers I cite are all stored
>>> with the author field of the BibTeX (followed by the extension
>>> ".pdf"). Thus, I would just need to input the folder location into a
>>> LyX document setting, and the feature would work.
>>
>> Interesting idea - and useful. But I would see it as a two step process:
>>
>> 1) right click - see bibtex entry
>> 2) click on "file" field in the bibtex entry to see the pdf. In the same
>> way, on could open URL to see the paper online.
>
> This seems more complicated for no real reason. You basically have the
> information when hovering. 

Ups - must have missed this - sorry.

> However, having a new menu entry "see
> document" when there is a "pdf" or "postscript" or "url" entry (and
> the ps or pdf file actually exists) would be neat.

Yes - that would be neat - selecting which one could be useful, as they
could contain different versions or documents (article, supplements, ...).

>
> When trying this out, I have a weird situation. I include a Bibtex
> inset, pick bilbiography style "plain"; when I insert a Cite inset,
> the only form that I can pick is one that shows the whole citation
> like "Smith & Wesson (2002) In the Head: How to Get it Right Every
> time, Springer"
>
> How come I cannot have a plain [1]?
>
> JMarc
>

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

PGP: 0x0F52F982


pgp3TGTk2z_ke.pgp
Description: PGP signature

Re: Feature: open pdf from right click on citation inset ?

2014-05-07 Thread Rainer M Krug

Scott Kostyshak  writes:

> My first guess is that not many others would find this idea useful,
> but I figured it's worth an email to see if I'm wrong.

It is.

>
> I would like to be able to right click on a citation and be able to
> click on "open pdf". The filenames of the papers I cite are all stored
> with the author field of the BibTeX (followed by the extension
> ".pdf"). Thus, I would just need to input the folder location into a
> LyX document setting, and the feature would work.

Interesting idea - and useful. But I would see it as a two step process:

1) right click - see bibtex entry
2) click on "file" field in the bibtex entry to see the pdf. In the same
way, on could open URL to see the paper online.

>
> I'm guessing this feature might not make sense to be in LyX. I'm
> expecting a response of "use JabRef" or another bibliography manager
> that does that for me.

I think this is not a "managing bibtex files" issue for Jabref et al. and could 
definitely has its place in LyX.

+1

Rainer

>
> Any thoughts?
>
> Scott

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

PGP: 0x0F52F982


pgpSC0jwlKd7V.pgp
Description: PGP signature

Re: Feature request

2014-04-25 Thread Rainer M Krug

Scott Kostyshak  writes:

> On Thu, Apr 24, 2014 at 1:29 PM, Pavel Sanda  wrote:
>> Scott Kostyshak wrote:
>>> Another problem is that some mailing lists require/encourage "quote
>>> prior messages in entirety" (e.g.
>>
>> It makes any longer exchange unreadable.
>
> Agreed.
>
>> When involved in the exchange I usually care to strip it no matter what the
>> other party does, but anyway it's not nice to let other people do your 
>> work...
>
> My point is that I think many do it out of ignorance, not laziness. At
> least that was the case for me. I wish someone had told me sooner. In
> the end it is my fault for not having remembered the list netiquette.

Gmail has folding, Thunderbird has folding, GNUS has folding, and I
assume most email clients have folding / hiding of quotes.

As stated, some mailing lists wish to have the whole thread, to make
reading a reply separately possible. 

Snipping of sections I do not reply to is OK, but selectively snipping
out of sections I reply to make it possible to change the original
meaning. 

So I think no snipping is not a major problem.

Rainer

>
> Scott

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

PGP: 0x0F52F982


pgp5RWA1JYiz0.pgp
Description: PGP signature

Re: #7631: Page tabs disappear with table tools

2014-04-23 Thread F M Salter


I have checked that this behavior does not occur with 2.1rc1.
However the ticket appears not to be accessible through the bug tracker.
Regards
Frank Salter

On 20/04/14 19:42, LyX Ticket Tracker wrote:

#7631: Page tabs disappear with table tools
--+-
  Reporter:  fmsalter  |   Owner:  nobody
  Type:  defect|  Status:  new
  Priority:  normal|   Milestone:  2.1.x
Component:  frontend-qt4  | Version:  2.0.0
  Severity:  normal|  Resolution:
  Keywords:|
--+-
Changes (by rgheck):

  * milestone:  2.0.x => 2.1.x


Comment:

  LyX 2.0.8 is released, so all 2.0.x bugs are being retargeted to 2.1.x. If
  this is your bug, please check whether the 2.1.x milestone makes sense
  and, if not, remove it.

Re: GSoC: Overhauling LyX's converter scheme

2014-03-12 Thread Rainer M Krug

Jean-Marc Lasgouttes  writes:

> Le 11/03/2014 10:10, Roy Xia a écrit :
>> Hi everyone,
>
> Hello,
>
>> I suppose my first question to you all is whether there are
>> any alternative suggestions or additional goals out there for
>> overhauling the converter scheme.
>
> To be frank I am not sure yet. We have some bugs in the current code,
> like: a sweave document[*] (that outputs Tnw, and should follow a
> Rnw->latex step) cannot use the platex (japanese) converter. platex
> (or rather japanese) may need to be a modifier.
>
> [*] see the OutputFormat layout tag, that allows to preprocess latex files.
>
>> I also suspect that the
>> path-finding algorithm will be further complicated by the presence of
>> multiple flags; for example, I have noticed that pdf7 (PDF cropped) is
>> not labeled as a vector graphics format whereas other pdf variants are,
>> so if the pdf extension is to be consolidated I suspect that vector
>> graphics format will also have to become a qualifier of some sort.
>
> I think that many of our flags will become modifiers.
>
>> In
>> that sense, there may need to be some judgement on which converter chain
>> to use if, for example, the search only results in two valid paths, one
>> with qualifier A but not B, and another with qualifier B but not A. All
>> said and done though I'm not an expert on the converters, so perhaps
>> someone could shed some light on other considerations or critique my
>> analysis of the task at hand.
>
> I suspect indeed that there will be several possible paths. We need
> some criterion to find the better path.

Criterion should be:

1) resulting quality
2) resulting size
3) length of conversion path (although I am not sure this is really that
relevant)

>
>> As for dealing with the latex flavors, within the context of the
>> converter it seems they aren't used for much aside from generating log
>> and aux files--in fact, unless I missed something,
>
> It is used to set the OutputParams::flavor vluae and they change the
> content of the LaTeX file.
>
>> My gut instinct says
>> to just have a general "latex" flag set for each of these formats and
>> automatically determine the proper program to call from there without
>> knowing what specific type of latex it is, but since I'm not that
>> experienced with latex or any of its flavors I'm not sure if that's the
>> right approach.
>
> I would say that at first you decide to output "latex". If your final
> format is pdf:pdflatex, then all the converter chain (and all the
> formats in the list) inherits the "pdflatex" flag and therefore you
> know that your first format has to be "latex:pdflatex".
>
>> Finally after all of those changes are in place there would probably
>> need to be some UI changes to reflect the modified converter scheme, but
>> I think that's more of an afterthought.
>
> Well our current converter setting UI is a mess so if there is enough
> time, they woll deserve more than an afterthought.
>
> Finally, we may need to add some pref2pref python code to update the
> users preferences.
>
>> Thanks for reading all of that and I appreciate any advice you have to
>> spare.
>
> I think your thoughts are on the right track :)
>
> JMarc
>
>

-- 
Rainer M. Krug

email: RMKruggmailcom


pgp6mW84RUkrb.pgp
Description: PGP signature

Re: GSoC: Overhauling LyX's converter scheme

2014-03-12 Thread Rainer M Krug

Jean-Marc Lasgouttes  writes:

> Le 11/03/14 10:43, Rainer M Krug a écrit :
>> Just an observation from somebody not involved:
>>
>> The conversion route should be taking quality loss in consideration,
>> i.e. a conversion path which only involves lossless conversions, even if
>> it is longer, should be preferred.
>
> We already have a "vector" flag that serves this purpose, but we could
> maybe improve on that.

The vector is fine for - well - vector formats, but there should be an
equivalent for bitmap formats, which can be lossless (tiff or png) or
lossy (jpeg) and there could be different qualities (jpeg).

It would be nice, if one could define a "draft conversion route" which then
generates smaller, less resolution files for inclusion - but this might
not be directly related.

Rainer

>
> JMarc
>

-- 
Rainer M. Krug

email: RMKruggmailcom

pgpdjBVoQFKFj.pgp
Description: PGP signature

Re: GSoC: Overhauling LyX's converter scheme

2014-03-11 Thread Rainer M Krug

Roy Xia  writes:

> Hi everyone,
>
> So I've been studying the converter scheme in pursuit of the aforementioned
> project suggestion. I've been mostly focusing on the particular changes
> mentioned in the explanation on the wiki page; that is, to consolidate
> output formats under one extension type but use qualifiers to distinguish
> output format variants from one another, and to also refactor the converter
> code to handle latex flavors more elegantly. I suppose my first question to
> you all is whether there are any alternative suggestions or additional
> goals out there for overhauling the converter scheme.
>
> I've also been studying the source code, gathering ideas on how the
> overhaul might be implemented. As far as consolidating "variant" output
> formats, I suspect that for the most part the actual conversion code will
> remain the same, but a.) functionality for parsing and recognizing
> qualifiers will need to be added, and b.) the path-finding algorithm for
> finding the shortest chain will probably need to be somewhat modified to
> first search for output formats with the desired qualifier and then search
> for the generalized output format. I also suspect that the path-finding
> algorithm will be further complicated by the presence of multiple flags;

Just an observation from somebody not involved:

The conversion route should be taking quality loss in consideration,
i.e. a conversion path which only involves lossless conversions, even if
it is longer, should be preferred.

Cheers,

Rainer

> for example, I have noticed that pdf7 (PDF cropped) is not labeled as a
> vector graphics format whereas other pdf variants are, so if the pdf
> extension is to be consolidated I suspect that vector graphics format will
> also have to become a qualifier of some sort. In that sense, there may need
> to be some judgement on which converter chain to use if, for example, the
> search only results in two valid paths, one with qualifier A but not B, and
> another with qualifier B but not A. All said and done though I'm not an
> expert on the converters, so perhaps someone could shed some light on other
> considerations or critique my analysis of the task at hand.
>
> As for dealing with the latex flavors, within the context of the converter
> it seems they aren't used for much aside from generating log and aux
> files--in fact, unless I missed something, the different flavors only
> differ from one another by which program they use to generate those files,
> and the current code seems to determine that program solely from the
> command associated with the converter anyway. My gut instinct says to just
> have a general "latex" flag set for each of these formats and automatically
> determine the proper program to call from there without knowing what
> specific type of latex it is, but since I'm not that experienced with latex
> or any of its flavors I'm not sure if that's the right approach. Again
> perhaps someone could shed more light on this subject for me, or make sure
> my thinking isn't totally off track.
>
> Finally after all of those changes are in place there would probably need
> to be some UI changes to reflect the modified converter scheme, but I think
> that's more of an afterthought.
>
> Thanks for reading all of that and I appreciate any advice you have to
> spare.
>
> Roy Xia

-- 
Rainer M. Krug

email: RMKruggmailcom


pgpFrhbB8ZI5P.pgp
Description: PGP signature

Re: Update on discussions of LyX<-->Word export and round trip

2014-03-04 Thread Rainer M Krug

> examples: LatexML
>>>>
>>>> b. Run Latex and process the resulting Pdf or DVI file into XML
>>>> examples: tex4ht
>>>>
>>>> c. Modify an existing Tex engine to target XML instead of pdf (or dvi)
>>>> examples: XML from Context input in LuaTeX
>>>>
>>>> All three approaches are ambitious and have different shortcomings.
>>>>
>>>> (a) (Mimicking Latex) has the obvious problem that even once the basic
>>>> LaTeX functionality is recovered, the LaTeX packages have to be
>>>> basically recreated for the new engine. This is what happens in
>>>> LaTeXML, where you have to write "bindings" fr every package you need
>>>> to support. At the moment, many packages are not supported, including
>>>> biblatex, and from the little I have seen on their mailing list adding
>>>> such support is not trivial.
>>>> On the plus side, since XML is the target, all the formatting-only
>>>> machinery of TeX can be ignored (well, in theory. Real world is messy)
>>>>
>>>> b. This approach has the advantage of bringing in support for all
>>>> LaTeX packages for free. However, parsing a DVI file with the goal of
>>>> producing XML is not trivial given the completely different design
>>>> goals of DVI/vs/XMl
>>>>
>>>> c. Finally, modifying an existing TeX engine (e.g. LuaTeX) may be the
>>>> cleaner approach---at the price of much increased complexity.
>>>>
>>>> 3. Should  LyX<-->Word conversion be direct or use an intermediary
>>>> format (e.g. pandoc | mmd | etc.)?
>>>>
>>>> This question applies mostly to the roundtrip project. The consensus
>>>> seems to be that it would be better to avoid yet another format and go
>>>> for direct conversion. On the minus side, such an approach would make
>>>> it impossible (well, more difficult) to switch back-ends for the round
>>>> trip, if so desired (see Rainer's points)
>>>
>>> Unless one defines a clear software interface, which can be used by
>>> other converters. Effectively, this could mean to extend the LyX server
>>> to provide the information needed by the converter. So the parsing would
>>> be doing in LyX (advantage: no worries about different .lyx formats) and
>>> the conversion into docx in the external converter.
>>
>> Right. Even though I am not sure I fully understand Rob's suggestion
>> about using the server  yet.
>>
>>
>> --
>> __
>> Stefano Franchi
>> Associate Research Professor
>> Department of Hispanic Studies Ph:   +1 (979) 845-2125
>> Texas A&M University  Fax:  +1 (979) 845-6421
>> College Station, Texas, USA
>>
>> stef...@tamu.edu
>> http://stefano.cleinias.org

-- 
Rainer M. Krug

email: RMKruggmailcom


pgpmUcwKgmRf_.pgp
Description: PGP signature

Re: Update on discussions of LyX<-->Word export and round trip

2014-03-04 Thread Rainer M Krug

stefano franchi  writes:

> On Mon, Mar 3, 2014 at 3:17 AM, Rainer M Krug  wrote:
>> stefano franchi  writes:
>>
>>> Dear Lyx devels,
>>
>> Hi Stefano,
>>
>> thanks for a good summary of the discussion - I think you have
>> identified the main points. I have some comments below.
>>
>>>
>>> given the intense discussion we have had in the last few days on this
>>> possible project, I thought I would briefly sum up some of the early
>>> conclusions (also because some items were discussed in private
>>> emails).
>>> (BTW: In the following I  say "Word" for the sake of brevity.  I
>>> actually mean Word XML | Libreoffice ODT)
>>>
>>> 1. One project or two?
>>>
>>> Is a LyX-->Word export a subset of the LyX<-->Word roundtrip?
>>>
>>> A. If the final ouput is Word, the conversion to Word is a subset of
>>> the roundtrip *if and only if* the XML output preserve Lyx-only
>>> (non-LaTeX) information (e.g. tracked-changes, LyX-notes, etc).
>>
>> This point needs to be clarified: If one needs a semantic export, this
>> is true, as all semantic information needs to be maintained in the
>> round-trip as well as in the export. But not if the export should *look
>> like* the latex export. The limit in these discussions is semantics, and
>> not as much formatting (exceptions do apply, e.g. italics or bold of
>> words, which is important in articles which contain species names which
>> have to be in italics).
>>
>
> It should not.  That is: a word-export conversion should *not* aim at
> preserving formatting. It should preserve the same (often
> formatting-encoded)  semantic information of the round-trip converter.
> The only difference is that LyX has only pointers for some of these
> info (e.g. bibtes keys)  and not the information  itself. This is the
> major problem.
> (Additionally, some semantic LyX-provide semantic information could be
> shed by the exporter, such as tracked-changes and so on. But this is a
> minor problem).

OK - then I agree completely with you.

>
>
>> Additionally: if it is a subset - perfect - but as in (B), the
>> round-trip does not have to include everything, as there could be a
>> semantic exporter.
>>
>>>
>>> B. If the final output is pdf, then it is not. It is not necessary to
>>> actually process the info in the .tex file with Latex (e.g
>>> bibliography,, and more). All we need to do is to make sure that the
>>> info that Latex will eventually need are preserved through the
>>> roundtrip. So, for a citation, we only need to make sure that when we
>>> go to Word we produce something like (made up XML):
>>> 
>>>citet
>>>
>>> myBibkey
>>>
>>> 
>>>
>>> and when we come back we reconstruct the proper LyX bib inset from
>>> those info. It will then be up to Latex to produce the actual citation
>>> and the corresponding reference.
>>
>> Agreed.
>>
>>>
>>> So scenario 2 is actually simpler, because we do not have a dependency
>>> on LaTeX at all.
>>> At the same time, scenario 1 is more important for those people who
>>> are likely to interact with Word users (see Juergen's comments, which
>>> I subscribe to).
>>
>> I would say to design the round-trip-export so that it can easily be
>> extended to become a fully fledged semantic exporter.
>>
>>>
>>> In general, then, we have overlapping projects with substantial
>>> differences sets:
>>> A - The LyX-only information that needs to be somehow encoded in the XML 
>>> file
>>> B - The Latex-produced-only information that is missing from LyX
>>>
>>> Preserving LyX-only information in a XML file (A) strikes me as being
>>> substantially easier than producing the LyX-missing information (B)
>>> for the Word file. The latter requires TeX runs, the former does not.
>>
>> I assume you are here referring to the last A and B, as if I understand
>> correctly, the first definition of A and B is the opposite?
>
> Yes, Sorry, I switched them up. But the following refers correctly to
> the A and B options just mentioned.

OK.

>
>>
>>
>>>
>>> 2. How to produce a Word output, that is, how to solve problem B above?
>>> Since TeX is basically required to process a Lyx-produced tex file,
>>> the following approaches are available (there may be more than three,
>>> but these have kn

Re: Update on discussions of LyX<-->Word export and round trip

2014-03-03 Thread Rainer M Krug

on be direct or use an intermediary
> format (e.g. pandoc | mmd | etc.)?
>
> This question applies mostly to the roundtrip project. The consensus
> seems to be that it would be better to avoid yet another format and go
> for direct conversion. On the minus side, such an approach would make
> it impossible (well, more difficult) to switch back-ends for the round
> trip, if so desired (see Rainer's points)

Unless one defines a clear software interface, which can be used by
other converters. Effectively, this could mean to extend the LyX server
to provide the information needed by the converter. So the parsing would
be doing in LyX (advantage: no worries about different .lyx formats) and
the conversion into docx in the external converter.

>
>
>
> These seem to me to be the most important issues we face. I maybe
> forgetting some important points. If so, please correct me.
> Comments of any kind are welcome.

One important point in the general design would be, to keep in mind that
the round-trip converters do not depend heavily on the .lyx file format,
which is likely (?) to change into xml in the medium future.

Cheers,

Rainer

>
>
> Cheers,
>
> Stefano

-- 
Rainer M. Krug

email: RMKruggmailcom


pgp3BLfAsFnwb.pgp
Description: PGP signature

Re: [GSoC 2014]Interested in Round trip conversion between LyX and .docx formats

2014-02-28 Thread Rainer M Krug

Richard Heck  writes:

> On 02/28/2014 02:43 AM, Jürgen Spitzmüller wrote:
>> Am Donnerstag 27 Februar 2014, 12:29:36 schrieb stefano franchi:
>>> - Bibliography support with suitable styles is a must. This feature
>>> is as crucial to someone working in the Humanities, as math support
>>> is for
>>> someone working in the sciences. With the difference that scientists can
>>> often avoid conversion to Word, while Humanists just can't.
>>  From my point of view (as someone being in the Humanities), this is
>> almost all that matters and the criterion that makes LyX -> Docx/ODT
>> conversion useful or completely useless for me. Everything else is
>> just a plus.
>
> Here, I think it's especially helpful to distinguish "round trip"
> conversion, which would be used during collaboration, from final
> export for publication. I take it that in the former case we just need
> to make sure not to lose bibliographic information. Only in the latter
> case do we need to be able to use or mimic biblatex, or whatever, to
> get the bibliographic information into some final form.

Exactly - for round-trip, the format of the references is effectively
irrelevant, as long as one can see which ones they are, whereas for
export, the format is essential (not only for Humanities!). I would even
go so far and say that the inclusion of a properly formatted
bibliography in the round-trip would be causing more problems, as bibtex
et al only help on the one way - but how to get a new reference back
into LyX? So I would suggest to leave the citations in a basic format
(e.g. #+#bibtexID1,bibtexID2#+#) as a comment in the docx, so that they
can be seen. On the way back, #+#...#+# is then replaced by the citation
command in LyX, and if inside the #+# is not a valid bibtex id, it is
imported as a comment, which then can be interpreted by hand (could be a
new reference).

Rainer

>
> This Sort of thing has been frequently requested just for XHTML: Parse
> the bbl file and use that to construct the bibliography. So perhaps
> the problem should be solved there first.

>
> Richard
>
>

-- 
Rainer M. Krug

email: RMKruggmailcom

pgpgzvY5CF8D3.pgp
Description: PGP signature

Re: [GSoC 2014]Interested in Round trip conversion between LyX and .docx formats

2014-02-28 Thread Rainer M Krug

Richard Heck  writes:

> On 02/28/2014 05:35 AM, Rainer M Krug wrote:
>> Rob Oakes  writes:
>>
>>> Dear Developers,
>>>
>>> I've been following this conversation from the shadows, but I had one
>>> thought that they be relevant.
>>>
>>> I think everyone agrees that we want to avoid reimplementing the
>>> internal logic of a LyX document. While thinking about what might be
>>> the best way to implement a converter, it occurred to me that it might
>>> be worthwhile to implement the converters as clients that are able to
>>> use a LyX server session.
>> This comes close to my thought about an API, but it would be even better
>> in the sense of more versatile and easier usable by external tools.
>>
>> The server - client approach would be the optimal and most flexible approach.
>>
>>> For export, the server could load a document, provide data about inset
>>> and paragraph contents, and the client could then convert the logical
>>> representation to docx or odf. For import, the process might work in
>>> reverse. The importer reads in the data from the document, translates
>>> it to a logical format that could be consumed by the server, and the
>>> server creates a new document. Document internals remain internal to
>>> LyX, while the server-client communicate over a well-defined protocol
>>> to interactively build the document.
>> This would be the best approach, as the internals are hidden in LyX, and
>> the external clients only ask the same questions to retrieve the content
>> they need to do what they want to do.
>>
>> It would also open many more options, e.g. web based editing.
>
> The "building the document" part is already do-able. Every editing
> action is an LFUN. Try it in the minibuffer:
> layout-section Section 1
> break-paragraph
> self-insert This is the contents.
> footnote-insert
> self-insert This is a footnote.
> char-forward
> self-insert That's all folks.
> There's a bit of a problem here: There's no easy way to insert a space
> after the footnote, from what I can see.
>
> I'm not sure I understand, conceptually, what the API would look like
> going the other direction. The obvious way to "provide data about
> inset and paragraph contents" would be to send the client a copy of
> the LyX file. I mean, we have to serialize the data somehow, which is
> something LyX even does internally. And the serialization looks just
> like the LyX file. That allows us to reuse the code that reads the LyX
> file to read serialized data produced internally.

The main point would be, that this serialized content is independent of
the .lyx file format used, i.e. that it stays the same (or at the least
is backward compatible) through the conversion to any new file format
(xml). 

The information given out of LyX could also be hierarchical, i.e. that
for different requests, different kinds of content are provided an
example would be that

1) a request for "text only" returns the text - without bibliography,
formating of text (e,g, bold words), graphs, tables, headers as a
paragraph, ...

2) a request for "paragraph formats" request returns the type of the paragraphs 
(Section,
Subsection, List, enumeration, ...), which can then be merged into (1)

3) a third request for "character format" would return character
formatting (e.g. bold)

4) a fourth request for "bibliograhy" returns where the citations are,
the format and the .bib file

5) ...

Consequently, the structure would be modular and new features could be
easily added and implemented in the round-trip converter.


Cheers

Rainer
 

>
> Richard
>
>

-- 
Rainer M. Krug

email: RMKruggmailcom


pgpkrMCK05G4g.pgp
Description: PGP signature

Re: [GSoC 2014]Interested in Round trip conversion between LyX and .docx formats

2014-02-28 Thread Rainer M Krug

Rob Oakes  writes:

> Dear Developers,
>
> I've been following this conversation from the shadows, but I had one 
> thought that they be relevant.
>
> I think everyone agrees that we want to avoid reimplementing the 
> internal logic of a LyX document. While thinking about what might be 
> the best way to implement a converter, it occurred to me that it might 
> be worthwhile to implement the converters as clients that are able to 
> use a LyX server session.

This comes close to my thought about an API, but it would be even better
in the sense of more versatile and easier usable by external tools.

The server - client approach would be the optimal and most flexible approach.

>
> For export, the server could load a document, provide data about inset 
> and paragraph contents, and the client could then convert the logical 
> representation to docx or odf. For import, the process might work in 
> reverse. The importer reads in the data from the document, translates 
> it to a logical format that could be consumed by the server, and the 
> server creates a new document. Document internals remain internal to 
> LyX, while the server-client communicate over a well-defined protocol 
> to interactively build the document.

This would be the best approach, as the internals are hidden in LyX, and
the external clients only ask the same questions to retrieve the content
they need to do what they want to do.

It would also open many more options, e.g. web based editing.

>
> If I understand the LyX server pipe, it is already possible to retrieve 
> information about insets, citations, cross-references, and other 
> document components. Moreover, there are only a few properties for a 
> particular type of inset (ID, text, meta, etc.), which provides a 
> manageable way to handle output data. Might it even be possible to 
> export the data for a particular inset in a serialized key/value 
> format? This would allow for insets without a good output format to 
> main their data as DOCX/ODF metadata which could be faithfully 
> translated back during import.
>
> As I've followed the pandoc conversation, I've been concerned about the 
> introduction of another dependency. If the import/export tools can be 
> kept to LyX and some processing script, that seems easier to maintain 
> than a complex chain of tools and external dependencies which we don't 
> control.

Pandoc in the round-trip is definitely a sub-optimal solution due to the
reliance on another tool, and quite a few modules for pandoc would have
to be written. 

It is a different topic to use pandoc for export, as in this case only one
pandoc would be needed.

Cheers,

Rainer

>
> Just my 0.02.
>
> Cheers,
>
> Rob
>

-- 
Rainer M. Krug

email: RMKruggmailcom


pgp4vzHRb53UD.pgp
Description: PGP signature

Re: [GSoC 2014]Interested in Round trip conversion between LyX and .docx formats

2014-02-27 Thread Rainer M Krug

Richard Heck  writes:

> On 02/27/2014 03:44 AM, Prannoy Pilligundla wrote:
>>
>> I also had a look at pandoc and tex4ht but as they are converters
>> from Latex,i feel we should only consider them as secondary options.
>
> I believe pandoc is pretty modular. One would only need to add LyX to
> the list of formats that it handles and then, like magic, we could
> convert the LyX format to anything else that pandoc handles. It seems
> to me that this would be a very good approach.

I really like pandoc, and it would be in my opinion, the perfect
companion for one way export from LyX - as you said, this would be like
magic.

But it does not provide conversion from the target formats, only from:

,
| markdown, reStructuredText, textile, HTML, DocBook, LaTeX, MediaWiki
| markup, OPML, or Haddock markup
`

see [1] for details.

Therefore I don't see it as useful for the round trip.

>
> The downside to any python-based approach, though, is that the LyX
> format is a moving target. The script would need to be updated with
> every syntax change.

I assume that in LyX, there is an API which could be used to convert 
*independent* from
the file format?  I don't assume they are exposed outside LyX so that
they can be accessed from e.g. python?

Along this lines - I guess there are no news about the LyX xml format?

Rainer

>
> Richard
>
>

Footnotes: 
[1]  http://johnmacfarlane.net/pandoc/

-- 
Rainer M. Krug

email: RMKruggmailcom

pgp7al2AcB8Lp.pgp
Description: PGP signature

Re: [GSoC 2014]Interested in Round trip conversion between LyX and .docx formats

2014-02-27 Thread Rainer M Krug

Prannoy Pilligundla  writes:

> I have been following the discussion going on in this thread and have been
> exploring Lyx at the same time.I understood how to integrate python scripts
> into the editor and all but i have a some queries regarding the round trip
> conversion
>
> Since we have something like eLyxer which parses the Lyx format,can we
> modify the eLyxer program and use this python-docx library(
> https://github.com/python-openxml/python-docx) or anyother library which
> helps in creating .docx files?In this way maybe we can also inject metadata
> which MS Word ignores.Since we already have the .docx--->.lyx converter
> written by Rob(http://blog.oak-tree.us/index.php/2012/03/08/word2lyx01-2)
> we can modify it to read the metadata also. 

I have my reservations of sticking to close to the docx file format in
the implementation, as my initial idea was that the conversion process
is modular, and other backends can be plugged in easily, while re-using
basic metadata extraction and format specification mechanisms. So
effectively, the initial idea (from my side) to 

1) read supported round-trip feature list from config file   
1) extract metadata, i.e. features which are not supported by round-trip, into 
file
2) convert remaining round-trip-suitable data into new format
3) possibly merge metadata into file, or leave in sidecar file
- file goes away
- do something in other format (edits, ...)
- file returns
4) extract metadata, i.e. features which are not supported by
round-trip, from file / sidecar file
5) convert remaining round-trip-suitable data into lyx format
6) merge metadata back into lyx file

So existing converters might be a starting point for (2) and (5), but
they should be optimized for semantic conversion of the
supported round-trip-features and not trying to convert formats.

The basic reasoning is here, that only 

1) the definition of supported features
2) converter definitions (2) and (3) and
3) how to merge metadata into second format (3)

need to be changed to support other formats (e.g. markdown come to
mind).

Or am I aiming to high here?

> I feel we should be able to do a
> roundtrip conversion this way but i am not sure of the math part.I mean i
> should read more how can we convert mathematical expressions from .lyx to
> .docx. Can someone please brief me on what's the crucial information that
> is absent in Lyx but produced by Latex?

Information which is missing in the LyX document but generated by LaTeX
is 

1) bibliography information and format
2) Text in cross references and citation format
3) similar to (2) figure, table, ... caption labels
4) constructs in ERT blocks, like tikz graphs et al

Out of the head, I can't think of anything else, at the moment

>
> I also had a look at pandoc and tex4ht but as they are converters from
> Latex,i feel we should only consider them as secondary options.

I thought about pandoc as well, but the problem is the back conversion,
as it does not accept docx as input format.

And I think a chain of converters (as used for pictures and graphs in
LyX) introduces to many potential instabilities in such an important feature.

>
> I am new to the Lyx community so please forgive me if you find any of my
> suggestions too lame because i may not have complete overview and insight
> into things.

No problem at all - go ahead with asking.

Cheers,

Rainer

> Also it would be great if someone could provide me links to
> understand the .lyx format.I wrote a simple .lyx file and opened it in a
> text editor and found a lot of stuff,i think i should be able to understand
> this properly if i want to parse a .lyx file and convert it to something
> else
>
> Thanks and Regards
> Prannoy Pilligundla
> ᐧ

-- 
Rainer M. Krug

email: RMKruggmailcom


pgpmkMmvfpG3P.pgp
Description: PGP signature

Re: [GSoC 2014]Interested in Round trip conversion between LyX and .docx formats

William Adams  writes:

> On Feb 25, 2014, at 11:03 AM, stefano franchi wrote:
>
>> Is the list comprehensive enough?
>
> No love for index entries?

Not from my side - sorry.

Rainer

>
> William

-- 
Rainer M. Krug

email: RMKruggmailcom


pgplFvC5aAhzZ.pgp
Description: PGP signature

Re: [GSoC 2014]Interested in Round trip conversion between LyX and .docx formats

stefano franchi  writes:

> I am preparing a LyX document with all the features listed in our GSOC
> 2014 page. I will transfer it to ODF with tex4ht, possibly fix it
> manually,  and then will circulate it on list for ODF/Docx tests.

I think this is a brilliant idea - ths could then become the benchmark
for the complete round-trip.

>
> Here is what I am including:
>
> sections, headers, ...
> lists
> emphasis, bold, ...
> comments
> track changes
> tables and figures
> footnotes
> bibliographic references
> math
> cross-references
> tracked changes
>
> It will have one section per item, do we can focus the tests on one
> feature at a time, and perhaps split the document in mini-docs an have
> a series of unit tests of sorts.
>
>
> Question:
>
> 1. Is the list comprehensive enough? Too comprehensive?

We should possibly prioritize some aspects which are more essential then
others. There will very likely be some different views on e.g. math and
footnotes, but I assume that there are some we can agree on. My list
would be, in descending order of importance:

1) sections, headers, ...
2) lists
3) emphasis, bold, ...
4) comments
5) track changes
6) tables and figures
7) bibliographic references
8) tables
9) figures
10) math, footnotes & cross-references

>
> 2. For the Math: anyone having favorite equations / math constructs
> that represent a sort of "baseline" case that would be desired and
> other cases that would be the "optimum". I am thinking of the
> complicated things I sometimes here you guys discussing on the list
> and which I never use

Not from my side - sorry. I prefer simple maths.

Looking forward to the document,

Rainer

>
>
> S.
>
>
> On Tue, Feb 25, 2014 at 8:58 AM, Richard Heck  wrote:
>> It looks to me as if ODT <--> docx is OK via Libre Office. And if it's
>> editors of journals, etc, then one way is good enough, no?
>>
>> R
>>
>> On Feb 25, 2014 4:15 AM, "Rainer M Krug"  wrote:
>>>
>>> Wilfried  writes:
>>>
>>> > Rainer M Krug wrote:
>>> >
>>> >> Wilfried  writes:
>>> >>
>>> >> > stefano franchi wrote:
>>> >> >
>>> >> >> On Sun, Feb 23, 2014 at 1:29 PM, Rainer M Krug 
>>> >> >> wrote:
>>> >> >> > stefano franchi  writes:
>>> >> >> >
>>> >> >>
>>> >> >> >> 2. Whether to target Microsoft's Word XML format or the Open
>>> >> >> >> Document
>>> >> >> >> Format (similarly XML-based)
>>> >> >> >
>>> >> >> > I would strongly argue for the Microsoft Word XML, as each
>>> >> >> > conversion
>>> >> >> > creates problems and inconsistencies. This said, if the conversion
>>> >> >> > from
>>> >> >> > MS Word XML to ODF and back can be done without causing problems
>>> >> >> > in the
>>> >> >> > roundtrip (i.e. the round-trip would then be lyx - ODF XML - MS
>>> >> >> > XML -
>>> >> >> > ODF XML - lyx)I would argue for the more "open" format which can
>>> >> >> > be used
>>> >> >> > on more Operating systems.
>>> >> >> >
>>> >> >>
>>> >> >> I have been told that, in its most recent versions, Microsoft Word
>>> >> >> can
>>> >> >> read ODF version >= 1.2 directly. That is, it can open,
>>> >> >> edit, and save files in OpenOffice's native format. I have no means
>>> >> >> of
>>> >> >> checking this assertion, as I have no access to MS Word.
>>> >> >> Could anyone with such access give it a try?
>>> >> >
>>> >> > In principle, this is true.
>>> >> > However OO (I tested with Apache OO 4.01) cannot save in the latest
>>> >> > Word
>>> >> > format (.docx), and saveing as MS .xml results in complete loss of
>>> >> > the
>>> >> > equations.
>>> >>
>>> >> This is not true for Libre Office (4.1.2.3) on ac - I just tried, and a
>>> >> small formula in LibreOffice, saved as .odt, then saved as .docx
>>> >> (Microsoft Office 2007/2010 XML) resulted in a docx which could be
>>> >> opened in Word 2011 and the equation was th

Re: GSOC 2014 -- next steps

stefano franchi  writes:

> Dear Lyx developers,
>
> as you know, we have been accepted into GSOC 2014. The next step is to
> get ready to evaluate students' proposal, which will start coming in
> about a week, with the usual flurry as we get close to the deadline
> (March 21st).
>
> I would appreciate if all the developers who participated in GSOC last
> year could register again as mentors on google-melange [1], *even if
> you do not plan to be an active mentor* this year. Registration on
> melange will give you access to the proposals and will let you assess
> them.
>
> Notice that you may have to reregister with google-melange, as te app
> seems to have deleted usernames from last year. Both Liviu and I had
> to do so. Once you are properly logged in, go to the Dashboard and
> click on "connect with organizations" requesting the role of mentor.
> Liviu or I will have to approve your request, after which you will
> recive a confirmation and you'll be ready to roll.

Just to inform you, I have registered as a co-mentor for the roundtrip
project. I will not be able to provide programming mentoring as I have
no knowledge in the internals of LyX, but I would be very much
interested to be involve=d in the discussion about the direction and
outline of the roundtrip, as I was one of the initial authors ot=f the proposal.

Cheers,

Rainer

>
> Thanks!
>
> Stefano
>
>
> [1] https://google-melange.appspot.com/gsoc/events/google/gsoc2014

-- 
Rainer M. Krug

email: RMKruggmailcom


pgptDs5d5BXe_.pgp
Description: PGP signature

Re: [GSoC 2014]Interested in Round trip conversion between LyX and .docx formats

Wilfried  writes:

> Rainer M Krug wrote:
>
>> Wilfried  writes:
>> 
>> > stefano franchi wrote:
>> >
>> >> On Sun, Feb 23, 2014 at 1:29 PM, Rainer M Krug  wrote:
>> >> > stefano franchi  writes:
>> >> >
>> >> 
>> >> >> 2. Whether to target Microsoft's Word XML format or the Open Document
>> >> >> Format (similarly XML-based)
>> >> >
>> >> > I would strongly argue for the Microsoft Word XML, as each conversion
>> >> > creates problems and inconsistencies. This said, if the conversion from
>> >> > MS Word XML to ODF and back can be done without causing problems in the
>> >> > roundtrip (i.e. the round-trip would then be lyx - ODF XML - MS XML -
>> >> > ODF XML - lyx)I would argue for the more "open" format which can be used
>> >> > on more Operating systems.
>> >> >
>> >> 
>> >> I have been told that, in its most recent versions, Microsoft Word can
>> >> read ODF version >= 1.2 directly. That is, it can open,
>> >> edit, and save files in OpenOffice's native format. I have no means of
>> >> checking this assertion, as I have no access to MS Word.
>> >> Could anyone with such access give it a try?
>> >
>> > In principle, this is true.
>> > However OO (I tested with Apache OO 4.01) cannot save in the latest Word
>> > format (.docx), and saveing as MS .xml results in complete loss of the
>> > equations. 
>> 
>> This is not true for Libre Office (4.1.2.3) on ac - I just tried, and a
>> small formula in LibreOffice, saved as .odt, then saved as .docx
>> (Microsoft Office 2007/2010 XML) resulted in a docx which could be
>> opened in Word 2011 and the equation was there. I=t could be edited and,
>> when re-opened in LibreOffice, the edits were there.
>> 
>> > Round trip is best if saving to Word 97/2000/2003 .doc
>> > format.
>> 
>> As far as I know, doc is a non documented binary format - so I would
>> definitely not go there.
>> 
>> >
>> > Word supports 3 ways to write equations:
>> > The oldest one is the EQ field function, which is easy to convert but
>> > rarely used in practice.
>> > The next is using the Equation Editor (standard for up to Word 2000) or
>> > its mature brother MathType which both create MTEF objects.
>> > The latest are Word 2007 and up equations (with a different object type
>> > OMML).
>> > And OpenOffice has its own equation editor which creates another object
>> > type, which cannot be converted to any of Word's equation types, at
>> > least not by Word nor by MathType (up to 6.7.a - current version is
>> > 6.9). However, Mathtype can convert to and from MathML and LaTeX.
>> > The newer Word equation object can only be converted to the older object
>> > type by MathType (AFAIK).
>> 
>> I can not comment on this.
>> 
>> >
>> > An OO document, containing an equation created in OO, saved as MS .doc
>> > (Word 97/2000/2003) and opened in Word 2010 contains the equation but
>> > this equation is not editable in Word - for editing this equation one
>> > needs OpenOffice installed. At least after the round trip OO -> .doc ->
>> > Word -> .doc -> OO the equation is still editable in OO.
>> > And an equation created in Word is not editable in OO. Even worse, if
>> > one uses the newer (Word 2007 and up) equation format (which is default
>> > if one uses the .docx format), then saves as .doc, the newer equations
>> > are irreversibly converted to pictures.
>> >
>> > Hope that makes the problems more clear.
>> 
>> As I stated above, I could create a document =in Libre office, including
>> equation, save it as docx, open it in Word 2011, edit the formula, save
>> it, open the document in LibreOffice, edits were there, and I could
>> continue editing there. May be differences between OpenOffice and
>> LibreOffice?
>
> I comparedLibreOfficeandOpenOffice:
>
> Save as .doc yesyes
> Equation saved asMTEF, editable  OOmath, not editable
> Roundtripno, stays MTEF  remains OOMath
>  MTEF remains MTEF 
>
> Save as .docxyes    no
> Equation saved asOMML, editable
> Roundtripyes, back to OOMath
>  MTEF remains MTEF 
>
>
> A

Re: [GSoC 2014]Interested in Round trip conversion between LyX and .docx formats

stefano franchi  writes:

> On Mon, Feb 24, 2014 at 5:21 PM, Cyrille Artho  wrote:
>> I agree. A user who is interested in using LyX is also going to install
>> LibreOffice (if it's not already installed). Furthermore, we can't expect
>> student participants to pay hundreds of dollars just to be able to test the
>> converter.
>>
>>
>> Richard Heck wrote:
>>>
>>> On 02/24/2014 06:11 PM, stefano franchi wrote:
>>>>
>>>> On Mon, Feb 24, 2014 at 3:41 PM, Georg Baum
>>>>  wrote:
>>>>>
>>>>> Rainer M Krug wrote:
>>>>>
>>>>>> As far as I know, doc is a non documented binary format - so I would
>>>>>> definitely not go there.
>>>>>
>>>>> AFAIK there are many details known about .doc, but this is a dead
>>>>> format,
>>>>> and any round trip that uses it will be obsolete rather sooner than
>>>>> later.
>>>>>
>>>>
>>>> I agree completely. Let's avoid dead formats and focus on the choice
>>>> Word vs. ODF
>>>
>>>
>>> I would have thought it was in the spirit of the project to focus on ODF.
>>> Word reads and writes it, and anyone who's a Word-user can download and
>>> use
>>> Libre Office for free without much loss.
>>>
>
>
> I agree, in principle and on practical grounds too (see the
> possibility to leverage tex4ht). However, it is true that the eventual
> users of the Lyx-->Doc converter (and of the roundtrip tool) will
> overwhelmingly be Word users, not LibreOffice users. Before we choose
> to go down the ODF path I would very much like to test whether the
> core features we are interested in---semantic marking, footnotes,
> math,  changes, notes and possibly frames---can survive the
> ODF<-->Word round trip.
>
> Is anyone with Word willing to carry out the test? I can provide a
> test document in ODF format.

I can test it on a Mac. If you send me the document privately, I can 

1) save it in LibreOffice 4.1.2.3 as .docx
2) open it in MS Word:Mac 2011 14.3.9
3) compare the documents
4) do a minor edit (if you have any specific edits I shoud do, please
let me know)
5) save it again
6) open it in LibreOffice

I will also create pdfs of each stage.

We have to keep in mind, that it seems that at least MS Office 2011 on
a Mac *can not* read and write .odt files. If somebody using a newer
version of OS Office for Mac can confirm this?

Cheers,

Rainer

>
>
> S.

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug


pgpMtpyTThwim.pgp
Description: PGP signature

Re: [GSoC 2014]Interested in Round trip conversion between LyX and .docx formats

2014-02-24 Thread Rainer M Krug

Wilfried  writes:

> stefano franchi wrote:
>
>> On Sun, Feb 23, 2014 at 1:29 PM, Rainer M Krug  wrote:
>> > stefano franchi  writes:
>> >
>> 
>> >> 2. Whether to target Microsoft's Word XML format or the Open Document
>> >> Format (similarly XML-based)
>> >
>> > I would strongly argue for the Microsoft Word XML, as each conversion
>> > creates problems and inconsistencies. This said, if the conversion from
>> > MS Word XML to ODF and back can be done without causing problems in the
>> > roundtrip (i.e. the round-trip would then be lyx - ODF XML - MS XML -
>> > ODF XML - lyx)I would argue for the more "open" format which can be used
>> > on more Operating systems.
>> >
>> 
>> I have been told that, in its most recent versions, Microsoft Word can
>> read ODF version >= 1.2 directly. That is, it can open,
>> edit, and save files in OpenOffice's native format. I have no means of
>> checking this assertion, as I have no access to MS Word.
>> Could anyone with such access give it a try?
>
> In principle, this is true.
> However OO (I tested with Apache OO 4.01) cannot save in the latest Word
> format (.docx), and saveing as MS .xml results in complete loss of the
> equations. 

This is not true for Libre Office (4.1.2.3) on ac - I just tried, and a
small formula in LibreOffice, saved as .odt, then saved as .docx
(Microsoft Office 2007/2010 XML) resulted in a docx which could be
opened in Word 2011 and the equation was there. I=t could be edited and,
when re-opened in LibreOffice, the edits were there.

> Round trip is best if saving to Word 97/2000/2003 .doc
> format.

As far as I know, doc is a non documented binary format - so I would
definitely not go there.

>
> Word supports 3 ways to write equations:
> The oldest one is the EQ field function, which is easy to convert but
> rarely used in practice.
> The next is using the Equation Editor (standard for up to Word 2000) or
> its mature brother MathType which both create MTEF objects.
> The latest are Word 2007 and up equations (with a different object type
> OMML).
> And OpenOffice has its own equation editor which creates another object
> type, which cannot be converted to any of Word's equation types, at
> least not by Word nor by MathType (up to 6.7.a - current version is
> 6.9). However, Mathtype can convert to and from MathML and LaTeX.
> The newer Word equation object can only be converted to the older object
> type by MathType (AFAIK).

I can not comment on this.

>
> An OO document, containing an equation created in OO, saved as MS .doc
> (Word 97/2000/2003) and opened in Word 2010 contains the equation but
> this equation is not editable in Word - for editing this equation one
> needs OpenOffice installed. At least after the round trip OO -> .doc ->
> Word -> .doc -> OO the equation is still editable in OO.
> And an equation created in Word is not editable in OO. Even worse, if
> one uses the newer (Word 2007 and up) equation format (which is default
> if one uses the .docx format), then saves as .doc, the newer equations
> are irreversibly converted to pictures.
>
> Hope that makes the problems more clear.

As I stated above, I could create a document =in Libre office, including
equation, save it as docx, open it in Word 2011, edit the formula, save
it, open the document in LibreOffice, edits were there, and I could
continue editing there. May be differences between OpenOffice and
LibreOffice?

Cheers,

Rainer

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug


pgpD0M2w9iCZA.pgp
Description: PGP signature

Re: [GSoC 2014]Interested in Round trip conversion between LyX and .docx formats

2014-02-23 Thread Rainer M Krug

stefano franchi  writes:

> On Sun, Feb 23, 2014 at 1:29 PM, Rainer M Krug  wrote:
>> stefano franchi  writes:
>>
>
>>> 2. Whether to target Microsoft's Word XML format or the Open Document
>>> Format (similarly XML-based)
>>
>> I would strongly argue for the Microsoft Word XML, as each conversion
>> creates problems and inconsistencies. This said, if the conversion from
>> MS Word XML to ODF and back can be done without causing problems in the
>> roundtrip (i.e. the round-trip would then be lyx - ODF XML - MS XML -
>> ODF XML - lyx)I would argue for the more "open" format which can be used
>> on more Operating systems.
>>
>
> I have been told that, in its most recent versions, Microsoft Word can
> read ODF version >= 1.2 directly. That is, it can open,
> edit, and save files in OpenOffice's native format. I have no means of
> checking this assertion, as I have no access to MS Word.

I remember trying this with an older version of word (I think it
was 2010) by using the additional plugin by Microsoft to read odt, but
quite a few formatings were lost and there was an issue with repairing
the file. I just checked Office Mac 2011, and it can't open .odt format.

But The windows version can, apparently:

http://office.microsoft.com/en-us/word-help/use-word-to-open-or-save-a-document-in-the-opendocument-text-odt-format-HA010355766.aspx

As a side note:

MS states on the above mentioned page according to collaboration:

,
| When you collaborate on a document shared between Word and another word
| processing application, such as Google Docs or OpenOffice.org Writer,
| think of writing (the words) and formatting (the look) as different
| tasks. Complete as much of the writing as possible without applying
| formatting to the text and save the formatting until the end. This
| allows you to focus on the writing while minimizing the loss of
| formatting as you switch between the OpenDocument Text format and Word
| format.
`

Cheers,

Rainer

> Could anyone with such access give it a try?
>
> S.

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

pgpFEcBhlWAQt.pgp
Description: PGP signature

Re: [GSoC 2014]Interested in Round trip conversion between LyX and .docx formats

2014-02-23 Thread Rainer M Krug

s this approach.  The project is not actively developed now,
due to the untimely death of its founder,
   but it is still available, and it actually works. tex4ht runs latex with
a special style which inserts parsing
   commands into LaTeX's DVI output. A java program then parses the special
DVI output and produces
   html or ODF output. This approach allows tex4ht to exploit Latex's own
processing (including the
   processing of index and bibliographic information), at the cost of
increased complexity.
   One possibility would be to follow tex4ht's approach, while simplifying
as much as possible the kind of
   LaTeX information actively supported.

  One important drawback of this second strategy (LyX-->LaTeX-->Word|ODF)
is that LyX's only information
  are lost when converting to LaTeX. The most important of those are
tracked changes. Standard LaTex has no
  conception of tracked changes. There are LaTeX additional packages that
manage changes (e.g. [7]),
  and we would have to convert LyX's changes into that format. This of
course adds an additional dependency,
  unless the package functionalities are somehow replicated by us.

2. Whether to target Microsoft's Word XML format or the Open Document

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug


pgp97EUI2H0Kl.pgp
Description: PGP signature

Re: Requst: Improved use of maxima inside LyX

2014-02-11 Thread Rainer M Krug



On 02/11/14, 13:06 , Rami Veiberman wrote:
> Hello,
> 
> I'm using maxima as a smart calculator while working on my documents
> inside lyx and it is working quite well. I also use wxmaxima by itself
> to make some calculations and symbolic math easily.
> 
> I wish I could do both.  I wonder if I can open maxima session using a
> command at lyx which will evaluate all maxima indicated cells and help
> me create my smart document. 
> My final goal is to be able to create nice documents (which lyx does
> just great) and be able to use some symbolic math and simple function
> plots (which maxima does well) but today it is just not possible to
> combine the two.
> 
> for example, I want to define varibales at the start of the document.
> something like
> 
> var1:2 , var2:13
> 
> and then later to do
> 
> ans:var1^2 + var2
> 
> today I'm unable to do so :(

You are looking for something like knitr or sveawe for R (which are
supported in LyX) for maxima - I don't think something like this exist.

But at least for graphs, you could use R.

Cheers,

Rainer

> 
> I am aware that wxmaxima can use latex text output but it lacks the nice
> GUI of LyX which I'm very found of and it also lacks the support for
> hebrew that LyX has.
> 
> can we combine the two worlds into a better future?
> 
> Rami

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug



signature.asc
Description: OpenPGP digital signature

Re: GSOC 2014 project list: on LyX<-->docx roundtrip conversion

2014-02-11 Thread Rainer M Krug



On 02/10/14, 21:47 , stefano franchi wrote:
> 
> 
> 
> On Mon, Feb 10, 2014 at 2:36 PM, Rainer M Krug  <mailto:rai...@krugs.de>> wrote:
> 
> I have the feeling, this discussion can be summed up in two lines:
> 
> 1) we would like to have a round-trip (docx backend)
> 2) but we need a sematic export (to docx)
> 
> 
> Or perhaps:
> 1) we would like to have a round-trip (docx backend)
> 2) but we need a semantic export (to docx)
> 3) so let's begin with (2)
> 4) and hopefully will will halfway through to (1)

Agreed - We can work on that.

> 
> The important question is:
> 
> - which design decisions in (2) could prevent a successful roundtrip?
> How do we avoid those?

Exactly - and also, which elements in LyX should be (initially) included
in the semantic export and how they should be mapped.

I won't be able to help in regards of any programming questions, as I
know neither the inner workings of LyX nor of docx, but I would be more
then interested in participating in these kind of discussions and support.

Cheers,

Rainer

> 
> 
> S.  
> 
> 
> 
> -- 
> __
> Stefano Franchi
> Associate Research Professor
> Department of Hispanic Studies Ph:   +1 (979) 845-2125
> Texas A&M University  Fax:  +1 (979) 845-6421
> College Station, Texas, USA
> 
> stef...@tamu.edu <mailto:stef...@tamu.edu>
> http://stefano.cleinias.org

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug



signature.asc
Description: OpenPGP digital signature

Re: GSOC 2014 project list: on LyX<-->docx roundtrip conversion

I have the feeling, this discussion can be summed up in two lines:

1) we would like to have a round-trip (docx backend)
2) but we need a sematic export (to docx)

Rainer

On 02/10/14, 21:09 , Georg Baum wrote:
> Rainer M Krug wrote:
> 
>> On 02/09/14, 20:25 , Georg Baum wrote:
>>
>>> This is not possible. There are LyX features that simply do not appear in
>>> the exported LaTeX, so they can't be imported (e.g. branches or notes).
>>> It might be possible to support all LaTeX features, but the cost would be
>>> extremely high, so there will always be LaTeX files which can't be
>>> imported (usually the stuff found in .cls or .sty files).
>>
>> OK - in this regard you are right - haven't considered branches. But LyX
>> notes could be exported as LaTeX comments starting with %%LyX-Note%%.
>>
>> Branches: isn't there conditional compiling in LaTeX? In this way
>> branches could be kept and switched by activating these in the preamble?
> 
> Yes. IIRC there was even a discussion about how to translate branches into 
> LaTeX if-statements some time ago, so branches are may not be the best 
> example. Anyway, there will always be features without direct LaTeX 
> representation,
> 
>>>> So: yes, the round-trip framework could be used for a subset of features
>>>> initially for LyX <-> LaTeX, which can then be extended over time - I
>>>> guess this would be the easiest to start with, actually.
>>>
>>> This does not make sense IMHO. Why artificially restrict the roundtrip?
>>
>> Because, as you said above, some features in LyX can not be exported
>> into LaTeX and the other way round?
> 
> OK, if you meant these features I agree, then I probably misunderstood you 
> in the first place.
> 
>> In addition, the round-trip would be
>> needed to mainly edit content, and not that much formating - how a
>> section header looks in word or in LyX is irrelevant, as long as it is
>> recognised in the re-import / re-export for round-trip as a section
>> header. In Contrast, when exporting (non-round trip) one wants a
>> document as similar as possible to the LyX / LaTeX pdf (in most cases).
> 
> This is a useful feature as well, but IMHO not restricted to roundtrip: Even 
> if you want to do a one-way export (e.g. because you know that somebody else 
> will continue to work on the document and it will never come back to you), a 
> switch similar to the "clean" option of writer2latex would be a good thing 
> to have.
> 
>> You are right - LaTeX is a special case, as it is the default backend
>> for LyX. So there are more strict requirements for the round-trip, and
>> all improvements in the round-trip should be immediately in the LaTeX
>> importer as well. But the story is different with other backends, e.g.
>> docx, where, if you go to replicating the LaTeX view, you might end with
>> "painted" documents which are not easily to be re-imported into LyX. But
>> for round trip, the look is not that relevant, as long as the content
>> and the structure can be re-imported.
> 
> I believe this alls boils down to semantic export as Stefano called it vs. 
> "painted" export, and semantic export would be useful with roundtrip and 
> without.
> 
> 
> Georg
> 

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug



signature.asc
Description: OpenPGP digital signature

Re: GSOC 2014 project list: on LyX<-->docx roundtrip conversion



On 02/10/14, 21:09 , Georg Baum wrote:
> Rainer M Krug wrote:
> 
>> On 02/09/14, 20:25 , Georg Baum wrote:
>>
>>> This is not possible. There are LyX features that simply do not appear in
>>> the exported LaTeX, so they can't be imported (e.g. branches or notes).
>>> It might be possible to support all LaTeX features, but the cost would be
>>> extremely high, so there will always be LaTeX files which can't be
>>> imported (usually the stuff found in .cls or .sty files).
>>
>> OK - in this regard you are right - haven't considered branches. But LyX
>> notes could be exported as LaTeX comments starting with %%LyX-Note%%.
>>
>> Branches: isn't there conditional compiling in LaTeX? In this way
>> branches could be kept and switched by activating these in the preamble?
> 
> Yes. IIRC there was even a discussion about how to translate branches into 
> LaTeX if-statements some time ago, so branches are may not be the best 
> example. Anyway, there will always be features without direct LaTeX 
> representation,
> 
>>>> So: yes, the round-trip framework could be used for a subset of features
>>>> initially for LyX <-> LaTeX, which can then be extended over time - I
>>>> guess this would be the easiest to start with, actually.
>>>
>>> This does not make sense IMHO. Why artificially restrict the roundtrip?
>>
>> Because, as you said above, some features in LyX can not be exported
>> into LaTeX and the other way round?
> 
> OK, if you meant these features I agree, then I probably misunderstood you 
> in the first place.
> 
>> In addition, the round-trip would be
>> needed to mainly edit content, and not that much formating - how a
>> section header looks in word or in LyX is irrelevant, as long as it is
>> recognised in the re-import / re-export for round-trip as a section
>> header. In Contrast, when exporting (non-round trip) one wants a
>> document as similar as possible to the LyX / LaTeX pdf (in most cases).
> 
> This is a useful feature as well, but IMHO not restricted to roundtrip: Even 
> if you want to do a one-way export (e.g. because you know that somebody else 
> will continue to work on the document and it will never come back to you), a 
> switch similar to the "clean" option of writer2latex would be a good thing 
> to have.

I agree - there would be nothing stopping you to use the round-trip
export for a semantic export, as you define it below.

> 
>> You are right - LaTeX is a special case, as it is the default backend
>> for LyX. So there are more strict requirements for the round-trip, and
>> all improvements in the round-trip should be immediately in the LaTeX
>> importer as well. But the story is different with other backends, e.g.
>> docx, where, if you go to replicating the LaTeX view, you might end with
>> "painted" documents which are not easily to be re-imported into LyX. But
>> for round trip, the look is not that relevant, as long as the content
>> and the structure can be re-imported.
> 
> I believe this alls boils down to semantic export as Stefano called it vs. 
> "painted" export, and semantic export would be useful with roundtrip and 
> without.

Nothing to add here - a semantic export would be really a very useful
addition to LyX.

> 
> 
> Georg
> 

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug



signature.asc
Description: OpenPGP digital signature

Re: GSOC 2014 project list: on LyX<-->docx roundtrip conversion



On 02/10/14, 14:59 , stefano franchi wrote:
> 
> 
> 
> On Mon, Feb 10, 2014 at 3:41 AM, Rainer M Krug  <mailto:rai...@krugs.de>> wrote:
> 
> 
> 
> On 02/09/14, 19:44 , Georg Baum wrote:
> > Rainer M Krug wrote:
> >
> >> The idea would be that a round-trip framework is envisaged, which
> >> provides the facilities to easily expand it from one export backend
> >> (docx) to another (possibly odt? markdown?).
> >>
> >> IMPORTANT: this would NOT change ANYTHING in the existing export /
> >> import features, as these are geared to export / import the
> documents as
> >> good as possible, with maintaining as many features as possible
> in the
> >> document.
> >>
> >> The round-trip would guarantee that:
> >>
> >> A document authored in LyX would result in a e.g. docx with a LIMITED
> >> set of features, but that a re-import would result in the SAME .lyx
> >> file. features and formats not supported by the backend should be
> stored
> >> in a metadata file.
> >>
> >> The important point here is *limited set of features*!
> >>
> >> In addition, the framework should be easily, possibly only by using
> >> config files, able to be extended to other formats.
> >
> > I don't understand the difference between round trip and the existing
> > export/import here. Why is it important? If the additional metadata is
> > stored in a different file, it could simply be generated for the
> standard
> > export, and be used by the standard import (if it exists).
> >
> > The goal of the export/import is to support as many features as
> possible.
> > This is needed for round trip as well. The only difference I see
> is the
> > additional metadata file, so the roundtrip framework vs. export/import
> > difference reduces to a switch whether the metadata file should be
> generated
> > (for export) or used (for import). Or did I understand anything wrong?
> 
> The difference is that for round-trip, i.e. working together with
> co-authors and getting comments back, a different set of features are
> relevant. These are mainly concerned about content and not that much
> formating. The import - export is concerned with both. In addition, a
> round trip has to be symmetric, i.e. that exported features have to be
> available in the re-importd as well - this is not the case in the export
> and import. Lastly, round-trip is for editing, and export - import is
> for editing and final consumption (reading).
> 
> 
> 
> I actually disagree on this point: the most useful doc-export facility
> for LyX would be equally focused on semantic content and not on
> formatting. 

Only partial disagreement - In the case you describe below, the export
to semantic, which is equal to the round-trip export, would be the end
product.

So let's call it a "semantic exporter" versus a "complete exporter" (as
the one used export to for LaTeX).

> In other words, it would be just half (or slightly less than
> half) of the round-trip project. The rationale is simple: exporting to
> doc(x) makes sense and is actually required when working with a third
> party (typically, for  Lyx's main audience, with a publisher) who will
> then either provide final formatting directly with Word (the worst case)
> or will use the doc(x) file as import into a real typesetting program
> (InDesign, etc). In neither case formatting instructions are relevant. I
> think it is a losing proposition to aim for the preservation of format
> when exporting to Word---and in fact it is the reason why, in my
> experience, *all* latex-to- word- (or to-odt) or lyx-to-word exporters
> actually fail in practice. It is impossibly hard to provide the same pdf
> look that (la)tex produces with Word. And the use cases in which this
> conversion is required are exceedingly rare. Far more pressing for our
> user base is the need to guarantee a hassle-free 100% valid export to a
> "sanitized word format" which is narrowly restricted, on both sides, to
> the semantic information contained in LyX.
> 
> To put it more bluntly (and to repeat what I and others have stated many
> times in the past): LyX is  barely usable right now for any academic
> work in the Humanities, due to the necessity to deliver doc documents to
> virtually any publisher. If you are a student, you are similarly asked
> by professor to submit drafts in Word format.   
> 
> I had t

Re: GSOC 2014 project list: on LyX<-->docx roundtrip conversion



On 02/09/14, 19:44 , Georg Baum wrote:
> Rainer M Krug wrote:
> 
>> The idea would be that a round-trip framework is envisaged, which
>> provides the facilities to easily expand it from one export backend
>> (docx) to another (possibly odt? markdown?).
>>
>> IMPORTANT: this would NOT change ANYTHING in the existing export /
>> import features, as these are geared to export / import the documents as
>> good as possible, with maintaining as many features as possible in the
>> document.
>>
>> The round-trip would guarantee that:
>>
>> A document authored in LyX would result in a e.g. docx with a LIMITED
>> set of features, but that a re-import would result in the SAME .lyx
>> file. features and formats not supported by the backend should be stored
>> in a metadata file.
>>
>> The important point here is *limited set of features*!
>>
>> In addition, the framework should be easily, possibly only by using
>> config files, able to be extended to other formats.
> 
> I don't understand the difference between round trip and the existing 
> export/import here. Why is it important? If the additional metadata is 
> stored in a different file, it could simply be generated for the standard 
> export, and be used by the standard import (if it exists).
> 
> The goal of the export/import is to support as many features as possible. 
> This is needed for round trip as well. The only difference I see is the 
> additional metadata file, so the roundtrip framework vs. export/import 
> difference reduces to a switch whether the metadata file should be generated 
> (for export) or used (for import). Or did I understand anything wrong?

The difference is that for round-trip, i.e. working together with
co-authors and getting comments back, a different set of features are
relevant. These are mainly concerned about content and not that much
formating. The import - export is concerned with both. In addition, a
round trip has to be symmetric, i.e. that exported features have to be
available in the re-importd as well - this is not the case in the export
and import. Lastly, round-trip is for editing, and export - import is
for editing and final consumption (reading).

> 
>> Yes - although I see one problem which I could not find in any of the
>> .lyx <-> .docx : comments and track changes. These *have to be handled*.
>> I somehow have the feeling, that an inclusion of comments and track
>> changes into pandoc would be the best way forward...
> 
> I agree. Unfortunately pandoc is written in Haskell which reduces the number 
> of possible contributors significantly (which does not mean that Haskell is 
> a bad language, but that it is much less known than e.g. C++ or python).

True.

Cheers,

Rainer


> 
> 
> Georg
> 
> 

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug



signature.asc
Description: OpenPGP digital signature

Re: GSOC 2014 project list: on LyX<-->docx roundtrip conversion



On 02/07/14, 17:35 , Rob Oakes wrote:
> Hi all,

Hi Rob,

good to hear from you on this topic.

> 
> I have been following conversations with significant interest. I 
> started a new job in the middle of last year. That combined with an 
> 18-month old little boy have left me almost no time for 
> extracurriculars. There is no way I can realistically mentor a student 
> this year. I tried really hard last year, and the effor didn't turn out 
> quite so well.
> 
> With that said, I would be happy to provide some support to a student 
> who might be trying to work on a round-trip Python module, or on the 
> non-linear writing project. If someone else were to be primary mentor, 
> I could certainly answer questions.
> 
> Re: Round-Tripping
> 
> As others in the thread have mentioned, I think the magic happens in 
> the export from LyX to Word. There are places where meta-data can be 
> placed in DOCX so that we can try and preserve LyX-specific features 
> through a round trip; and if we focus on semantic markup only, I think 
> we can do a pretty good job of maintaining content.

This is exactly what I think the round-triop has to focus on: semantic
markup to maintain the content and to have it available after edits for
re-import.

> 
> I think this means that we would need our own library to handle the 
> export. Most of the other modules out there do a very poor job of 
> handling semantic markup, and instead try and get the styling right. 
> That way madness lies. The Python module I started hacking on for the 
> import provides some support for generating docx, but this would need 
> to be beefed up pretty heavily. Moreover, it would be a really good 
> idea to make use of XSLT stylesheets to handle the transformation from 
> docx to LyX, instead of the Python approach I took.

This is why I also think that round-trip is a different story then
export - import. Different aspects of the document are relevant and need
to be preserved.

> 
> On another note, you should also probably have a discussion about how 
> you want to handle maths. The math XML vocabulary in docx is pretty 
> well contained, but it would still be an enormous job to translate it 
> to LyX/LaTeX. For export, we might make use of the MathML support LyX 
> already supports, and then translate thtat to docx math XML. There may 
> even be XSLT to do that.

I can't comment here, but I think that it would be nice to have this,
and in many cases this might be absolutely essential, but it could be
addad at a later stage, when the basic round-trip features are in place.
But it should definitely be considered.

Cheers,

Rainer

> 
> Cheers,
> 
> Rob
> 

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug



signature.asc
Description: OpenPGP digital signature

Re: GSOC 2014 project list: on LyX<-->docx roundtrip conversion