Re: The painting bug with ligatures reproduced on linux too

[Abdelrazak Younes]

On 11/22/2010 01:50 AM, Pavel Sanda wrote:

hi,

by accident i successfully reproduced quite horrible problem of unsynced visual
cursor position and the actual position of typing, so this is no more MacOS
thing only. the key point was to switch to dejavu fonts in linux.

http://www.lyx.org/trac/ticket/6920
   


Try this:


Index: src/rowpainter.cpp
===
--- src/rowpainter.cpp(revision 36426)
+++ src/rowpainter.cpp(working copy)
@@ -265,6 +265,9 @@
 break;
 }

+if (c == 'i'  prev_char == 'f')
+break;
+
 if (!isPrintableNonspace(c))
 break;

Re: r36430 - lyx-devel/trunk/src

[Abdelrazak Younes]

On 11/22/2010 09:57 AM, you...@lyx.org wrote:

Author: younes
Date: Mon Nov 22 09:57:33 2010
New Revision: 36430
URL: http://www.lyx.org/trac/changeset/36430

Log:
Work around bug #6920. This disables ligatures with involving 'f'
character.
   


Bennett, Stefan, please check that.

Abdel.

Re: The painting bug with ligatures reproduced on linux too

[Abdelrazak Younes]

On 11/22/2010 08:58 AM, Abdelrazak Younes wrote:

On 11/22/2010 01:50 AM, Pavel Sanda wrote:

hi,

by accident i successfully reproduced quite horrible problem of 
unsynced visual
cursor position and the actual position of typing, so this is no more 
MacOS

thing only. the key point was to switch to dejavu fonts in linux.

http://www.lyx.org/trac/ticket/6920


Try this:


Index: src/rowpainter.cpp
===
--- src/rowpainter.cpp(revision 36426)
+++ src/rowpainter.cpp(working copy)
@@ -265,6 +265,9 @@
 break;
 }

+if (c == 'i'  prev_char == 'f')
+break;
+
 if (!isPrintableNonspace(c))
 break;


I committed a more general patch. I reckon this is safe and will have 
almost no impact on performance.


Please test.

Abdel.

Re: lettre.layout bug

[Jean-Pierre Chrétien]

Jürgen Spitzmüller a écrit :

Jean-Pierre Chrétien wrote:

Attached.


Thanks. Committed to branch and trunk.


I have a warning with View DVI:

xdvi-xaw: Warning: Invalid papersize special `0.0pt,0.0pt'

Harmless because the DVI file is displayed all right and is
in A4 format.

This comes from this command added by LyX to the preamble:
\special{papersize=\the\paperwidth,\the\paperheight}

As lettre.cls does not define \paperwidth and \paperheight, the command
\special{papersize=0.0pt,0.0pt} is handed over to xdvi.

Both the original format issue with pdflatex and this one come from the fact 
that the lettre class ignore the a4paper option, so \(pdf)paperwidth and 
\(pdf)paperheight are undefined.


Hacking the preamble with \input{pdftexconfig.tex} is avoided if I simply remove 
the a4paper class option in the template, as the attached patch does.


On the other side, the fact that \[pdf]paperwidth and \[pdf]paperheight can be 
undefined by certain classes will create the same format issues than with 
lettre.cls. If classes are not required to define these, the commands added by 
LyX in the preamble do not seem to be activated correctly.


What do you think ?
--
Jean-Pierre
--- lib/layouts/lettre.layout.orig	2010-11-22 09:10:41.0 +0100
+++ lib/layouts/lettre.layout	2010-11-22 09:14:12.0 +0100
@@ -22,7 +22,9 @@
 #  - margins set to dynamic to ensure alignment of line headings
 #  - categories
 #  - ordering control left at the beginning (any other way ?)
-
+# rev.4; J.-P. Chretien nov 2010
+#  - remove \input{pdftexconfig.tex} workaround
+#(not needed if a4paper class option is not used)
 
 Format 11
 
@@ -126,11 +128,6 @@
 \fi		% if needSendFax
   }	%findemessage
 
-% to get the specified pagesize 
-% (workaround for an a4paper/lettre problem in pdf mode)
-...@ifpackageloaded{ifpdf}{}{\usepackage{ifpdf}}
-\ifpdf\input pdftexconfig.tex\fi
-
 EndPreamble
 
 # My Address style used to specify sender name and coordinates
--- lib/templates/lettre.lyx.orig	2010-11-22 09:11:08.0 +0100
+++ lib/templates/lettre.lyx	2010-11-22 09:49:20.0 +0100
@@ -1,4 +1,4 @@
-#LyX 1.6.8svn created this file. For more info see http://www.lyx.org/
+#LyX 1.6.9svn created this file. For more info see http://www.lyx.org/
 \lyxformat 345
 \begin_document
 \begin_header
@@ -19,7 +19,7 @@
 \paperfontsize 11
 \spacing single
 \use_hyperref false
-\papersize a4paper
+\papersize default
 \use_geometry false
 \use_amsmath 1
 \use_esint 1
@@ -37,6 +37,7 @@
 \tracking_changes false
 \output_changes false
 \author  
+\author  
 \end_header
 
 \begin_body
@@ -55,6 +56,17 @@
 L'ordre des éléments est indifférent.
 \end_layout
 
+\begin_layout Plain Layout
+La classe lettre ne connaît pas l'option a4paper, ne pas sélectionner 
+\family sans
+Document\SpecialChar \menuseparator
+Paramètres\SpecialChar \ldots{}
+\SpecialChar \menuseparator
+Format de la page\SpecialChar \menuseparator
+Format\SpecialChar \menuseparator
+A4
+\end_layout
+
 \end_inset
 
 

Re: lyx2.0 modifies read-only files!

[Sebastian Guttenberg]

 This was changed to solve bug http://www.lyx.org/trac/ticket/6587.
 
 Now we move the file to the backup file before saving the current file. 
 So, we basically do not overwrite the original file, but we move away 
 the original read-only file and write a new file.

I have read the discussion around the old bug, so I can understand that
you don't want to change back. But what about comparing the flags of the
original file and the new file for every time you save it (and not only
when you open it) ?
- Sebastian

Crash in multine AMS context with CAS [#7058] PSTricks instant preview

[venom00]

I've made a bug report about a crash when invoking a CAS in multine AMS 
context. The LyX stdout doesn't tell anything useful.

Moreover I've a question about instant preview and PSTricks, see the 
attachment, it doesn't show up the graph. I didn't make a bug report because 
maybe it's just due to some misconfiguration or conflict specific to my system. 
You need pst-tricks and pst-plot. I just see the pre and post text but no 
graph!

I'm under Windows 7, using MiKTeX 2.8, using LyX 2.0beta1.

Thanks in advance,
Ale


pst-tricks_instant-preview.lyx
Description: application/lyx

Re: r36430 - lyx-devel/trunk/src

[Pavel Sanda]

Abdelrazak Younes wrote:
 On 11/22/2010 09:57 AM, you...@lyx.org wrote:
 Author: younes
 Date: Mon Nov 22 09:57:33 2010
 New Revision: 36430
 URL: http://www.lyx.org/trac/changeset/36430

 Log:
 Work around bug #6920. This disables ligatures with involving 'f'
 character.


 Bennett, Stefan, please check that.

its fixed here now. Juergen this problem is also in branch.

pavel

Re: [patch] polyglossia

[Pavel Sanda]

Jürgen Spitzmüller wrote:
 Jürgen Spitzmüller wrote:
  The attached patch adds support for polyglossia with XeTeX.
  
  As estimated, the patch is rather big, and it needs good testing. I have 
  tested with multiple languages (including Arabic, Hebrew, and Greek), but
  of  course, there could be many things I have overlooked.
 
 Attached a slightly polished patch (I factored out all the arabic - 
 Arabic  transformations).
 
 Pavel, shall I put this in?

yes. please can you write some concise statement what has been changed wrt 
xetex?
i would like to put it into beta2 announce (or feel free to add it there 
directly).

pavel

Re: r36430 - lyx-devel/trunk/src

[Enrico Forestieri]

On Mon, Nov 22, 2010 at 12:33:17PM +0100, Pavel Sanda wrote:

 Abdelrazak Younes wrote:
  On 11/22/2010 09:57 AM, you...@lyx.org wrote:
  Author: younes
  Date: Mon Nov 22 09:57:33 2010
  New Revision: 36430
  URL: http://www.lyx.org/trac/changeset/36430
 
  Log:
  Work around bug #6920. This disables ligatures with involving 'f'
  character.
 
 
  Bennett, Stefan, please check that.
 
 its fixed here now. Juergen this problem is also in branch.

I cannot reproduce this bug with any font (including DejaVu) on Linux,
Windows and Solaris, with or without this patch. I verified that the
ligatures are present at U+FB00-U+FB04, so it cannot be due to their
presence or absence (tested with Qt 4.6.3 and 4.7.0).
So, what triggers it?

-- 
Enrico

Re: r36430 - lyx-devel/trunk/src

[Pavel Sanda]

Enrico Forestieri wrote:
  its fixed here now. Juergen this problem is also in branch.
 
 I cannot reproduce this bug with any font (including DejaVu) on Linux,
 Windows and Solaris, with or without this patch. I verified that the
 ligatures are present at U+FB00-U+FB04, so it cannot be due to their
 presence or absence (tested with Qt 4.6.3 and 4.7.0).
 So, what triggers it?

only two things come to my mind -  some magical switch in Qt compilation
or fontconfig settings...

we can try to make small poll around which people are able to reproduce,
so we get idea what can be the common denominator.

pavel

Re: [patch] polyglossia

[Jürgen Spitzmüller]

Pavel Sanda wrote:
 yes. please can you write some concise statement what has been changed wrt
 xetex? i would like to put it into beta2 announce (or feel free to add it
 there directly).

The statement would be something like:

Support for polyglossia, XeTeX's new language interface and babel 
replacement, has been added. If polyglossia is installed and if the used 
languages are supported by polyglossia, LyX will now automatically use this 
package instead of babel with XeTeX output.

Jürgen

Re: [patch] fix bug 3008

[Guenter Milde]

On 2010-11-19, Georg Baum wrote:

 Hi,

 after I needed to explain several times lately why one should not use the 
 menu entries for sub/superscript in text and what to do instead, I finally 
 sat down and completed a fix for bug 3008 that I started years ago. It 
 implements a new inset for subscript and superscript in text mode, including 
 correct output for all backends. There are some other ideas discussed in 
 http://www.lyx.org/trac/ticket/3008, but the inset approach is the best one 
 IMO.

...  
  
 +# these classes provide a \textsubscript command:
 +# FIXME: Would be nice if we could use the information of the .layout 
 file here
 +classes = [memoir, scrartcl, scrbook, scrlttr2, scrreprt]
 +if foundsubscript and find_token_exact(classes, document.textclass, 0) 
 == -1:
 +add_to_preamble(document, ['\\usepackage{subscript}'])

Please use the fixltx2e package for \textsubscript:

  Provides a command \textsubscript , which is a modified version the
  command \textsuperscript that's part of LaTeX.  The command is also
  (now) provided by the fixltx2e package distributed with LaTeX itself;
  if you are running a LaTeX distribution no earlier than 2005/12/01, you
  will have a more satisfactory means of using the command.

  -- http://tug.ctan.org/cgi-bin/ctanPackageInformation.py?id=subscript

I argue, that LyX-2 should by default *always* insert
\usepackage{fixltx2e}. This package collects a range of fixes and
improvements that are not not in the LaTeX core due to backwards
compatibility issues. The quantum-leap from 1 to 2 would be a good
place for this change:

  Identifierfixltx2e
  
  Caption   Patches for LaTeX.
  
  Description   
  
LaTeX policy is that things should not change, between releases, in a
way that will cause incompatibility with old documents, or will cause
typesetting of an unchanged document to change.
  
Nevertheless, there are problems in LaTeX that it “would be nice” to
correct; fixltx2e provides a home for these corrections.  Corrections
in the current version are:
  
  * ensure one-column floats don't get ahead of two-column floats;
  
  * correct page headers in twocolumn documents;
  
  * stop spaces disappearing in moving arguments;
  
  * allowing  \fnysmbol  to use text symbols;
  
  * allow the first word after a float to hyphenate;
  
  * \emph  can produce caps/small caps text;
  
  * bugs in  \setlength  and flushbottom.
  
-- http://tug.ctan.org/pkg/fixltx2e

Günter

Re: [patch] fix bug 3008

[Jürgen Spitzmüller]

Guenter Milde wrote:
 I argue, that LyX-2 should by default always insert
 \usepackage{fixltx2e}. This package collects a range of fixes and
 improvements that are not not in the LaTeX core due to backwards
 compatibility issues. The quantum-leap from 1 to 2 would be a good
 place for this change:

While I agree that fixltx2e is the correct package, we should no always insert 
it. There's a reason why these fixes have not been integrated into the kernel, 
and so we should also let the user decide here.

Jürgen

Re: [patch] fix bug 3008

[Guenter Milde]

On 2010-11-22, Uwe Stöhr wrote:
  On 21/11/2010 5:20 PM, Uwe Stöhr wrote:
 
 That it is not included in MiKTeX, also not via the fragments or
 fixltx2e package. Therefore all LyX on Windows would be forced to
 install the file manually which is not acceptable.
 
  How about using
 
  \usepackage{fixltx2e}
 
  for providing \textsubscript? This one is shipped with miktex.

 As I said (you even cited this) fixltx2e is not available for MiKTeX,
 at last not under MiKTeX 2.9.

This would be very strange: 

   The package is distributed as part of LaTeX; the extracted package is
   also available on the archive (location linked here). 

   -- http://www.ctan.org/tex-archive/help/Catalogue/entries/fixltx2e.html
   
I suppose it is not mentioned as extra download/extension because it
is already part of every latex base install.

Günter   

Re: old (mhchem-)package issue in lyx2.0

[Sebastian Guttenberg]

Hi all
I have now produced an example tex-file that my problem is of a more
general nature and can appear also with other packages than mhchem. I
have constructed an example of a conflict with the automatic package
support in the case of \tfrac of the ams-package. 
The following is a bug for the Latex-import and has data-loss (well, at
least if one re-exports and overwrites the original tex-file):

1. first compile the attached tex-file to see how the outcome should
look like
2. then import this tex-file into lyx.20. You will immediately see that
things get a bit messed up, because ams-math is loaded by default. Still
we can try to compile and get of course an LaTeX error-message, that
\tfrac has already been defined.
3. Go to Documents-Settings-Math Options
and deselect Use AMS package automatically
4. Although this prevents Lyx from actually loading the latex-package
amsmath, it does not remove the lyx-internal support for ams-related
macros (like tfrac). So at least within lyx, equations look still
spoiled.
4. compiling now works but leads to a quite different output then the
original tex-file! Better than in lyx itself, but still spoiled. In
particular, the whole content of the last line is missing!!

For most appearances of \tfrac, only place-holders are eaten, so
that for the dvi-file only the formatting of the equation gets spoiled.
But when one uses \tfrac inside a bracket then whole lines get lost. 
Actually I was a bit surprised by the result myself, because I was
expecting to produce this bug only when I define the macro in a
child-document. Apparently the problem is not related to child
documents, but probably in general for imports (you'll know better). So
I guess that someone who has defined his own \tfrac in an old
lyx-version where this ams-math-command was not yet supported, should
run into the same problems, when importing. There are thousands of other
examples one could think of. 

Not being a programmer, I should not be demanding, but I personally
think that a proper fix would include the following:
* For any imported file lyx should neither load nor support any package
that has not been loaded in the original file
* deselecting packages should result in removing the lyx-internal
support for the corresponding commands
* ideally, if for some reason still a package support is wrongly loaded,
this should at most lead to a chaos in the lyx-internal way of
presenting the result and in LaTex errors due to double-definitions, but
never to real data-loss. So having such a mess, it should always be
possible to manually deselect the packages and get back something
reasonable. 
I don't know how much effort each of these items would require, but
without this I would imagine that in future always some related problems
will reappear and require a case-by-case fix. 
- Sebastian
Here's the tex-file:

\documentclass{article}  %% testTexImport.tex

\newcommand{\tfrac}{\frac{t_1}{t_2}}

\begin{document}
\begin{eqnarray}
t_1  =  ac,\quad t_2=ad \\
2+\tfrac  =  2+\frac{ac}{ad}\\
  =  \frac{c}{d}+2\\
  =  \left(\tfrac \right)+2\quad\rm{this\;line\;will\;be\;missing!!}
\end{eqnarray}
\end{document}

Re: r36430 - lyx-devel/trunk/src

[Abdelrazak Younes]

On 11/22/2010 12:57 PM, Pavel Sanda wrote:

Enrico Forestieri wrote:
   

its fixed here now. Juergen this problem is also in branch.
   

I cannot reproduce this bug with any font (including DejaVu) on Linux,
Windows and Solaris, with or without this patch. I verified that the
ligatures are present at U+FB00-U+FB04, so it cannot be due to their
presence or absence (tested with Qt 4.6.3 and 4.7.0).
So, what triggers it?
 

only two things come to my mind -  some magical switch in Qt compilation
or fontconfig settings...
   


I've searched a bit and no, there's nothing like that, AFAICS.


we can try to make small poll around which people are able to reproduce,
so we get idea what can be the common denominator.
   


It essentially depends on the font. Not all fonts implement automatic 
ligature and within one font, some builds do others don't.


But as I said in trac, this is not a bug of Qt or freetype or the font. 
The issue is just that we use own own text engine and we compute metrics 
character by character in order to have correct cursor positioning. As 
we paint word by word the cursor is not painted at the correct position.


Abdel.

Re: lettre.layout bug

[Jürgen Spitzmüller]

Jean-Pierre Chrétien wrote:
 I have a warning with View DVI:
 
 xdvi-xaw: Warning: Invalid papersize special `0.0pt,0.0pt'
 
 Harmless because the DVI file is displayed all right and is
 in A4 format.
 
 This comes from this command added by LyX to the preamble:
 \special{papersize=\the\paperwidth,\the\paperheight}
 
 As lettre.cls does not define \paperwidth and \paperheight, the command
 \special{papersize=0.0pt,0.0pt} is handed over to xdvi.
 
 Both the original format issue with pdflatex and this one come from the
 fact  that the lettre class ignore the a4paper option, so \(pdf)paperwidth
 and \(pdf)paperheight are undefined.
 
 Hacking the preamble with \input{pdftexconfig.tex} is avoided if I simply
 remove  the a4paper class option in the template, as the attached patch
 does.
 
 On the other side, the fact that \[pdf]paperwidth and \[pdf]paperheight can
 be  undefined by certain classes will create the same format issues than
 with lettre.cls. If classes are not required to define these, the commands
 added by LyX in the preamble do not seem to be activated correctly.
 
 What do you think ?

