pitfalls with search paths
Hi,
I just discovered a pitfall (bug, inconsistency or undocumented feature ?) in
LyX 1.5.3 under XP (haven't tried under linux yet)
I normally use a preamble include file, located in the same directory as the
main document, which does the main Documents settings. So my normal preambel
entry in the LyX-file just says:
\input{preamble-inc}
where the inclusion from the local directory is the normal TeX behavior.
Unfortunately, as i have the preamble-inc together with additional styles in
one cvs-project another version of that file also exists in the tex-search
paths.
The - dvi compilation from LyX now uses this version, whereas the latex export
and external compilation works as expected.
The relevant diff between the two log files is:
-Class scrbook Info: longtable captions redefined on input line 14.
- (preamble-inc.tex
+Class scrbook Info: longtable captions redefined on input line 16.
+(C:\localtexmf\tex\latex\ubastyle\preamble-inc.tex
(C:\texmf\tex\latex\base\ift+hen.sty
BTW
if I include the preamble with
\input{./preamble-inc}
it also works from within LyX.
I'd propose to make the LyX / TeX behavior consistent.
Greetings from Berlin
--
Dr. Joachim Heidemeier
c/o Umweltbundesamt FG II 2.2
Tel.: +49340 2103-2780
eMail: [EMAIL PROTECTED]
Re: Incoming 1.5.3 binaries for debian/ubuntu distributions
On Thu, Jan 17, 2008 at 10:26:48PM +, Sam Lewis wrote: Sven Hoexter [EMAIL PROTECTED] writes: Moin Sam, a) The social/trust problem [...] What solution could you think of? Does the development team use key? Well the Debian project has a known web of trust based on key exchange and extensive peer review of packages. Since you don't have source packages there is nothing to review. That's again a pro of the backports.org infrastructure where you've clean build enviroments supported by trusted people and signed binary packages. That's something you can't even provide without proper packaging. But in the end the trust thing is a personal decision to be made by everyone on their own. b) Technical problems I guess this is a specific debian issue you're raising and might differ at each distro (my apologies to for the possibly off-list-topic discussion here). Not really. The examples are Debian specific (well and in this case Ubuntu specific aswell because they use the same packages) but the problems can occure within any other system with package management aswell. ba) You're breaking the upgrade path. [...] True, if you are using checkinstall binaries and (in the unlikely event of) your stable debian release upgrading to this specific lyx release, libraries might most probably not match. All you need to do is to reinstall, through the comfort of checkinstall the offending lyx package. sudo dpkg -r lyx And then there is the user who doesn't remember what he did in good faith to his system. A year later he upgrades to the next stable releases und this fscking update broke his nice LyX installation working for fine for the last year. So who's responsible for the non working package? Must be the Debian guys who just prepared the new stable release which seems to ship a broken package. It's hard to make sure that everyone is able to track such subtle changes he doesn't completly understand and it's hard for the developers on the other side to find out what happened. The frontend tools like apt-get where implemented to ease the system management for everyone but they can not work if you install bogus packages. bb) Maintainer scripts have a reason For example somebody doing QA work recently noticed that we've left an /etc/lyxrc file on the system with the 1.4.x-1.5.x upgrade which should not happen. So we're now cleaning up behind us with a maintainer script which is of course bound to special versions. You'll break if you install your current package an try to upgrade it at a later point to a Debian version again. In this case it's only an unused old file but it could of course be anything more important. So how about a recommendation that users when installing a checkinstall binary should uses the following command line: sudo dpkg -r lyx sudo dpkg -i lyx_1.5.3-1_i386_etch.deb sudo apt-get -f install Here you missed the point. The error (actually an error we made in the Debian package) is in the 1.4.x packages and will be resolved with a maintainer script in the latest revision of the 1.5.x package. In this special case the file will be left on the system even if you purge the package. So your proposed fiddling won't solve anything. Additionaly it won't solve the latex-beamer issue but it won't cause bigger problems because you're installing into /usr/local. At least I hope that it won't cause trouble but I didn't test if it would confuse latex in anyway or not. bc) Dependencies don't exist for fun. See above. The toolchain with dpkg and apt were build to resolve the dependencies for you and you're ignoring that part completly. Installing the checkinstall package you can even remove latex (maybe some clean up mechanism even suggest to remove them because they look unused now) without anything complaining. Bds..) i386? And where is the rest? Yep that would be good, but to make it clear, this is an instrumental move. I'm not a developer or maintainer; I am a social scientist, who uses LyX on a daily basis on computers that happen to be i386. For the benefit of others, I am providing my own compiled binaries, for others who don't have the knowledge or the resources to compile the source themselves. I might count that in as the only small benefit. I might be one of the rare cases of users who used one installation for seven years with several hardware changes. If you'd like to reinstall a clean system with every stable release of your distribution of choice go ahead and use broken packages. Impressive -- this deserves applause! Don't get my wrong, your concerns are valid, but there are many pragmatic and practical reason as to why people compile their own software rather than waiting for a backport or using a rather old version of it. What I don't get is why you waste your time with this broken checkinstall crap? It's only a very small step you've to make to get the source package and create a backport.
Re: generic X copy-and-paste not working
On Fri, 18 Jan 2008, G. Milde shared this with us all: --} On 17.01.08, Jeremy C. Reed wrote: --} Normally, I can highlight text in a terminal and paste it with a --} middle-click. In LyX, usually I can get to it with Edit - Paste Special. --} (I can copy-and-paste fine in my xterms.) --} --} In my LyX, the Paste Special choices are shaded out and not clickable. --} --} This is LyX 1.5.2 on NetBSD. I am not running any clipboard utility. --} --} Any ideas why I can't paste into LyX? --} --} I did a test on my LyX 1.5.3 on Debian/testing++ with XFCE4 and --} xfce4-clipman and got very strange results: --} --} A newly opened LyX (first time after starting the Computer) with a new --} buffer did not accept any mouse-pasting (middle click) from xterms or xjed. --} (Whether with a simple middel click or via EditPaste did not matter.) --} --} Just typing some text in the LyX window did not change this behaviour. --} --} After marking some text (with mouse) and Ctrl-C, I could paste this text --} with a middle-mouse click. --} --} Now also pasting text from other applications works fine. --} --} Closing LyX and opening a new one: The second time pasting works from the --} start. --} --} Any clues? --} --} Guenter --} This version [LyX Version 1.5.2] of Lyx seems to require the Ctrl+c to copy and Ctrl+v command. Just highlight then middle mouse button [scrollwheel] or double right/left mouse click to paste into a Lyx document doesn't work in Debian testing. Using Icewm. If there is a selected passage in any other program, prior to starting Lyx, you can just copy with the double mouse or scrollwheel click. It seems that as Lyx loads up, after something has been highlighted it works because Lyx gathers that information from the clipboard, which copies highlighted text. This may not be the case using KDE? -- Registered Linux User:- 329524 ** When it's over, I want to say: all my life I was a bride married to amazement. I was the bridegroom, taking the world into my arms . . . --- MARY OLIVER Debian - Just the best way to do magic.
Re: Figures and Schemes
Andreas Zumbuehl wrote: I am a chemist, trying to work with Lyx. I would need to distinguish between 'figure' captions and 'scheme' captions.However, if I use insert - float I can only choose 'Figure'. How can I add a command allowing me to insert -float - scheme ? 1.) create a file myfloats.inc with the following content: Format 4 Float Type scheme GuiName Scheme Placement tbp Extension los NumberWithin none Style plain ListName List of Schemes LaTeXBuiltin false End 2.) Save it in you LyX user directory (see About-LyX for where this is). 3.) Copy the layout file of the class you're using to the user directory as well, and put in the following line at the end Input myfloats.inc HTH, Jürgen
Re: Incoming 1.5.3 binaries for debian/ubuntu distributions
Sven Hoexter [EMAIL PROTECTED] writes: Hi Sven, I'll keep it on list because some of the topics might help people eventually creating Ubuntu backports to do it right. Fine! [...] Again, what kind of LyX users are there? Why link LyX to a specific latex? Would there be anyone who does not know the relationship between LyX and latex, I wonder? I should know that I need libc to use some software or shouldn't I? If you question the need of explicit dependencies you can question the whole model of creating ready to intall system distributions. Hmm, libc definitely not! Libraries should be explicitly linked, no doubt. Not sure about the linking a whole independent programme like latex. Btw, you might like to read the following discussion on checkinstall stating that some consider the absence of dependencies in checkinstall packages as *either a bug or a feature* ! http://www.debian-administration.org/articles/147 I would formulate it a bit different. Depending on your own skills and intention you can in some cases consider it as feature. In the case of distributing such packages on the internet to an unknown mass of people with a very different level of knowledge it's IMO a disavantage. Reasonable assumption. I'm considering building a package that specifies decencies. About backporting I'm not sure at all. [...] Of course you've to support your backports in case of security problems in the version you've backported. It's the same for the checkinstall stuff. You're pulling in a second, isolated, version of boost btw that needs to be patched as well in case of problems with boost. That's a very bad thing and I'm happy that we can use with the external boost packages provide within Debian with the next stable release. For a current backport you've to backport libboost aswell. IMHO it's easier to notice a DSA for boost and check if your boost backport is affected as well then searching in all your packages which libs they ship. I guess this means, I should compile and provide the boost lib too than, for Juergen to upload. Should I? Main point how, much time and effort does this really take? Perhaps you can send me some relevant links off list about the issue. That depends on the package and your own skill level and how much you know about the package you're backporting. This is what I was fearing, I have no knowledge about the source and very limited skills. In most cases it's just recompiling in a stable chroot. In case of LyX you've to recompile boost first with a proper version number so that it will be replaced with the next stable release that ships the same version. Then you've to install this new boost version in a chroot and modify the LyX source package a bit. You might want to interdiff the .diff.gz from sid against Emilios .diff.gz. It's actually rolling back two versioned dependencies, removing a dh_icons call which would require a new version of debhelper scripts and at least lenny to be usefull at all. If you like you'll pull in the tetex stuff as alternative to texlive and then you only need to build the package. If you know what to do it's about 5min plus compile time. There are some hints on http://debian.ethz.ch/pub/debian-backports/utils/Backport-HOWTO.html Also, is it right, that according to this instruction LyX 1.5.3 cannot yet be build: ` 2.2.1 [...] make sure you use sources with an upstream version not higher than what is available in testing.' because testing is only at 1.5.2? http://bjorn.haxx.se/debian/testing.pl?package=lyx Does this mean, we only *now* could have a backport of LyX 1.5.3? What would you say to build a real debian package following this instruction instead of checkinstall: http://www.debian-administration.org/articles/336 I would consider this in light of you convincing argument, as a reasonable compromise. Cheers, Sam
Re: Math font error on Lyx - Windows
Andrew Barr wrote: I was using Times Roman font. I changed the font settings to default, and all the math comes through fine. So...I guess that problem is solved for the moment. Sorry for the dumb question. I don't think this is a dumb question. Something unusual is happening that should not be happening. Unfortunately, I am not the person to fix it. However... I think Computer Modern is the default, but I can't actually recall how to check what the defaults are. I recall changing some font stuff around and Saving as Default in the past. I haven't gotten any errors, but it would be nice to be able to go to a file or window and see the current defaults (rather than just seeing Default displayed without knowing what it is). Anyone know how to get that? I rambled through all the documentation and didn't come up with anything. - David Hewitt Virginia Institute of Marine Science http://www.vims.edu/fish/students/dhewitt/ -- View this message in context: http://www.nabble.com/Math-font-error-on-Lyx---Windows-tp14927537p14950994.html Sent from the LyX - Users mailing list archive at Nabble.com.
Re: Incoming 1.5.3 binaries for debian/ubuntu distributions
On Fri, Jan 18, 2008 at 01:06:27PM +, Sam Lewis wrote: Sven Hoexter [EMAIL PROTECTED] writes: Hi Sam, I'll keep it on list because some of the topics might help people eventually creating Ubuntu backports to do it right. And then there is the user who doesn't remember what he did in good faith to his system. A year later he upgrades to the next stable releases und this fscking update broke his nice LyX installation working for fine for the last year. So who's responsible for the non [...] What kind of LyX user (who opts for the latest version of LyX) do you envisage? All the packages clearly state in the README file that they are checkinstall. How many users who possibly find the package via google or on the ftp site know what that means? I doubt that many know or even care. I even doubt that everyone can follow what we're discussing here and they should not need to understand it. The toolchain with dpkg and apt were build to resolve the dependencies for you and you're ignoring that part completly. Installing the checkinstall package you can even remove latex (maybe some clean up mechanism even suggest to remove them because they look unused now) without anything complaining. That's what I was trying to say. You might be surprised I've seen people running LyX on a tiny system without any latex for the purpose of writing and managing lyx files. I personally have used TexLive for years and was precisely only able to do this as I complied source myself rather than using an official LyX version linked to tetex in some distro. Those people wouldn't install the distribution packages anyway. Regarding the tex version thingy etch is the last Debian stable release with tetex and texlive. So in a perfect world everyone would switch to texlive now. Since nobody should be forced to replace his tetex installation now a backport should readd the tetex alternative for texlive. I did this in my own backport proposed for backports.org already but that's not so important here. Again, what kind of LyX users are there? Why link LyX to a specific latex? Would there be anyone who does not know the relationship between LyX and latex, I wonder? I should know that I need libc to use some software or shouldn't I? If you question the need of explicit dependencies you can question the whole model of creating ready to intall system distributions. Btw, you might like to read the following discussion on checkinstall stating that some consider the absence of dependencies in checkinstall packages as *either a bug or a feature* ! http://www.debian-administration.org/articles/147 I would formulate it a bit different. Depending on your own skills and intention you can in some cases consider it as feature. In the case of distributing such packages on the internet to an unknown mass of people with a very different level of knowledge it's IMO a disavantage. What I don't get is why you waste your time with this broken checkinstall crap? It's only a very small step you've to make to get the source package and create a backport. The Debian source packages are free for everyone to use (that's essentialy what Ubuntu and other distributions are based upon). I thought I was saving time, by just typing checkinstall rather make install. It's more about dpkg-buildpackage then checkinstall vs. make install. Of course you might save some time but you pay for that with the risc of some more or less subtle problems. So please use the source packages and build proper backports instead of punching your package management system right in the face! One and a half thing: Backporting always presents a slight security issues, which can be minimised by backporting as few as possible decencies, if understand this correctly (see http://debian.ethz.ch/pub/debian-backports/utils/Backport-HOWTO.html ). Of course you've to support your backports in case of security problems in the version you've backported. It's the same for the checkinstall stuff. You're pulling in a second, isolated, version of boost btw that needs to be patched as well in case of problems with boost. That's a very bad thing and I'm happy that we can use with the external boost packages provide within Debian with the next stable release. For a current backport you've to backport libboost aswell. IMHO it's easier to notice a DSA for boost and check if your boost backport is affected as well then searching in all your packages which libs they ship. Main point how, much time and effort does this really take? Perhaps you can send me some relevant links off list about the issue. That depends on the package and your own skill level and how much you know about the package you're backporting. In most cases it's just recompiling in a stable chroot. In case of LyX you've to recompile boost first with a proper version number so that it will be replaced with the next stable release that ships the same version.
Figures and Schemes
Hello! I am a chemist, trying to work with Lyx. I would need to distinguish between 'figure' captions and 'scheme' captions.However, if I use insert - float I can only choose 'Figure'. How can I add a command allowing me to insert -float - scheme ? Thank you very much for your help! Andreas
Re: Incoming 1.5.3 binaries for debian/ubuntu distributions
Sven Hoexter [EMAIL PROTECTED] writes: On Thu, Jan 17, 2008 at 10:26:48PM +, Sam Lewis wrote: Sven Hoexter [EMAIL PROTECTED] writes: Moin moin, a) The social/trust problem [...] What solution could you think of? Does the development team use key? Well the Debian project has a known web of trust based on key exchange Sensible! b) Technical problems [...] ba) You're breaking the upgrade path. [...] True, if you are using checkinstall binaries and (in the unlikely event of) your stable debian release upgrading to this specific lyx release, libraries might most probably not match. All you need to do is to reinstall, through the comfort of checkinstall the offending lyx package. sudo dpkg -r lyx And then there is the user who doesn't remember what he did in good faith to his system. A year later he upgrades to the next stable releases und this fscking update broke his nice LyX installation working for fine for the last year. So who's responsible for the non [...] What kind of LyX user (who opts for the latest version of LyX) do you envisage? All the packages clearly state in the README file that they are checkinstall. [...] bb) Maintainer scripts have a reason For example somebody doing QA work recently noticed that we've left an /etc/lyxrc file on the system with the 1.4.x-1.5.x upgrade which should not happen. So we're now cleaning up behind us with a maintainer script which is of course bound to special versions. You'll break if you install your current package an try to upgrade it at a later point to a Debian version again. In this case it's only an unused old file but it could of course be anything more important. So how about a recommendation that users when installing a checkinstall binary should uses the following command line: sudo dpkg -r lyx sudo dpkg -i lyx_1.5.3-1_i386_etch.deb sudo apt-get -f install Here you missed the point. The error (actually an error we made in the Debian package) is in the 1.4.x packages and will be resolved with a maintainer script in the latest revision of the 1.5.x package. In this special case the file will be left on the system even if you purge the package. So your proposed fiddling won't solve anything. OK, I see. [...] bc) Dependencies don't exist for fun. See above. The toolchain with dpkg and apt were build to resolve the dependencies for you and you're ignoring that part completly. Installing the checkinstall package you can even remove latex (maybe some clean up mechanism even suggest to remove them because they look unused now) without anything complaining. That's what I was trying to say. You might be surprised I've seen people running LyX on a tiny system without any latex for the purpose of writing and managing lyx files. I personally have used TexLive for years and was precisely only able to do this as I complied source myself rather than using an official LyX version linked to tetex in some distro. Again, what kind of LyX users are there? Why link LyX to a specific latex? Would there be anyone who does not know the relationship between LyX and latex, I wonder? Btw, you might like to read the following discussion on checkinstall stating that some consider the absence of dependencies in checkinstall packages as *either a bug or a feature* ! http://www.debian-administration.org/articles/147 Bds..) i386? And where is the rest? Yep that would be good, but to make it clear, this is an instrumental move. I'm not a developer or maintainer; I am a social scientist, who uses LyX on a daily basis on computers that happen to be i386. For the benefit of others, I am providing my own compiled binaries, for others who don't have the knowledge or the resources to compile the source themselves. I might count that in as the only small benefit. Thanks! [...] What I don't get is why you waste your time with this broken checkinstall crap? It's only a very small step you've to make to get the source package and create a backport. The Debian source packages are free for everyone to use (that's essentialy what Ubuntu and other distributions are based upon). I thought I was saving time, by just typing checkinstall rather make install. The prefered solution for Debian would be to find a DD willing to sponsor the backports.org uploads. Per has no time and interested in the backports stuff and I'm not a DD yet. I guess something similar would be needed for Ubuntu backports but I'm not involved there. It seems that they've a few more releases in work which should be supported with backports but that's a manpower issue. So please use the source packages and build proper backports instead of punching your package management system right in the face! One and a half thing: Backporting always presents a slight security issues, which can be minimised by backporting as few as possible decencies, if understand
natbib APA references for multiple authors
When there are two or more authors on a paper and the reference is
withing brackets, the APA guidelines are that it should be (Linehan
Linehan, 2008). Its doing this, which is good. However, when the
authors are outside the brackets it should be Linehan and Linehan
(2008). The '' sign should never be used outside of brackets. So
natbib should be doing this:
\citet*{jon90} Jones, Baker, and Williams (1990)
\citep*{jon90} (Jones, Baker, Williams, 1990)
Is this something I can modify in a .bst file. Could anyone help me
with this? Im using this natbib compatible .bst file
(http://www.dsg.cs.tcd.ie/~linehane/lyx/apa-good.bst).
Thanks
___
Éamonn Linehan,
Distributed Systems Group,
F.35 Computer Science Dept.,
Trinity College,
Dublin 2.
Phone: 00353 1 8961543
Email: [EMAIL PROTECTED]
Web: https://www.cs.tcd.ie/Eamonn.Linehan
Re: natbib APA references for multiple authors
Éamonn Linehan wrote:
When there are two or more authors on a paper and the reference is
withing brackets, the APA guidelines are that it should be (Linehan
Linehan, 2008). Its doing this, which is good. However, when the
authors are outside the brackets it should be Linehan and Linehan
(2008). The '' sign should never be used outside of brackets. So
natbib should be doing this:
\citet*{jon90} Jones, Baker, and Williams (1990)
\citep*{jon90} (Jones, Baker, Williams, 1990)
Is this something I can modify in a .bst file. Could anyone help me
with this? Im using this natbib compatible .bst file
(http://www.dsg.cs.tcd.ie/~linehane/lyx/apa-good.bst).
I don't know if this is possible. The way natbib works, it writes things
like this:
\bibitem[Author Names(Year)]{key}
to the .aux file, where they are picked up by LaTeX. At this point,
natbib knows nothing about how anything will be cited. What might work,
though, would be to re-write the \citet and \citet* commands to replace
the '' with 'and' if it's there. But I'm not at all sure how to do that.
I can think of other ways to do this, too, but they're all pretty
complicated.
Richard
Re: generic X copy-and-paste not working
M-L wrote: This version [LyX Version 1.5.2] of Lyx seems to require the Ctrl+c to copy and Ctrl+v command. Just highlight then middle mouse button [scrollwheel] or double right/left mouse click to paste into a Lyx document doesn't work in Debian testing. Using Icewm. FWIW, 1.5.3 includes some cut and paste fixes. Jürgen
Re: left justify floats?
On Thursday 17 January 2008 06:07, Helge Hafting wrote: I was hoping for a preference setting that allows printing via pdflatex instead of the usual way, because that is necessary for using microtype. But lyx currently doesn't support microtype directly so there is no need. . . Helge, So what? Microtype is only used to improve the final output; Lyx is only concerned with the on-screen user interface. Couldn't the user replace the dvips used as the printer command with a short script to run pdflatex to a temporary file, run pdf2ps on the temporary file, then send the output to the printer? Les
Re: LyX install on Fedora
Milen Ivanov wrote: Dear Abdel, I'd be interested in a more detailed comparison about the speed. It is mostly my general feeling, but I have collected some data for a rather arbitrary example. 1/ I run Linux F8 on laptop with Intel 1.7GHz and XP on Intel 1GHz (both 32bit, of course). Now, they say that both configuration should be comparable in speed because laptop configuration slows down things. Anyway even if factor of 1/2 is applied to below figures, the conclusion is still in favor of Linux. 2/ Of course, this applies to whole configuration: it may be that teTeX is faster than MikTeX, the viewer is faster and so on. So, the test is that I opened one of my files: custom, the Introduction and the User Guide, clicked DVI and PDF (after that) and measured approximately how many seconds it will take to show. OK, this means that teTeX is faster that MikTeX but this does not talk about LyX itself. I was thinking more in terms of startup time, file loading, scrolling, etc. But thanks anyway for the numbers, Abdel.
Re: Math font error on Lyx - Windows
Andre Zimmermann wrote: Thanks for finding a solution to this problem. As a brand new user to LyX I couldn't get math functions to work which was the main reason I am switching from Word, but have been stuck on this problem for about a week and was ready to quit trying to find a solution and go back to word. I was also using Times New Roman and had the same problem. Now fixed, but would be good if it didn't happen. For the record if a developer/wiz can help here... I'm on WinXP Pro with LyX 1.5.3 and MikTeX 2.6 and cannot reproduce this problem in a standard article class with Times Roman font (I don't have Times New Roman, but I think they're the same). - David Hewitt Virginia Institute of Marine Science http://www.vims.edu/fish/students/dhewitt/ -- View this message in context: http://www.nabble.com/Math-font-error-on-Lyx---Windows-tp14927537p14957798.html Sent from the LyX - Users mailing list archive at Nabble.com.
Re: Incoming 1.5.3 binaries for debian/ubuntu distributions
On Fri, Jan 18, 2008 at 03:54:22PM +, Sam Lewis wrote: Sven Hoexter [EMAIL PROTECTED] writes: Hi, Reasonable assumption. I'm considering building a package that specifies decencies. About backporting I'm not sure at all. That would be equal to a backport. :) IMHO it's easier to notice a DSA for boost and check if your boost backport is affected as well then searching in all your packages which libs they ship. I guess this means, I should compile and provide the boost lib too than, for Juergen to upload. Should I? Emilio did it already. IMHO you should do nothing at all and simply use Emilios packages. I hope that Emilio will change the dependency on texlive soon that could help some people to avoid the tetex-texlive now. I simply didn't mention his backport before because I had some hope to get a package on backports.org soon. Since it seems to be a bit more complicated to find a sponsor I'd recommend his repository until that's solved in some way or another. Main point how, much time and effort does this really take? Perhaps you can send me some relevant links off list about the issue. That depends on the package and your own skill level and how much you know about the package you're backporting. This is what I was fearing, I have no knowledge about the source and very limited skills. Then you should not distribute packages at all or try to read a little bit about Debian packaging before doing so. If you know what to do it's about 5min plus compile time. There are some hints on http://debian.ethz.ch/pub/debian-backports/utils/Backport-HOWTO.html *argh* Wrong link. Sorry, it should have been this one: http://www.backports.org/dokuwiki/doku.php?id=contribute Also, is it right, that according to this instruction LyX 1.5.3 cannot yet be build: ` 2.2.1 [...] make sure you use sources with an upstream version not higher than what is available in testing.' because testing is only at 1.5.2? http://bjorn.haxx.se/debian/testing.pl?package=lyx Does this mean, we only *now* could have a backport of LyX 1.5.3? What you could and what you should are two different things *g*. You can of course backport 1.5.3 and that's what Emilio did. ATM such a backport would not be accepted on backports.org to avoid potential version conflicts. This is hypothetical: If Lenny would be released with LyX 1.5.2 and you've a backport of 1.5.3 installed on your etch system it wouldn't work because the backport has been build with the old libs of etch and because of the higher version it would not downgrade. To avoid this problem it's a good practise to only create backports for packages that will be included in the next stable release. For some further understanding you can play around with dpkgs version-compare option to understand how the versions would interact on hypothetical upgrades. What would you say to build a real debian package following this instruction instead of checkinstall: http://www.debian-administration.org/articles/336 I would consider this in light of you convincing argument, as a reasonable compromise. Building real Debian packages is called backporting in this case. You don't have to recreate the whole package because you can base it on the work already done. Add a deb-src line for unstable to your sources.list and apt-get update apt-get source lyx. Cheers, Sven -- If God passed a mic to me to speak I'd say stay in bed, world Sleep in peace [The Cardigans - 03:45: No sleep]
RE: Re: LyX install on Fedora
Dear Abdel, I'd be interested in a more detailed comparison about the speed. It is mostly my general feeling, but I have collected some data for a rather arbitrary example. 1/ I run Linux F8 on laptop with Intel 1.7GHz and XP on Intel 1GHz (both 32bit, of course). Now, they say that both configuration should be comparable in speed because laptop configuration slows down things. Anyway even if factor of 1/2 is applied to below figures, the conclusion is still in favor of Linux. 2/ Of course, this applies to whole configuration: it may be that teTeX is faster than MikTeX, the viewer is faster and so on. So, the test is that I opened one of my files: custom, the Introduction and the User Guide, clicked DVI and PDF (after that) and measured approximately how many seconds it will take to show. The results are: Linux: DVI PDF Custom 8 3 Introduction15 4 User Guide 20 10 Windows: DVI PDF Custom 21 12 Introduction35 14 User Guide more than 60s I do not know if this info is useful for you, but anyway. Best regards, Milen -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Abdelrazak Younes Sent: Tuesday, January 15, 2008 4:10 PM To: lyx-users@lists.lyx.org Subject: Re: LyX install on Fedora Milen Ivanov wrote: From what I can see so far, LyX on Linux is clearly faster than LyX on Windows. I'd be interested in a more detailed comparison about the speed. Abdel.
Re: Incoming 1.5.3 binaries for debian/ubuntu distributions
Sven Hoexter [EMAIL PROTECTED] writes: [...] Building real Debian packages is called backporting in this case. You don't have to recreate the whole package because you can base it on the work already done. Add a deb-src line for unstable to your sources.list and apt-get update apt-get source lyx. Great! Thanks very much. :-) Cheers, Sam
Re: Math font error on Lyx - Windows
Thanks for finding a solution to this problem. As a brand new user to LyX I couldn't get math functions to work which was the main reason I am switching from Word, but have been stuck on this problem for about a week and was ready to quit trying to find a solution and go back to word. I was also using Times New Roman and had the same problem. Now fixed, but would be good if it didn't happen. Andre
pitfalls with search paths
Hi,
I just discovered a pitfall (bug, inconsistency or undocumented feature ?) in
LyX 1.5.3 under XP (haven't tried under linux yet)
I normally use a preamble include file, located in the same directory as the
main document, which does the main Documents settings. So my normal preambel
entry in the LyX-file just says:
\input{preamble-inc}
where the inclusion from the local directory is the normal TeX behavior.
Unfortunately, as i have the preamble-inc together with additional styles in
one cvs-project another version of that file also exists in the tex-search
paths.
The - dvi compilation from LyX now uses this version, whereas the latex export
and external compilation works as expected.
The relevant diff between the two log files is:
-Class scrbook Info: longtable captions redefined on input line 14.
- (preamble-inc.tex
+Class scrbook Info: longtable captions redefined on input line 16.
+(C:\localtexmf\tex\latex\ubastyle\preamble-inc.tex
(C:\texmf\tex\latex\base\ift+hen.sty
BTW
if I include the preamble with
\input{./preamble-inc}
it also works from within LyX.
I'd propose to make the LyX / TeX behavior consistent.
Greetings from Berlin
--
Dr. Joachim Heidemeier
c/o Umweltbundesamt FG II 2.2
Tel.: +49340 2103-2780
eMail: [EMAIL PROTECTED]
Re: Incoming 1.5.3 binaries for debian/ubuntu distributions
On Thu, Jan 17, 2008 at 10:26:48PM +, Sam Lewis wrote: Sven Hoexter [EMAIL PROTECTED] writes: Moin Sam, a) The social/trust problem [...] What solution could you think of? Does the development team use key? Well the Debian project has a known web of trust based on key exchange and extensive peer review of packages. Since you don't have source packages there is nothing to review. That's again a pro of the backports.org infrastructure where you've clean build enviroments supported by trusted people and signed binary packages. That's something you can't even provide without proper packaging. But in the end the trust thing is a personal decision to be made by everyone on their own. b) Technical problems I guess this is a specific debian issue you're raising and might differ at each distro (my apologies to for the possibly off-list-topic discussion here). Not really. The examples are Debian specific (well and in this case Ubuntu specific aswell because they use the same packages) but the problems can occure within any other system with package management aswell. ba) You're breaking the upgrade path. [...] True, if you are using checkinstall binaries and (in the unlikely event of) your stable debian release upgrading to this specific lyx release, libraries might most probably not match. All you need to do is to reinstall, through the comfort of checkinstall the offending lyx package. sudo dpkg -r lyx And then there is the user who doesn't remember what he did in good faith to his system. A year later he upgrades to the next stable releases und this fscking update broke his nice LyX installation working for fine for the last year. So who's responsible for the non working package? Must be the Debian guys who just prepared the new stable release which seems to ship a broken package. It's hard to make sure that everyone is able to track such subtle changes he doesn't completly understand and it's hard for the developers on the other side to find out what happened. The frontend tools like apt-get where implemented to ease the system management for everyone but they can not work if you install bogus packages. bb) Maintainer scripts have a reason For example somebody doing QA work recently noticed that we've left an /etc/lyxrc file on the system with the 1.4.x-1.5.x upgrade which should not happen. So we're now cleaning up behind us with a maintainer script which is of course bound to special versions. You'll break if you install your current package an try to upgrade it at a later point to a Debian version again. In this case it's only an unused old file but it could of course be anything more important. So how about a recommendation that users when installing a checkinstall binary should uses the following command line: sudo dpkg -r lyx sudo dpkg -i lyx_1.5.3-1_i386_etch.deb sudo apt-get -f install Here you missed the point. The error (actually an error we made in the Debian package) is in the 1.4.x packages and will be resolved with a maintainer script in the latest revision of the 1.5.x package. In this special case the file will be left on the system even if you purge the package. So your proposed fiddling won't solve anything. Additionaly it won't solve the latex-beamer issue but it won't cause bigger problems because you're installing into /usr/local. At least I hope that it won't cause trouble but I didn't test if it would confuse latex in anyway or not. bc) Dependencies don't exist for fun. See above. The toolchain with dpkg and apt were build to resolve the dependencies for you and you're ignoring that part completly. Installing the checkinstall package you can even remove latex (maybe some clean up mechanism even suggest to remove them because they look unused now) without anything complaining. Bds..) i386? And where is the rest? Yep that would be good, but to make it clear, this is an instrumental move. I'm not a developer or maintainer; I am a social scientist, who uses LyX on a daily basis on computers that happen to be i386. For the benefit of others, I am providing my own compiled binaries, for others who don't have the knowledge or the resources to compile the source themselves. I might count that in as the only small benefit. I might be one of the rare cases of users who used one installation for seven years with several hardware changes. If you'd like to reinstall a clean system with every stable release of your distribution of choice go ahead and use broken packages. Impressive -- this deserves applause! Don't get my wrong, your concerns are valid, but there are many pragmatic and practical reason as to why people compile their own software rather than waiting for a backport or using a rather old version of it. What I don't get is why you waste your time with this broken checkinstall crap? It's only a very small step you've to make to get the source package and create a backport.
Re: generic X copy-and-paste not working
On Fri, 18 Jan 2008, G. Milde shared this with us all: --} On 17.01.08, Jeremy C. Reed wrote: --} Normally, I can highlight text in a terminal and paste it with a --} middle-click. In LyX, usually I can get to it with Edit - Paste Special. --} (I can copy-and-paste fine in my xterms.) --} --} In my LyX, the Paste Special choices are shaded out and not clickable. --} --} This is LyX 1.5.2 on NetBSD. I am not running any clipboard utility. --} --} Any ideas why I can't paste into LyX? --} --} I did a test on my LyX 1.5.3 on Debian/testing++ with XFCE4 and --} xfce4-clipman and got very strange results: --} --} A newly opened LyX (first time after starting the Computer) with a new --} buffer did not accept any mouse-pasting (middle click) from xterms or xjed. --} (Whether with a simple middel click or via EditPaste did not matter.) --} --} Just typing some text in the LyX window did not change this behaviour. --} --} After marking some text (with mouse) and Ctrl-C, I could paste this text --} with a middle-mouse click. --} --} Now also pasting text from other applications works fine. --} --} Closing LyX and opening a new one: The second time pasting works from the --} start. --} --} Any clues? --} --} Guenter --} This version [LyX Version 1.5.2] of Lyx seems to require the Ctrl+c to copy and Ctrl+v command. Just highlight then middle mouse button [scrollwheel] or double right/left mouse click to paste into a Lyx document doesn't work in Debian testing. Using Icewm. If there is a selected passage in any other program, prior to starting Lyx, you can just copy with the double mouse or scrollwheel click. It seems that as Lyx loads up, after something has been highlighted it works because Lyx gathers that information from the clipboard, which copies highlighted text. This may not be the case using KDE? -- Registered Linux User:- 329524 ** When it's over, I want to say: all my life I was a bride married to amazement. I was the bridegroom, taking the world into my arms . . . --- MARY OLIVER Debian - Just the best way to do magic.
Re: Figures and Schemes
Andreas Zumbuehl wrote: I am a chemist, trying to work with Lyx. I would need to distinguish between 'figure' captions and 'scheme' captions.However, if I use insert - float I can only choose 'Figure'. How can I add a command allowing me to insert -float - scheme ? 1.) create a file myfloats.inc with the following content: Format 4 Float Type scheme GuiName Scheme Placement tbp Extension los NumberWithin none Style plain ListName List of Schemes LaTeXBuiltin false End 2.) Save it in you LyX user directory (see About-LyX for where this is). 3.) Copy the layout file of the class you're using to the user directory as well, and put in the following line at the end Input myfloats.inc HTH, Jürgen
Re: Incoming 1.5.3 binaries for debian/ubuntu distributions
Sven Hoexter [EMAIL PROTECTED] writes: Hi Sven, I'll keep it on list because some of the topics might help people eventually creating Ubuntu backports to do it right. Fine! [...] Again, what kind of LyX users are there? Why link LyX to a specific latex? Would there be anyone who does not know the relationship between LyX and latex, I wonder? I should know that I need libc to use some software or shouldn't I? If you question the need of explicit dependencies you can question the whole model of creating ready to intall system distributions. Hmm, libc definitely not! Libraries should be explicitly linked, no doubt. Not sure about the linking a whole independent programme like latex. Btw, you might like to read the following discussion on checkinstall stating that some consider the absence of dependencies in checkinstall packages as *either a bug or a feature* ! http://www.debian-administration.org/articles/147 I would formulate it a bit different. Depending on your own skills and intention you can in some cases consider it as feature. In the case of distributing such packages on the internet to an unknown mass of people with a very different level of knowledge it's IMO a disavantage. Reasonable assumption. I'm considering building a package that specifies decencies. About backporting I'm not sure at all. [...] Of course you've to support your backports in case of security problems in the version you've backported. It's the same for the checkinstall stuff. You're pulling in a second, isolated, version of boost btw that needs to be patched as well in case of problems with boost. That's a very bad thing and I'm happy that we can use with the external boost packages provide within Debian with the next stable release. For a current backport you've to backport libboost aswell. IMHO it's easier to notice a DSA for boost and check if your boost backport is affected as well then searching in all your packages which libs they ship. I guess this means, I should compile and provide the boost lib too than, for Juergen to upload. Should I? Main point how, much time and effort does this really take? Perhaps you can send me some relevant links off list about the issue. That depends on the package and your own skill level and how much you know about the package you're backporting. This is what I was fearing, I have no knowledge about the source and very limited skills. In most cases it's just recompiling in a stable chroot. In case of LyX you've to recompile boost first with a proper version number so that it will be replaced with the next stable release that ships the same version. Then you've to install this new boost version in a chroot and modify the LyX source package a bit. You might want to interdiff the .diff.gz from sid against Emilios .diff.gz. It's actually rolling back two versioned dependencies, removing a dh_icons call which would require a new version of debhelper scripts and at least lenny to be usefull at all. If you like you'll pull in the tetex stuff as alternative to texlive and then you only need to build the package. If you know what to do it's about 5min plus compile time. There are some hints on http://debian.ethz.ch/pub/debian-backports/utils/Backport-HOWTO.html Also, is it right, that according to this instruction LyX 1.5.3 cannot yet be build: ` 2.2.1 [...] make sure you use sources with an upstream version not higher than what is available in testing.' because testing is only at 1.5.2? http://bjorn.haxx.se/debian/testing.pl?package=lyx Does this mean, we only *now* could have a backport of LyX 1.5.3? What would you say to build a real debian package following this instruction instead of checkinstall: http://www.debian-administration.org/articles/336 I would consider this in light of you convincing argument, as a reasonable compromise. Cheers, Sam
Re: Math font error on Lyx - Windows
Andrew Barr wrote: I was using Times Roman font. I changed the font settings to default, and all the math comes through fine. So...I guess that problem is solved for the moment. Sorry for the dumb question. I don't think this is a dumb question. Something unusual is happening that should not be happening. Unfortunately, I am not the person to fix it. However... I think Computer Modern is the default, but I can't actually recall how to check what the defaults are. I recall changing some font stuff around and Saving as Default in the past. I haven't gotten any errors, but it would be nice to be able to go to a file or window and see the current defaults (rather than just seeing Default displayed without knowing what it is). Anyone know how to get that? I rambled through all the documentation and didn't come up with anything. - David Hewitt Virginia Institute of Marine Science http://www.vims.edu/fish/students/dhewitt/ -- View this message in context: http://www.nabble.com/Math-font-error-on-Lyx---Windows-tp14927537p14950994.html Sent from the LyX - Users mailing list archive at Nabble.com.
Re: Incoming 1.5.3 binaries for debian/ubuntu distributions
On Fri, Jan 18, 2008 at 01:06:27PM +, Sam Lewis wrote: Sven Hoexter [EMAIL PROTECTED] writes: Hi Sam, I'll keep it on list because some of the topics might help people eventually creating Ubuntu backports to do it right. And then there is the user who doesn't remember what he did in good faith to his system. A year later he upgrades to the next stable releases und this fscking update broke his nice LyX installation working for fine for the last year. So who's responsible for the non [...] What kind of LyX user (who opts for the latest version of LyX) do you envisage? All the packages clearly state in the README file that they are checkinstall. How many users who possibly find the package via google or on the ftp site know what that means? I doubt that many know or even care. I even doubt that everyone can follow what we're discussing here and they should not need to understand it. The toolchain with dpkg and apt were build to resolve the dependencies for you and you're ignoring that part completly. Installing the checkinstall package you can even remove latex (maybe some clean up mechanism even suggest to remove them because they look unused now) without anything complaining. That's what I was trying to say. You might be surprised I've seen people running LyX on a tiny system without any latex for the purpose of writing and managing lyx files. I personally have used TexLive for years and was precisely only able to do this as I complied source myself rather than using an official LyX version linked to tetex in some distro. Those people wouldn't install the distribution packages anyway. Regarding the tex version thingy etch is the last Debian stable release with tetex and texlive. So in a perfect world everyone would switch to texlive now. Since nobody should be forced to replace his tetex installation now a backport should readd the tetex alternative for texlive. I did this in my own backport proposed for backports.org already but that's not so important here. Again, what kind of LyX users are there? Why link LyX to a specific latex? Would there be anyone who does not know the relationship between LyX and latex, I wonder? I should know that I need libc to use some software or shouldn't I? If you question the need of explicit dependencies you can question the whole model of creating ready to intall system distributions. Btw, you might like to read the following discussion on checkinstall stating that some consider the absence of dependencies in checkinstall packages as *either a bug or a feature* ! http://www.debian-administration.org/articles/147 I would formulate it a bit different. Depending on your own skills and intention you can in some cases consider it as feature. In the case of distributing such packages on the internet to an unknown mass of people with a very different level of knowledge it's IMO a disavantage. What I don't get is why you waste your time with this broken checkinstall crap? It's only a very small step you've to make to get the source package and create a backport. The Debian source packages are free for everyone to use (that's essentialy what Ubuntu and other distributions are based upon). I thought I was saving time, by just typing checkinstall rather make install. It's more about dpkg-buildpackage then checkinstall vs. make install. Of course you might save some time but you pay for that with the risc of some more or less subtle problems. So please use the source packages and build proper backports instead of punching your package management system right in the face! One and a half thing: Backporting always presents a slight security issues, which can be minimised by backporting as few as possible decencies, if understand this correctly (see http://debian.ethz.ch/pub/debian-backports/utils/Backport-HOWTO.html ). Of course you've to support your backports in case of security problems in the version you've backported. It's the same for the checkinstall stuff. You're pulling in a second, isolated, version of boost btw that needs to be patched as well in case of problems with boost. That's a very bad thing and I'm happy that we can use with the external boost packages provide within Debian with the next stable release. For a current backport you've to backport libboost aswell. IMHO it's easier to notice a DSA for boost and check if your boost backport is affected as well then searching in all your packages which libs they ship. Main point how, much time and effort does this really take? Perhaps you can send me some relevant links off list about the issue. That depends on the package and your own skill level and how much you know about the package you're backporting. In most cases it's just recompiling in a stable chroot. In case of LyX you've to recompile boost first with a proper version number so that it will be replaced with the next stable release that ships the same version.
Figures and Schemes
Hello! I am a chemist, trying to work with Lyx. I would need to distinguish between 'figure' captions and 'scheme' captions.However, if I use insert - float I can only choose 'Figure'. How can I add a command allowing me to insert -float - scheme ? Thank you very much for your help! Andreas
Re: Incoming 1.5.3 binaries for debian/ubuntu distributions
Sven Hoexter [EMAIL PROTECTED] writes: On Thu, Jan 17, 2008 at 10:26:48PM +, Sam Lewis wrote: Sven Hoexter [EMAIL PROTECTED] writes: Moin moin, a) The social/trust problem [...] What solution could you think of? Does the development team use key? Well the Debian project has a known web of trust based on key exchange Sensible! b) Technical problems [...] ba) You're breaking the upgrade path. [...] True, if you are using checkinstall binaries and (in the unlikely event of) your stable debian release upgrading to this specific lyx release, libraries might most probably not match. All you need to do is to reinstall, through the comfort of checkinstall the offending lyx package. sudo dpkg -r lyx And then there is the user who doesn't remember what he did in good faith to his system. A year later he upgrades to the next stable releases und this fscking update broke his nice LyX installation working for fine for the last year. So who's responsible for the non [...] What kind of LyX user (who opts for the latest version of LyX) do you envisage? All the packages clearly state in the README file that they are checkinstall. [...] bb) Maintainer scripts have a reason For example somebody doing QA work recently noticed that we've left an /etc/lyxrc file on the system with the 1.4.x-1.5.x upgrade which should not happen. So we're now cleaning up behind us with a maintainer script which is of course bound to special versions. You'll break if you install your current package an try to upgrade it at a later point to a Debian version again. In this case it's only an unused old file but it could of course be anything more important. So how about a recommendation that users when installing a checkinstall binary should uses the following command line: sudo dpkg -r lyx sudo dpkg -i lyx_1.5.3-1_i386_etch.deb sudo apt-get -f install Here you missed the point. The error (actually an error we made in the Debian package) is in the 1.4.x packages and will be resolved with a maintainer script in the latest revision of the 1.5.x package. In this special case the file will be left on the system even if you purge the package. So your proposed fiddling won't solve anything. OK, I see. [...] bc) Dependencies don't exist for fun. See above. The toolchain with dpkg and apt were build to resolve the dependencies for you and you're ignoring that part completly. Installing the checkinstall package you can even remove latex (maybe some clean up mechanism even suggest to remove them because they look unused now) without anything complaining. That's what I was trying to say. You might be surprised I've seen people running LyX on a tiny system without any latex for the purpose of writing and managing lyx files. I personally have used TexLive for years and was precisely only able to do this as I complied source myself rather than using an official LyX version linked to tetex in some distro. Again, what kind of LyX users are there? Why link LyX to a specific latex? Would there be anyone who does not know the relationship between LyX and latex, I wonder? Btw, you might like to read the following discussion on checkinstall stating that some consider the absence of dependencies in checkinstall packages as *either a bug or a feature* ! http://www.debian-administration.org/articles/147 Bds..) i386? And where is the rest? Yep that would be good, but to make it clear, this is an instrumental move. I'm not a developer or maintainer; I am a social scientist, who uses LyX on a daily basis on computers that happen to be i386. For the benefit of others, I am providing my own compiled binaries, for others who don't have the knowledge or the resources to compile the source themselves. I might count that in as the only small benefit. Thanks! [...] What I don't get is why you waste your time with this broken checkinstall crap? It's only a very small step you've to make to get the source package and create a backport. The Debian source packages are free for everyone to use (that's essentialy what Ubuntu and other distributions are based upon). I thought I was saving time, by just typing checkinstall rather make install. The prefered solution for Debian would be to find a DD willing to sponsor the backports.org uploads. Per has no time and interested in the backports stuff and I'm not a DD yet. I guess something similar would be needed for Ubuntu backports but I'm not involved there. It seems that they've a few more releases in work which should be supported with backports but that's a manpower issue. So please use the source packages and build proper backports instead of punching your package management system right in the face! One and a half thing: Backporting always presents a slight security issues, which can be minimised by backporting as few as possible decencies, if understand
natbib APA references for multiple authors
When there are two or more authors on a paper and the reference is
withing brackets, the APA guidelines are that it should be (Linehan
Linehan, 2008). Its doing this, which is good. However, when the
authors are outside the brackets it should be Linehan and Linehan
(2008). The '' sign should never be used outside of brackets. So
natbib should be doing this:
\citet*{jon90} Jones, Baker, and Williams (1990)
\citep*{jon90} (Jones, Baker, Williams, 1990)
Is this something I can modify in a .bst file. Could anyone help me
with this? Im using this natbib compatible .bst file
(http://www.dsg.cs.tcd.ie/~linehane/lyx/apa-good.bst).
Thanks
___
Éamonn Linehan,
Distributed Systems Group,
F.35 Computer Science Dept.,
Trinity College,
Dublin 2.
Phone: 00353 1 8961543
Email: [EMAIL PROTECTED]
Web: https://www.cs.tcd.ie/Eamonn.Linehan
Re: natbib APA references for multiple authors
Éamonn Linehan wrote:
When there are two or more authors on a paper and the reference is
withing brackets, the APA guidelines are that it should be (Linehan
Linehan, 2008). Its doing this, which is good. However, when the
authors are outside the brackets it should be Linehan and Linehan
(2008). The '' sign should never be used outside of brackets. So
natbib should be doing this:
\citet*{jon90} Jones, Baker, and Williams (1990)
\citep*{jon90} (Jones, Baker, Williams, 1990)
Is this something I can modify in a .bst file. Could anyone help me
with this? Im using this natbib compatible .bst file
(http://www.dsg.cs.tcd.ie/~linehane/lyx/apa-good.bst).
I don't know if this is possible. The way natbib works, it writes things
like this:
\bibitem[Author Names(Year)]{key}
to the .aux file, where they are picked up by LaTeX. At this point,
natbib knows nothing about how anything will be cited. What might work,
though, would be to re-write the \citet and \citet* commands to replace
the '' with 'and' if it's there. But I'm not at all sure how to do that.
I can think of other ways to do this, too, but they're all pretty
complicated.
Richard
Re: generic X copy-and-paste not working
M-L wrote: This version [LyX Version 1.5.2] of Lyx seems to require the Ctrl+c to copy and Ctrl+v command. Just highlight then middle mouse button [scrollwheel] or double right/left mouse click to paste into a Lyx document doesn't work in Debian testing. Using Icewm. FWIW, 1.5.3 includes some cut and paste fixes. Jürgen
Re: left justify floats?
On Thursday 17 January 2008 06:07, Helge Hafting wrote: I was hoping for a preference setting that allows printing via pdflatex instead of the usual way, because that is necessary for using microtype. But lyx currently doesn't support microtype directly so there is no need. . . Helge, So what? Microtype is only used to improve the final output; Lyx is only concerned with the on-screen user interface. Couldn't the user replace the dvips used as the printer command with a short script to run pdflatex to a temporary file, run pdf2ps on the temporary file, then send the output to the printer? Les
Re: LyX install on Fedora
Milen Ivanov wrote: Dear Abdel, I'd be interested in a more detailed comparison about the speed. It is mostly my general feeling, but I have collected some data for a rather arbitrary example. 1/ I run Linux F8 on laptop with Intel 1.7GHz and XP on Intel 1GHz (both 32bit, of course). Now, they say that both configuration should be comparable in speed because laptop configuration slows down things. Anyway even if factor of 1/2 is applied to below figures, the conclusion is still in favor of Linux. 2/ Of course, this applies to whole configuration: it may be that teTeX is faster than MikTeX, the viewer is faster and so on. So, the test is that I opened one of my files: custom, the Introduction and the User Guide, clicked DVI and PDF (after that) and measured approximately how many seconds it will take to show. OK, this means that teTeX is faster that MikTeX but this does not talk about LyX itself. I was thinking more in terms of startup time, file loading, scrolling, etc. But thanks anyway for the numbers, Abdel.
Re: Math font error on Lyx - Windows
Andre Zimmermann wrote: Thanks for finding a solution to this problem. As a brand new user to LyX I couldn't get math functions to work which was the main reason I am switching from Word, but have been stuck on this problem for about a week and was ready to quit trying to find a solution and go back to word. I was also using Times New Roman and had the same problem. Now fixed, but would be good if it didn't happen. For the record if a developer/wiz can help here... I'm on WinXP Pro with LyX 1.5.3 and MikTeX 2.6 and cannot reproduce this problem in a standard article class with Times Roman font (I don't have Times New Roman, but I think they're the same). - David Hewitt Virginia Institute of Marine Science http://www.vims.edu/fish/students/dhewitt/ -- View this message in context: http://www.nabble.com/Math-font-error-on-Lyx---Windows-tp14927537p14957798.html Sent from the LyX - Users mailing list archive at Nabble.com.
Re: Incoming 1.5.3 binaries for debian/ubuntu distributions
On Fri, Jan 18, 2008 at 03:54:22PM +, Sam Lewis wrote: Sven Hoexter [EMAIL PROTECTED] writes: Hi, Reasonable assumption. I'm considering building a package that specifies decencies. About backporting I'm not sure at all. That would be equal to a backport. :) IMHO it's easier to notice a DSA for boost and check if your boost backport is affected as well then searching in all your packages which libs they ship. I guess this means, I should compile and provide the boost lib too than, for Juergen to upload. Should I? Emilio did it already. IMHO you should do nothing at all and simply use Emilios packages. I hope that Emilio will change the dependency on texlive soon that could help some people to avoid the tetex-texlive now. I simply didn't mention his backport before because I had some hope to get a package on backports.org soon. Since it seems to be a bit more complicated to find a sponsor I'd recommend his repository until that's solved in some way or another. Main point how, much time and effort does this really take? Perhaps you can send me some relevant links off list about the issue. That depends on the package and your own skill level and how much you know about the package you're backporting. This is what I was fearing, I have no knowledge about the source and very limited skills. Then you should not distribute packages at all or try to read a little bit about Debian packaging before doing so. If you know what to do it's about 5min plus compile time. There are some hints on http://debian.ethz.ch/pub/debian-backports/utils/Backport-HOWTO.html *argh* Wrong link. Sorry, it should have been this one: http://www.backports.org/dokuwiki/doku.php?id=contribute Also, is it right, that according to this instruction LyX 1.5.3 cannot yet be build: ` 2.2.1 [...] make sure you use sources with an upstream version not higher than what is available in testing.' because testing is only at 1.5.2? http://bjorn.haxx.se/debian/testing.pl?package=lyx Does this mean, we only *now* could have a backport of LyX 1.5.3? What you could and what you should are two different things *g*. You can of course backport 1.5.3 and that's what Emilio did. ATM such a backport would not be accepted on backports.org to avoid potential version conflicts. This is hypothetical: If Lenny would be released with LyX 1.5.2 and you've a backport of 1.5.3 installed on your etch system it wouldn't work because the backport has been build with the old libs of etch and because of the higher version it would not downgrade. To avoid this problem it's a good practise to only create backports for packages that will be included in the next stable release. For some further understanding you can play around with dpkgs version-compare option to understand how the versions would interact on hypothetical upgrades. What would you say to build a real debian package following this instruction instead of checkinstall: http://www.debian-administration.org/articles/336 I would consider this in light of you convincing argument, as a reasonable compromise. Building real Debian packages is called backporting in this case. You don't have to recreate the whole package because you can base it on the work already done. Add a deb-src line for unstable to your sources.list and apt-get update apt-get source lyx. Cheers, Sven -- If God passed a mic to me to speak I'd say stay in bed, world Sleep in peace [The Cardigans - 03:45: No sleep]
RE: Re: LyX install on Fedora
Dear Abdel, I'd be interested in a more detailed comparison about the speed. It is mostly my general feeling, but I have collected some data for a rather arbitrary example. 1/ I run Linux F8 on laptop with Intel 1.7GHz and XP on Intel 1GHz (both 32bit, of course). Now, they say that both configuration should be comparable in speed because laptop configuration slows down things. Anyway even if factor of 1/2 is applied to below figures, the conclusion is still in favor of Linux. 2/ Of course, this applies to whole configuration: it may be that teTeX is faster than MikTeX, the viewer is faster and so on. So, the test is that I opened one of my files: custom, the Introduction and the User Guide, clicked DVI and PDF (after that) and measured approximately how many seconds it will take to show. The results are: Linux: DVI PDF Custom 8 3 Introduction15 4 User Guide 20 10 Windows: DVI PDF Custom 21 12 Introduction35 14 User Guide more than 60s I do not know if this info is useful for you, but anyway. Best regards, Milen -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Abdelrazak Younes Sent: Tuesday, January 15, 2008 4:10 PM To: lyx-users@lists.lyx.org Subject: Re: LyX install on Fedora Milen Ivanov wrote: From what I can see so far, LyX on Linux is clearly faster than LyX on Windows. I'd be interested in a more detailed comparison about the speed. Abdel.
Re: Incoming 1.5.3 binaries for debian/ubuntu distributions
Sven Hoexter [EMAIL PROTECTED] writes: [...] Building real Debian packages is called backporting in this case. You don't have to recreate the whole package because you can base it on the work already done. Add a deb-src line for unstable to your sources.list and apt-get update apt-get source lyx. Great! Thanks very much. :-) Cheers, Sam
Re: Math font error on Lyx - Windows
Thanks for finding a solution to this problem. As a brand new user to LyX I couldn't get math functions to work which was the main reason I am switching from Word, but have been stuck on this problem for about a week and was ready to quit trying to find a solution and go back to word. I was also using Times New Roman and had the same problem. Now fixed, but would be good if it didn't happen. Andre
pitfalls with search paths
Hi,
I just discovered a pitfall (bug, inconsistency or undocumented feature ?) in
LyX 1.5.3 under XP (haven't tried under linux yet)
I normally use a preamble include file, located in the same directory as the
main document, which does the main Documents settings. So my normal preambel
entry in the LyX-file just says:
\input{preamble-inc}
where the inclusion from the local directory is the normal TeX behavior.
Unfortunately, as i have the preamble-inc together with additional styles in
one cvs-project another version of that file also exists in the tex-search
paths.
The -> dvi compilation from LyX now uses this version, whereas the latex export
and external compilation works as expected.
The relevant diff between the two log files is:
-Class scrbook Info: longtable captions redefined on input line 14.
- (preamble-inc.tex
+Class scrbook Info: longtable captions redefined on input line 16.
+(C:\localtexmf\tex\latex\ubastyle\preamble-inc.tex
(C:\texmf\tex\latex\base\ift+hen.sty
BTW
if I include the preamble with
\input{./preamble-inc}
it also works from within LyX.
I'd propose to make the LyX / TeX behavior consistent.
Greetings from Berlin
--
Dr. Joachim Heidemeier
c/o Umweltbundesamt FG II 2.2
Tel.: +49340 2103-2780
eMail: [EMAIL PROTECTED]
Re: Incoming 1.5.3 binaries for debian/ubuntu distributions
On Thu, Jan 17, 2008 at 10:26:48PM +, Sam Lewis wrote: > Sven Hoexter <[EMAIL PROTECTED]> writes: Moin Sam, > > a) The social/trust problem [...] > What solution could you think of? Does the development team use key? Well the Debian project has a known web of trust based on key exchange and extensive peer review of packages. Since you don't have source packages there is nothing to review. That's again a pro of the backports.org infrastructure where you've clean build enviroments supported by trusted people and signed binary packages. That's something you can't even provide without proper packaging. But in the end the trust thing is a personal decision to be made by everyone on their own. > > b) Technical problems > > I guess this is a specific debian issue you're raising and might differ > at each distro (my apologies to for the possibly off-list-topic > discussion here). Not really. The examples are Debian specific (well and in this case Ubuntu specific aswell because they use the same packages) but the problems can occure within any other system with package management aswell. > > ba) You're breaking the upgrade path. [...] > True, if you are using checkinstall binaries and (in the unlikely event > of) your stable debian release upgrading to this specific lyx release, > libraries might most probably not match. All you need to do is to > reinstall, through the comfort of checkinstall the offending lyx > package. > > sudo dpkg -r lyx And then there is the user who doesn't remember what he did in good faith to his system. A year later he upgrades to the next stable releases und this fscking update broke his nice LyX installation working for fine for the last year. So who's responsible for the non working package? Must be the Debian guys who just prepared the new stable release which seems to ship a broken package. It's hard to make sure that everyone is able to track such subtle changes he doesn't completly understand and it's hard for the developers on the other side to find out what happened. The frontend tools like apt-get where implemented to ease the system management for everyone but they can not work if you install bogus packages. > > bb) Maintainer scripts have a reason > > For example somebody doing QA work recently noticed that we've left > > an /etc/lyxrc file on the system with the 1.4.x->1.5.x upgrade which > > should not happen. So we're now cleaning up behind us with a maintainer > > script which is of course bound to special versions. You'll break if > > you install your current package an try to upgrade it at a later point > > to a Debian version again. In this case it's only an unused old file > > but it could of course be anything more important. > > So how about a recommendation that users when installing a checkinstall > binary should uses the following command line: > > sudo dpkg -r lyx && sudo dpkg -i lyx_1.5.3-1_i386_etch.deb && sudo apt-get -f > install Here you missed the point. The error (actually an error we made in the Debian package) is in the 1.4.x packages and will be resolved with a maintainer script in the latest revision of the 1.5.x package. In this special case the file will be left on the system even if you purge the package. So your proposed fiddling won't solve anything. Additionaly it won't solve the latex-beamer issue but it won't cause bigger problems because you're installing into /usr/local. At least I hope that it won't cause trouble but I didn't test if it would confuse latex in anyway or not. > > bc) Dependencies don't exist for fun. > > See above. The toolchain with dpkg and apt were build to resolve the dependencies for you and you're ignoring that part completly. Installing the checkinstall package you can even remove latex (maybe some clean up mechanism even suggest to remove them because they look unused now) without anything complaining. > > Bds..) i386? And where is the rest? > > Yep that would be good, but to make it clear, this is an instrumental move. > I'm > not a developer or maintainer; I am a social scientist, who uses LyX on a > daily > basis on computers that happen to be i386. For the benefit of others, I am > providing my own compiled binaries, for others who don't have the knowledge or > the resources to compile the source themselves. I might count that in as the only small benefit. > > I might be one of the rare cases of users who used one installation for > > seven years with several hardware changes. If you'd like to reinstall > > a clean system with every stable release of your distribution of choice > > go ahead and use broken packages. > > Impressive -- this deserves applause! Don't get my wrong, your concerns > are valid, but there are many pragmatic and practical reason as to why > people compile their own software rather than waiting for a backport or > using a rather old version of it. What I don't get is why you waste your time with this broken checkinstall crap? It's only a very
Re: generic X copy-and-paste not working
On Fri, 18 Jan 2008, G. Milde shared this with us all: >--} On 17.01.08, Jeremy C. Reed wrote: >--} > Normally, I can highlight text in a terminal and paste it with a >--} > middle-click. In LyX, usually I can get to it with Edit -> Paste > Special. --} > (I can copy-and-paste fine in my xterms.) >--} >--} > In my LyX, the Paste Special choices are shaded out and not clickable. >--} >--} > This is LyX 1.5.2 on NetBSD. I am not running any clipboard utility. >--} >--} > Any ideas why I can't paste into LyX? >--} >--} I did a test on my LyX 1.5.3 on Debian/testing++ with XFCE4 and >--} xfce4-clipman and got very strange results: >--} >--} A newly opened LyX (first time after starting the Computer) with a new >--} buffer did not accept any mouse-pasting (middle click) from xterms or > xjed. --} (Whether with a simple middel click or via Edit>Paste did not > matter.) --} >--} Just typing some text in the LyX window did not change this behaviour. >--} >--} After marking some text (with mouse) and Ctrl-C, I could paste this text >--} with a middle-mouse click. >--} >--} Now also pasting text from other applications works fine. >--} >--} Closing LyX and opening a new one: The second time pasting works from > the --} start. >--} >--} Any clues? >--} >--} Guenter >--} This version [LyX Version 1.5.2] of Lyx seems to require the Ctrl+c to copy and Ctrl+v command. Just highlight then middle mouse button [scrollwheel] or double right/left mouse click to paste into a Lyx document doesn't work in Debian testing. Using Icewm. If there is a selected passage in any other program, prior to starting Lyx, you can just copy with the double mouse or scrollwheel click. It seems that as Lyx loads up, after something has been highlighted it works because Lyx gathers that information from the clipboard, which copies highlighted text. This may not be the case using KDE? -- Registered Linux User:- 329524 ** When it's over, I want to say: all my life I was a bride married to amazement. I was the bridegroom, taking the world into my arms . . . --- MARY OLIVER <<<>>> Debian - Just the best way to do magic.
Re: Figures and Schemes
Andreas Zumbuehl wrote: > I am a chemist, trying to work with Lyx. I would need to distinguish > between 'figure' captions and 'scheme' captions.However, if I use insert > -> float I can only choose 'Figure'. How can I add a command allowing me > to insert ->float -> scheme ? 1.) create a file "myfloats.inc" with the following content: Format 4 Float Type scheme GuiName Scheme Placement tbp Extension los NumberWithin none Style plain ListName "List of Schemes" LaTeXBuiltin false End 2.) Save it in you LyX user directory (see About->LyX for where this is). 3.) Copy the layout file of the class you're using to the user directory as well, and put in the following line at the end Input myfloats.inc HTH, Jürgen
Re: Incoming 1.5.3 binaries for debian/ubuntu distributions
Sven Hoexter <[EMAIL PROTECTED]> writes: Hi Sven, > I'll keep it on list because some of the topics might > help people eventually creating Ubuntu backports to do it right. Fine! [...] > > Again, what kind of LyX users are there? Why link LyX to a specific > > latex? Would there be anyone who does not know the relationship > > between LyX and latex, I wonder? > > I should know that I need libc to use some software or shouldn't I? > If you question the need of explicit dependencies you can question > the whole model of creating ready to intall system distributions. Hmm, libc definitely not! Libraries should be explicitly linked, no doubt. Not sure about the linking a whole independent programme like latex. > > Btw, you might like to read the following discussion on checkinstall > > stating that some consider the absence of dependencies in > > checkinstall packages as *either a bug or a feature* ! > > > > http://www.debian-administration.org/articles/147 > > I would formulate it a bit different. Depending on your own skills > and intention you can in some cases consider it as feature. > > In the case of distributing such packages on the internet to an > unknown mass of people with a very different level of knowledge it's > IMO a disavantage. Reasonable assumption. I'm considering building a package that specifies decencies. About backporting I'm not sure at all. [...] > Of course you've to support your backports in case of security > problems in the version you've backported. It's the same for the > checkinstall stuff. You're pulling in a second, isolated, version of > boost btw that needs to be patched as well in case of problems with > boost. That's a very bad thing and I'm happy that we can use with the > external boost packages provide within Debian with the next stable > release. For a current backport you've to backport libboost aswell. > > IMHO it's easier to notice a DSA for boost and check if your boost > backport is affected as well then searching in all your packages > which libs they ship. I guess this means, I should compile and provide the boost lib too than, for Juergen to upload. Should I? > > Main point how, much time and effort does this really take? Perhaps > > you can send me some relevant links off list about the issue. > > That depends on the package and your own skill level and how much you > know about the package you're backporting. This is what I was fearing, I have no knowledge about the source and very limited skills. > In most cases it's just recompiling in a stable chroot. In case of LyX > you've to recompile boost first with a proper version number so that > it will be replaced with the next stable release that ships the same > version. Then you've to install this new boost version in a chroot > and modify the LyX source package a bit. > You might want to interdiff the .diff.gz from sid against Emilios > .diff.gz. It's actually rolling back two versioned dependencies, > removing a dh_icons call which would require a new version of > debhelper scripts and at least lenny to be usefull at all. If you > like you'll pull in the tetex stuff as alternative to texlive and > then you only need to build the package. > > If you know what to do it's about 5min plus compile time. > There are some hints on > http://debian.ethz.ch/pub/debian-backports/utils/Backport-HOWTO.html Also, is it right, that according to this instruction LyX 1.5.3 cannot yet be build: ` 2.2.1 [...] make sure you use sources with an upstream version not higher than what is available in testing.' because testing is only at 1.5.2? http://bjorn.haxx.se/debian/testing.pl?package=lyx Does this mean, we only *now* could have a backport of LyX 1.5.3? What would you say to build a "real" debian package following this instruction instead of checkinstall: http://www.debian-administration.org/articles/336 I would consider this in light of you convincing argument, as a reasonable compromise. Cheers, Sam
Re: Math font error on Lyx - Windows
Andrew Barr wrote: > > I was using Times Roman font. I changed the font settings to default, and > all the math comes through fine. So...I guess that problem is solved for > the moment. Sorry for the dumb question. > I don't think this is a dumb question. Something unusual is happening that should not be happening. Unfortunately, I am not the person to fix it. However... I think Computer Modern is the default, but I can't actually recall how to check what the defaults are. I recall changing some font stuff around and "Saving as Default" in the past. I haven't gotten any errors, but it would be nice to be able to go to a file or window and see the current defaults (rather than just seeing "Default" displayed without knowing what it is). Anyone know how to get that? I rambled through all the documentation and didn't come up with anything. - David Hewitt Virginia Institute of Marine Science http://www.vims.edu/fish/students/dhewitt/ -- View this message in context: http://www.nabble.com/Math-font-error-on-Lyx---Windows-tp14927537p14950994.html Sent from the LyX - Users mailing list archive at Nabble.com.
Re: Incoming 1.5.3 binaries for debian/ubuntu distributions
On Fri, Jan 18, 2008 at 01:06:27PM +, Sam Lewis wrote: > Sven Hoexter <[EMAIL PROTECTED]> writes: Hi Sam, I'll keep it on list because some of the topics might help people eventually creating Ubuntu backports to do it right. > > And then there is the user who doesn't remember what he did in good > > faith to his system. A year later he upgrades to the next stable > > releases und this fscking update broke his nice LyX installation > > working for fine for the last year. So who's responsible for the non > [...] > > What kind of LyX user (who opts for the latest version of LyX) do you > envisage? All the packages clearly state in the README file that they > are checkinstall. How many users who possibly find the package via google or on the ftp site know what that means? I doubt that many know or even care. I even doubt that everyone can follow what we're discussing here and they should not need to understand it. > > The toolchain with dpkg and apt were build to resolve the > > dependencies for you and you're ignoring that part completly. > > Installing the checkinstall package you can even remove latex (maybe > > some clean up mechanism even suggest to remove them because they look > > unused now) without anything complaining. > > That's what I was trying to say. You might be surprised I've seen > people running LyX on a tiny system without any latex for the purpose of > writing and managing lyx files. I personally have used TexLive for years > and was precisely only able to do this as I complied source myself > rather than using an "official" LyX version linked to tetex in some > distro. Those people wouldn't install the distribution packages anyway. Regarding the tex version thingy etch is the last Debian stable release with tetex and texlive. So in a perfect world everyone would switch to texlive now. Since nobody should be forced to replace his tetex installation now a backport should readd the tetex alternative for texlive. I did this in my own backport proposed for backports.org already but that's not so important here. > Again, what kind of LyX users are there? Why link LyX to a specific > latex? Would there be anyone who does not know the relationship between > LyX and latex, I wonder? I should know that I need libc to use some software or shouldn't I? If you question the need of explicit dependencies you can question the whole model of creating ready to intall system distributions. > Btw, you might like to read the following discussion on checkinstall > stating that some consider the absence of dependencies in checkinstall > packages as *either a bug or a feature* ! > > http://www.debian-administration.org/articles/147 I would formulate it a bit different. Depending on your own skills and intention you can in some cases consider it as feature. In the case of distributing such packages on the internet to an unknown mass of people with a very different level of knowledge it's IMO a disavantage. > > What I don't get is why you waste your time with this broken > > checkinstall crap? It's only a very small step you've to make to get > > the source package and create a backport. The Debian source packages > > are free for everyone to use (that's essentialy what Ubuntu and other > > distributions are based upon). > > I thought I was saving time, by just typing checkinstall rather make > install. It's more about dpkg-buildpackage then checkinstall vs. make install. Of course you might save some time but you pay for that with the risc of some more or less subtle problems. > > So please use the source packages and build proper backports instead > > of punching your package management system right in the face! > > One and a half thing: > > Backporting always presents a slight security issues, which can be > minimised by backporting as few as possible decencies, if understand > this correctly (see > http://debian.ethz.ch/pub/debian-backports/utils/Backport-HOWTO.html ). Of course you've to support your backports in case of security problems in the version you've backported. It's the same for the checkinstall stuff. You're pulling in a second, isolated, version of boost btw that needs to be patched as well in case of problems with boost. That's a very bad thing and I'm happy that we can use with the external boost packages provide within Debian with the next stable release. For a current backport you've to backport libboost aswell. IMHO it's easier to notice a DSA for boost and check if your boost backport is affected as well then searching in all your packages which libs they ship. > Main point how, much time and effort does this really take? Perhaps you > can send me some relevant links off list about the issue. That depends on the package and your own skill level and how much you know about the package you're backporting. In most cases it's just recompiling in a stable chroot. In case of LyX you've to recompile boost first with a proper version number so that it will
Figures and Schemes
Hello! I am a chemist, trying to work with Lyx. I would need to distinguish between 'figure' captions and 'scheme' captions.However, if I use insert -> float I can only choose 'Figure'. How can I add a command allowing me to insert ->float -> scheme ? Thank you very much for your help! Andreas
Re: Incoming 1.5.3 binaries for debian/ubuntu distributions
Sven Hoexter <[EMAIL PROTECTED]> writes: > > On Thu, Jan 17, 2008 at 10:26:48PM +, Sam Lewis wrote: > > Sven Hoexter <[EMAIL PROTECTED]> writes: Moin moin, > > > a) The social/trust problem > [...] > > What solution could you think of? Does the development team use key? > > Well the Debian project has a known web of trust based on key exchange Sensible! > > > b) Technical problems [...] > > > ba) You're breaking the upgrade path. > [...] > > True, if you are using checkinstall binaries and (in the unlikely > > event of) your stable debian release upgrading to this specific lyx > > release, libraries might most probably not match. All you need to > > do is to reinstall, through the comfort of checkinstall the > > offending lyx package. > > > > sudo dpkg -r lyx > > And then there is the user who doesn't remember what he did in good > faith to his system. A year later he upgrades to the next stable > releases und this fscking update broke his nice LyX installation > working for fine for the last year. So who's responsible for the non [...] What kind of LyX user (who opts for the latest version of LyX) do you envisage? All the packages clearly state in the README file that they are checkinstall. [...] > > > bb) Maintainer scripts have a reason > > > For example somebody doing QA work recently noticed that we've > > > left an /etc/lyxrc file on the system with the 1.4.x->1.5.x > > > upgrade which should not happen. So we're now cleaning up behind > > > us with a maintainer script which is of course bound to special > > > versions. You'll break if you install your current package an try > > > to upgrade it at a later point to a Debian version again. In this > > > case it's only an unused old file but it could of course be > > > anything more important. > > > > So how about a recommendation that users when installing a > > checkinstall binary should uses the following command line: > > > > sudo dpkg -r lyx && sudo dpkg -i lyx_1.5.3-1_i386_etch.deb && sudo > > apt-get -f install > > Here you missed the point. The error (actually an error we made in > the Debian package) is in the 1.4.x packages and will be resolved > with a maintainer script in the latest revision of the 1.5.x package. > In this special case the file will be left on the system even if you > purge the package. So your proposed fiddling won't solve anything. OK, I see. [...] > > > bc) Dependencies don't exist for fun. > > > > See above. > > The toolchain with dpkg and apt were build to resolve the > dependencies for you and you're ignoring that part completly. > Installing the checkinstall package you can even remove latex (maybe > some clean up mechanism even suggest to remove them because they look > unused now) without anything complaining. That's what I was trying to say. You might be surprised I've seen people running LyX on a tiny system without any latex for the purpose of writing and managing lyx files. I personally have used TexLive for years and was precisely only able to do this as I complied source myself rather than using an "official" LyX version linked to tetex in some distro. Again, what kind of LyX users are there? Why link LyX to a specific latex? Would there be anyone who does not know the relationship between LyX and latex, I wonder? Btw, you might like to read the following discussion on checkinstall stating that some consider the absence of dependencies in checkinstall packages as *either a bug or a feature* ! http://www.debian-administration.org/articles/147 > > > Bds..) i386? And where is the rest? > > > > Yep that would be good, but to make it clear, this is an > > instrumental move. I'm not a developer or maintainer; I am a social > > scientist, who uses LyX on a daily basis on computers that happen > > to be i386. For the benefit of others, I am providing my own > > compiled binaries, for others who don't have the knowledge or the > > resources to compile the source themselves. > > I might count that in as the only small benefit. Thanks! [...] > What I don't get is why you waste your time with this broken > checkinstall crap? It's only a very small step you've to make to get > the source package and create a backport. The Debian source packages > are free for everyone to use (that's essentialy what Ubuntu and other > distributions are based upon). I thought I was saving time, by just typing checkinstall rather make install. > The prefered solution for Debian would be to find a DD willing to > sponsor the backports.org uploads. Per has no time and interested in > the backports stuff and I'm not a DD yet. > I guess something similar would be needed for Ubuntu backports but > I'm not involved there. It seems that they've a few more releases in > work which should be supported with backports but that's a manpower > issue. > > So please use the source packages and build proper backports instead > of punching your package management system right in the face! One and a half
natbib APA references for multiple authors
When there are two or more authors on a paper and the reference is
withing brackets, the APA guidelines are that it should be (Linehan &
Linehan, 2008). Its doing this, which is good. However, when the
authors are outside the brackets it should be Linehan and Linehan
(2008). The '&' sign should never be used outside of brackets. So
natbib should be doing this:
\citet*{jon90} Jones, Baker, and Williams (1990)
\citep*{jon90} (Jones, Baker, & Williams, 1990)
Is this something I can modify in a .bst file. Could anyone help me
with this? Im using this natbib compatible .bst file
(http://www.dsg.cs.tcd.ie/~linehane/lyx/apa-good.bst).
Thanks
___
Éamonn Linehan,
Distributed Systems Group,
F.35 Computer Science Dept.,
Trinity College,
Dublin 2.
Phone: 00353 1 8961543
Email: [EMAIL PROTECTED]
Web: https://www.cs.tcd.ie/Eamonn.Linehan
Re: natbib APA references for multiple authors
Éamonn Linehan wrote:
When there are two or more authors on a paper and the reference is
withing brackets, the APA guidelines are that it should be (Linehan &
Linehan, 2008). Its doing this, which is good. However, when the
authors are outside the brackets it should be Linehan and Linehan
(2008). The '&' sign should never be used outside of brackets. So
natbib should be doing this:
\citet*{jon90} Jones, Baker, and Williams (1990)
\citep*{jon90} (Jones, Baker, & Williams, 1990)
Is this something I can modify in a .bst file. Could anyone help me
with this? Im using this natbib compatible .bst file
(http://www.dsg.cs.tcd.ie/~linehane/lyx/apa-good.bst).
I don't know if this is possible. The way natbib works, it writes things
like this:
\bibitem[Author Names(Year)]{key}
to the .aux file, where they are picked up by LaTeX. At this point,
natbib knows nothing about how anything will be cited. What might work,
though, would be to re-write the \citet and \citet* commands to replace
the '&' with 'and' if it's there. But I'm not at all sure how to do that.
I can think of other ways to do this, too, but they're all pretty
complicated.
Richard
Re: generic X copy-and-paste not working
M-L wrote: > This version [LyX Version 1.5.2] of Lyx seems to require the Ctrl+c to copy > and Ctrl+v command. Just highlight then middle mouse button [scrollwheel] > or double right/left mouse click to paste into a Lyx document doesn't work > in Debian testing. Using Icewm. FWIW, 1.5.3 includes some cut and paste fixes. Jürgen
Re: left justify floats?
On Thursday 17 January 2008 06:07, Helge Hafting wrote: > I was hoping for a preference setting that allows printing > via pdflatex instead of the usual way, because that > is necessary for using microtype. But lyx currently doesn't > support microtype directly so there is "no need". . . Helge, So what? Microtype is only used to improve the final output; Lyx is only concerned with the on-screen user interface. Couldn't the user replace the dvips used as the printer command with a short script to run pdflatex to a temporary file, run pdf2ps on the temporary file, then send the output to the printer? Les
Re: LyX install on Fedora
Milen Ivanov wrote: Dear Abdel, I'd be interested in a more detailed comparison about the speed. It is mostly my general feeling, but I have collected some data for a rather arbitrary example. 1/ I run Linux F8 on laptop with Intel 1.7GHz and XP on Intel 1GHz (both 32bit, of course). Now, they say that both configuration should be comparable in speed because laptop configuration slows down things. Anyway even if factor of 1/2 is applied to below figures, the conclusion is still in favor of Linux. 2/ Of course, this applies to whole configuration: it may be that teTeX is faster than MikTeX, the viewer is faster and so on. So, the test is that I opened one of my files: "custom", the Introduction and the User Guide, clicked DVI and PDF (after that) and measured approximately how many seconds it will take to show. OK, this means that teTeX is faster that MikTeX but this does not talk about LyX itself. I was thinking more in terms of startup time, file loading, scrolling, etc. But thanks anyway for the numbers, Abdel.
Re: Math font error on Lyx - Windows
Andre Zimmermann wrote: > > Thanks for finding a solution to this problem. > As a brand new user to LyX I couldn't get math functions to work which was > the main reason I am switching from Word, but have been stuck on this > problem for about a week and was ready to quit trying to find a solution > and go back to word. I was also using Times New Roman and had the same > problem. > Now fixed, but would be good if it didn't happen. > For the record if a developer/wiz can help here... I'm on WinXP Pro with LyX 1.5.3 and MikTeX 2.6 and cannot reproduce this problem in a standard article class with Times Roman font (I don't have Times New Roman, but I think they're the same). - David Hewitt Virginia Institute of Marine Science http://www.vims.edu/fish/students/dhewitt/ -- View this message in context: http://www.nabble.com/Math-font-error-on-Lyx---Windows-tp14927537p14957798.html Sent from the LyX - Users mailing list archive at Nabble.com.
Re: Incoming 1.5.3 binaries for debian/ubuntu distributions
On Fri, Jan 18, 2008 at 03:54:22PM +, Sam Lewis wrote: > Sven Hoexter <[EMAIL PROTECTED]> writes: Hi, > Reasonable assumption. I'm considering building a package that > specifies decencies. About backporting I'm not sure at all. That would be equal to a backport. :) > > IMHO it's easier to notice a DSA for boost and check if your boost > > backport is affected as well then searching in all your packages > > which libs they ship. > > I guess this means, I should compile and provide the boost lib too > than, for Juergen to upload. Should I? Emilio did it already. IMHO you should do nothing at all and simply use Emilios packages. I hope that Emilio will change the dependency on texlive soon that could help some people to avoid the tetex->texlive now. I simply didn't mention his backport before because I had some hope to get a package on backports.org soon. Since it seems to be a bit more complicated to find a sponsor I'd recommend his repository until that's solved in some way or another. > > > Main point how, much time and effort does this really take? Perhaps > > > you can send me some relevant links off list about the issue. > > > > That depends on the package and your own skill level and how much you > > know about the package you're backporting. > > This is what I was fearing, I have no knowledge about the source and > very limited skills. Then you should not distribute packages at all or try to read a little bit about Debian packaging before doing so. > > > > If you know what to do it's about 5min plus compile time. > > There are some hints on > > http://debian.ethz.ch/pub/debian-backports/utils/Backport-HOWTO.html *argh* Wrong link. Sorry, it should have been this one: http://www.backports.org/dokuwiki/doku.php?id=contribute > Also, is it right, that according to this instruction LyX 1.5.3 cannot > yet be build: ` 2.2.1 [...] make sure you use sources with an upstream > version not higher than what is available in testing.' because testing > is only at 1.5.2? > http://bjorn.haxx.se/debian/testing.pl?package=lyx > > Does this mean, we only *now* could have a backport of LyX 1.5.3? What you could and what you should are two different things *g*. You can of course backport 1.5.3 and that's what Emilio did. ATM such a backport would not be accepted on backports.org to avoid potential version conflicts. This is hypothetical: If Lenny would be released with LyX 1.5.2 and you've a backport of 1.5.3 installed on your etch system it wouldn't work because the backport has been build with the old libs of etch and because of the higher version it would not downgrade. To avoid this problem it's a good practise to only create backports for packages that will be included in the next stable release. For some further understanding you can play around with dpkgs version-compare option to understand how the versions would interact on hypothetical upgrades. > What would you say to build a "real" debian package following this > instruction instead of checkinstall: > http://www.debian-administration.org/articles/336 > > I would consider this in light of you convincing argument, as a > reasonable compromise. Building real Debian packages is called backporting in this case. You don't have to recreate the whole package because you can base it on the work already done. Add a deb-src line for unstable to your sources.list and apt-get update && apt-get source lyx. Cheers, Sven -- If God passed a mic to me to speak I'd say stay in bed, world Sleep in peace [The Cardigans - 03:45: No sleep]
RE: Re: LyX install on Fedora
Dear Abdel, >I'd be interested in a more detailed comparison about the speed. It is mostly my general feeling, but I have collected some data for a rather arbitrary example. 1/ I run Linux F8 on laptop with Intel 1.7GHz and XP on Intel 1GHz (both 32bit, of course). Now, they say that both configuration should be comparable in speed because laptop configuration slows down things. Anyway even if factor of 1/2 is applied to below figures, the conclusion is still in favor of Linux. 2/ Of course, this applies to whole configuration: it may be that teTeX is faster than MikTeX, the viewer is faster and so on. So, the test is that I opened one of my files: "custom", the Introduction and the User Guide, clicked DVI and PDF (after that) and measured approximately how many seconds it will take to show. The results are: Linux: DVI PDF Custom 8 3 Introduction15 4 User Guide 20 10 Windows: DVI PDF Custom 21 12 Introduction35 14 User Guide more than 60s I do not know if this info is useful for you, but anyway. Best regards, Milen -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Abdelrazak Younes Sent: Tuesday, January 15, 2008 4:10 PM To: lyx-users@lists.lyx.org Subject: Re: LyX install on Fedora Milen Ivanov wrote: > From what I can see so far, LyX on Linux is clearly faster than LyX on > Windows. I'd be interested in a more detailed comparison about the speed. Abdel.
Re: Incoming 1.5.3 binaries for debian/ubuntu distributions
Sven Hoexter <[EMAIL PROTECTED]> writes: [...] > Building real Debian packages is called backporting in this case. > You don't have to recreate the whole package because you can base > it on the work already done. > > Add a deb-src line for unstable to your sources.list and > apt-get update && apt-get source lyx. Great! Thanks very much. :-) Cheers, Sam
Re: Math font error on Lyx - Windows
Thanks for finding a solution to this problem. As a brand new user to LyX I couldn't get math functions to work which was the main reason I am switching from Word, but have been stuck on this problem for about a week and was ready to quit trying to find a solution and go back to word. I was also using Times New Roman and had the same problem. Now fixed, but would be good if it didn't happen. Andre
