Re: [Cvslog] r18919 - in /lyx-devel/trunk/development/Win32/packaging/...
Uwe Stöhr wrote: Bo Peng schrieb: What is the reason to keep a special stdtoolbars.inc? I think we agreed on not deviating from a standard LyX distribution. I asked about this special topic several times: The Update PDF button doesn't work on Windows due to our view PDF scripts that are needed because popular viewers like Adobe Reader preserves write permissions on PDF's that are shown. I also proposed a solution but this requires too much work and is only something for Lyx 1.6.0. The update button works in the official installer (view creates a new window, update reloads all windows). If you use the same PDF viewing method, there will be no problems. Joost
Re: [patch] doc/TOC.lyx: \usepackage[utf-8]{inputenc} causes 'utf-8.def not found'
Uwe Stöhr wrote: > OK to apply the patch? OK. Jürgen
1.5.0beta2: export Latex(plain), why must overwrite my EPS graphics files?
Hi, I'm using 1.5.0beta2. For all my graphics files I use eps format, which works OK within LyX. However, when I export my document with "Export -> LaTeX(plain)", a dialog pops up with annoying choices: The file ~/my/doc/dir/figure.eps already exists. Do you want to over-write that file? [Over-write] [Overwrite-all] [Cancel export] So I have to overwrite my own eps file, or cancel the export. Why isn't there the option [Do not overwrite] instead of [Cancel export] ? I would prefer to keep my original eps files (although you might say, the overwrite is the exactly the same file, I don't feel comfortable when clicking on 'overwrite', scared to lose my figure file.). So scared by the 'overwrite' option, I had to cancel the export. It wouldn't be too much of a problem to let the export go along with the already existing eps file, would it? If so, this option should then be added here Rob. - Expecting? Get great news right away with email Auto-Check. Try the Yahoo! Mail Beta.
Re: [patch] doc/TOC.lyx: \usepackage[utf-8]{inputenc} causes 'utf-8.def not found'
OK to apply the patch? +1 Bo
Re: 1.4.4 -> 1.5.0beta2: citation problem in PS and DVI output.
Rob wrote: Hi, The upgrade from Fedora 6 to 7 confronted me with an automagically upgrade of LyX from 1.4.4 to 1.5.0beta2. So, after the Fedora upgrade, I started LyX (looks good!) and opened my 1.4.4 document. It looks alright, but the citations in the postscript and dvi output look awkward. A citation that should become like "[1]" (without the quotes), now looks like "(author?)[1]", where "(author?)" is in bold. Any idea why this is going wrong? Is it possible that this is fixed in the beta3 release? Or is there a simple conversion possible? (This is a large document, so I hope there is an easy conversion!!!). Solved it. In "Document->Settings...", I use Document Class article (REVTeX 4) and Bibliography Natbib Author-year I had to change 'Author-year' to 'Numerical', and then all is OK again. Somehow, the 'author-year' got automagically set when loading the 1.4.4 document into 1.5.0 lyx. At least, I never had problems with this lyx document before, when using 1.4.4 lyx. Anyway, it turns out that the 'author-year' setting requires an additional field in the bibtex file, which I obviously don't provide, since I don't want to use this type of citation. I wonder whether a lot more people will run into this, when loading their 1.4.4 documents, once 1.5.0 lyx is officially released.. --- And yes indeed; Fedora 7 ships with lyx-1.5.0-0.5.beta2.fc7. Now, I hope they are also quick in providing the official release, once you guys push the 1.5.0 release out :). Cheers, Rob. - Shape Yahoo! in your own image. Join our Network Research Panel today!
An Icon...
I've just installed Lyx1.5rc2... So far its great, but something has been bothering me since about beta2: the icon for demoting a heading in the outline panel says '2.1' instead of '1.1'. I know it is a small thing, but I look at it all the time and notice it :) I just thought I would mention it in case no one had noticed. -alex
Re: chinese po file of lyx
SET LANG=zh_TW: brings me Chinese menus but a lot of warnings about wrong or doubles menu shortcut Because there is no ascii character in the Chinese translated menus. SET LANG=zh_CN: brings me English menus, why? Because it is not translated yet. :-) Bo
Re: [Cvslog] r18919 - in /lyx-devel/trunk/development/Win32/packaging/...
Bo Peng schrieb: What is the reason to keep a special stdtoolbars.inc? I think we agreed on not deviating from a standard LyX distribution. I asked about this special topic several times: The Update PDF button doesn't work on Windows due to our view PDF scripts that are needed because popular viewers like Adobe Reader preserves write permissions on PDF's that are shown. I also proposed a solution but this requires too much work and is only something for Lyx 1.6.0. For one test release I used the Update PDF button anyway and got lots of complaints, so I took it out again. I informed the list about this and then Richard tried to find a quick solution with me. As consequience we gave up and I think this one button as only difference doesn't harm. (Pressing the view PDF button on Windows acts as View button or as Update button, depending if the file is already viewed or not.) And I had hoped that Uwe release this installer in a *standard* way, i.e., ask JMarc to put the files on ftp.lyx.org, without a special announcement. Sorry. I was in a hurry today and wanted to take it from my todo list. JMarc, could you please upload the installers from http://developer.berlios.de/project/showfiles.php?group_id=5117&release_id=13014 to ftp.lyx.org thanks in advance and regards Uwe
Re: [PATCH] bug 3947 (was: bug RC2)
> the attached patch fixes the bug. Yes fixed, I tested it. But could you add yourself to the authors list of InsetBibtex.cpp as you did a lot there to improve LyX's BibTeX support. The fix seems straight forward and fixes a regression. José can this go in? regards Uwe
Re: chinese po file of lyx
> Can I rename zh.po to zh_CN.po and add zh_TW.po from Mr. Chao? zh_CN > and zh_TW are two dialects of Chinese. When I try to use Chinese as menu language I get the following: SET LANG=zh_TW: brings me Chinese menus but a lot of warnings about wrong or doubles menu shortcut SET LANG=zh_CN: brings me English menus, why? (I aded the two new .po files to scons_manifest.py now but couldn't fine the corresponding entry in the makefiles.) regards Uwe
Re: Arabic Wiki Page
> Done. The truth is, I think the instructions there should mostly be relevant
to Windows, as well.
No, they are only incomletey for arabtex.
I merged your description a bit now: http://wiki.lyx.org/Windows/Arabic
Concerning the page: I would not mention the bind file because this is unnecessary. New users will
be scared about every preferences fiddling. We don't use special bind files for the other languages,
and when the user is experianced enough, he can create any time later its own bind file.
If you find this really important, set it at the end on the wiki page under the heading
"Tips".
> As far as I can tell, Arabi support in LyX does not fully work yet.
For me it works much better than than arabtex.
> You can do most of the work in LyX, and export the file to latex, but then
there is some editing
> that needs to be done to the generated latex file in order for it to be legal
latex:
>
>* latex preamble: instead of "\documentclass[arabic,english]{article}",
should be just
> "documentclass{article}"
This is correct. You only get Arabic AND english when you have both languages
in your document.
>* latex preamble: instead of "\usepackage{babel}", should be
> "\usepackage[arabic,english]{babel}"
This is already the case. We load the babel languages in the class options.
>* latex preamble: according to the documentation,
"\usepackage[T1]{fontenc}" should be
> something like "\usepackage[LAE,T1]{fontenc}", but I don't see that this has
any effect either
> way.
But you already get
\usepackage[T1,LFE,LAE]{fontenc}
when using arabic_arabi.
> * In Tools -> Preferences... -> Look and feel -> Keyboard, make sure that "Use
keyboard map" is
> checked, and then type in @@null@@ as "first", and @@arabic@@ as "second".
Why not using Arabic directly as the first keyboard map?
regards Uwe
[patch] doc/TOC.lyx: \usepackage[utf-8]{inputenc} causes 'utf-8.def not found'
> I can not compile doc/TOC.lyx. I guess this is caused by line
> \usepackage[utf-8]{inputenc}.
Because the correct line would be
\usepackage[utf8]{inputenc}
The attached trivial patch fixes this and sets the Python file encoding to utf-8 as we once agred
that all our scripts for LyX 1.5 should be unicode encoded. All are now, only not doc-toc.py and the
brand new "ext_copy.py" from two weeks ago.
OK to apply the patch?
regards Uwe
Index: doc/doc_toc.py
===
--- doc/doc_toc.py (revision 18933)
+++ doc/doc_toc.py (working copy)
@@ -1,7 +1,7 @@
#! /usr/bin/env python
-# -*- coding: iso-8859-1 -*-
+# -*- coding: utf-8 -*-
# This file is part of the LyX Documentation
-# Copyright (C) 2004 José Matos <[EMAIL PROTECTED]>
+# Copyright (C) 2004 José Matos <[EMAIL PROTECTED]>
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License
@@ -113,7 +113,7 @@
lang = dir
file = LyX.NewFile(output = output)
data = info[lang]
-file.set_header(language = data[0], language_quotes = data[1], inputencoding = "utf-8")
+file.set_header(language = data[0], language_quotes = data[1], inputencoding = "utf8")
file.language = data[0]
file.encoding = "utf-8"
body = [ LyX.Paragraph('Title', [data[3]])]
Index: scripts/ext_copy.py
===
--- scripts/ext_copy.py (revision 18933)
+++ scripts/ext_copy.py (working copy)
@@ -1,5 +1,5 @@
#! /usr/bin/env python
-# -*- coding: iso-8859-1 -*-
+# -*- coding: utf-8 -*-
# file ext_copy.py
# This file is part of LyX, the document processor.
Re: [patch] Re: RTL justification bug
José Matos wrote: On Thursday 28 June 2007 21:00:28 Dov Feldstern wrote: I haven't gotten any further comments regarding this patch. Is it OK to go in? Are you sure it is safe? Could have the opinion of other RTL users? Would anyone like the patch attached at http://permalink.gmane.org/gmane.editors.lyx.devel/88617? It fixes http://bugzilla.lyx.org/show_bug.cgi?id=3889 (and some other problems, actually, see the related thread for details). It would be good if non-RTL users test this as well, just to make sure it doesn't break anything... But it's working for me, I think it's safe... Thanks! Dov
Re: RC2: can not convert user's guide to 1.4.x
This is bug 3313, that seems not to be fully fixed yet: http://bugzilla.lyx.org/show_bug.cgi?id=3313#c23
[PATCH] bug 3947 (was: bug RC2)
Hello,
the attached patch fixes the bug. The problem was that bibtex allows parentheses in the key (even if
the whole entry is delimeted by parentheses!)
Bernhard
W. Bentley MacLeod schrieb:
I have installed RC2, and there is a bug that was in RC1 that I did not
mention since I thought it would be fixed. My bibtex cites are all of
the form
Author1-Author2(1980):JPE
where JPE refers to a journal.
When I insert a cite using lyx it puts in "Author1-Author2(1980" rather
than "Author1-Author2(1980):JPE".
For the moment I just enter cites as latex commands.
The program is great - one all the bugs are worked out it will be a
killer app. best bm
Index: src/insets/InsetBibtex.cpp
===
--- src/insets/InsetBibtex.cpp (revision 18935)
+++ src/insets/InsetBibtex.cpp (working copy)
@@ -393,7 +393,8 @@
/// @return true if a string of length > 0 could be read.
///
bool readTypeOrKey(docstring & val, idocfstream & ifs,
- docstring const & delimChars, charCase chCase) {
+ docstring const & delimChars, docstring const &illegalChars,
+ charCase chCase) {
char_type ch;
@@ -411,7 +412,11 @@
return false;
// read value
- while (ifs && !isSpace(ch) && delimChars.find(ch) ==
docstring::npos) {
+ bool legalChar;
+ while (ifs && !isSpace(ch) &&
+ delimChars.find(ch) == docstring::npos &&
+ (legalChar = illegalChars.find(ch) ==
docstring::npos)
+ ) {
if (chCase == makeLowerCase) {
val += lowercase(ch);
} else {
@@ -419,6 +424,11 @@
}
ifs.get(ch);
}
+
+ if (!legalChar) {
+ ifs.putback(ch);
+ return false;
+ }
// skip whitespace
while (ifs && isSpace(ch)) {
@@ -596,7 +606,8 @@
docstring entryType;
- if (!readTypeOrKey(entryType, ifs, from_ascii("{("),
makeLowerCase) || !ifs)
+ if (!readTypeOrKey(entryType, ifs, from_ascii("{("),
+ docstring(), makeLowerCase) || !ifs)
continue;
if (entryType == from_ascii("comment")) {
@@ -623,9 +634,11 @@
docstring name;
docstring value;
- if (!readTypeOrKey(name, ifs,
from_ascii("#=}),"), makeLowerCase) || !ifs)
+ if (!readTypeOrKey(name, ifs, from_ascii("="),
+ from_ascii("#{}(),"),
makeLowerCase) || !ifs)
continue;
+ // next char must be an equal sign
ifs.get(ch);
if (!ifs || ch != '=')
continue;
@@ -653,7 +666,8 @@
docstring value;
docstring commaNewline;
- if (!readTypeOrKey(key, ifs, from_ascii(",})"),
keepCase) || !ifs)
+ if (!readTypeOrKey(key, ifs, from_ascii(","),
+ from_ascii("}"), keepCase)
|| !ifs)
continue;
// now we have a key, so we will add an entry
@@ -667,7 +681,8 @@
while (ifs && readNext) {
// read field name
- if (!readTypeOrKey(name, ifs,
from_ascii("=}),"), makeLowerCase) || !ifs)
+ if (!readTypeOrKey(name, ifs,
from_ascii("="),
+ from_ascii("{}(),"),
makeLowerCase) || !ifs)
break;
// next char must be an equal sign
Re: [patch] Re: RTL justification bug
On Thursday 28 June 2007 21:00:28 Dov Feldstern wrote: > I haven't gotten any further comments regarding this patch. Is it OK to > go in? Are you sure it is safe? Could have the opinion of other RTL users? -- José Abílio
Re: doc/TOC.lyx: \usepackage[utf-8]{inputenc} causes 'utf-8.def not found'
On Thursday 28 June 2007 22:57:47 Bo Peng wrote:
> I can not compile doc/TOC.lyx. I guess this is caused by line
> \usepackage[utf-8]{inputenc}.
>
> Bo
What latex version?
--
José Abílio
Re: 1.4.4 -> 1.5.0beta2: citation problem in PS and DVI output.
On Thursday 28 June 2007 21:36:26 Jean-Marc Lasgouttes wrote: > Is fedora 7 really shipping lyx 1.5.0beta2? That's stupid! > > JMarc It will be solved as soon as we release 1.5.0. It was the update version at the time fedora was released and Rex asked us before if we would expect for the stable version to be released in April (first estimate of F7 release). -- José Abílio
Re: Arabic Wiki Page
Uwe Stöhr wrote: I think you should add the Linux installation instructions to the existing wiki page behind the Windows install section. The actual page contains the both OSes and can be referenced everywhere. Done. The truth is, I think the instructions there should mostly be relevant to Windows, as well. The first stage of the initial setup should really be done by us now, the user shouldn't have to deal with that. (But we're discussing that in a separate thread ;) ). regards Uwe
Re: bug RC2
W. Bentley MacLeod schrieb: I have installed RC2, and there is a bug that was in RC1 that I did not mention since I thought it would be fixed. My bibtex cites are all of the form Author1-Author2(1980):JPE where JPE refers to a journal. When I insert a cite using lyx it puts in "Author1-Author2(1980" rather than "Author1-Author2(1980):JPE". For the moment I just enter cites as latex commands. The program is great - one all the bugs are worked out it will be a killer app. best bm a patch is on the way...
doc/TOC.lyx: \usepackage[utf-8]{inputenc} causes 'utf-8.def not found'
I can not compile doc/TOC.lyx. I guess this is caused by line
\usepackage[utf-8]{inputenc}.
Bo
Re: RC2: can not convert user's guide to 1.4.x
Also EmbeddedObjects.lyx. Bo
RC2: can not convert user's guide to 1.4.x
As title. Bo
Re: [Cvslog] r18919 - in /lyx-devel/trunk/development/Win32/packaging/...
What is the reason to keep a special stdtoolbars.inc? I think we agreed on not deviating from a standard LyX distribution. And I had hoped that Uwe release this installer in a *standard* way, i.e., ask JMarc to put the files on ftp.lyx.org, without a special announcement. Anyway, to merge two installers in an organized way, I would request that users of the alternative installer register bug reports and feature requests to bugzilla. If there is no complaint against the official installer, I do not know why I should work on it. As a matter of fact, it works perfectly for me. Cheers, Bo
Re: [Cvslog] r18919 - in /lyx-devel/trunk/development/Win32/packaging/...
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes: Bo> Anyway, to merge two installers in an organized way, I would Bo> request that users of the alternative installer register bug Bo> reports and feature requests to bugzilla. If there is no complaint Bo> against the official installer, I do not know why I should work on Bo> it. As a matter of fact, it works perfectly for me. BTW, on Jooost request, I have put a rc2 installer on ftp.devel.lyx.org. JMarc
Re: LyX 1.5.0 (release candidate 1) crashes when beamer-template is scrolled down
[EMAIL PROTECTED] schrieb: When I open the "beamer-conference-ornate-20min.lyx" template in the "\lyx15\resources\templates" directory and scroll down the document, lyx crashes every time! I installed the LyX-1.5.0rc1-Installer-bundle.exe for Windows. Please check 1.5.0rc2. I cannot reproduce the bug with this new version. Michael
Re: [Cvslog] r18919 - in /lyx-devel/trunk/development/Win32/packaging/...
[EMAIL PROTECTED] schrieb: Author: uwestoehr Date: Thu Jun 28 00:29:46 2007 New Revision: 18919 URL: http://www.lyx.org/trac/changeset/18919 Log: installer updates Modified: lyx-devel/trunk/development/Win32/packaging/AltInstaller/ChangeLog.txt lyx-devel/trunk/development/Win32/packaging/AltInstaller/Deleted.nsh lyx-devel/trunk/development/Win32/packaging/AltInstaller/Settings.nsh lyx-devel/trunk/development/Win32/packaging/AltInstaller/Updated.nsh lyx-devel/trunk/development/Win32/packaging/AltInstaller/specials/stdtoolbars.inc What is the reason to keep a special stdtoolbars.inc? I think we agreed on not deviating from a standard LyX distribution. Michael
Re: 1.4.4 -> 1.5.0beta2: citation problem in PS and DVI output.
> "José" == José Matos <[EMAIL PROTECTED]> writes: José> Could you run as root: José> yum --enablerepo=updates-testing update lyx José> This will give you rc1. Let us know if the problem is still José> there. Is fedora 7 really shipping lyx 1.5.0beta2? That's stupid! JMarc
cusorsX speedup? (was: Re: [patch] Re: RTL justification bug)
Dov Feldstern wrote: Attached find a patch for this bug. OK? Twice almost the same code sequence. Any chance of factoring this out? I know... But if you'll take a look at the two functions (paintText and cursorX), the loop at the heart of them is very similar, and a lot of the same things are happening in both functions, except they're written in different forms. But it is actually very very similar. I think that to correctly factor this out would mean rewriting the loop for both these functions, which is not something for now... I've been thinking about this some more, and I think I have a direction for solving this: During painting, we should cache the cursorX positions. Then we won't have to repeat the same code again inside cursorX, that will solve the repeated code issue. It will also provide some speedup to the cursorX function, which currently goes through all of the characters on the line in order to calculate the position, on every single cursor blink! This would require some minor changes to the painting code --- for example, the painting code may not currently calculate X positions for every character, because we try to paint whole words at a time. But this should be easy to solve. And it would still be less expensive, because the painting code is called less frequently than the cursorX code; and anyhow, I'm pretty sure that every time painting occurs (at least in the cursor's line), cursorX will be called anyhow. We would also have to decide where the correct place for this cache is (TextMetrics?); should caching occur for the entire paragraph (or even document), or just for the line which the cursor is in? But basically, I think this would solve the repeated code, as well as provide an efficiency boost. Comments are welcome! Dov
Re: [patch] Re: RTL justification bug
Dov Feldstern wrote: Stefan Schimanski wrote: Ok, after rereading your previous mail I got it. Would be good to put a better documentation there like: // Spaces at line breaks in bidi text can appear visually in the middle // of a row and must be skipped during painting: // * logically "abc_[HEBREW_\nHEBREW]" // * visually "abc_[_WERBEH\nWERBEH]" Haven't tested the patch, but it looks good. Stefan Thanks, Stefan. Attached the same patch, but better-commented... Any other opinions? Dov I haven't gotten any further comments regarding this patch. Is it OK to go in?
Re: [patch] for bug 2928: make "arabic_arabtex" correctly usable
Hi, Uwe!
All of the problems you're describing are because you haven't performed
the one-time setup required for Arabtex, see
http://permalink.gmane.org/gmane.editors.lyx.devel/88100 for details.
Note that most or all of the things I'm saying that you should add to
the preferences file could also be added from within the preferences in
the GUI.
I'll elaborate below.
Uwe Stöhr wrote:
Dov Feldstern schrieb:
one-time setup for ArabTeX) were not taking effect. It looks like
the language switch commands are currently used only if babel is
activated.
I cannot reproduce this - works fine here or I do need a better
recipe to reproduce.
Try the attached file.
First, I cannot process your file because the command \R is not known.
It therefore only works when I add \usepackage{arabtex} to the preamble.
add the following line to your preferences file:
\language_package "\usepackage{arabtex,cp1256} \setcode{cp1256}"
This is bug 2928 that I originally tried to fix when I started the
discussions about Arabic, see also my last request in the bug report to
add this preamble command automatically. Attached is a patch that does
this, OK?
The patch is not working for me. I think it's because the document
language is not (and shouldn't be) arabtex --- it should be English, as
in the example file I provided; in which case the patch won't kick in.
Secondly, I agree with JMarc about the hardcoding of language info ---
I'm not sure that it really belongs in the source code. I don't think
it's so terrible to require a little setup from the user, and if it is
--- the installer could do this one-time setup.
> With the current situation (latest svn) I get the
> output in arabtex2-bad.dvi. Adding arabtex (or anything, it doesn't
> matter what, it could say 'dummy') to lib/languages as in my patch fixes
> it, and I get the output as portrayed in arabtex2-good.lyx.
Not for me: when I use e.g. the word "arabtex" as dummy language for
babel I get LaTeX-errors, because then your file reads in LaTeX:
\selectlanguage{english}
\inputencoding{latin9}English and \inputencoding{cp1256}\R{عربي}
\selectlanguage{arabtex}
عربي وال-\inputencoding{latin9}\L{English}
\selectlanguage calls babel and therefore needs a valid language name.
When you use "arabic" you always get arabi and not arabtex.
Right, that's why you need to add the following two lines to the
preferences file, so that you *don't* use babel's \selectlanguage:
\language_command_begin "\begin{arabtext}"
\language_command_end "\end{arabtext}"
With current SVN where no babel ame is given, the file reads:
\selectlanguage{english}
\inputencoding{latin9}English and \inputencoding{cp1256}\R{عربي
عربي وال-\inputencoding{latin9}\L{English}
Then you get LaTeX errors because the characters are unknown in the
encoding. To fix this \inputencoding must be replace by \setcode as
described in the arabtex manual or omitted. So this one compiles:
This is taken care of by the line added above (the language_package
preference).
\selectlanguage{english}
\inputencoding{latin9}English and \setcode{cp1256}\R{عربي
عربي وال-\inputencoding{latin9}\L{English}
But the output is as ugly as in your dvi-file. What was the LaTeX-code
when you get the nice output?
I'm not able to get this at the moment.
I'm attaching the latex file as it should look, produced directly from
LyX without any manual tweaking (except for the one-time setup that I
did last week).
Uwe, before trying to patch the code, please try to perform the setup I
described for ArabTeX --- use a separate user directory and start from
scratch. I think you'll find that it solves all the problems you're
having, and if not --- ask me, I'll try to help (and don't forget to add
back arabtex or whatever into the lib/languages!). But you should be
able to reach the stage where you are able to generate correct latex and
dvi, without having to touch the latex file.
Once you're at that stage, then we can see about maybe solving the issue
so that the user won't have to perform the manual setup. Although as
I've already said, I'm not sure that hardcoding is the correct way to go
about this.
regards Uwe
Good luck!
Dov
arabtex2.tex
Description: TeX document
bug RC2
I have installed RC2, and there is a bug that was in RC1 that I did not mention since I thought it would be fixed. My bibtex cites are all of the form Author1-Author2(1980):JPE where JPE refers to a journal. When I insert a cite using lyx it puts in "Author1-Author2(1980" rather than "Author1-Author2(1980):JPE". For the moment I just enter cites as latex commands. The program is great - one all the bugs are worked out it will be a killer app. best bm -- - W. Bentley MacLeod Professor and Co-Director, Program for Economic Research Columbia University 420 West 118th, Mail Code 3308 New York, NY 10027-7296 Email: [EMAIL PROTECTED]
Re: 1.4.4 -> 1.5.0beta2: citation problem in PS and DVI output.
On Thursday 28 June 2007 09:29:19 Rob wrote: > Hi, > > The upgrade from Fedora 6 to 7 confronted me with an automagically > upgrade of LyX from 1.4.4 to 1.5.0beta2. > > So, after the Fedora upgrade, I started LyX (looks good!) and opened > my 1.4.4 document. It looks alright, but the citations in the postscript > and dvi output look awkward. A citation that should become like "[1]" > (without the quotes), now looks like "(author?)[1]", where "(author?)" is > in bold. > > Any idea why this is going wrong? > > Is it possible that this is fixed in the beta3 release? Could you run as root: yum --enablerepo=updates-testing update lyx This will give you rc1. Let us know if the problem is still there. > Or is there a simple conversion possible? > (This is a large document, so I hope there is an easy conversion!!!). > > Thanks, > Rob. -- José Abílio
Re: chinese po file of lyx
On Thursday 28 June 2007 17:39:01 Bo Peng wrote: > Hi, Jose, > > Can I rename zh.po to zh_CN.po and add zh_TW.po from Mr. Chao? Sure, I trust your decision here. :-) -- José Abílio
Re: r18924 - in /www-user/trunk: announce/1_5_0_rc2.txt news.inc
On Thursday 28 June 2007 13:47:43 Juergen Spitzmueller wrote: > > Should be "the second release candidate". You are right. I have fixed it, thanks. > Jürgen -- José Abílio
Re: Update documents to latest file format
On Thursday 28 June 2007 08:11:23 [EMAIL PROTECTED] wrote: > Are you saying it's time to do it now, or should we wait a little while > longer until we know the file format is not going to change? > > /C The later. -- José Abílio
Re: chinese po file of lyx
> 趙惟倫> Hello, Please test the po file in attachment. (still > 趙惟倫> incomplete but hope useful) Hi, Jose, Can I rename zh.po to zh_CN.po and add zh_TW.po from Mr. Chao? zh_CN and zh_TW are two dialects of Chinese. I planned to translate lyx to simplified Chinese (zh_CN) but never got a chance to do it. (I did ask around in Chinese tex group etc). Since Mr. Chao has added zh_TW.po, it is better to rename mine to zh_CN.po for clarity. BTW, I am not very familiar with traditional Chinese terms used in zh_TW.po. For example, the translation of inset looks weird but I will trust Mr. Chao on this. Cheers, Bo
Re: RC2 coming soon
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes: Georg> Sorry, but I don't like it :-( I would prefer to get rid of the Georg> caption inset completely and switch back to the layout based Georg> solution. I would prefer that too... Georg> Since I know that that won't happen my second choice is to Georg> modify Hangzai's patch so that it does not output a caption Georg> inset, but a caption layout. In contrast to the layout file Georg> solution it does not have any side effects, and I believe that Georg> it would be very easy to do. I thought about it too, but it means that a textclass that uses \caption for something else will get to use the caption inset. Not a big problem probably. I'll have a look at this solution. JMarc
Re: chinese po file of lyx
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes: >> Is there someone who can tell me whether this file makes sense? Bo, >> what is the concept behind your own zh.po? Bo> zh.po in svn is empty now. I will have a look at this po file and Bo> commit. Thanks a lot Bo. JMarc
Re: RC2 coming soon
Jean-Marc Lasgouttes wrote: >> "Jean-Marc" == Jean-Marc Lasgouttes >> <[EMAIL PROTECTED]> writes: > >> "José" == José Matos <[EMAIL PROTECTED]> writes: > José> If it works go on. :-) > > Jean-Marc> This would be the following patch. If it does work, I will > Jean-Marc> add the same stub to the few classes that do not use > Jean-Marc> stdlayouts.inc. > > The problem I can see with the patch is that it conflicts with > layout2layout which removes Caption styles. A possibility would be to > restore our own layout files to their Format 3 status, and modify > layout2layout to insert the new Caption definition from the patch > instead of removing all traces of captions. > > Georg, I'd appreciate to hear your views on that. Sorry, but I don't like it :-( I would prefer to get rid of the caption inset completely and switch back to the layout based solution. Since I know that that won't happen my second choice is to modify Hangzai's patch so that it does not output a caption inset, but a caption layout. In contrast to the layout file solution it does not have any side effects, and I believe that it would be very easy to do. Georg
Re: User guide inaccuracy
Darren Freeman schrieb: This doesn't change the fact that if you open a new document and hit C-m around some text in mathed, the View->Source window will show \mbox in use. This is a completely different case and a known bug btw. (consequence of bug 1435). Presing C-m in mathed should create another formula inside the formula. To trasform text in formulas, use "Alt-m m". regards Uwe
Re: chinese po file of lyx
On 6/28/07, Jean-Marc Lasgouttes <[EMAIL PROTECTED]> wrote: > "趙惟倫" == 趙惟倫 <[EMAIL PROTECTED]> writes: 趙惟倫> Hello, Please test the po file in attachment. (still 趙惟倫> incomplete but hope useful) I have tried to get Bo's attention about that, but no luck. So, shall we use this file in 1.5, since the current zh.po seems to be of little use to me. I put a copy at http://www-rocq.inria.fr/~lasgoutt/lyx-1.5.zh_TW.po.gz Is there someone who can tell me whether this file makes sense? Bo, what is the concept behind your own zh.po? zh.po in svn is empty now. I will have a look at this po file and commit. Thanks. Bo
Re: User guide inaccuracy
> I guess the behaviour changed after that part of the guide was written, > and maybe old LyX files should have instances of \textrm replaced by > \mbox on load, for consistency with what you will get if you add another > one. Please no. Using \mbox the text is not scaled right. (See attached example) Wouldn't using \textnormal or \text if using AMS math instead be better? Jonathan newfile2.lyx Description: application/lyx
Re: User guide inaccuracy
On Thu, 2007-06-28 at 16:34 +0200, Uwe Stöhr wrote:
> > As you can see above, I am pointing out that the manual refers to old
> > behaviour of LyX which must have since changed, according to my
> > observations.
>
> What are you talking about? Open the View-> source Window in lyx and set the
> cursor into the formula
> of the section 5.7.2 and you will see that its LaTeX-code is:
>
> \[
> f(x)=\begin{array}{cc}
> x & \textrm{if I say so}\\
> -x & \textrm{otherwise}\end{array}\]
I don't believe it! I looked again and you are right. I could have sworn
the last time I checked (this morning) it was using \mbox. Maybe related
to my working dir having some files owned by root - might not have had
the dead latest version of the user guide until just now. (or I'm making
it up, in which case sorry :)
This doesn't change the fact that if you open a new document and hit C-m
around some text in mathed, the View->Source window will show \mbox in
use.
I guess the behaviour changed after that part of the guide was written,
and maybe old LyX files should have instances of \textrm replaced by
\mbox on load, for consistency with what you will get if you add another
one.
Have fun,
Darren
Re: User guide inaccuracy
On Thu, 28 Jun 2007, Darren Freeman wrote:
On Thu, 2007-06-28 at 12:57 +0200, [EMAIL PROTECTED]
wrote:
"Moreover, math text mode outputs its contents inside a
\textrm{}, whereas and \mbox (or AMS-LaTeX's \text) might have been a
better choice"
This is wrong because LyX now uses \mbox{}.
I didn't understand you - is it a difference in behaviour of LyX
that you're discussing?
As you can see above, I am pointing out that the manual refers to old
behaviour of LyX which must have since changed, according to my
observations.
I understood that, but not how you and Uwe can have different behaviours
in LyX (assuming you both use SVN). Oh well, I'll leave this to you
experts :-)
/Christian
--
Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: User guide inaccuracy
> As you can see above, I am pointing out that the manual refers to old
> behaviour of LyX which must have since changed, according to my
> observations.
What are you talking about? Open the View-> source Window in lyx and set the cursor into the formula
of the section 5.7.2 and you will see that its LaTeX-code is:
\[
f(x)=\begin{array}{cc}
x & \textrm{if I say so}\\
-x & \textrm{otherwise}\end{array}\]
regards Uwe
Re: RC2 coming soon
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: > "José" == José Matos <[EMAIL PROTECTED]> writes: José> If it works go on. :-) Jean-Marc> This would be the following patch. If it does work, I will Jean-Marc> add the same stub to the few classes that do not use Jean-Marc> stdlayouts.inc. The problem I can see with the patch is that it conflicts with layout2layout which removes Caption styles. A possibility would be to restore our own layout files to their Format 3 status, and modify layout2layout to insert the new Caption definition from the patch instead of removing all traces of captions. Georg, I'd appreciate to hear your views on that. JMarc
Re: LyX version 1.5.0 (release candidate 2) is released
> "Sven" == Sven Schreiber <[EMAIL PROTECTED]> writes: Sven> (I'm not in the position to demand anything, as I have never Sven> contributed anything to lyx except bug reports. But I have come Sven> to depend on it as a tool and therefore I have also become a Sven> little paranoid with respect to its stability. I hope you Sven> understand.) The fact is that there are still bugs in LyX 1.5.0svn that will not be found before a release of 1.5.0. Testing will not change much at this point. So if you are paranoid, please wait until 1.5.1 or 1.5.2. JMarc
Re: chinese po file of lyx
> "趙惟倫" == 趙惟倫 <[EMAIL PROTECTED]> writes: 趙惟倫> Hello, Please test the po file in attachment. (still 趙惟倫> incomplete but hope useful) I have tried to get Bo's attention about that, but no luck. So, shall we use this file in 1.5, since the current zh.po seems to be of little use to me. I put a copy at http://www-rocq.inria.fr/~lasgoutt/lyx-1.5.zh_TW.po.gz Is there someone who can tell me whether this file makes sense? Bo, what is the concept behind your own zh.po? JMarc
Re: LyX version 1.5.0 (release candidate 2) is released
José Matos schrieb: > Public release of LyX version 1.5.0 (release candidate 2) > === First of all, great news and thank you all for the big effort! > We expect this to be the last release before 1.5.0, and until the > first stable release only critical bugs and regressions will be > addressed. > So if I understand this correctly, there will be some changes in 1.5.0 final that don't get widespread testing. Why not release other rc's until one is satisfactory and that is then declared the final version, with no further changes? I thought that was the whole point of calling it rc instead of beta. (I'm not in the position to demand anything, as I have never contributed anything to lyx except bug reports. But I have come to depend on it as a tool and therefore I have also become a little paranoid with respect to its stability. I hope you understand.) thanks, sven
Re: r18924 - in /www-user/trunk: announce/1_5_0_rc2.txt news.inc
[EMAIL PROTECTED] wrote:
> +news_item("LyX 1.5.0 (release candidate 2) released.", "Release
> Candidate", "Jun 27, 2007", +
> +"We are pleased to announce the release of the first release candidate
> of LyX +1.5.0.
Should be "the second release candidate".
Jürgen
Re: [PATCH] Fix bug 3939
Richard Heck wrote: Helge Hafting wrote: Richard Heck wrote: This fixes a bug reported by Helge: changing the paragraph style needlessly resets all the paragraph parameters. This is important to fix in the context of the recently committed fixes to paragraph settings. I'd appreciate it if someone could commit this for me, once we get the OK. I'll be on vacation starting tomorrow. Here's a log message: Fix bug 3939. Don't reset all the parameters when the layout is changed, but instead: Check if the alignment is permitted; if not, issue a warning, and reset to LYX_ALIGN_LAYOUT. I tested the patch and it works. The alignment setting is now preserved over layout changes, as long as the alignment set is valid in the new layout. Very good! A couple of small issues: * Changing the layout to something that doesn't support the current alignment bothers me with a message box. (For example, when turning a right-aligned paragraph into "title".) The message box hampers workflow as one have to click on "ok", and the message isn't important enough to justify that. A message printed on the status bar would be much better, that is what the status bar is there for. The status bar is nice in that you don't have to _do_ anything after reading the message, the status line don't demand useless action. I'm leaving for vacation in a few minutes. Someone else, hopefully, can fix this. Or I can do it when I get back. Great! I hope this small issue won't hold the patch back. * The paragraph settings dialog is now modal - I _have_ to close it before continuing work in LyX. Non-modal is nicer as one don't have to close it. Yes, it has been for a while. The reason is that there is no way to be sure it gets updated if the cursor gets moved. We're working on this, too. Nice to hear. Have a nice vacation! Helge Hafting
Re: LyX version 1.5.0 (release candidate 2) is released
Am Freitag, 18. Mai 2007 14:37 schrieb José Matos: > Public release of LyX version 1.5.0 (release candidate 2) > === > > We are glad to announce the release of LyX 1.5.0 (release candidate 2). > We expect this to be the last release before 1.5.0, and until the > first stable release only critical bugs and regressions will be > addressed. > > We encourage users to try this release candidate and report > any feedback or problems to lyx-devel at lists.lyx.org. very impressive work, thanks and congratulations to the team. I am planning to try 1.5.0 (release candidate 2) out and would appreciate if somebody could tell me whether and how I can do it without throwing my 1.4.3 version out (Debian etch). Should I create a new user in my home? Wolfgang
Re: i18n Nynorsk
> "ingar" == ingar pareliussen <[EMAIL PROTECTED]> writes:
ingar> Hi Jean-Marc, I do not have SVN account so I need someone to
ingar> put this into the trunk. I tried to send it to the devel list,
ingar> but it exceeds the 300kb limit on the list, so I send it
ingar> directly to you. I hope you do not mind to much.
Hello Ingar,
Thanks for the file, it is in now.
ingar> I have a couple of questions, I'll raise here, with your
ingar> permission, to the string translations which I do not
ingar> understand: 1. When I start lyx with the Lang=nn_NO i get this
ingar> warning: Menu warning: menu entry "Rein tekst..." does not
ingar> contain shortcut `a'. However, I can not find this text in the
ingar> po file, the closest I have is "Rein tekst...|t".
The entry comes from the following line in lib/configure.py:
\Format text txt"Plain text"a "" "%%""document"
It seems that these entries are translated now, but apparently not in
a useable form. Does someone know about that?
ingar> 2. Some of the text for beamer template are not used even if
ingar> they are translated eg: example block: "block (ERT[{title}]
ingar> example text)"
I do not know about this one.
JMarc
Re: [PATCH] Fix bug 3939
Helge Hafting wrote: Richard Heck wrote: This fixes a bug reported by Helge: changing the paragraph style needlessly resets all the paragraph parameters. This is important to fix in the context of the recently committed fixes to paragraph settings. I'd appreciate it if someone could commit this for me, once we get the OK. I'll be on vacation starting tomorrow. Here's a log message: Fix bug 3939. Don't reset all the parameters when the layout is changed, but instead: Check if the alignment is permitted; if not, issue a warning, and reset to LYX_ALIGN_LAYOUT. I tested the patch and it works. The alignment setting is now preserved over layout changes, as long as the alignment set is valid in the new layout. Very good! A couple of small issues: * Changing the layout to something that doesn't support the current alignment bothers me with a message box. (For example, when turning a right-aligned paragraph into "title".) The message box hampers workflow as one have to click on "ok", and the message isn't important enough to justify that. A message printed on the status bar would be much better, that is what the status bar is there for. The status bar is nice in that you don't have to _do_ anything after reading the message, the status line don't demand useless action. I'm leaving for vacation in a few minutes. Someone else, hopefully, can fix this. Or I can do it when I get back. * The paragraph settings dialog is now modal - I _have_ to close it before continuing work in LyX. Non-modal is nicer as one don't have to close it. Yes, it has been for a while. The reason is that there is no way to be sure it gets updated if the cursor gets moved. We're working on this, too. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: User guide inaccuracy
On Thu, 2007-06-28 at 12:57 +0200, [EMAIL PROTECTED]
wrote:
> > "Moreover, math text mode outputs its contents inside a
> > \textrm{}, whereas and \mbox (or AMS-LaTeX's \text) might have been a
> > better choice"
> >
> > This is wrong because LyX now uses \mbox{}.
> I didn't understand you - is it a difference in behaviour of LyX
> that you're discussing?
As you can see above, I am pointing out that the manual refers to old
behaviour of LyX which must have since changed, according to my
observations.
Have fun,
Darren
Re: User guide inaccuracy
On Thu, 28 Jun 2007, Darren Freeman wrote:
On Thu, 2007-06-28 at 09:10 +0200, [EMAIL PROTECTED]
wrote:
On Thu, 28 Jun 2007, Darren Freeman wrote:
On Thu, 2007-06-28 at 01:56 +0200, Uwe Stöhr wrote:
"Moreover, math text mode outputs its contents inside a
\textrm{}, whereas and \mbox (or AMS-LaTeX's \text) might have been a
better choice"
This is wrong because LyX now uses \mbox{}.
Where? When I look at the code of the formula in that section, I still
see \textrm for the text.
But on my system I do the same thing and see \mbox{} even for the user
guide.
Do you use the same file?
I guess so, I'm on the latest svn. I haven't seen any \textrm anywhere
and I would have thought it doesn't depend on the particular LyX file.
I didn't understand you - is it a difference in behaviour of LyX
that you're discussing?
/C
--
Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: RC2 coming soon
> "José" == José Matos <[EMAIL PROTECTED]> writes: José> If it works go on. :-) This would be the following patch. If it does work, I will add the same stub to the few classes that do not use stdlayouts.inc. Please test. JMarc Index: lib/layouts/stdlayouts.inc === --- lib/layouts/stdlayouts.inc (révision 18926) +++ lib/layouts/stdlayouts.inc (copie de travail) @@ -78,3 +78,14 @@ Style --Separator-- Color Blue EndFont End + +# This Style is only needed to make tex2lyx convert the \caption macro +# to Caption style, so that lyx2lyx can later convert that to the new +# caption inset. Please remove it when tex2lyx has been upgraded to +# format >= 257 and properly supports the caption inset. (JMarc) +Style Caption + ObsoletedBy Standard + LatexType Command + LatexName caption + OptionalArgs 1 +End
Re: Makefile install target does a lot of work
On Thu, 2007-06-28 at 11:38 +0200, Helge Hafting wrote: > The fix is to let root run a > "chown -R your_username *" in the top build directory. > After that, you own all the files and can compile without root's help again. You got it! Solved, thanks. I was wondering why I had to wait so long after issuing a "make install" :) Usually I go away for a drink and come back with a root prompt waiting. It should be usable seconds later. Have fun, Darren
Bug with outline panel and child documents
1. Open a document with child documents, each comprising divisions; 2. Show the outline pane. You can see childs' divisions; 3. Select (view) one of the childs; 4. Close this child doc. The focus comes back to the master doc; 5. Click in the outline pane at some point corresponding to the child doc you closed. LyX crashes with SIGSEGV (instead of reopening the child...). Anyone can confirm? I'm on Mac, 1.5.0rc2. Same problem with rc1. Mael.
Re: [PATCH] Fix bug 3939
Richard Heck wrote: This fixes a bug reported by Helge: changing the paragraph style needlessly resets all the paragraph parameters. This is important to fix in the context of the recently committed fixes to paragraph settings. I'd appreciate it if someone could commit this for me, once we get the OK. I'll be on vacation starting tomorrow. Here's a log message: Fix bug 3939. Don't reset all the parameters when the layout is changed, but instead: Check if the alignment is permitted; if not, issue a warning, and reset to LYX_ALIGN_LAYOUT. I tested the patch and it works. The alignment setting is now preserved over layout changes, as long as the alignment set is valid in the new layout. Very good! A couple of small issues: * Changing the layout to something that doesn't support the current alignment bothers me with a message box. (For example, when turning a right-aligned paragraph into "title".) The message box hampers workflow as one have to click on "ok", and the message isn't important enough to justify that. A message printed on the status bar would be much better, that is what the status bar is there for. The status bar is nice in that you don't have to _do_ anything after reading the message, the status line don't demand useless action. * The paragraph settings dialog is now modal - I _have_ to close it before continuing work in LyX. Non-modal is nicer as one don't have to close it. Helge Hafting
Re: Makefile install target does a lot of work
Darren Freeman wrote: Hi all, why does "make install" under Linux have so much work to do? It seems to be linking and building docs etc. Surely this stuff is meant to be done by "make". Since I have to run "make install" as root, I generally prefer not to have actual processing being done here. I have seen this occationally. It seems to me that "make install" will "make" anything that isn't up to date. So, if you patched something since the last "make", then "make install" will indeed compile and link for you. If this happens once, then you are kind of stuck. The next "make" run as non-root will not be able to overwrite the object files created by root. So the next "make install" will have to recreate them again. The fix is to let root run a "chown -R your_username *" in the top build directory. After that, you own all the files and can compile without root's help again. Helge Hafting
1.4.4 -> 1.5.0beta2: citation problem in PS and DVI output.
Hi, The upgrade from Fedora 6 to 7 confronted me with an automagically upgrade of LyX from 1.4.4 to 1.5.0beta2. So, after the Fedora upgrade, I started LyX (looks good!) and opened my 1.4.4 document. It looks alright, but the citations in the postscript and dvi output look awkward. A citation that should become like "[1]" (without the quotes), now looks like "(author?)[1]", where "(author?)" is in bold. Any idea why this is going wrong? Is it possible that this is fixed in the beta3 release? Or is there a simple conversion possible? (This is a large document, so I hope there is an easy conversion!!!). Thanks, Rob. - Got a little couch potato? Check out fun summer activities for kids.
Re: Mathed sub/superscripts highlighting
Darren Freeman wrote:
> What I am most concerned about is being able to write chemical formulas
> with each element as a nucleus. I guess if I ensure the nucleus is
> math-text then it will work anyway but there must be others who would
> like this to work without brace insets.
>
> Maybe there should be a chemical mode or chemical inset within mathed?
That might be useful, but not for this reason.
> Spare a thought for anybody who wants to write down:
>
> $\mbox{La}_5\mbox{Pr}_2\mbox{Eu}_4\mbox{Yb}_3
> \mbox{Si}_{12}\mbox{Sn}_{16}\Rightarrow\mbox{Purple}_2\mbox{Monkey}_1
> \mbox{Dishwasher}_3$
>
> :)
>
> Suggestion: can you define \nuc{} to mean the same as {}? Then \nuc
> would be used for multiple char nuclei and LyX would have no ambiguity
> in parsing it.
That would be a hack that will cause complaints from whose who want readable
TeX export. Another idea I had is to automatically insert a brace inset if
you enter more than one character of a nucleus. It is certainly not a good
idea UI wise, but IMHO better than the current situation.
Of course the best thing would be if the braces could be part of the
nucleus. Read the old discussions, we were not able to find a reliable
solution for this problem.
Georg
Re: Mathed sub/superscripts highlighting
Darren Freeman wrote: > The multi-char nucleus is saved and loaded properly by LyX, right? No, it becomes a single char nucleus. Try it. > So > why not export with braces? It shouldn't be that often that people > import LaTeX that was generated by LyX, right? They do that all the time they load a .lyx file, because math is stored as TeX in .lyx files. And they do that if they use undo/redo, because that also uses the TeX serialization. Therefore reading that back _must_ work. Georg
Re: Add BibTeX database confusing
Darren Freeman wrote: > How can that be the preferable way? Are you saying that I should move my > database over to the texmf tree? Yes. Sure. > I was planning to have it live next to > the LyX file it was created for. This might be OK if you're planning to write a single publication on a given topic. However, if you are writing several papers on the same issue, you don't have to care for the path if the database is in the texmf tree. Jürgen
Re: LyX version 1.5.0 (release candidate 2) is released
* Unified Windows installer The two windows installers are being merged and bug reports regarding both installers are welcome. This text could probably be clarified. It almost sounds as if this has already happened. How about: * Unified Windows installer The plan is to merge the code base of the two LyX installers for Microsoft Windows during the LyX 1.5.x-series, so bug reports regarding both installers are welcome. Maybe to detailed, but at least it's accurate. There are several issues that need to be discussed regarding the installers, but I'm postponing that until 1.5.0 is out to avoid distractions. /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: Makefile install target does a lot of work
> "Darren" == Darren Freeman <[EMAIL PROTECTED]> writes: Darren> I'm far from an expert on what a makefile should do under each Darren> target, I'm just commenting on the overall volume of work Darren> being done by the install target. There are a lot of commands passing by, but basically this should be only copying stuff. JMarc
Re: Update documents to latest file format
On Wed, 27 Jun 2007, José Matos wrote: On Tuesday 26 June 2007 21:10:31 Michael Gerz wrote: José, (when) should we update all LyX files to the latest file format? We should wait and do that before the first stable release. So after RC2 it is OK. Are you saying it's time to do it now, or should we wait a little while longer until we know the file format is not going to change? /C -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: User guide inaccuracy
On Thu, 2007-06-28 at 09:10 +0200, [EMAIL PROTECTED]
wrote:
> On Thu, 28 Jun 2007, Darren Freeman wrote:
>
> > On Thu, 2007-06-28 at 01:56 +0200, Uwe Stöhr wrote:
> >> > "Moreover, math text mode outputs its contents inside a
> >> > \textrm{}, whereas and \mbox (or AMS-LaTeX's \text) might have been a
> >> > better choice"
> >> >
> >> > This is wrong because LyX now uses \mbox{}.
> >>
> >> Where? When I look at the code of the formula in that section, I still
> >> see \textrm for the text.
> >
> > But on my system I do the same thing and see \mbox{} even for the user
> > guide.
>
> Do you use the same file?
I guess so, I'm on the latest svn. I haven't seen any \textrm anywhere
and I would have thought it doesn't depend on the particular LyX file.
Have fun,
Darren
Re: Arabic Wiki Page
On Thu, 28 Jun 2007, Uwe Stöhr wrote: * I would like to add the instructions for non-windows to the Wiki as well (Dekel's instructions are quite dated, and after the change to arabic_arabtex is applied, won't even work). Should I do that on a separate page, or in the same page? Or would you prefer that I write it up and send it to you, and you will integrate it into the wiki page? I think you should add the Linux installation instructions to the existing wiki page behind the Windows install section. The actual page contains the both OSes and can be referenced everywhere. I'm fine with this, and it's easy to create a page LyX.Arabic that automatically redirects to Windows.Arabic (or vice versa). To do it, just create the page LyX.Arabic with the content: (:redirect Windows.Arabic:) /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: User guide inaccuracy
On Thu, 28 Jun 2007, Darren Freeman wrote:
On Thu, 2007-06-28 at 01:56 +0200, Uwe Stöhr wrote:
> "Moreover, math text mode outputs its contents inside a
> \textrm{}, whereas and \mbox (or AMS-LaTeX's \text) might have been a
> better choice"
>
> This is wrong because LyX now uses \mbox{}.
Where? When I look at the code of the formula in that section, I still
see \textrm for the text.
But on my system I do the same thing and see \mbox{} even for the user
guide.
Do you use the same file?
/Christian
--
Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: Help! Problem with Windows Installer
On Wed, 27 Jun 2007, Uwe Stöhr wrote: Joel Yuen schrieb: Once I install all the components such as MikTex, Gsview, etc., there is a black window that shows up and says +checking for default encoding (this may take a long time) + checking for ec fonts... yes + checking for ec support in LaTex format... yes and then it gets stuck even after 8 hours. It seems that the check and downloading for the LaTeX-packages fails. This should work for you when you open an internet connection before installing LyX. Hi Uwe, I thought it was LyX (or a LyX script) that did the reconfigure? Does it invoke MiKTex, which then might try to go online? If that's the case, I think some kind of information message is in order. It doesn't seem obvious to me at all that a reconfigure should require an internet connection. /Christian In your case LyX is already installed, only the configuration fails, so open an internet connection, start LyX, reconfigure it using the menu Tools->reconfigure. If it then sops at the same position after some for more than some minutes, there are troubles with your internet connection - firewall for example. regards Uwe -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