I'm fine with that, but this all strikes me like the bugs in the class itself. 
Did you consider to inform the class author?

Jürgen

Subscription needed?

[Pavel Sanda]

hi Tommaso,

i dont see your commits like r36411 in our cvs list. is tomm...@lyx subscribed
there? iirc this was needed so distribution works properly. can you have a look?

pavel

Re: LyX without menu in Ubuntu Netbook 10.10

[Manveru]

2010/11/19 Waluyo Adi Siswanto was.u...@gmail.com:
 It works by using this command  (from the terminal)

 QT_X11_NO_NATIVE_MENUBAR=1 lyx


 Perhaps, for those using Ubuntu Netbook and have the same problem;

 a) Create a file lyx_command.sh
    #!/bin/sh
     QT_X11_NO_NATIVE_MENUBAR=1 lyx
 b) Change permission to Allow executing file as program
 c) Replace the previous lyx command (lyx %f) by browsing to lyx_command.sh

 Now clicking LyX menu under applications - office, can see LyX with
 normal menus.

Proper script is that:
#!/usr/bin/env sh
QT_X11_NO_NATIVE_MENUBAR=1 lyx $@

Such version allows passing of invocation arguments.
-- 
Manveru
jabber: manv...@manveru.pl
     gg: 1624001
   http://www.manveru.pl

internationalized messages should not contain the `\r' escape sequence

[Kornel]

(trunk)
This is what I get since today, with all po-files.

The appropriate messages in the po-files are:

msgid Itemize\r
msgid Description\r
msgid Labeling\r
msgid List\r
msgid 00.00.\r
msgid Enumerate-Resume\r

It is warning only, but does not look correct.

Kornel


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

Re: internationalized messages should not contain the `\r' escape sequence

[Pavel Sanda]

Kornel wrote:
 (trunk)
 This is what I get since today, with all po-files.
 
 The appropriate messages in the po-files are:
 
 msgid Itemize\r
 msgid Description\r
 msgid Labeling\r
 msgid List\r
 msgid 00.00.\r
 msgid Enumerate-Resume\r
 
 It is warning only, but does not look correct.

i see, enumitem module is saved as crlf file...
pavel

Re: [patch] fix bug 3008

[Jean-Marc Lasgouttes]

Le 21/11/2010 18:05, Georg Baum a écrit :

Yeah. I run into this a lot these days. But then I think: Do I really want
to write a layout parser for lyx2lyx?


These were exactly my thoughts. Nevertheless, it would be nice to have one
:-)


Could our in-LyX textclass parser be augmented to dump textclasses as 
python structs, so that lyx2lyx can read them effortlessly?


We could run this dump-textclasses lfun from time to time to make sure 
that lyx2lyx has up-to-date information.


JMarc

Re: internationalized messages should not contain the `\r' escape sequence

[Vincent van Ravesteijn]

 i see, enumitem module is saved as crlf file...
 pavel

Fixed in http://www.lyx.org/trac/changeset/36435.

;).

I accidentally set the  svn property eol-style instead of
svn:eol-style. Being on windows, the crlf line endings got committed
which I just wanted to prevent by setting the svn:eol-style property
in the first place.

Vincent

Re: internationalized messages should not contain the `\r' escape sequence

[Pavel Sanda]

Vincent van Ravesteijn wrote:
  i see, enumitem module is saved as crlf file...
  pavel
 
 Fixed in http://www.lyx.org/trac/changeset/36435.
 
 ;).

Sendinglayouts/enumitem.module
Transmitting file data .svn: Commit failed (details follow):
svn: File '/lyx-devel/trunk/lib/layouts/enumitem.module' is out of date
svn: Your commit message was left in a temporary file:
svn:'/home/paf/lyx/tree/trunk/lib/svn-commit.tmp'

:)
p

Re: r36430 - lyx-devel/trunk/src

[BH]

On Mon, Nov 22, 2010 at 3:58 AM, Abdelrazak Younes you...@lyx.org wrote:
 On 11/22/2010 09:57 AM, you...@lyx.org wrote:

 Author: younes
 Date: Mon Nov 22 09:57:33 2010
 New Revision: 36430
 URL: http://www.lyx.org/trac/changeset/36430

 Log:
 Work around bug #6920. This disables ligatures with involving 'f'
 character.


 Bennett, Stefan, please check that.

It works as advertised with ligatures. But a related problem I had
reported long ago is with swooshes with italics fonts, such as Hoefler
Text Italics. I'm attaching a screenshot.

BH
attachment: text.png

Re: [patch] fix bug 3008

[Richard Heck]

On 11/22/2010 08:41 AM, Jean-Marc Lasgouttes wrote:

Le 21/11/2010 18:05, Georg Baum a écrit :
Yeah. I run into this a lot these days. But then I think: Do I 
really want

to write a layout parser for lyx2lyx?


These were exactly my thoughts. Nevertheless, it would be nice to 
have one

:-)


Could our in-LyX textclass parser be augmented to dump textclasses as 
python structs, so that lyx2lyx can read them effortlessly?


We could run this dump-textclasses lfun from time to time to make 
sure that lyx2lyx has up-to-date information.



That's one idea, sure. Let me think about it.

Richard

[patch] LuaTeX

[Jürgen Spitzmüller]

Out of curiosity, I checked out what it would need us to implement basic 
support for Lua(La)TeX (basic in the sense of what we had for XeTeX prior to 
the polyglossia commit today*). And it's really as simple as the attached.

What I would do additionally to the patch are just two cosmetic things:

(1) rename the buffer param useXeTeX to useLuaXeTeX (or something else, if 
someone comes up with a better name), since that param just tells us that we 
use a modern utf8- and OpenType-aware processor (such as XeTeX and LuaTeX), 
contrary to the flavour that tells us which processor this is.
This one would be a file format change, although a very simple one.

(2) In the GUI, I would rename the Use XeTeX checkbox to Use System Fonts 
(since this is really what is of interest for the end user) and put the 
checkbox to fonts.

I hesitated to send this now, since I agree we should not add any more new 
features, and of course I respect if this is gonna be postponed. OTOH, people 
are just starting to use LuaTeX now for serious work, and I expect it to 
become more mature within the next months. So I just wanted to let you know 
how cheap this inclusion would be ;-)

Jürgen

* there is nothing like polyglossia for LuaTeX yet, and alas, LuaTeX faces the 
same problems with babel than XeTeX. That is: it works for many languages, but 
has problems with some (Greek, Arabic for instance).
Index: src/insets/InsetExternal.cpp
===
--- src/insets/InsetExternal.cpp	(Revision 36432)
+++ src/insets/InsetExternal.cpp	(Arbeitskopie)
@@ -725,6 +725,7 @@
 	case OutputParams::LATEX:
 		format = LaTeX;
 		break;
+	case OutputParams::LUATEX:
 	case OutputParams::PDFLATEX:
 	case OutputParams::XETEX:
 		format = PDFLaTeX;
Index: src/insets/InsetGraphics.cpp
===
--- src/insets/InsetGraphics.cpp	(Revision 36432)
+++ src/insets/InsetGraphics.cpp	(Arbeitskopie)
@@ -102,9 +102,10 @@
 /// Note that \p format may be unknown (i. e. an empty string)
 string findTargetFormat(string const  format, OutputParams const  runparams)
 {
-	// Are we using latex or XeTeX/pdflatex?
+	// Are we using latex or XeTeX/LuaTeX/pdflatex?
 	if (runparams.flavor == OutputParams::PDFLATEX
-	|| runparams.flavor == OutputParams::XETEX) {
+	|| runparams.flavor == OutputParams::XETEX
+	|| runparams.flavor == OutputParams::LUATEX) {
 		LYXERR(Debug::GRAPHICS, findTargetFormat: PDF mode);
 		Format const * const f = formats.getFormat(format);
 		// Convert vector graphics to pdf
Index: src/insets/InsetListings.cpp
===
--- src/insets/InsetListings.cpp	(Revision 36432)
+++ src/insets/InsetListings.cpp	(Arbeitskopie)
@@ -144,10 +144,11 @@
 	Encoding const * const save_enc = runparams.encoding;
 
 	if (runparams.flavor != OutputParams::XETEX
+	 runparams.flavor != OutputParams::LUATEX
 	 !runparams.encoding-hasFixedWidth()) {
 		// We need to switch to a singlebyte encoding, since the
 		// listings package cannot deal with multi-byte-encoded
-		// glyphs (not needed with XeTeX).
+		// glyphs (not needed with XeTeX or LuaTeX).
 		Language const * const outer_language =
 			(runparams.local_font != 0) ?
 runparams.local_font-language()
Index: src/Converter.cpp
===
--- src/Converter.cpp	(Revision 36432)
+++ src/Converter.cpp	(Arbeitskopie)
@@ -257,6 +257,8 @@
 		if (conv.latex)
 			if (contains(conv.from, xetex))
 return OutputParams::XETEX;
+			if (contains(conv.from, luatex))
+return OutputParams::LUATEX;
 			if (contains(conv.to, pdf))
 return OutputParams::PDFLATEX;
 		if (conv.xml)
@@ -747,6 +749,7 @@
 	v.push_back(docbook);
 	v.push_back(latex);
 	v.push_back(literate);
+	v.push_back(luatex);
 	v.push_back(lyx);
 	v.push_back(xhtml);
 	v.push_back(pdflatex);
Index: src/OutputParams.h
===
--- src/OutputParams.h	(Revision 36433)
+++ src/OutputParams.h	(Arbeitskopie)
@@ -29,6 +29,7 @@
 public:
 	enum FLAVOR {
 		LATEX,
+		LUATEX,
 		PDFLATEX,
 		XETEX,
 		XML,
Index: src/output_latex.cpp
===
--- src/output_latex.cpp	(Revision 36433)
+++ src/output_latex.cpp	(Arbeitskopie)
@@ -865,7 +865,7 @@
 	// If this is the last paragraph, and a local_font was set upon entering
 	// the inset, and we're using auto or default encoding, the encoding
 	// should be set back to that local_font's encoding.
-	// However, do not change the encoding when XeTeX is used.
+	// However, do not change the encoding when XeTeX or LuaTeX are used.
 	if (nextpit == paragraphs.end()  runparams_in.local_font != 0
 	 runparams_in.encoding != runparams_in.local_font-language()-encoding()
 	 (bparams.inputenc == auto || bparams.inputenc == default)
Index: src/OutputParams.cpp

Re: [patch] LuaTeX

[Pavel Sanda]

Jürgen Spitzmüller wrote:
 features, and of course I respect if this is gonna be postponed. OTOH, people 
 are just starting to use LuaTeX now for serious work, and I expect it to 
 become more mature within the next months. So I just wanted to let you know 

i have rather general questions:
* are there security considerations (havent worked with it, but
  its possible to write ERT for rm -rf/ in lua)?

* why do we want it at all - or in more general, what are we aiming to support?
  all pdftex, xetex, luatex?
  each new engine will have its own quirks i guess. its not clear to me whether
  its fashion for next five years or its mature and is going to survive -- or be
  replaced by some new xeluatex creature?
  (honest question, i dont follow development steps of these. short googling
  returns bunch of time-dependent infos...).

pavel

Re: LyX without menu in Ubuntu Netbook 10.10

[Waluyo Adi Siswanto]

 Proper script is that:
    #!/usr/bin/env sh
    QT_X11_NO_NATIVE_MENUBAR=1 lyx $@

 Such version allows passing of invocation arguments.

Oh.. yes, that's correct. Running LyX from the menu using the previous
script, creates another problem. Double clicking lyx document will not
be successful.

I have corrected the script in my netbook, thank you.

Regards
waluyo

Re: [patch] LuaTeX

[Jürgen Spitzmüller]

Pavel Sanda wrote:
 i have rather general questions:
 * are there security considerations (havent worked with it, but
   its possible to write ERT for rm -rf/ in lua)?

I don't think so. The LuaTeX developers are rather security-aware guys (after 
all, these are the pdflatex/context people, a bunch of real good programmers).

 * why do we want it at all - or in more general, what are we aiming to
 support? all pdftex, xetex, luatex?

Yes.

   each new engine will have its own quirks i guess. its not clear to me
 whether its fashion for next five years or its mature and is going to
 survive -- or be replaced by some new xeluatex creature?
   (honest question, i dont follow development steps of these. short
 googling returns bunch of time-dependent infos...).

Well, nobody knows for sure, of course. From what I know, LuaTeX is planned to 
replace PDFTeX in the long term (it's already the default engine in ConTeXt, I 
think). The pdftex maintainers only fix bugs in pdftex itself, all new 
features go into LuaTeX. Having said that, pdftex is very stable and reliable, 
and for people who do not need all the nifty new features, there's no need to 
depart from pdftex, neither to XeTeX nor to LuaTeX. 

XeTeX is completely orthogonal to LuaTeX, although there are shared aims. I 
guess both the LuaTeX and XeTeX maintainers respect the respective other 
project (Han The Than, the original pdftex author, even contributed to XeteX 
recently). From a user POV, both provide OpenType and true Unicode support, 
but they also have their respective strengthes and weaknesses:

* XeTeX is rather monolithic, while LuateX is modular
* XeTeX only produces PDF, LuaTex can also output DVI
* LuaTeX has better micro-typographic features (font expansion)
* XeTeX has (still) better language support (via polyglossia)
* XeTeX is basically a one-man project, LuaTeX is team-driven

I guess it is fair to support either of these backend. 

Jürgen

Re: Subscription needed?

[Tommaso Cucinotta]

Il 22/11/2010 14:02, Pavel Sanda ha scritto:

hi Tommaso,

i dont see your commits like r36411 in our cvs list. is tomm...@lyx subscribed
there? iirc this was needed so distribution works properly. can you have a look?

Hi,

I confess I have no clue of what you're talking about. Please, explain 
as if I were 3 years old, thanks.
If you mean the list that notifies me of each and every commit in LyX, I 
probably don't actually need to be there :-).


T.

Re: r36430 - lyx-devel/trunk/src

[Stephan Witt]

Am 22.11.2010 um 12:50 schrieb Enrico Forestieri:

 On Mon, Nov 22, 2010 at 12:33:17PM +0100, Pavel Sanda wrote:
 
 Abdelrazak Younes wrote:
 On 11/22/2010 09:57 AM, you...@lyx.org wrote:
 Author: younes
 Date: Mon Nov 22 09:57:33 2010
 New Revision: 36430
 URL: http://www.lyx.org/trac/changeset/36430
 
 Log:
 Work around bug #6920. This disables ligatures with involving 'f'
 character.
 
 
 Bennett, Stefan, please check that.
 
 its fixed here now. Juergen this problem is also in branch.
 
 I cannot reproduce this bug with any font (including DejaVu) on Linux,
 Windows and Solaris, with or without this patch. I verified that the
 ligatures are present at U+FB00-U+FB04, so it cannot be due to their
 presence or absence (tested with Qt 4.6.3 and 4.7.0).
 So, what triggers it?

I don't know if you already have an answer.
I think the surprising fact is - it has nothing to do with unicode ligatures.

The problem is the too clever font rendering of Qt. Similar to the TeX engine.
E. g. you typeset the word infinite. The fi ligature is rendered 
automatically
if the font has the appropriate capabilities.
Currently this happens only for rare circumstances.

Abdel's solution is like a hard coded ligature-break.
When fi is found LyX will render f and i instead.

Abdel, I'm sorry to say that, but I don't think it's sufficient.
This fi ligature is only one example. There are others, for sure.
And Bennett presented another incarnation of this bug in his mail today.
Please, correct me if I'm wrong...

I understand, it's very hard to solve correctly. 
I guess, the text metrics machinery of LyX is not ready to handle that.

Qt proposes the use of QTextLayout.

In QFontMetrics::width() one can read:

\warning This function will produce incorrect results for Arabic
characters or non-spacing marks in the middle of a string, as the
glyph shaping and positioning of marks that happens when
processing strings cannot be taken into account. When implementing
an interactive text control, use QTextLayout instead.

Stephan

Re: [patch] LuaTeX

[Richard Heck]

On 11/22/2010 10:55 AM, Jürgen Spitzmüller wrote:

Out of curiosity, I checked out what it would need us to implement basic
support for Lua(La)TeX (basic in the sense of what we had for XeTeX prior to
the polyglossia commit today*). And it's really as simple as the attached.

What I would do additionally to the patch are just two cosmetic things:

(1) rename the buffer param useXeTeX to useLuaXeTeX (or something else, if
someone comes up with a better name), since that param just tells us that we
use a modern utf8- and OpenType-aware processor (such as XeTeX and LuaTeX),
contrary to the flavour that tells us which processor this is.
This one would be a file format change, although a very simple one.


useUnicodeTeX? useUTF8TeX?



(2) In the GUI, I would rename the Use XeTeX checkbox to Use System Fonts
(since this is really what is of interest for the end user) and put the
checkbox to fonts.

This one I'm less sure about. I cant tell from the patch how we decide 
which one to use. Wasn't it determined

before by the Use XeTeX box? Anyway, clearly I'm confused.


I hesitated to send this now, since I agree we should not add any more new
features, and of course I respect if this is gonna be postponed. OTOH, people
are just starting to use LuaTeX now for serious work, and I expect it to
become more mature within the next months. So I just wanted to let you know
how cheap this inclusion would be ;-)


Cheap indeed.

On a somewhat unrelated note:


Index: src/Converter.cpp
===
--- src/Converter.cpp   (Revision 36432)
+++ src/Converter.cpp   (Arbeitskopie)
@@ -257,6 +257,8 @@
if (conv.latex)
if (contains(conv.from, xetex))
return OutputParams::XETEX;
+   if (contains(conv.from, luatex))
+   return OutputParams::LUATEX;
if (contains(conv.to, pdf))
return OutputParams::PDFLATEX;
if (conv.xml)

These tests look wrong. At the very least, shouldn't these check 
startswith. What if someone defines a format nopdf?


Richard

Re: Subscription needed?

[Vincent van Ravesteijn]

If you mean the list that notifies me of each and every commit in LyX, 
I probably don't actually need to be there :-).


Yes, you do. If you're not on that list, we are not notified either.

Vincent

Re: [patch] LuaTeX

[Guenter Milde]

On 2010-11-22, Jürgen Spitzmüller wrote:
 Pavel Sanda wrote:

 * why do we want it at all - or in more general, what are we aiming to
 support? all pdftex, xetex, luatex?

 Yes.

Seconded.

...

 pdftex is very stable and reliable, and for people who do not need all
 the nifty new features, there's no need to depart from pdftex, neither
 to XeTeX nor to LuaTeX. 

and while more and more packages are made unicode ready, pdftex is
the save bet.

 XeTeX is completely orthogonal to LuaTeX, although there are shared aims.
...
 From a user POV, both provide OpenType and true Unicode support, 
 but they also have their respective strengthes and weaknesses:
...
 I guess it is fair to support either of these backend. 

Especially as there is active work to have a common LaTeX interface,
e.g. hyperref, fontspec and unicode-math are all updated to work with
both engines (hyperref also with pdftex), polyglossia will follow.

Günter

Re: [patch] LuaTeX

[Guenter Milde]

On 2010-11-22, Richard Heck wrote:
 On 11/22/2010 10:55 AM, Jürgen Spitzmüller wrote:
 Out of curiosity, I checked out what it would need us to implement basic
 support for Lua(La)TeX (basic in the sense of what we had for XeTeX prior to
 the polyglossia commit today*). And it's really as simple as the attached.

 What I would do additionally to the patch are just two cosmetic things:

 (1) rename the buffer param useXeTeX to useLuaXeTeX (or something else, if
 someone comes up with a better name), since that param just tells us that we
 use a modern utf8- and OpenType-aware processor (such as XeTeX and LuaTeX),
 contrary to the flavour that tells us which processor this is.
 This one would be a file format change, although a very simple one.

 useUnicodeTeX? useUTF8TeX?

useUniTex?

 (2) In the GUI, I would rename the Use XeTeX checkbox to Use System
 Fonts (since this is really what is of interest for the end user) and
 put the checkbox to fonts.

Rather not:

* The reason to use XeTeX/LuaTeX can also be a craving for better Unicode
  support (e.g. Latin words in a Greek document without the need to set
  the language, support for more Unicode characters like e.g. Block
  Elements).

* XeTeX can also use OpenType fonts that are not system-wide installed as
  well as traditional LaTeX fonts.

 This one I'm less sure about. I cant tell from the patch how we decide 
 which one to use. Wasn't it determined
 before by the Use XeTeX box? Anyway, clearly I'm confused.

There should be no need to have separate XeTeX and LuaTeX settings.

IMV, it is also wrong to define the used engine as a special document
setting: Just like we allow export of the same document to XHTML, PS, and
PDF without change in the document settings, we should allow

* PDF (ps2pdf)
* PDF (pslatex)
* PDF (xetex)
* PDF (luatex)

as export options.

This would also mean that there should be the possibility to configure
font sets for pdftex, xetex/luates, and html in parallel in one document.

I suppose it is too late to change this for 2.0, though.

Currently, you would need to set the LaTeX - PDF (UniTeX) converter
to either xetex or luatex.

Günter

Re: [patch] fix bug 3008

[Guenter Milde]

On 2010-11-22, Jürgen Spitzmüller wrote:
 Guenter Milde wrote:
 I argue, that LyX-2 should by default always insert
 \usepackage{fixltx2e}. This package collects a range of fixes and
 improvements that are not not in the LaTeX core due to backwards
 compatibility issues. The quantum-leap from 1 to 2 would be a good
 place for this change:

 While I agree that fixltx2e is the correct package, we should no always
 insert it. There's a reason why these fixes have not been integrated
 into the kernel, and so we should also let the user decide here.

The reason is bug-for-bug backwards compatibilty: old (originall latex09-)
documents should convert without change. I.e. even without improvement
if this carries the possibility of larger changes (e.g. different
page-breaks):

  LaTeX policy is that things should not change, between releases, in a
  way that will cause incompatibility with old documents, or will cause
  typesetting of an unchanged document to change.

I agree that we should provide for customization.

If LyX policy is to follow LaTeX policy regarding stability, it's a bit
more complicated:

a) New documents should use fixltx2e by default.

b) Old documents should not change:

   Use fixltx2e, if \usepackage{fixltx2e} is found in the user-preamble,
   else don't use it.

c) Converting new documents to older LyXformats should place
   \usepackage{fixltx2e} in the user preable if use_fixltx2e is true.

Disabling use fixltx2e would also disable the subscript inset
(with a hint: requires fixltx2e ...) or we must ressort to including
the literal definition from fixltx2e in this case.

Günter

Re: Crash in multine AMS context with CAS [#7058] PSTricks instant preview

[Julien Rioux]

On 22/11/2010 4:40 AM, veno...@arcadiaclub.com wrote:

Moreover I've a question about instant preview and PSTricks, see the attachment, it doesn't show up 
the graph. I didn't make a bug report because maybe it's just due to some misconfiguration or 
conflict specific to my system. You need pst-tricks and pst-plot. I just see the pre 
and post text but no graph!


pstricks require postscript output:
related to http://www.lyx.org/trac/ticket/7042

--
Julien

Re: [patch] fix bug 3008

[Georg Baum]

Uwe Stöhr wrote:

   What is the problem with using that package?
 
 That it is not included in MiKTeX, also not via the fragments or fixltx2e
 package. Therefore all LyX on Windows would be forced to install the file
 manually which is not acceptable.

That would be a bug in MikTeX. subscript.sty is meant to be used by other 
packages - How could that be done if it is not avilable?

 I provide LyX for Windows as one-click instalation. So you start the
 installer and at the end of the installation process, you have a
 full-equipped LyX, LaTeX environment and all necessary third-party
 programs. All LaTeX-packages needed by LyX are automatically installed
 when LyX is started the first time. This mechanism only works for packages
 available in MiKTeX. I can ask the MiKTeX maintainer to include subfigure
 but I can understand if he denies this.

Please do that.

 With your current implementation I'm forced to ship the subfigure.sty with
 the installer and install it using installer code. This is a lot of extra
 work and becomes complicated for fresh installation (where MiKTeX is
 installed together with LyX). That's why I shout.

LyX installs other files that should be visible by TeX (e.g. lyxchess.sty). 
Is adding one additional file really more effort than putting it into the 
installer archive and adding one line in the install script?

 In principle yes. As these lines are also used by other packages like
 KOMA-script and have not been touched at CTAN for 11 years we can assume
 them being stable to insert them directly via LyX.

I would really prefer a packaging fix, because the bug is a packaging bug 
(of MiKTeX), but if you insist I can implement a fallback (using the package 
if available, else provide the command). What do others think?


Georg

Re: [patch] fix bug 3008

[Georg Baum]

Guenter Milde wrote:

 Please use the fixltx2e package for \textsubscript:

I did not do that on purpose. It has side effects, and the usage of a 
subscript should not cgange anything else. It is bad enough that the usage 
of some math symbols of the wasy package has the side effect that e.g. 
integral signs may change.

 I argue, that LyX-2 should by default *always* insert
 \usepackage{fixltx2e}. This package collects a range of fixes and
 improvements that are not not in the LaTeX core due to backwards
 compatibility issues. The quantum-leap from 1 to 2 would be a good
 place for this change:

I agree too that this package should be used, but that should be independent 
of subscripts, and it should be possible to switch it off. Furthermore I 
don't think that this should be done now (in order to get 2.0 out soon). The 
scripts problem did annoy many people, but you are the first one to mention 
fixltx2e.


Georg

Re: old (mhchem-)package issue in lyx2.0

[Georg Baum]

Sebastian Guttenberg wrote:

 Great! That indeed fixes the problem for me! Thanks a lot!
 Probably one should do the same for all packages whose support was added
 at a later stage and for all future new supports: Set their default
 off for all older lyx-documents...

Yes. AFAIK this is the case for the other settings. The patch is now in.

 For me personally it's now fine. But I think that it's quite a serious
 issue because of the possible data loss. And I could imagine that the
 same things happen for old documents that redefined in a similar manner
 ams-functions (imagine somebody having defined \tfrac to be some macro
 without argument instead of a macro with two arguments as it is
 supported).

amsmath has been there forever, so this is not a problem of old .lyx 
documents, but of importing .tex.

 What I still don't understand: even if the support is wrongly loaded, it
 should not change the content of the document, but only the way it's
 being displayed and then being reversible by onloading the
 package-support, shouldn't it? Is there no way to make such data-losses
 impossible, even if some package is loaded by mistake?

Not in math. The reason is that there is no true ERT in math: The parser 
parses everything and translates it into the different math insets, and for 
many commands the number and kind of arguments is hardcoded (for others it 
is defined in $LYX_DIR/lib/symbols). The parser is simply not designed in 
such a way that one could use arbitrary commands. Therefore, the data loss 
happens at loading time. While I agree that it would be nice to allow 
arbitray commands in math that are not interpreted at all, it would be a 
huge effort to accomplish that, because this would be a redesign of the 
current parser (and there are not too many people who understand it). 
Surprisingly this problem arises not very often in real world examples, and 
therefore I doubt that anything will happen in the near future.


Georg

Re: old (mhchem-)package issue in lyx2.0

[Georg Baum]

Sebastian Guttenberg wrote:

 Not being a programmer, I should not be demanding, but I personally
 think that a proper fix would include the following:
 * For any imported file lyx should neither load nor support any package
 that has not been loaded in the original file
 * deselecting packages should result in removing the lyx-internal
 support for the corresponding commands
 * ideally, if for some reason still a package support is wrongly loaded,
 this should at most lead to a chaos in the lyx-internal way of
 presenting the result and in LaTex errors due to double-definitions, but
 never to real data-loss. So having such a mess, it should always be
 possible to manually deselect the packages and get back something
 reasonable.
 I don't know how much effort each of these items would require, but
 without this I would imagine that in future always some related problems
 will reappear and require a case-by-case fix.

I agree basically, but see my other mail for an explanation why this is not 
easy to fix. If not already done, please file a bug report in trac with your 
example and the expected behaviour, so that at least it is accessible if 
someone should decide to work on that problem.


Georg

Re: r36430 - lyx-devel/trunk/src

[Stephan Witt]

Am 22.11.2010 um 09:58 schrieb Abdelrazak Younes:

 On 11/22/2010 09:57 AM, you...@lyx.org wrote:
 Author: younes
 Date: Mon Nov 22 09:57:33 2010
 New Revision: 36430
 URL: http://www.lyx.org/trac/changeset/36430
 
 Log:
 Work around bug #6920. This disables ligatures with involving 'f'
 character.
   
 
 Bennett, Stefan, please check that.

Regardless of my already mentioned concerns...
I tried it and it works for infinite but not for fix.

Stephan

Re: Subscription needed?

[Tommaso Cucinotta]

Il 22/11/2010 19:27, Vincent van Ravesteijn ha scritto:


If you mean the list that notifies me of each and every commit in 
LyX, I probably don't actually need to be there :-).


Yes, you do. If you're not on that list, we are not notified either.
hmmm, and excellent opportunity to commit whatever without the tough 
reviews to the patches by Vincent ... let me think about it!

.
.
.
.
.
ok, just joking :-): I just subscribed.

T.

Re: [patch] fix bug 3008

[Richard Heck]

On 11/22/2010 03:58 PM, Georg Baum wrote:

Uwe Stöhr wrote:


What is the problem with using that package?

That it is not included in MiKTeX, also not via the fragments or fixltx2e
package. Therefore all LyX on Windows would be forced to install the file
manually which is not acceptable.

That would be a bug in MikTeX. subscript.sty is meant to be used by other
packages - How could that be done if it is not avilable?.
I would really prefer a packaging fix, because the bug is a packaging bug
(of MiKTeX), but if you insist I can implement a fallback (using the package
if available, else provide the command). What do others think?

I'm inclined to agree with you. I do not see why we need to work around 
this kind of bug at the LyX level.


Richard

Re: [patch] fix bug 3008

[Richard Heck]

Guenter Milde wrote:


I argue, that LyX-2 should by default *always* insert
\usepackage{fixltx2e}. This package collects a range of fixes and
improvements that are not not in the LaTeX core due to backwards
compatibility issues. The quantum-leap from 1 to 2 would be a good
place for this change:

I agree too that this package should be used, but that should be independent
of subscripts, and it should be possible to switch it off. Furthermore I
don't think that this should be done now (in order to get 2.0 out soon). The
scripts problem did annoy many people, but you are the first one to mention
fixltx2e.

It's come up in other contexts. I can't remember which right now. But of 
course you are right, and this can

easily be put on the radar for 2.1.

Richard

Re: old (mhchem-)package issue in lyx2.0

[Sebastian Guttenberg]

Hi Georg
Thanks a lot for your answers. I see the point. 
I'm sorry, but in the meantime I was already impatient and sent another
message (with subject: examples of failing tex-import) to the mailing
list with an extended tex-file with a few more examples (I don't know
why it hasn't yet appeared on the list). After having read your answers,
I think you can disregard the new post anyway. I will file a bug-report,
as you suggested.
One last comment: I have observed that the bug for the tex-import
(without child document) does not appear, if the newcommand is used
after \begin{document}, because then it is imported as a math-macro and
is afterwards respected by lyx.
Thanks again for your patch. Regards, Sebastian

Re: The painting bug with ligatures reproduced on linux too

[Abdelrazak Younes]

On 11/22/2010 01:50 AM, Pavel Sanda wrote:

hi,

by accident i successfully reproduced quite horrible problem of unsynced visual
cursor position and the actual position of typing, so this is no more MacOS
thing only. the key point was to switch to dejavu fonts in linux.

http://www.lyx.org/trac/ticket/6920
   


Try this:


Index: src/rowpainter.cpp
===
--- src/rowpainter.cpp(revision 36426)
+++ src/rowpainter.cpp(working copy)
@@ -265,6 +265,9 @@
 break;
 }

+if (c == 'i' && prev_char == 'f')
+break;
+
 if (!isPrintableNonspace(c))
 break;

Re: r36430 - lyx-devel/trunk/src

[Abdelrazak Younes]

On 11/22/2010 09:57 AM, you...@lyx.org wrote:

Author: younes
Date: Mon Nov 22 09:57:33 2010
New Revision: 36430
URL: http://www.lyx.org/trac/changeset/36430

Log:
Work around bug #6920. This disables ligatures with involving 'f'
character.
   


Bennett, Stefan, please check that.

Abdel.

Re: The painting bug with ligatures reproduced on linux too

[Abdelrazak Younes]

On 11/22/2010 08:58 AM, Abdelrazak Younes wrote:

On 11/22/2010 01:50 AM, Pavel Sanda wrote:

hi,

by accident i successfully reproduced quite horrible problem of 
unsynced visual
cursor position and the actual position of typing, so this is no more 
MacOS

thing only. the key point was to switch to dejavu fonts in linux.

http://www.lyx.org/trac/ticket/6920


Try this:


Index: src/rowpainter.cpp
===
--- src/rowpainter.cpp(revision 36426)
+++ src/rowpainter.cpp(working copy)
@@ -265,6 +265,9 @@
 break;
 }

+if (c == 'i' && prev_char == 'f')
+break;
+
 if (!isPrintableNonspace(c))
 break;


I committed a more general patch. I reckon this is safe and will have 
almost no impact on performance.


Please test.

Abdel.

Re: lettre.layout bug

[Jean-Pierre Chrétien]

Jürgen Spitzmüller a écrit :

Jean-Pierre Chrétien wrote:

Attached.


Thanks. Committed to branch and trunk.


I have a warning with "View DVI":

xdvi-xaw: Warning: Invalid papersize special `0.0pt,0.0pt'

Harmless because the DVI file is displayed all right and is
in A4 format.

This comes from this command added by LyX to the preamble:
\special{papersize=\the\paperwidth,\the\paperheight}

As lettre.cls does not define \paperwidth and \paperheight, the command
\special{papersize=0.0pt,0.0pt} is handed over to xdvi.

Both the original format issue with pdflatex and this one come from the fact 
that the lettre class ignore the a4paper option, so \(pdf)paperwidth and 
\(pdf)paperheight are undefined.


Hacking the preamble with \input{pdftexconfig.tex} is avoided if I simply remove 
the a4paper class option in the template, as the attached patch does.


On the other side, the fact that \[pdf]paperwidth and \[pdf]paperheight can be 
undefined by certain classes will create the same format issues than with 
lettre.cls. If classes are not required to define these, the commands added by 
LyX in the preamble do not seem to be activated correctly.


What do you think ?
--
Jean-Pierre
--- lib/layouts/lettre.layout.orig	2010-11-22 09:10:41.0 +0100
+++ lib/layouts/lettre.layout	2010-11-22 09:14:12.0 +0100
@@ -22,7 +22,9 @@
 #  - margins set to dynamic to ensure alignment of line headings
 #  - categories
 #  - ordering control left at the beginning (any other way ?)
-
+# rev.4; J.-P. Chretien nov 2010
+#  - remove \input{pdftexconfig.tex} workaround
+#(not needed if a4paper class option is not used)
 
 Format 11
 
@@ -126,11 +128,6 @@
 \fi		% if needSendFax
   }	%findemessage
 
-% to get the specified pagesize 
-% (workaround for an a4paper/lettre problem in pdf mode)
-...@ifpackageloaded{ifpdf}{}{\usepackage{ifpdf}}
-\ifpdf\input pdftexconfig.tex\fi
-
 EndPreamble
 
 # My Address style used to specify sender name and coordinates
--- lib/templates/lettre.lyx.orig	2010-11-22 09:11:08.0 +0100
+++ lib/templates/lettre.lyx	2010-11-22 09:49:20.0 +0100
@@ -1,4 +1,4 @@
-#LyX 1.6.8svn created this file. For more info see http://www.lyx.org/
+#LyX 1.6.9svn created this file. For more info see http://www.lyx.org/
 \lyxformat 345
 \begin_document
 \begin_header
@@ -19,7 +19,7 @@
 \paperfontsize 11
 \spacing single
 \use_hyperref false
-\papersize a4paper
+\papersize default
 \use_geometry false
 \use_amsmath 1
 \use_esint 1
@@ -37,6 +37,7 @@
 \tracking_changes false
 \output_changes false
 \author "" 
+\author "" 
 \end_header
 
 \begin_body
@@ -55,6 +56,17 @@
 L'ordre des éléments est indifférent.
 \end_layout
 
+\begin_layout Plain Layout
+La classe lettre ne connaît pas l'option a4paper, ne pas sélectionner 
+\family sans
+Document\SpecialChar \menuseparator
+Paramètres\SpecialChar \ldots{}
+\SpecialChar \menuseparator
+Format de la page\SpecialChar \menuseparator
+Format\SpecialChar \menuseparator
+A4
+\end_layout
+
 \end_inset
 
 

Re: lyx2.0 modifies read-only files!

[Sebastian Guttenberg]

> This was changed to solve bug http://www.lyx.org/trac/ticket/6587.
> 
> Now we move the file to the backup file before saving the current file. 
> So, we basically do not overwrite the original file, but we move away 
> the original read-only file and write a new file.

I have read the discussion around the old bug, so I can understand that
you don't want to change back. But what about comparing the flags of the
original file and the new file for every time you save it (and not only
when you open it) ?
- Sebastian

Crash in multine AMS context with CAS [#7058] & PSTricks instant preview

[venom00]

I've made a bug report about a crash when invoking a CAS in multine AMS 
context. The LyX stdout doesn't tell anything useful.

Moreover I've a question about instant preview and PSTricks, see the 
attachment, it doesn't show up the graph. I didn't make a bug report because 
maybe it's just due to some misconfiguration or conflict specific to my system. 
You need pst-tricks and pst-plot. I just see the "pre" and "post" text but no 
graph!

I'm under Windows 7, using MiKTeX 2.8, using LyX 2.0beta1.

Thanks in advance,
Ale


pst-tricks_instant-preview.lyx
Description: application/lyx

Re: r36430 - lyx-devel/trunk/src

[Pavel Sanda]

Abdelrazak Younes wrote:
> On 11/22/2010 09:57 AM, you...@lyx.org wrote:
>> Author: younes
>> Date: Mon Nov 22 09:57:33 2010
>> New Revision: 36430
>> URL: http://www.lyx.org/trac/changeset/36430
>>
>> Log:
>> Work around bug #6920. This disables ligatures with involving 'f'
>> character.
>>
>
> Bennett, Stefan, please check that.

its fixed here now. Juergen this problem is also in branch.

pavel

Re: [patch] polyglossia

[Pavel Sanda]

Jürgen Spitzmüller wrote:
> Jürgen Spitzmüller wrote:
> > The attached patch adds support for polyglossia with XeTeX.
> > 
> > As estimated, the patch is rather big, and it needs good testing. I have 
> > tested with multiple languages (including Arabic, Hebrew, and Greek), but
> > of  course, there could be many things I have overlooked.
> 
> Attached a slightly polished patch (I factored out all the "arabic" -> 
> "Arabic"  transformations).
> 
> Pavel, shall I put this in?

yes. please can you write some concise statement what has been changed wrt 
xetex?
i would like to put it into beta2 announce (or feel free to add it there 
directly).

pavel

Re: r36430 - lyx-devel/trunk/src

[Enrico Forestieri]

On Mon, Nov 22, 2010 at 12:33:17PM +0100, Pavel Sanda wrote:

> Abdelrazak Younes wrote:
> > On 11/22/2010 09:57 AM, you...@lyx.org wrote:
> >> Author: younes
> >> Date: Mon Nov 22 09:57:33 2010
> >> New Revision: 36430
> >> URL: http://www.lyx.org/trac/changeset/36430
> >>
> >> Log:
> >> Work around bug #6920. This disables ligatures with involving 'f'
> >> character.
> >>
> >
> > Bennett, Stefan, please check that.
> 
> its fixed here now. Juergen this problem is also in branch.

I cannot reproduce this bug with any font (including DejaVu) on Linux,
Windows and Solaris, with or without this patch. I verified that the
ligatures are present at U+FB00-U+FB04, so it cannot be due to their
presence or absence (tested with Qt 4.6.3 and 4.7.0).
So, what triggers it?

-- 
Enrico

Re: r36430 - lyx-devel/trunk/src

[Pavel Sanda]

Enrico Forestieri wrote:
> > its fixed here now. Juergen this problem is also in branch.
> 
> I cannot reproduce this bug with any font (including DejaVu) on Linux,
> Windows and Solaris, with or without this patch. I verified that the
> ligatures are present at U+FB00-U+FB04, so it cannot be due to their
> presence or absence (tested with Qt 4.6.3 and 4.7.0).
> So, what triggers it?

only two things come to my mind -  some magical switch in Qt compilation
or fontconfig settings...

we can try to make small poll around which people are able to reproduce,
so we get idea what can be the common denominator.

pavel

Re: [patch] polyglossia

[Jürgen Spitzmüller]

Pavel Sanda wrote:
> yes. please can you write some concise statement what has been changed wrt
> xetex? i would like to put it into beta2 announce (or feel free to add it
> there directly).

The statement would be something like:

"Support for polyglossia, XeTeX's new language interface and babel 
replacement, has been added. If polyglossia is installed and if the used 
languages are supported by polyglossia, LyX will now automatically use this 
package instead of babel with XeTeX output."

Jürgen

Re: [patch] fix bug 3008

[Guenter Milde]

On 2010-11-19, Georg Baum wrote:

> Hi,

> after I needed to explain several times lately why one should not use the 
> menu entries for sub/superscript in text and what to do instead, I finally 
> sat down and completed a fix for bug 3008 that I started years ago. It 
> implements a new inset for subscript and superscript in text mode, including 
> correct output for all backends. There are some other ideas discussed in 
> http://www.lyx.org/trac/ticket/3008, but the inset approach is the best one 
> IMO.

...  
  
> +# these classes provide a \textsubscript command:
> +# FIXME: Would be nice if we could use the information of the .layout 
> file here
> +classes = ["memoir", "scrartcl", "scrbook", "scrlttr2", "scrreprt"]
> +if foundsubscript and find_token_exact(classes, document.textclass, 0) 
> == -1:
> +add_to_preamble(document, ['\\usepackage{subscript}'])

Please use the fixltx2e package for \textsubscript:

  Provides a command \textsubscript , which is a modified version the
  command \textsuperscript that's part of LaTeX.  The command is also
  (now) provided by the fixltx2e package distributed with LaTeX itself;
  if you are running a LaTeX distribution no earlier than 2005/12/01, you
  will have a more satisfactory means of using the command.

  -- http://tug.ctan.org/cgi-bin/ctanPackageInformation.py?id=subscript

I argue, that LyX-2 should by default *always* insert
\usepackage{fixltx2e}. This package collects a range of fixes and
improvements that are not not in the LaTeX core due to backwards
compatibility issues. The "quantum-leap" from 1 to 2 would be a good
place for this change:

  Identifierfixltx2e
  
  Caption   Patches for LaTeX.
  
  Description   
  
LaTeX policy is that things should not change, between releases, in a
way that will cause incompatibility with old documents, or will cause
typesetting of an unchanged document to change.
  
Nevertheless, there are problems in LaTeX that it “would be nice” to
correct; fixltx2e provides a home for these corrections.  Corrections
in the current version are:
  
  * ensure one-column floats don't get ahead of two-column floats;
  
  * correct page headers in twocolumn documents;
  
  * stop spaces disappearing in moving arguments;
  
  * allowing  \fnysmbol  to use text symbols;
  
  * allow the first word after a float to hyphenate;
  
  * \emph  can produce caps/small caps text;
  
  * bugs in  \setlength  and flushbottom.
  
-- http://tug.ctan.org/pkg/fixltx2e

Günter

Re: [patch] fix bug 3008

[Jürgen Spitzmüller]

Guenter Milde wrote:
> I argue, that LyX-2 should by default always insert
> \usepackage{fixltx2e}. This package collects a range of fixes and
> improvements that are not not in the LaTeX core due to backwards
> compatibility issues. The "quantum-leap" from 1 to 2 would be a good
> place for this change:

While I agree that fixltx2e is the correct package, we should no always insert 
it. There's a reason why these fixes have not been integrated into the kernel, 
and so we should also let the user decide here.

Jürgen

Re: [patch] fix bug 3008

[Guenter Milde]

On 2010-11-22, Uwe Stöhr wrote:
> > On 21/11/2010 5:20 PM, Uwe Stöhr wrote:
> >>
> >>That it is not included in MiKTeX, also not via the fragments or
> >>fixltx2e package. Therefore all LyX on Windows would be forced to
> >>install the file manually which is not acceptable.
> >
> > How about using
> >
> > \usepackage{fixltx2e}
> >
> > for providing \textsubscript? This one is shipped with miktex.

> As I said (you even cited this) fixltx2e is not available for MiKTeX,
> at last not under MiKTeX 2.9.

This would be very strange: 

   The package is distributed as part of LaTeX; the extracted package is
   also available on the archive (location linked here). 

   -- http://www.ctan.org/tex-archive/help/Catalogue/entries/fixltx2e.html
   
I suppose it is not mentioned as extra download/extension because it
is already part of every latex base install.

Günter   

Re: old (mhchem-)package issue in lyx2.0

[Sebastian Guttenberg]

Hi all
I have now produced an example tex-file that my problem is of a more
general nature and can appear also with other packages than mhchem. I
have constructed an example of a conflict with the automatic package
support in the case of \tfrac of the ams-package. 
The following is a bug for the Latex-import and has data-loss (well, at
least if one re-exports and overwrites the original tex-file):

1. first compile the attached tex-file to see how the outcome should
look like
2. then import this tex-file into lyx.20. You will immediately see that
things get a bit messed up, because ams-math is loaded by default. Still
we can try to compile and get of course an LaTeX error-message, that
\tfrac has already been defined.
3. Go to Documents->Settings->Math Options
and deselect "Use AMS package automatically"
4. Although this prevents Lyx from actually loading the latex-package
amsmath, it does not remove the lyx-internal support for ams-related
macros (like tfrac). So at least within lyx, equations look still
spoiled.
4. compiling now works but leads to a quite different output then the
original tex-file! Better than in lyx itself, but still spoiled. In
particular, the whole content of the last line is missing!!

For most appearances of \tfrac, "only" place-holders are "eaten", so
that for the dvi-file only the formatting of the equation gets spoiled.
But when one uses \tfrac inside a bracket then whole lines get lost. 
Actually I was a bit surprised by the result myself, because I was
expecting to produce this bug only when I define the macro in a
child-document. Apparently the problem is not related to child
documents, but probably in general for imports (you'll know better). So
I guess that someone who has defined his own \tfrac in an old
lyx-version where this ams-math-command was not yet supported, should
run into the same problems, when importing. There are thousands of other
examples one could think of. 

Not being a programmer, I should not be demanding, but I personally
think that a proper fix would include the following:
* For any imported file lyx should neither load nor support any package
that has not been loaded in the original file
* deselecting packages should result in removing the lyx-internal
support for the corresponding commands
* ideally, if for some reason still a package support is wrongly loaded,
this should at most lead to a chaos in the lyx-internal way of
presenting the result and in LaTex errors due to double-definitions, but
never to real data-loss. So having such a mess, it should always be
possible to manually deselect the packages and get back something
reasonable. 
I don't know how much effort each of these items would require, but
without this I would imagine that in future always some related problems
will reappear and require a case-by-case fix. 
- Sebastian
Here's the tex-file:

\documentclass{article}  %% testTexImport.tex

\newcommand{\tfrac}{\frac{t_1}{t_2}}

\begin{document}
\begin{eqnarray}
t_1 & = & ac,\quad t_2=ad \\
2+\tfrac & = & 2+\frac{ac}{ad}\\
 & = & \frac{c}{d}+2\\
 & = & \left(\tfrac \right)+2\quad\rm{this\;line\;will\;be\;missing!!}
\end{eqnarray}
\end{document}

Re: r36430 - lyx-devel/trunk/src

[Abdelrazak Younes]

On 11/22/2010 12:57 PM, Pavel Sanda wrote:

Enrico Forestieri wrote:
   

its fixed here now. Juergen this problem is also in branch.
   

I cannot reproduce this bug with any font (including DejaVu) on Linux,
Windows and Solaris, with or without this patch. I verified that the
ligatures are present at U+FB00-U+FB04, so it cannot be due to their
presence or absence (tested with Qt 4.6.3 and 4.7.0).
So, what triggers it?
 

only two things come to my mind -  some magical switch in Qt compilation
or fontconfig settings...
   


I've searched a bit and no, there's nothing like that, AFAICS.


we can try to make small poll around which people are able to reproduce,
so we get idea what can be the common denominator.
   


It essentially depends on the font. Not all fonts implement automatic 
ligature and within one font, some builds do others don't.


But as I said in trac, this is not a bug of Qt or freetype or the font. 
The issue is just that we use own own text engine and we compute metrics 
character by character in order to have correct cursor positioning. As 
we paint word by word the cursor is not painted at the correct position.


Abdel.

Re: lettre.layout bug

[Jürgen Spitzmüller]

Jean-Pierre Chrétien wrote:
> I have a warning with "View DVI":
> 
> xdvi-xaw: Warning: Invalid papersize special `0.0pt,0.0pt'
> 
> Harmless because the DVI file is displayed all right and is
> in A4 format.
> 
> This comes from this command added by LyX to the preamble:
> \special{papersize=\the\paperwidth,\the\paperheight}
> 
> As lettre.cls does not define \paperwidth and \paperheight, the command
> \special{papersize=0.0pt,0.0pt} is handed over to xdvi.
> 
> Both the original format issue with pdflatex and this one come from the
> fact  that the lettre class ignore the a4paper option, so \(pdf)paperwidth
> and \(pdf)paperheight are undefined.
> 
> Hacking the preamble with \input{pdftexconfig.tex} is avoided if I simply
> remove  the a4paper class option in the template, as the attached patch
> does.
> 
> On the other side, the fact that \[pdf]paperwidth and \[pdf]paperheight can
> be  undefined by certain classes will create the same format issues than
> with lettre.cls. If classes are not required to define these, the commands
> added by LyX in the preamble do not seem to be activated correctly.
> 
> What do you think ?

I'm fine with that, but this all strikes me like the bugs in the class itself. 
Did you consider to inform the class author?

Jürgen

Subscription needed?

[Pavel Sanda]

hi Tommaso,

i dont see your commits like r36411 in our cvs list. is tomm...@lyx subscribed
there? iirc this was needed so distribution works properly. can you have a look?

pavel

Re: LyX without menu in Ubuntu Netbook 10.10

[Manveru]

2010/11/19 Waluyo Adi Siswanto :
>> It works by using this command  (from the terminal)
>>
>> QT_X11_NO_NATIVE_MENUBAR=1 lyx
>>
>
> Perhaps, for those using Ubuntu Netbook and have the same problem;
>
> a) Create a file lyx_command.sh
>    #!/bin/sh
>     QT_X11_NO_NATIVE_MENUBAR=1 lyx
> b) Change permission to "Allow executing file as program"
> c) Replace the previous lyx command (lyx %f) by browsing to lyx_command.sh
>
> Now clicking LyX menu under applications -> office, can see LyX with
> normal menus.

Proper script is that:
#!/usr/bin/env sh
QT_X11_NO_NATIVE_MENUBAR=1 lyx "$@"

Such version allows passing of invocation arguments.
-- 
Manveru
jabber: manv...@manveru.pl
     gg: 1624001
   http://www.manveru.pl

internationalized messages should not contain the `\r' escape sequence

[Kornel]

(trunk)
This is what I get since today, with all po-files.

The appropriate messages in the po-files are:

msgid "Itemize\r"
msgid "Description\r"
msgid "Labeling\r"
msgid "List\r"
msgid "00.00.\r"
msgid "Enumerate-Resume\r"

It is warning only, but does not look correct.

Kornel


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

Re: internationalized messages should not contain the `\r' escape sequence

[Pavel Sanda]

Kornel wrote:
> (trunk)
> This is what I get since today, with all po-files.
> 
> The appropriate messages in the po-files are:
> 
> msgid "Itemize\r"
> msgid "Description\r"
> msgid "Labeling\r"
> msgid "List\r"
> msgid "00.00.\r"
> msgid "Enumerate-Resume\r"
> 
> It is warning only, but does not look correct.

i see, enumitem module is saved as cr file...
pavel

Re: [patch] fix bug 3008

[Jean-Marc Lasgouttes]

Le 21/11/2010 18:05, Georg Baum a écrit :

Yeah. I run into this a lot these days. But then I think: Do I really want
to write a layout parser for lyx2lyx?


These were exactly my thoughts. Nevertheless, it would be nice to have one
:-)


Could our in-LyX textclass parser be augmented to dump textclasses as 
python structs, so that lyx2lyx can read them effortlessly?


We could run this "dump-textclasses" lfun from time to time to make sure 
that lyx2lyx has up-to-date information.


JMarc

Re: internationalized messages should not contain the `\r' escape sequence

[Vincent van Ravesteijn]

> i see, enumitem module is saved as cr file...
> pavel

Fixed in http://www.lyx.org/trac/changeset/36435.

;).

I accidentally set the  svn property "eol-style" instead of
"svn:eol-style". Being on windows, the crlf line endings got committed
which I just wanted to prevent by setting the svn:eol-style property
in the first place.

Vincent

Re: internationalized messages should not contain the `\r' escape sequence

[Pavel Sanda]

Vincent van Ravesteijn wrote:
> > i see, enumitem module is saved as cr file...
> > pavel
> 
> Fixed in http://www.lyx.org/trac/changeset/36435.
> 
> ;).

Sendinglayouts/enumitem.module
Transmitting file data .svn: Commit failed (details follow):
svn: File '/lyx-devel/trunk/lib/layouts/enumitem.module' is out of date
svn: Your commit message was left in a temporary file:
svn:'/home/paf/lyx/tree/trunk/lib/svn-commit.tmp'

:)
p

Re: r36430 - lyx-devel/trunk/src

[BH]

On Mon, Nov 22, 2010 at 3:58 AM, Abdelrazak Younes  wrote:
> On 11/22/2010 09:57 AM, you...@lyx.org wrote:
>>
>> Author: younes
>> Date: Mon Nov 22 09:57:33 2010
>> New Revision: 36430
>> URL: http://www.lyx.org/trac/changeset/36430
>>
>> Log:
>> Work around bug #6920. This disables ligatures with involving 'f'
>> character.
>>
>
> Bennett, Stefan, please check that.

It works as advertised with ligatures. But a related problem I had
reported long ago is with swooshes with italics fonts, such as Hoefler
Text Italics. I'm attaching a screenshot.

BH
<>

Re: [patch] fix bug 3008

[Richard Heck]

On 11/22/2010 08:41 AM, Jean-Marc Lasgouttes wrote:

Le 21/11/2010 18:05, Georg Baum a écrit :
Yeah. I run into this a lot these days. But then I think: Do I 
really want

to write a layout parser for lyx2lyx?


These were exactly my thoughts. Nevertheless, it would be nice to 
have one

:-)


Could our in-LyX textclass parser be augmented to dump textclasses as 
python structs, so that lyx2lyx can read them effortlessly?


We could run this "dump-textclasses" lfun from time to time to make 
sure that lyx2lyx has up-to-date information.



That's one idea, sure. Let me think about it.

Richard

[patch] LuaTeX

[Jürgen Spitzmüller]

Out of curiosity, I checked out what it would need us to implement basic 
support for Lua(La)TeX (basic in the sense of what we had for XeTeX prior to 
the polyglossia commit today*). And it's really as simple as the attached.

What I would do additionally to the patch are just two cosmetic things:

(1) rename the buffer param useXeTeX to useLuaXeTeX (or something else, if 
someone comes up with a better name), since that param just tells us that we 
use a modern utf8- and OpenType-aware processor (such as XeTeX and LuaTeX), 
contrary to the flavour that tells us which processor this is.
This one would be a file format change, although a very simple one.

(2) In the GUI, I would rename the "Use XeTeX" checkbox to "Use System Fonts" 
(since this is really what is of interest for the end user) and put the 
checkbox to fonts.

I hesitated to send this now, since I agree we should not add any more new 
features, and of course I respect if this is gonna be postponed. OTOH, people 
are just starting to use LuaTeX now for serious work, and I expect it to 
become more mature within the next months. So I just wanted to let you know 
how cheap this inclusion would be ;-)

Jürgen

* there is nothing like polyglossia for LuaTeX yet, and alas, LuaTeX faces the 
same problems with babel than XeTeX. That is: it works for many languages, but 
has problems with some (Greek, Arabic for instance).
Index: src/insets/InsetExternal.cpp
===
--- src/insets/InsetExternal.cpp	(Revision 36432)
+++ src/insets/InsetExternal.cpp	(Arbeitskopie)
@@ -725,6 +725,7 @@
 	case OutputParams::LATEX:
 		format = "LaTeX";
 		break;
+	case OutputParams::LUATEX:
 	case OutputParams::PDFLATEX:
 	case OutputParams::XETEX:
 		format = "PDFLaTeX";
Index: src/insets/InsetGraphics.cpp
===
--- src/insets/InsetGraphics.cpp	(Revision 36432)
+++ src/insets/InsetGraphics.cpp	(Arbeitskopie)
@@ -102,9 +102,10 @@
 /// Note that \p format may be unknown (i. e. an empty string)
 string findTargetFormat(string const & format, OutputParams const & runparams)
 {
-	// Are we using latex or XeTeX/pdflatex?
+	// Are we using latex or XeTeX/LuaTeX/pdflatex?
 	if (runparams.flavor == OutputParams::PDFLATEX
-	|| runparams.flavor == OutputParams::XETEX) {
+	|| runparams.flavor == OutputParams::XETEX
+	|| runparams.flavor == OutputParams::LUATEX) {
 		LYXERR(Debug::GRAPHICS, "findTargetFormat: PDF mode");
 		Format const * const f = formats.getFormat(format);
 		// Convert vector graphics to pdf
Index: src/insets/InsetListings.cpp
===
--- src/insets/InsetListings.cpp	(Revision 36432)
+++ src/insets/InsetListings.cpp	(Arbeitskopie)
@@ -144,10 +144,11 @@
 	Encoding const * const save_enc = runparams.encoding;
 
 	if (runparams.flavor != OutputParams::XETEX
+	&& runparams.flavor != OutputParams::LUATEX
 	&& !runparams.encoding->hasFixedWidth()) {
 		// We need to switch to a singlebyte encoding, since the
 		// listings package cannot deal with multi-byte-encoded
-		// glyphs (not needed with XeTeX).
+		// glyphs (not needed with XeTeX or LuaTeX).
 		Language const * const outer_language =
 			(runparams.local_font != 0) ?
 runparams.local_font->language()
Index: src/Converter.cpp
===
--- src/Converter.cpp	(Revision 36432)
+++ src/Converter.cpp	(Arbeitskopie)
@@ -257,6 +257,8 @@
 		if (conv.latex)
 			if (contains(conv.from, "xetex"))
 return OutputParams::XETEX;
+			if (contains(conv.from, "luatex"))
+return OutputParams::LUATEX;
 			if (contains(conv.to, "pdf"))
 return OutputParams::PDFLATEX;
 		if (conv.xml)
@@ -747,6 +749,7 @@
 	v.push_back("docbook");
 	v.push_back("latex");
 	v.push_back("literate");
+	v.push_back("luatex");
 	v.push_back("lyx");
 	v.push_back("xhtml");
 	v.push_back("pdflatex");
Index: src/OutputParams.h
===
--- src/OutputParams.h	(Revision 36433)
+++ src/OutputParams.h	(Arbeitskopie)
@@ -29,6 +29,7 @@
 public:
 	enum FLAVOR {
 		LATEX,
+		LUATEX,
 		PDFLATEX,
 		XETEX,
 		XML,
Index: src/output_latex.cpp
===
--- src/output_latex.cpp	(Revision 36433)
+++ src/output_latex.cpp	(Arbeitskopie)
@@ -865,7 +865,7 @@
 	// If this is the last paragraph, and a local_font was set upon entering
 	// the inset, and we're using "auto" or "default" encoding, the encoding
 	// should be set back to that local_font's encoding.
-	// However, do not change the encoding when XeTeX is used.
+	// However, do not change the encoding when XeTeX or LuaTeX are used.
 	if (nextpit == paragraphs.end() && runparams_in.local_font != 0
 	&& runparams_in.encoding != runparams_in.local_font->language()->encoding()
 	&& (bparams.inputenc == "auto" || 

Re: [patch] LuaTeX

[Pavel Sanda]

Jürgen Spitzmüller wrote:
> features, and of course I respect if this is gonna be postponed. OTOH, people 
> are just starting to use LuaTeX now for serious work, and I expect it to 
> become more mature within the next months. So I just wanted to let you know 

i have rather general questions:
* are there security considerations (havent worked with it, but
  its possible to write ERT for "rm -rf/" in lua)?

* why do we want it at all - or in more general, what are we aiming to support?
  all pdftex, xetex, luatex?
  each new engine will have its own quirks i guess. its not clear to me whether
  its fashion for next five years or its mature and is going to survive -- or be
  replaced by some new xeluatex creature?
  (honest question, i dont follow development steps of these. short googling
  returns bunch of time-dependent infos...).

pavel

Re: LyX without menu in Ubuntu Netbook 10.10

[Waluyo Adi Siswanto]

> Proper script is that:
>    #!/usr/bin/env sh
>    QT_X11_NO_NATIVE_MENUBAR=1 lyx "$@"
>
> Such version allows passing of invocation arguments.

Oh.. yes, that's correct. Running LyX from the menu using the previous
script, creates another problem. Double clicking lyx document will not
be successful.

I have corrected the script in my netbook, thank you.

Regards
waluyo

Re: [patch] LuaTeX

[Jürgen Spitzmüller]

Pavel Sanda wrote:
> i have rather general questions:
> * are there security considerations (havent worked with it, but
>   its possible to write ERT for "rm -rf/" in lua)?

I don't think so. The LuaTeX developers are rather security-aware guys (after 
all, these are the pdflatex/context people, a bunch of real good programmers).

> * why do we want it at all - or in more general, what are we aiming to
> support? all pdftex, xetex, luatex?

Yes.

>   each new engine will have its own quirks i guess. its not clear to me
> whether its fashion for next five years or its mature and is going to
> survive -- or be replaced by some new xeluatex creature?
>   (honest question, i dont follow development steps of these. short
> googling returns bunch of time-dependent infos...).

Well, nobody knows for sure, of course. From what I know, LuaTeX is planned to 
replace PDFTeX in the long term (it's already the default engine in ConTeXt, I 
think). The pdftex maintainers only fix bugs in pdftex itself, all new 
features go into LuaTeX. Having said that, pdftex is very stable and reliable, 
and for people who do not need all the nifty new features, there's no need to 
depart from pdftex, neither to XeTeX nor to LuaTeX. 

XeTeX is completely orthogonal to LuaTeX, although there are shared aims. I 
guess both the LuaTeX and XeTeX maintainers respect the respective other 
project (Han The Than, the original pdftex author, even contributed to XeteX 
recently). From a user POV, both provide OpenType and true Unicode support, 
but they also have their respective strengthes and weaknesses:

* XeTeX is rather monolithic, while LuateX is modular
* XeTeX only produces PDF, LuaTex can also output DVI
* LuaTeX has better micro-typographic features (font expansion)
* XeTeX has (still) better language support (via polyglossia)
* XeTeX is basically a one-man project, LuaTeX is team-driven

I guess it is fair to support either of these backend. 

Jürgen

Re: Subscription needed?

[Tommaso Cucinotta]

Il 22/11/2010 14:02, Pavel Sanda ha scritto:

hi Tommaso,

i dont see your commits like r36411 in our cvs list. is tomm...@lyx subscribed
there? iirc this was needed so distribution works properly. can you have a look?

Hi,

I confess I have no clue of what you're talking about. Please, explain 
as if I were 3 years old, thanks.
If you mean the list that notifies me of each and every commit in LyX, I 
probably don't actually need to be there :-).


T.

Re: r36430 - lyx-devel/trunk/src

[Stephan Witt]

Am 22.11.2010 um 12:50 schrieb Enrico Forestieri:

> On Mon, Nov 22, 2010 at 12:33:17PM +0100, Pavel Sanda wrote:
> 
>> Abdelrazak Younes wrote:
>>> On 11/22/2010 09:57 AM, you...@lyx.org wrote:
 Author: younes
 Date: Mon Nov 22 09:57:33 2010
 New Revision: 36430
 URL: http://www.lyx.org/trac/changeset/36430
 
 Log:
 Work around bug #6920. This disables ligatures with involving 'f'
 character.
 
>>> 
>>> Bennett, Stefan, please check that.
>> 
>> its fixed here now. Juergen this problem is also in branch.
> 
> I cannot reproduce this bug with any font (including DejaVu) on Linux,
> Windows and Solaris, with or without this patch. I verified that the
> ligatures are present at U+FB00-U+FB04, so it cannot be due to their
> presence or absence (tested with Qt 4.6.3 and 4.7.0).
> So, what triggers it?

I don't know if you already have an answer.
I think the surprising fact is - it has nothing to do with unicode ligatures.

The problem is the "too clever" font rendering of Qt. Similar to the TeX engine.
E. g. you typeset the word "infinite". The "fi" ligature is rendered 
automatically
if the font has the appropriate capabilities.
Currently this happens only for rare circumstances.

Abdel's solution is like a hard coded ligature-break.
When "fi" is found LyX will render "f" and "i" instead.

Abdel, I'm sorry to say that, but I don't think it's sufficient.
This "fi" ligature is only one example. There are others, for sure.
And Bennett presented another incarnation of this bug in his mail today.
Please, correct me if I'm wrong...

I understand, it's very hard to solve correctly. 
I guess, the text metrics machinery of LyX is not ready to handle that.

Qt proposes the use of QTextLayout.

In QFontMetrics::width() one can read:

\warning This function will produce incorrect results for Arabic
characters or non-spacing marks in the middle of a string, as the
glyph shaping and positioning of marks that happens when
processing strings cannot be taken into account. When implementing
an interactive text control, use QTextLayout instead.

Stephan

Re: [patch] LuaTeX

[Richard Heck]

On 11/22/2010 10:55 AM, Jürgen Spitzmüller wrote:

Out of curiosity, I checked out what it would need us to implement basic
support for Lua(La)TeX (basic in the sense of what we had for XeTeX prior to
the polyglossia commit today*). And it's really as simple as the attached.

What I would do additionally to the patch are just two cosmetic things:

(1) rename the buffer param useXeTeX to useLuaXeTeX (or something else, if
someone comes up with a better name), since that param just tells us that we
use a modern utf8- and OpenType-aware processor (such as XeTeX and LuaTeX),
contrary to the flavour that tells us which processor this is.
This one would be a file format change, although a very simple one.


useUnicodeTeX? useUTF8TeX?



(2) In the GUI, I would rename the "Use XeTeX" checkbox to "Use System Fonts"
(since this is really what is of interest for the end user) and put the
checkbox to fonts.

This one I'm less sure about. I cant tell from the patch how we decide 
which one to use. Wasn't it determined

before by the "Use XeTeX" box? Anyway, clearly I'm confused.


I hesitated to send this now, since I agree we should not add any more new
features, and of course I respect if this is gonna be postponed. OTOH, people
are just starting to use LuaTeX now for serious work, and I expect it to
become more mature within the next months. So I just wanted to let you know
how cheap this inclusion would be ;-)


Cheap indeed.

On a somewhat unrelated note:


Index: src/Converter.cpp
===
--- src/Converter.cpp   (Revision 36432)
+++ src/Converter.cpp   (Arbeitskopie)
@@ -257,6 +257,8 @@
if (conv.latex)
if (contains(conv.from, "xetex"))
return OutputParams::XETEX;
+   if (contains(conv.from, "luatex"))
+   return OutputParams::LUATEX;
if (contains(conv.to, "pdf"))
return OutputParams::PDFLATEX;
if (conv.xml)

These tests look wrong. At the very least, shouldn't these check 
"startswith". What if someone defines a format nopdf?


Richard

Re: Subscription needed?

[Vincent van Ravesteijn]

If you mean the list that notifies me of each and every commit in LyX, 
I probably don't actually need to be there :-).


Yes, you do. If you're not on that list, we are not notified either.

Vincent

Re: [patch] LuaTeX

[Guenter Milde]

On 2010-11-22, Jürgen Spitzmüller wrote:
> Pavel Sanda wrote:

>> * why do we want it at all - or in more general, what are we aiming to
>> support? all pdftex, xetex, luatex?

> Yes.

Seconded.

...

> pdftex is very stable and reliable, and for people who do not need all
> the nifty new features, there's no need to depart from pdftex, neither
> to XeTeX nor to LuaTeX. 

and while more and more packages are made "unicode ready", pdftex is
the save bet.

> XeTeX is completely orthogonal to LuaTeX, although there are shared aims.
...
> From a user POV, both provide OpenType and true Unicode support, 
> but they also have their respective strengthes and weaknesses:
...
> I guess it is fair to support either of these backend. 

Especially as there is active work to have a common "LaTeX interface",
e.g. hyperref, fontspec and unicode-math are all updated to work with
both engines (hyperref also with pdftex), polyglossia will follow.

Günter

Re: [patch] LuaTeX

[Guenter Milde]

On 2010-11-22, Richard Heck wrote:
> On 11/22/2010 10:55 AM, Jürgen Spitzmüller wrote:
>> Out of curiosity, I checked out what it would need us to implement basic
>> support for Lua(La)TeX (basic in the sense of what we had for XeTeX prior to
>> the polyglossia commit today*). And it's really as simple as the attached.

>> What I would do additionally to the patch are just two cosmetic things:

>> (1) rename the buffer param useXeTeX to useLuaXeTeX (or something else, if
>> someone comes up with a better name), since that param just tells us that we
>> use a modern utf8- and OpenType-aware processor (such as XeTeX and LuaTeX),
>> contrary to the flavour that tells us which processor this is.
>> This one would be a file format change, although a very simple one.

> useUnicodeTeX? useUTF8TeX?

useUniTex?

>> (2) In the GUI, I would rename the "Use XeTeX" checkbox to "Use System
>> Fonts" (since this is really what is of interest for the end user) and
>> put the checkbox to fonts.

Rather not:

* The reason to use XeTeX/LuaTeX can also be a craving for better Unicode
  support (e.g. Latin words in a Greek document without the need to set
  the language, support for more Unicode characters like e.g. Block
  Elements).

* XeTeX can also use OpenType fonts that are not system-wide installed as
  well as "traditional" LaTeX fonts.

> This one I'm less sure about. I cant tell from the patch how we decide 
> which one to use. Wasn't it determined
> before by the "Use XeTeX" box? Anyway, clearly I'm confused.

There should be no need to have separate XeTeX and LuaTeX settings.

IMV, it is also wrong to define the used engine as a special document
setting: Just like we allow export of the same document to XHTML, PS, and
PDF without change in the document settings, we should allow

* PDF (ps2pdf)
* PDF (pslatex)
* PDF (xetex)
* PDF (luatex)

as export options.

This would also mean that there should be the possibility to configure
font sets for pdftex, xetex/luates, and html in parallel in one document.

I suppose it is too late to change this for 2.0, though.

Currently, you would need to set the "LaTeX" -> "PDF (UniTeX)" converter
to either xetex or luatex.

Günter

Re: [patch] fix bug 3008

[Guenter Milde]

On 2010-11-22, Jürgen Spitzmüller wrote:
> Guenter Milde wrote:
>> I argue, that LyX-2 should by default always insert
>> \usepackage{fixltx2e}. This package collects a range of fixes and
>> improvements that are not not in the LaTeX core due to backwards
>> compatibility issues. The "quantum-leap" from 1 to 2 would be a good
>> place for this change:

> While I agree that fixltx2e is the correct package, we should no always
> insert it. There's a reason why these fixes have not been integrated
> into the kernel, and so we should also let the user decide here.

The reason is bug-for-bug backwards compatibilty: old (originall latex09-)
documents should convert without change. I.e. even without improvement
if this carries the possibility of larger changes (e.g. different
page-breaks):

  LaTeX policy is that things should not change, between releases, in a
  way that will cause incompatibility with old documents, or will cause
  typesetting of an unchanged document to change.

I agree that we should provide for customization.

If LyX policy is to follow LaTeX policy regarding stability, it's a bit
more complicated:

a) New documents should use fixltx2e by default.

b) Old documents should not change:

   Use fixltx2e, if "\usepackage{fixltx2e}" is found in the user-preamble,
   else don't use it.

c) Converting new documents to older LyXformats should place
   \usepackage{fixltx2e} in the user preable if "use_fixltx2e" is true.

Disabling "use fixltx2e" would also disable the "subscript" inset
(with a hint: requires fixltx2e ...) or we must ressort to including
the literal definition from fixltx2e in this case.

Günter

Re: Crash in multine AMS context with CAS [#7058] & PSTricks instant preview

[Julien Rioux]

On 22/11/2010 4:40 AM, veno...@arcadiaclub.com wrote:

Moreover I've a question about instant preview and PSTricks, see the attachment, it doesn't show up 
the graph. I didn't make a bug report because maybe it's just due to some misconfiguration or 
conflict specific to my system. You need pst-tricks and pst-plot. I just see the "pre" 
and "post" text but no graph!


pstricks require postscript output:
related to http://www.lyx.org/trac/ticket/7042

--
Julien

Re: [patch] fix bug 3008

[Georg Baum]

Uwe Stöhr wrote:

>  > What is the problem with using that package?
> 
> That it is not included in MiKTeX, also not via the fragments or fixltx2e
> package. Therefore all LyX on Windows would be forced to install the file
> manually which is not acceptable.

That would be a bug in MikTeX. subscript.sty is meant to be used by other 
packages - How could that be done if it is not avilable?

> I provide LyX for Windows as one-click instalation. So you start the
> installer and at the end of the installation process, you have a
> full-equipped LyX, LaTeX environment and all necessary third-party
> programs. All LaTeX-packages needed by LyX are automatically installed
> when LyX is started the first time. This mechanism only works for packages
> available in MiKTeX. I can ask the MiKTeX maintainer to include subfigure
> but I can understand if he denies this.

Please do that.

> With your current implementation I'm forced to ship the subfigure.sty with
> the installer and install it using installer code. This is a lot of extra
> work and becomes complicated for fresh installation (where MiKTeX is
> installed together with LyX). That's why I shout.

LyX installs other files that should be visible by TeX (e.g. lyxchess.sty). 
Is adding one additional file really more effort than putting it into the 
installer archive and adding one line in the install script?

> In principle yes. As these lines are also used by other packages like
> KOMA-script and have not been touched at CTAN for 11 years we can assume
> them being stable to insert them directly via LyX.

I would really prefer a packaging fix, because the bug is a packaging bug 
(of MiKTeX), but if you insist I can implement a fallback (using the package 
if available, else provide the command). What do others think?


Georg

Re: [patch] fix bug 3008

[Georg Baum]

Guenter Milde wrote:

> Please use the fixltx2e package for \textsubscript:

I did not do that on purpose. It has side effects, and the usage of a 
subscript should not cgange anything else. It is bad enough that the usage 
of some math symbols of the wasy package has the side effect that e.g. 
integral signs may change.

> I argue, that LyX-2 should by default *always* insert
> \usepackage{fixltx2e}. This package collects a range of fixes and
> improvements that are not not in the LaTeX core due to backwards
> compatibility issues. The "quantum-leap" from 1 to 2 would be a good
> place for this change:

I agree too that this package should be used, but that should be independent 
of subscripts, and it should be possible to switch it off. Furthermore I 
don't think that this should be done now (in order to get 2.0 out soon). The 
scripts problem did annoy many people, but you are the first one to mention 
fixltx2e.


Georg

Re: old (mhchem-)package issue in lyx2.0

[Georg Baum]

Sebastian Guttenberg wrote:

> Great! That indeed fixes the problem for me! Thanks a lot!
> Probably one should do the same for all packages whose support was added
> at a later stage and for all future new supports: Set their default
> "off" for all older lyx-documents...

Yes. AFAIK this is the case for the other settings. The patch is now in.

> For me personally it's now fine. But I think that it's quite a serious
> issue because of the possible data loss. And I could imagine that the
> same things happen for old documents that redefined in a similar manner
> ams-functions (imagine somebody having defined "\tfrac" to be some macro
> without argument instead of a macro with two arguments as it is
> supported).

amsmath has been there forever, so this is not a problem of old .lyx 
documents, but of importing .tex.

> What I still don't understand: even if the support is wrongly loaded, it
> should not change the content of the document, but only the way it's
> being displayed and then being reversible by onloading the
> package-support, shouldn't it? Is there no way to make such data-losses
> impossible, even if some package is loaded by mistake?

Not in math. The reason is that there is no "true" ERT in math: The parser 
parses everything and translates it into the different math insets, and for 
many commands the number and kind of arguments is hardcoded (for others it 
is defined in $LYX_DIR/lib/symbols). The parser is simply not designed in 
such a way that one could use arbitrary commands. Therefore, the data loss 
happens at loading time. While I agree that it would be nice to allow 
arbitray commands in math that are not interpreted at all, it would be a 
huge effort to accomplish that, because this would be a redesign of the 
current parser (and there are not too many people who understand it). 
Surprisingly this problem arises not very often in real world examples, and 
therefore I doubt that anything will happen in the near future.


Georg

Re: old (mhchem-)package issue in lyx2.0

[Georg Baum]

Sebastian Guttenberg wrote:

> Not being a programmer, I should not be demanding, but I personally
> think that a proper fix would include the following:
> * For any imported file lyx should neither load nor support any package
> that has not been loaded in the original file
> * deselecting packages should result in removing the lyx-internal
> support for the corresponding commands
> * ideally, if for some reason still a package support is wrongly loaded,
> this should at most lead to a chaos in the lyx-internal way of
> presenting the result and in LaTex errors due to double-definitions, but
> never to real data-loss. So having such a mess, it should always be
> possible to manually deselect the packages and get back something
> reasonable.
> I don't know how much effort each of these items would require, but
> without this I would imagine that in future always some related problems
> will reappear and require a case-by-case fix.

I agree basically, but see my other mail for an explanation why this is not 
easy to fix. If not already done, please file a bug report in trac with your 
example and the expected behaviour, so that at least it is accessible if 
someone should decide to work on that problem.


Georg

Re: r36430 - lyx-devel/trunk/src

[Stephan Witt]

Am 22.11.2010 um 09:58 schrieb Abdelrazak Younes:

> On 11/22/2010 09:57 AM, you...@lyx.org wrote:
>> Author: younes
>> Date: Mon Nov 22 09:57:33 2010
>> New Revision: 36430
>> URL: http://www.lyx.org/trac/changeset/36430
>> 
>> Log:
>> Work around bug #6920. This disables ligatures with involving 'f'
>> character.
>>   
> 
> Bennett, Stefan, please check that.

Regardless of my already mentioned concerns...
I tried it and it works for "infinite" but not for "fix".

Stephan

Re: Subscription needed?

[Tommaso Cucinotta]

Il 22/11/2010 19:27, Vincent van Ravesteijn ha scritto:


If you mean the list that notifies me of each and every commit in 
LyX, I probably don't actually need to be there :-).


Yes, you do. If you're not on that list, we are not notified either.
hmmm, and excellent opportunity to commit whatever without the tough 
reviews to the patches by Vincent ... let me think about it!

.
.
.
.
.
ok, just joking :-): I just subscribed.

T.

Re: [patch] fix bug 3008

[Richard Heck]

On 11/22/2010 03:58 PM, Georg Baum wrote:

Uwe Stöhr wrote:


  >  What is the problem with using that package?

That it is not included in MiKTeX, also not via the fragments or fixltx2e
package. Therefore all LyX on Windows would be forced to install the file
manually which is not acceptable.

That would be a bug in MikTeX. subscript.sty is meant to be used by other
packages - How could that be done if it is not avilable?.
I would really prefer a packaging fix, because the bug is a packaging bug
(of MiKTeX), but if you insist I can implement a fallback (using the package
if available, else provide the command). What do others think?

I'm inclined to agree with you. I do not see why we need to work around 
this kind of bug at the LyX level.


Richard

Re: [patch] fix bug 3008

[Richard Heck]

Guenter Milde wrote:


I argue, that LyX-2 should by default *always* insert
\usepackage{fixltx2e}. This package collects a range of fixes and
improvements that are not not in the LaTeX core due to backwards
compatibility issues. The "quantum-leap" from 1 to 2 would be a good
place for this change:

I agree too that this package should be used, but that should be independent
of subscripts, and it should be possible to switch it off. Furthermore I
don't think that this should be done now (in order to get 2.0 out soon). The
scripts problem did annoy many people, but you are the first one to mention
fixltx2e.

It's come up in other contexts. I can't remember which right now. But of 
course you are right, and this can

easily be put on the radar for 2.1.

Richard

Re: old (mhchem-)package issue in lyx2.0

[Sebastian Guttenberg]

Hi Georg
Thanks a lot for your answers. I see the point. 
I'm sorry, but in the meantime I was already impatient and sent another
message (with subject: "examples of failing tex-import") to the mailing
list with an extended tex-file with a few more examples (I don't know
why it hasn't yet appeared on the list). After having read your answers,
I think you can disregard the new post anyway. I will file a bug-report,
as you suggested.
One last comment: I have observed that the bug for the tex-import
(without child document) does not appear, if the newcommand is used
after \begin{document}, because then it is imported as a math-macro and
is afterwards respected by lyx.
Thanks again for your patch. Regards, Sebastian