Math fonts and Ubuntu
Hi all, I am using Ubuntu (both 5.4 and 5.10) and several cm fonts are not found by LyX, and I get messages like this: Could not get font '-tex-cmr10-medium-r-normal--15-0-0-0-p-0-fontspecific-0'. Using 'fixed'. Could not get font '-tex-cmex10-medium-r-normal--15-0-0-0-p-0-fontspecific-0'. Using 'fixed'. Could not get font '-tex-cmsy10-medium-r-normal--11-0-0-0-p-0-fontspecific-0'. Using 'fixed'. A search for cmsy10 shows several .ttf files: /var/lib/defoma/gs.d/dirs/fonts/cmsy10.ttf /var/lib/defoma/fontconfig.d/c/cmsy10.ttf /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType/cmsy10.ttf /usr/share/fonts/truetype/latex-xft-fonts/cmsy10.ttf There are also .tfm, .pfb and .mf files. So, the question is: what should be done so that LyX and X recognize and find the missing fonts? Thank you for any help, joao
Math fonts and Ubuntu
Hi all, I am using Ubuntu (both 5.4 and 5.10) and several cm fonts are not found by LyX, and I get messages like this: Could not get font '-tex-cmr10-medium-r-normal--15-0-0-0-p-0-fontspecific-0'. Using 'fixed'. Could not get font '-tex-cmex10-medium-r-normal--15-0-0-0-p-0-fontspecific-0'. Using 'fixed'. Could not get font '-tex-cmsy10-medium-r-normal--11-0-0-0-p-0-fontspecific-0'. Using 'fixed'. A search for cmsy10 shows several .ttf files: /var/lib/defoma/gs.d/dirs/fonts/cmsy10.ttf /var/lib/defoma/fontconfig.d/c/cmsy10.ttf /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType/cmsy10.ttf /usr/share/fonts/truetype/latex-xft-fonts/cmsy10.ttf There are also .tfm, .pfb and .mf files. So, the question is: what should be done so that LyX and X recognize and find the missing fonts? Thank you for any help, joao
Math fonts and Ubuntu
Hi all, I am using Ubuntu (both 5.4 and 5.10) and several cm fonts are not found by LyX, and I get messages like this: Could not get font '-tex-cmr10-medium-r-normal--15-0-0-0-p-0-fontspecific-0'. Using 'fixed'. Could not get font '-tex-cmex10-medium-r-normal--15-0-0-0-p-0-fontspecific-0'. Using 'fixed'. Could not get font '-tex-cmsy10-medium-r-normal--11-0-0-0-p-0-fontspecific-0'. Using 'fixed'. A search for cmsy10 shows several .ttf files: /var/lib/defoma/gs.d/dirs/fonts/cmsy10.ttf /var/lib/defoma/fontconfig.d/c/cmsy10.ttf /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType/cmsy10.ttf /usr/share/fonts/truetype/latex-xft-fonts/cmsy10.ttf There are also .tfm, .pfb and .mf files. So, the question is: what should be done so that LyX and X recognize and find the "missing" fonts? Thank you for any help, joao
External material
Hi all, I was trying to use External Material (Xfig) and noticed the following behaviour: If a parameter like -m1.5 is used to scale the XFig image, everything gows well at the first time, but if the factor has to be changed to -m1.8, for example, LyX seems not to notice the change and does not produce a new .eps file, so the same image is used. BTW, is this the proper way of including XFig material? I usually need to rescale the images up or down, and as I tried with -m it went wrong... :( joao
External material
Hi all, I was trying to use External Material (Xfig) and noticed the following behaviour: If a parameter like -m1.5 is used to scale the XFig image, everything gows well at the first time, but if the factor has to be changed to -m1.8, for example, LyX seems not to notice the change and does not produce a new .eps file, so the same image is used. BTW, is this the proper way of including XFig material? I usually need to rescale the images up or down, and as I tried with -m it went wrong... :( joao
External material
Hi all, I was trying to use External Material (Xfig) and noticed the following behaviour: If a parameter like -m1.5 is used to scale the XFig image, everything gows well at the first time, but if the factor has to be changed to -m1.8, for example, LyX seems not to notice the change and does not produce a new .eps file, so the same image is used. BTW, is this the proper way of including XFig material? I usually need to rescale the images up or down, and as I tried with -m it went wrong... :( joao
Re: Master's or PhD thesis Class and Layout
Hi!! You may wish to try the dissertacao.* files on my page. They were are heavily based on article.cls, but may provide some of the facilities you wish. http://www.inf.pucrs.br/%7Eoliveira/formatos/formatos.html :) jb
Re: Master's or PhD thesis Class and Layout
Hi!! You may wish to try the dissertacao.* files on my page. They were are heavily based on article.cls, but may provide some of the facilities you wish. http://www.inf.pucrs.br/%7Eoliveira/formatos/formatos.html :) jb
Re: Master's or PhD thesis Class and Layout
Hi!! You may wish to try the dissertacao.* files on my page. They were are heavily based on "article.cls", but may provide some of the facilities you wish. http://www.inf.pucrs.br/%7Eoliveira/formatos/formatos.html :) jb
\LyX is missing in 1.3.2?
Hi everyone, after installing LyX 1.3.2 and running it happily, today I came across a file written with an older version, and it uses the \LyX macro, causing TeX to fail. This macro seems to be dropped in version 1.3.2 ? Dows anyone remember the actual macro? thanks in advance, joao b.
\LyX is missing: solved.
Sorry guys, the answer was in the devel list but seemingly not in the user list. http://www.mail-archive.com/[EMAIL PROTECTED]/msg56335.html j. b.
\LyX is missing in 1.3.2?
Hi everyone, after installing LyX 1.3.2 and running it happily, today I came across a file written with an older version, and it uses the \LyX macro, causing TeX to fail. This macro seems to be dropped in version 1.3.2 ? Dows anyone remember the actual macro? thanks in advance, joao b.
\LyX is missing: solved.
Sorry guys, the answer was in the devel list but seemingly not in the user list. http://www.mail-archive.com/[EMAIL PROTECTED]/msg56335.html j. b.
\LyX is missing in 1.3.2?
Hi everyone, after installing LyX 1.3.2 and running it happily, today I came across a file written with an older version, and it uses the \LyX macro, causing TeX to fail. This macro seems to be dropped in version 1.3.2 ? Dows anyone remember the actual macro? thanks in advance, joao b.
\LyX is missing: solved.
Sorry guys, the answer was in the devel list but seemingly not in the user list. http://www.mail-archive.com/[EMAIL PROTECTED]/msg56335.html j. b.
Re: User-defined converter fails under 1.3.0
On Wed, Mar 05, 2003 at 01:05:30PM -0300, Joao B. Oliveira wrote: under the previous version of LyX I had a owner-defined converter that could convert from PS to PSnup, defined as follows: \format psnup ps PSnup \viewer psnup gv -landscape -scale 1 \converter ps psnup psnup -2 $$i $$o ; mv -f $$o $$i Under LyX 1.3.0 this conversion command does get executed, but an error message is given thereafter and no viewer is applied (for exporting, no .ps file is generated as well). The problem is the 'mv' at the end. If you remove it, it should work correctly. As far as I test it, it does *not* work, even removing the mv. Two things are happening: 1) If I do not set a tmp directory in the Preferences, all intermediate files are generated in the current dir and are not erased at the end of the generation procedure. Of course, this produces rather messy results over time... :( 2) If a tmp directory was set up, the resulting Ps file is kept there AND erased thereafter. Take a look at the last lines of the debugging output: * Calling psnup -2 'artigo.ps' 'tmpfile.out' Executing command:psnup -2 'artigo.ps' 'tmpfile.out' [1] [2] [3] [4] [5] [6] [7] Wrote 7 pages, 990733 bytes renaming file /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/tmpfile.out to /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/artigo.ps ** Up to here, everything is ok. ** Output file is properly renamed. Document exported as PSnup to file `~/projs/ProdCNPq/artigo1/artigo.ps' ** ** This seems to be a simple message, because the file artigo.ps was not moved ** to the ~/projs/ directory. It is still in /tmp/lyx_tmpdir7509V42015/. ** ** It will be erased by the last of the following commands: Running QuitLyX. Buffer::~Buffer() Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/artigo.tex Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/_home_profs_oliveira_projs_ProdCNPq_artigo1_f1.eps Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/_home_profs_oliveira_projs_ProdCNPq_artigo1_f2.eps Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/_home_profs_oliveira_projs_ProdCNPq_artigo1_f3.eps Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/_home_profs_oliveira_projs_ProdCNPq_artigo1_z12.eps Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/_home_profs_oliveira_projs_ProdCNPq_artigo1_z32.eps Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/_home_profs_oliveira_projs_ProdCNPq_artigo1_z42.eps Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/_home_profs_oliveira_projs_ProdCNPq_artigo1_z62.eps Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/_home_profs_oliveira_projs_ProdCNPq_artigo1_z72.eps Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/_home_profs_oliveira_projs_ProdCNPq_artigo1_z13.eps Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/_home_profs_oliveira_projs_ProdCNPq_artigo1_z33.eps Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/_home_profs_oliveira_projs_ProdCNPq_artigo1_z43.eps Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/_home_profs_oliveira_projs_ProdCNPq_artigo1_z63.eps Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/_home_profs_oliveira_projs_ProdCNPq_artigo1_z73.eps Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/_home_profs_oliveira_projs_ProdCNPq_artigo1_f4.eps Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/_home_profs_oliveira_projs_ProdCNPq_artigo1_w72.eps Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/artigo.log Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/artigo.aux Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/artigo.dvi Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/artigo.blg Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/artigo.bbl Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/artigo.tex.dep Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/artigo.ps Deleting tmp dir /tmp/lyx_tmpdir7509V42015 All in all, Lyx is forgetting to move the resulting file from the tmp to the current directory... joao
Re: User-defined converter fails under 1.3.0
On Wed, Mar 05, 2003 at 01:05:30PM -0300, Joao B. Oliveira wrote: under the previous version of LyX I had a owner-defined converter that could convert from PS to PSnup, defined as follows: \format psnup ps PSnup \viewer psnup gv -landscape -scale 1 \converter ps psnup psnup -2 $$i $$o ; mv -f $$o $$i Under LyX 1.3.0 this conversion command does get executed, but an error message is given thereafter and no viewer is applied (for exporting, no .ps file is generated as well). The problem is the 'mv' at the end. If you remove it, it should work correctly. As far as I test it, it does *not* work, even removing the mv. Two things are happening: 1) If I do not set a tmp directory in the Preferences, all intermediate files are generated in the current dir and are not erased at the end of the generation procedure. Of course, this produces rather messy results over time... :( 2) If a tmp directory was set up, the resulting Ps file is kept there AND erased thereafter. Take a look at the last lines of the debugging output: * Calling psnup -2 'artigo.ps' 'tmpfile.out' Executing command:psnup -2 'artigo.ps' 'tmpfile.out' [1] [2] [3] [4] [5] [6] [7] Wrote 7 pages, 990733 bytes renaming file /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/tmpfile.out to /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/artigo.ps ** Up to here, everything is ok. ** Output file is properly renamed. Document exported as PSnup to file `~/projs/ProdCNPq/artigo1/artigo.ps' ** ** This seems to be a simple message, because the file artigo.ps was not moved ** to the ~/projs/ directory. It is still in /tmp/lyx_tmpdir7509V42015/. ** ** It will be erased by the last of the following commands: Running QuitLyX. Buffer::~Buffer() Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/artigo.tex Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/_home_profs_oliveira_projs_ProdCNPq_artigo1_f1.eps Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/_home_profs_oliveira_projs_ProdCNPq_artigo1_f2.eps Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/_home_profs_oliveira_projs_ProdCNPq_artigo1_f3.eps Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/_home_profs_oliveira_projs_ProdCNPq_artigo1_z12.eps Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/_home_profs_oliveira_projs_ProdCNPq_artigo1_z32.eps Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/_home_profs_oliveira_projs_ProdCNPq_artigo1_z42.eps Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/_home_profs_oliveira_projs_ProdCNPq_artigo1_z62.eps Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/_home_profs_oliveira_projs_ProdCNPq_artigo1_z72.eps Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/_home_profs_oliveira_projs_ProdCNPq_artigo1_z13.eps Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/_home_profs_oliveira_projs_ProdCNPq_artigo1_z33.eps Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/_home_profs_oliveira_projs_ProdCNPq_artigo1_z43.eps Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/_home_profs_oliveira_projs_ProdCNPq_artigo1_z63.eps Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/_home_profs_oliveira_projs_ProdCNPq_artigo1_z73.eps Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/_home_profs_oliveira_projs_ProdCNPq_artigo1_f4.eps Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/_home_profs_oliveira_projs_ProdCNPq_artigo1_w72.eps Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/artigo.log Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/artigo.aux Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/artigo.dvi Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/artigo.blg Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/artigo.bbl Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/artigo.tex.dep Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/artigo.ps Deleting tmp dir /tmp/lyx_tmpdir7509V42015 All in all, Lyx is forgetting to move the resulting file from the tmp to the current directory... joao
Re: User-defined converter fails under 1.3.0
> On Wed, Mar 05, 2003 at 01:05:30PM -0300, Joao B. Oliveira wrote: > > > > > under the previous version of LyX I had a owner-defined converter > > > that could convert from PS to PSnup, defined as follows: > > > > > > \format "psnup" "ps" "PSnup" "" > > > \viewer "psnup" "gv -landscape -scale 1" > > > \converter "ps" "psnup" "psnup -2 $$i $$o ; mv -f $$o $$i" "" > > > > > > Under LyX 1.3.0 this conversion command does get executed, but an > > > error message is given thereafter and no viewer is applied (for > > > exporting, no .ps file is generated as well). > > The problem is the 'mv' at the end. > If you remove it, it should work correctly. As far as I test it, it does *not* work, even removing the "mv". Two things are happening: 1) If I do not set a tmp directory in the Preferences, all intermediate files are generated in the current dir and are not erased at the end of the generation procedure. Of course, this produces rather messy results over time... :( 2) If a tmp directory was set up, the resulting Ps file is kept there AND erased thereafter. Take a look at the last lines of the debugging output: * Calling psnup -2 'artigo.ps' 'tmpfile.out' Executing command:psnup -2 'artigo.ps' 'tmpfile.out' [1] [2] [3] [4] [5] [6] [7] Wrote 7 pages, 990733 bytes renaming file /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/tmpfile.out to /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/artigo.ps ** Up to here, everything is ok. ** Output file is properly renamed. Document exported as PSnup to file `~/projs/ProdCNPq/artigo1/artigo.ps' ** ** This seems to be a simple message, because the file artigo.ps was not moved ** to the ~/projs/ directory. It is still in /tmp/lyx_tmpdir7509V42015/. ** ** It will be erased by the last of the following commands: Running QuitLyX. Buffer::~Buffer() Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/artigo.tex Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/_home_profs_oliveira_projs_ProdCNPq_artigo1_f1.eps Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/_home_profs_oliveira_projs_ProdCNPq_artigo1_f2.eps Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/_home_profs_oliveira_projs_ProdCNPq_artigo1_f3.eps Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/_home_profs_oliveira_projs_ProdCNPq_artigo1_z12.eps Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/_home_profs_oliveira_projs_ProdCNPq_artigo1_z32.eps Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/_home_profs_oliveira_projs_ProdCNPq_artigo1_z42.eps Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/_home_profs_oliveira_projs_ProdCNPq_artigo1_z62.eps Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/_home_profs_oliveira_projs_ProdCNPq_artigo1_z72.eps Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/_home_profs_oliveira_projs_ProdCNPq_artigo1_z13.eps Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/_home_profs_oliveira_projs_ProdCNPq_artigo1_z33.eps Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/_home_profs_oliveira_projs_ProdCNPq_artigo1_z43.eps Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/_home_profs_oliveira_projs_ProdCNPq_artigo1_z63.eps Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/_home_profs_oliveira_projs_ProdCNPq_artigo1_z73.eps Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/_home_profs_oliveira_projs_ProdCNPq_artigo1_f4.eps Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/_home_profs_oliveira_projs_ProdCNPq_artigo1_w72.eps Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/artigo.log Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/artigo.aux Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/artigo.dvi Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/artigo.blg Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/artigo.bbl Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/artigo.tex.dep Deleting file: /tmp/lyx_tmpdir7509V42015/lyx_tmpbuf0/artigo.ps Deleting tmp dir /tmp/lyx_tmpdir7509V42015 All in all, Lyx is forgetting to move the resulting file from the tmp to the current directory... joao
User-defined converter fails under 1.3.0
Hi everyone, under the previous version of LyX I had a owner-defined converter that could convert from PS to PSnup, defined as follows: \format psnup ps PSnup \viewer psnup gv -landscape -scale 1 \converter ps psnup psnup -2 $$i $$o ; mv -f $$o $$i Under LyX 1.3.0 this conversion command does get executed, but an error message is given thereafter and no viewer is applied (for exporting, no .ps file is generated as well). Does anyone know if the command syntax has been changed, or if there is an error in the above command? (It worked before!!) thanks in advance, joao b. oliveira
Re: User-defined converter fails under 1.3.0
under the previous version of LyX I had a owner-defined converter that could convert from PS to PSnup, defined as follows: \format psnup ps PSnup \viewer psnup gv -landscape -scale 1 \converter ps psnup psnup -2 $$i $$o ; mv -f $$o $$i Under LyX 1.3.0 this conversion command does get executed, but an error message is given thereafter and no viewer is applied (for exporting, no .ps file is generated as well). Does anyone know if the command syntax has been changed, or if there is an error in the above command? (It worked before!!) I have found little more detail: If a tmp directory is *not* defined in the preferences, the above command works properly but also generates all (aux,dvi,log, ...) files in the current directory, and that was not good. If a tmp directory IS defined in the preferences, then all work is done there but the resulting file is NOT moved properly to the original directory. BTW, it works for the usual (dvi,ps) files, but for a user-provided conversion it seems not to be the case. Some output from -dbg any: Converting from dvi to ps Calling dvips -t a4 -o 't1.ps' 't1.dvi' Executing command:dvips -t a4 -o 't1.ps' 't1.dvi' This is dvips(k) 5.86e Copyright 2001 Radical Eye Software (www.radicaleye.com) ' TeX output 2003.03.05:1259' - t1.ps texc.pro. [1] Converting from ps to psnup Calling psnup -2 't1.ps' 'tmpfile.out' Executing command:psnup -2 't1.ps' 'tmpfile.out' [1] Wrote 1 pages, 56099 bytes renaming file /tmp/lyx_tmpdir21685Wewzb/lyx_tmpbuf0/tmpfile.out to /tmp/lyx_tmpdir21685Wewzb/lyx_tmpbuf0/t1.ps Document exported as PSnup to file `~/didat/algoIII/trabZN20031/t1.ps' As you see in the last three lines, LyX makes the wrong renaming... joao b. oliveira
User-defined converter fails under 1.3.0
Hi everyone, under the previous version of LyX I had a owner-defined converter that could convert from PS to PSnup, defined as follows: \format psnup ps PSnup \viewer psnup gv -landscape -scale 1 \converter ps psnup psnup -2 $$i $$o ; mv -f $$o $$i Under LyX 1.3.0 this conversion command does get executed, but an error message is given thereafter and no viewer is applied (for exporting, no .ps file is generated as well). Does anyone know if the command syntax has been changed, or if there is an error in the above command? (It worked before!!) thanks in advance, joao b. oliveira
Re: User-defined converter fails under 1.3.0
under the previous version of LyX I had a owner-defined converter that could convert from PS to PSnup, defined as follows: \format psnup ps PSnup \viewer psnup gv -landscape -scale 1 \converter ps psnup psnup -2 $$i $$o ; mv -f $$o $$i Under LyX 1.3.0 this conversion command does get executed, but an error message is given thereafter and no viewer is applied (for exporting, no .ps file is generated as well). Does anyone know if the command syntax has been changed, or if there is an error in the above command? (It worked before!!) I have found little more detail: If a tmp directory is *not* defined in the preferences, the above command works properly but also generates all (aux,dvi,log, ...) files in the current directory, and that was not good. If a tmp directory IS defined in the preferences, then all work is done there but the resulting file is NOT moved properly to the original directory. BTW, it works for the usual (dvi,ps) files, but for a user-provided conversion it seems not to be the case. Some output from -dbg any: Converting from dvi to ps Calling dvips -t a4 -o 't1.ps' 't1.dvi' Executing command:dvips -t a4 -o 't1.ps' 't1.dvi' This is dvips(k) 5.86e Copyright 2001 Radical Eye Software (www.radicaleye.com) ' TeX output 2003.03.05:1259' - t1.ps texc.pro. [1] Converting from ps to psnup Calling psnup -2 't1.ps' 'tmpfile.out' Executing command:psnup -2 't1.ps' 'tmpfile.out' [1] Wrote 1 pages, 56099 bytes renaming file /tmp/lyx_tmpdir21685Wewzb/lyx_tmpbuf0/tmpfile.out to /tmp/lyx_tmpdir21685Wewzb/lyx_tmpbuf0/t1.ps Document exported as PSnup to file `~/didat/algoIII/trabZN20031/t1.ps' As you see in the last three lines, LyX makes the wrong renaming... joao b. oliveira
User-defined converter fails under 1.3.0
Hi everyone, under the previous version of LyX I had a owner-defined converter that could convert from PS to PSnup, defined as follows: \format "psnup" "ps" "PSnup" "" \viewer "psnup" "gv -landscape -scale 1" \converter "ps" "psnup" "psnup -2 $$i $$o ; mv -f $$o $$i" "" Under LyX 1.3.0 this conversion command does get executed, but an error message is given thereafter and no viewer is applied (for exporting, no .ps file is generated as well). Does anyone know if the command syntax has been changed, or if there is an error in the above command? (It worked before!!) thanks in advance, joao b. oliveira
Re: User-defined converter fails under 1.3.0
> under the previous version of LyX I had a owner-defined converter > that could convert from PS to PSnup, defined as follows: > > \format "psnup" "ps" "PSnup" "" > \viewer "psnup" "gv -landscape -scale 1" > \converter "ps" "psnup" "psnup -2 $$i $$o ; mv -f $$o $$i" "" > > Under LyX 1.3.0 this conversion command does get executed, but an > error message is given thereafter and no viewer is applied (for > exporting, no .ps file is generated as well). > > Does anyone know if the command syntax has been changed, or if > there is an error in the above command? (It worked before!!) > I have found little more detail: If a tmp directory is *not* defined in the preferences, the above command works properly but also generates all (aux,dvi,log, ...) files in the current directory, and that was not good. If a tmp directory IS defined in the preferences, then all work is done there but the resulting file is NOT moved properly to the original directory. BTW, it works for the usual (dvi,ps) files, but for a user-provided conversion it seems not to be the case. Some output from -dbg any: Converting from dvi to ps Calling dvips -t a4 -o 't1.ps' 't1.dvi' Executing command:dvips -t a4 -o 't1.ps' 't1.dvi' This is dvips(k) 5.86e Copyright 2001 Radical Eye Software (www.radicaleye.com) ' TeX output 2003.03.05:1259' -> t1.ps . [1] Converting from ps to psnup Calling psnup -2 't1.ps' 'tmpfile.out' Executing command:psnup -2 't1.ps' 'tmpfile.out' [1] Wrote 1 pages, 56099 bytes renaming file /tmp/lyx_tmpdir21685Wewzb/lyx_tmpbuf0/tmpfile.out to /tmp/lyx_tmpdir21685Wewzb/lyx_tmpbuf0/t1.ps Document exported as PSnup to file `~/didat/algoIII/trabZN20031/t1.ps' As you see in the last three lines, LyX makes the wrong renaming... joao b. oliveira
Re: LyX terrible converting images
I have used LyX in -dbg mode and checked the conversion process. It does not seem that LyX itself is doing things badly, but it calls convert for every image on the current screen and convert seems to be doing a bad job, taking up all memory and filling the swap area as well. Wouldn't 'nice' be useful in this situation? Sure. But not LyX's business. The user is free to write his own shell scrip t wrapper for convert/gs/whatever. Total freedom to set the nice value as desired. Oh, I agree... this was intended as a tip for Joao... (or people in general who suffer from this problem) Hm... I had to leave for 2 days, now I am catching up the news. I think that adding nice to the conversion process is a good idea that can be done in a user-by-user basis, but I believe that one of the major problems of convert is its memory consumption. Adding nice would reduce the CPU consumption, but after a while memory will again fill up with imaegs being coverted. Thta is why I believe that making the conversion process a serial one would speed up things much more: memory is used for one image at a time and thus fills up only in extreme cases. No swap, no disk delays, etc... joao
Re: LyX terrible converting images
I have used LyX in -dbg mode and checked the conversion process. It does not seem that LyX itself is doing things badly, but it calls convert for every image on the current screen and convert seems to be doing a bad job, taking up all memory and filling the swap area as well. Wouldn't 'nice' be useful in this situation? Sure. But not LyX's business. The user is free to write his own shell scrip t wrapper for convert/gs/whatever. Total freedom to set the nice value as desired. Oh, I agree... this was intended as a tip for Joao... (or people in general who suffer from this problem) Hm... I had to leave for 2 days, now I am catching up the news. I think that adding nice to the conversion process is a good idea that can be done in a user-by-user basis, but I believe that one of the major problems of convert is its memory consumption. Adding nice would reduce the CPU consumption, but after a while memory will again fill up with imaegs being coverted. Thta is why I believe that making the conversion process a serial one would speed up things much more: memory is used for one image at a time and thus fills up only in extreme cases. No swap, no disk delays, etc... joao
Re: LyX terrible converting images
> > > > > I have used LyX in -dbg mode and checked the conversion process. It > > > > > does not seem that LyX itself is doing things badly, but it calls > > > > > convert for every image on the current screen and convert seems to > > > > > be doing a bad job, taking up all memory and filling the swap area > > > > > as well. > > > > > > Wouldn't 'nice' be useful in this situation? > > > > Sure. But not LyX's business. The user is free to write his own shell scrip > t > > wrapper for convert/gs/whatever. Total freedom to set the nice value as > > desired. > > Oh, I agree... this was intended as a tip for Joao... (or people in > general who suffer from this problem) Hm... I had to leave for 2 days, now I am catching up the news. I think that adding nice to the conversion process is a good idea that can be done in a user-by-user basis, but I believe that one of the major problems of convert is its memory consumption. Adding nice would reduce the CPU consumption, but after a while memory will again fill up with imaegs being coverted. Thta is why I believe that making the conversion process a serial one would speed up things much more: memory is used for one image at a time and thus fills up only in extreme cases. No swap, no disk delays, etc... joao
LyX terrible converting images
Hi everyone (specially the folks from the devel team), I would like to raise a few questions about the handling of figures under LyX. Maybe the answers will help me to set LyX properly at our installation, as things are getting out of hand... Some history first: I keep LyX running on a Computer Science Department, with some 20-30 students constantly using LyX on several machines. Everything was fine, until LyX 1.2.0 came along. The problem was, the handling of figures was changed in that version, and from that version onwards the students that work on documents with a larger number of figures (or larger figures) were horrified to see that their documents were taking like 10 minutes (sometimes much longer) to be opened, and the convert processes would take over the machine. Simply opening a document and scrolling down to the editing point would create so many conversions and take up so much memory that using the system is impossible. In fact, situation is so bad that I have already given up LyX myself, at least for documents that have more than a few images. Unfortunately this affected both the work of the students (I saw one of once them waiting for 20 minutes until all conversions were ready) and disastrously affected morale, new students are reluctant to work with LyX. Currently, I am struggling with the administrative powers to keep LyX running, as they are saying that this situation is untenable. The problem is, if things do not get some solution, I'll have to agree with them. Back to 1.1.6 would be very bad. Our machines are neither small nor slow, and LyX (currently 1.3.0) simply makes them stop with the conversion process. So, I went after documentation or details but did not find anything that I could use to accelerate things. I really need to understand what is going on, and maybe someone can answer these questions (and ADD THEM to the current documentation): -- First of all, how does the conversion/display process really works? Specially, how EPS files are handled? (I understand that they are always converted to ppm for displaying? Why ppm?) -- In previous versions EPS files could be displayed rather quickly. Why was their processing slower from 1.2.0 on? -- Is there a way of avoiding the conversion process and handling EPS files directly? -- Is there a way of accelerating the conversion process (if it cannot be avoided)? Are there shortcuts to be used? -- When several images are in the same figure, they *all* get converted at the same time, filling up memory and swap space. At the very least, can this be changed so that we get one conversion at a time, to preserver swap space (and time, as a consequence?) -- If EPS files are large (I have some with more or less 1.5 Mb) their conversion and displaying takes all memory and a 64Mb computer simply crashes. With more images of the same size, larger machines crash as well. Was this foreseen? -- Are we the only ones with such a problem? That is, quite usual LyX files that take terribly long to load completely, fill the swap area and make real editing impossible during the process? There is always the possibility that a piece of software is missing here, and due to this unfortunate conversions take place, but I do not believe that this is the case. I would appreciate any help, as I want to keep LyX running but currently I also have to explain many things to both management and disappointed students. thank you all for any suggestion, j b oliveira
Re: LyX terrible converting images
hi everyone, Some history first: I keep LyX running on a Computer Science... The image handling code in LyX 1.2 is indeed nasty. Things should be much better in LyX 1.3. In LyX 1.3 the conversion process is triggered only for images that have been on screen for 2 seconds, so you should now be able to scroll without any conversion occurring. Well, first of all, thanks for the prompt answer to all these questions... one cannot stop wondering at the patience that the development team puts into answering questions. I have to admit, as we just installed LyX 1.3.0, we are still discovering the points that are causing us problems. For example, the problem about a long time on loading a document was reported for the previous version, not (yet) for 1.3.0. Our machines are neither small nor slow, and LyX (currently 1.3.0) simply makes them stop with the conversion process. I am surprised at this as I would expect only one or two images to be converted at a time (since only one or two images will be visible on the screen at any one time). Well, not really. It is rather common (at least here) to put several smaller images in a figure, to draw comparisons like In Fig 6a you see this, and in 6b we clearly see that, but 6c clearly shows Sometimes we put four or six smaller EPS imagens in a figure. (And it does not look that bad :) -- First of all, how does the conversion/display process really works? Specially, how EPS files are handled? (I understand that they are always converted to ppm for displaying? Why ppm?) By default, we use ImageMagick's 'convert' program, run through a script convertDefault.sh. I too find that 'convert' is very slow. (But this shouldn't really matter. See above.) I have used LyX in -dbg mode and checked the conversion process. It does not seem that LyX itself is doing things badly, but it calls convert for every image on the current screen and convert seems to be doing a bad job, taking up all memory and filling the swap area as well. I attach a modified convertDefault.sh that uses ghostscript to convert eps files to either ppm or png format. Personally, I would use it as the basis for a my_ps2ppm or my_ps2png converter... Thank you! As some initial tests are showing, using gs directly seems to be significantly more efficient than convert. Maybe this was the reason for most of our problems all along. I'll invest on that in the next days. To begin, comparing the shell script you sent (that is, gs) with the traditional convert, regarding time and memory consumption... -- Is there a way of accelerating the conversion process (if it cannot be avoided)? Are there shortcuts to be used? Try using a converter other than ImageMagick's convert. See attached. Ok. I think gs will be a resonable bet at the moment. -- If EPS files are large (I have some with more or less 1.5 Mb) their conversion and displaying takes all memory and a 64Mb computer simply crashes. With more images of the same size, larger machines crash as well. Was this foreseen? Of course not. Feel free to add you expertise to the development effort. Sorry. It was a bad choice of words. What I meant was, it was surprising that convert dies in a quite ungraceful way. I would appreciate any help, as I want to keep LyX running but currently I also have to explain many things to both management and disappointed students. Let us know if any of this information helps... Surely it helps, the path is getting clearer now. I suppose that trying other ways to avoid convert would be an interesting option, and I intend to spread the word around here. Of course, Jean-Marc's question about how to get 1.5 Mb EPS images is a valid one. The answer: we have a few programs that create images directly in XFig format. From that they can be edited and/or converted into whatever we want. Unfortunately they contain many rectangles and squares represented as polylines in XFig, and when a polyline is exported it produces a surprisingly large PS code. In fact, there is room for improvement in the tools, trying to avoid polylines or changing them to simpler structures. I'll test that too, as it is possible that 4 straight lines have a much shorter description produced by XFig than a polyline. Well, I have to thank again all people that contribute with suggestions to solve the problem... this is the kind of thing that makes LyX so amazing! thank you all, j. b. oliveira
LyX terrible converting images
Hi everyone (specially the folks from the devel team), I would like to raise a few questions about the handling of figures under LyX. Maybe the answers will help me to set LyX properly at our installation, as things are getting out of hand... Some history first: I keep LyX running on a Computer Science Department, with some 20-30 students constantly using LyX on several machines. Everything was fine, until LyX 1.2.0 came along. The problem was, the handling of figures was changed in that version, and from that version onwards the students that work on documents with a larger number of figures (or larger figures) were horrified to see that their documents were taking like 10 minutes (sometimes much longer) to be opened, and the convert processes would take over the machine. Simply opening a document and scrolling down to the editing point would create so many conversions and take up so much memory that using the system is impossible. In fact, situation is so bad that I have already given up LyX myself, at least for documents that have more than a few images. Unfortunately this affected both the work of the students (I saw one of once them waiting for 20 minutes until all conversions were ready) and disastrously affected morale, new students are reluctant to work with LyX. Currently, I am struggling with the administrative powers to keep LyX running, as they are saying that this situation is untenable. The problem is, if things do not get some solution, I'll have to agree with them. Back to 1.1.6 would be very bad. Our machines are neither small nor slow, and LyX (currently 1.3.0) simply makes them stop with the conversion process. So, I went after documentation or details but did not find anything that I could use to accelerate things. I really need to understand what is going on, and maybe someone can answer these questions (and ADD THEM to the current documentation): -- First of all, how does the conversion/display process really works? Specially, how EPS files are handled? (I understand that they are always converted to ppm for displaying? Why ppm?) -- In previous versions EPS files could be displayed rather quickly. Why was their processing slower from 1.2.0 on? -- Is there a way of avoiding the conversion process and handling EPS files directly? -- Is there a way of accelerating the conversion process (if it cannot be avoided)? Are there shortcuts to be used? -- When several images are in the same figure, they *all* get converted at the same time, filling up memory and swap space. At the very least, can this be changed so that we get one conversion at a time, to preserver swap space (and time, as a consequence?) -- If EPS files are large (I have some with more or less 1.5 Mb) their conversion and displaying takes all memory and a 64Mb computer simply crashes. With more images of the same size, larger machines crash as well. Was this foreseen? -- Are we the only ones with such a problem? That is, quite usual LyX files that take terribly long to load completely, fill the swap area and make real editing impossible during the process? There is always the possibility that a piece of software is missing here, and due to this unfortunate conversions take place, but I do not believe that this is the case. I would appreciate any help, as I want to keep LyX running but currently I also have to explain many things to both management and disappointed students. thank you all for any suggestion, j b oliveira
Re: LyX terrible converting images
hi everyone, Some history first: I keep LyX running on a Computer Science... The image handling code in LyX 1.2 is indeed nasty. Things should be much better in LyX 1.3. In LyX 1.3 the conversion process is triggered only for images that have been on screen for 2 seconds, so you should now be able to scroll without any conversion occurring. Well, first of all, thanks for the prompt answer to all these questions... one cannot stop wondering at the patience that the development team puts into answering questions. I have to admit, as we just installed LyX 1.3.0, we are still discovering the points that are causing us problems. For example, the problem about a long time on loading a document was reported for the previous version, not (yet) for 1.3.0. Our machines are neither small nor slow, and LyX (currently 1.3.0) simply makes them stop with the conversion process. I am surprised at this as I would expect only one or two images to be converted at a time (since only one or two images will be visible on the screen at any one time). Well, not really. It is rather common (at least here) to put several smaller images in a figure, to draw comparisons like In Fig 6a you see this, and in 6b we clearly see that, but 6c clearly shows Sometimes we put four or six smaller EPS imagens in a figure. (And it does not look that bad :) -- First of all, how does the conversion/display process really works? Specially, how EPS files are handled? (I understand that they are always converted to ppm for displaying? Why ppm?) By default, we use ImageMagick's 'convert' program, run through a script convertDefault.sh. I too find that 'convert' is very slow. (But this shouldn't really matter. See above.) I have used LyX in -dbg mode and checked the conversion process. It does not seem that LyX itself is doing things badly, but it calls convert for every image on the current screen and convert seems to be doing a bad job, taking up all memory and filling the swap area as well. I attach a modified convertDefault.sh that uses ghostscript to convert eps files to either ppm or png format. Personally, I would use it as the basis for a my_ps2ppm or my_ps2png converter... Thank you! As some initial tests are showing, using gs directly seems to be significantly more efficient than convert. Maybe this was the reason for most of our problems all along. I'll invest on that in the next days. To begin, comparing the shell script you sent (that is, gs) with the traditional convert, regarding time and memory consumption... -- Is there a way of accelerating the conversion process (if it cannot be avoided)? Are there shortcuts to be used? Try using a converter other than ImageMagick's convert. See attached. Ok. I think gs will be a resonable bet at the moment. -- If EPS files are large (I have some with more or less 1.5 Mb) their conversion and displaying takes all memory and a 64Mb computer simply crashes. With more images of the same size, larger machines crash as well. Was this foreseen? Of course not. Feel free to add you expertise to the development effort. Sorry. It was a bad choice of words. What I meant was, it was surprising that convert dies in a quite ungraceful way. I would appreciate any help, as I want to keep LyX running but currently I also have to explain many things to both management and disappointed students. Let us know if any of this information helps... Surely it helps, the path is getting clearer now. I suppose that trying other ways to avoid convert would be an interesting option, and I intend to spread the word around here. Of course, Jean-Marc's question about how to get 1.5 Mb EPS images is a valid one. The answer: we have a few programs that create images directly in XFig format. From that they can be edited and/or converted into whatever we want. Unfortunately they contain many rectangles and squares represented as polylines in XFig, and when a polyline is exported it produces a surprisingly large PS code. In fact, there is room for improvement in the tools, trying to avoid polylines or changing them to simpler structures. I'll test that too, as it is possible that 4 straight lines have a much shorter description produced by XFig than a polyline. Well, I have to thank again all people that contribute with suggestions to solve the problem... this is the kind of thing that makes LyX so amazing! thank you all, j. b. oliveira
LyX terrible converting images
Hi everyone (specially the folks from the devel team), I would like to raise a few questions about the handling of figures under LyX. Maybe the answers will help me to set LyX properly at our installation, as things are getting out of hand... Some history first: I keep LyX running on a Computer Science Department, with some 20-30 students constantly using LyX on several machines. Everything was fine, until LyX 1.2.0 came along. The problem was, the handling of figures was changed in that version, and from that version onwards the students that work on documents with a larger number of figures (or larger figures) were horrified to see that their documents were taking like 10 minutes (sometimes much longer) to be opened, and the convert processes would take over the machine. Simply opening a document and scrolling down to the editing point would create so many conversions and take up so much memory that using the system is impossible. In fact, situation is so bad that I have already given up LyX myself, at least for documents that have more than a few images. Unfortunately this affected both the work of the students (I saw one of once them waiting for 20 minutes until all conversions were ready) and disastrously affected morale, new students are reluctant to work with LyX. Currently, I am struggling with the administrative powers to keep LyX running, as they are saying that this situation is untenable. The problem is, if things do not get some solution, I'll have to agree with them. Back to 1.1.6 would be very bad. Our machines are neither small nor slow, and LyX (currently 1.3.0) simply makes them stop with the conversion process. So, I went after documentation or details but did not find anything that I could use to accelerate things. I really need to understand what is going on, and maybe someone can answer these questions (and ADD THEM to the current documentation): -- First of all, how does the conversion/display process really works? Specially, how EPS files are handled? (I understand that they are always converted to ppm for displaying? Why ppm?) -- In previous versions EPS files could be displayed rather quickly. Why was their processing slower from 1.2.0 on? -- Is there a way of avoiding the conversion process and handling EPS files directly? -- Is there a way of accelerating the conversion process (if it cannot be avoided)? Are there shortcuts to be used? -- When several images are in the same figure, they *all* get converted at the same time, filling up memory and swap space. At the very least, can this be changed so that we get one conversion at a time, to preserver swap space (and time, as a consequence?) -- If EPS files are large (I have some with more or less 1.5 Mb) their conversion and displaying takes all memory and a 64Mb computer simply crashes. With more images of the same size, larger machines crash as well. Was this foreseen? -- Are we the only ones with such a problem? That is, quite usual LyX files that take terribly long to load completely, fill the swap area and make real editing impossible during the process? There is always the possibility that a piece of software is missing here, and due to this unfortunate conversions take place, but I do not believe that this is the case. I would appreciate any help, as I want to keep LyX running but currently I also have to explain many things to both management and disappointed students. thank you all for any suggestion, j b oliveira
Re: LyX terrible converting images
hi everyone, > > Some history first: I keep LyX running on a Computer Science... > > The image handling code in LyX 1.2 is indeed nasty. Things should be much > better in LyX 1.3. In LyX 1.3 the conversion process is triggered only for > images that have been on screen for 2 seconds, so you should now be able to > scroll without any conversion occurring. Well, first of all, thanks for the prompt answer to all these questions... one cannot stop wondering at the patience that the development team puts into answering questions. I have to admit, as we just installed LyX 1.3.0, we are still discovering the points that are causing us problems. For example, the problem about a long time on loading a document was reported for the previous version, not (yet) for 1.3.0. > > Our machines are neither small nor slow, and LyX (currently 1.3.0) > > simply makes them stop with the conversion process. > > I am surprised at this as I would expect only one or two images to be > converted at a time (since only one or two images will be visible on the > screen at any one time). Well, not really. It is rather common (at least here) to put several smaller images in a figure, to draw comparisons like "In Fig 6a you see this, and in 6b we clearly see that, but 6c clearly shows...". Sometimes we put four or six smaller EPS imagens in a figure. (And it does not look that bad :) > > -- First of all, how does the conversion/display process really > > works? Specially, how EPS files are handled? (I understand that > > they are always converted to ppm for displaying? Why ppm?) > > By default, we use ImageMagick's 'convert' program, run through a script > convertDefault.sh. I too find that 'convert' is very slow. (But this > shouldn't really matter. See above.) I have used LyX in -dbg mode and checked the conversion process. It does not seem that LyX itself is doing things badly, but it calls convert for every image on the current screen and convert seems to be doing a bad job, taking up all memory and filling the swap area as well. > I attach a modified convertDefault.sh that uses ghostscript to convert eps > files to either ppm or png format. Personally, I would use it as the basis > for a my_ps2ppm or my_ps2png converter... Thank you! As some initial tests are showing, using gs directly seems to be significantly more efficient than convert. Maybe this was the reason for most of our problems all along. I'll invest on that in the next days. To begin, comparing the shell script you sent (that is, gs) with the traditional convert, regarding time and memory consumption... > > -- Is there a way of accelerating the conversion process (if it > > cannot be avoided)? Are there shortcuts to be used? > > Try using a converter other than ImageMagick's convert. See attached. Ok. I think gs will be a resonable bet at the moment. > > -- If EPS files are large (I have some with more or less 1.5 Mb) > > their conversion and displaying takes all memory and a 64Mb computer > > simply crashes. With more images of the same size, larger machines > > crash as well. Was this foreseen? > > Of course not. Feel free to add you expertise to the development effort. Sorry. It was a bad choice of words. What I meant was, it was surprising that convert dies in a quite ungraceful way. > > I would appreciate any help, as I want to keep LyX running but > > currently I also have to explain many things to both management > > and disappointed students. > > Let us know if any of this information helps... Surely it helps, the path is getting clearer now. I suppose that trying other ways to avoid convert would be an interesting option, and I intend to spread the word around here. Of course, Jean-Marc's question about how to get 1.5 Mb EPS images is a valid one. The answer: we have a few programs that create images directly in XFig format. From that they can be edited and/or converted into whatever we want. Unfortunately they contain many rectangles and squares represented as "polylines" in XFig, and when a polyline is exported it produces a surprisingly large PS code. In fact, there is room for improvement in the tools, trying to avoid polylines or changing them to simpler structures. I'll test that too, as it is possible that 4 straight lines have a much shorter description produced by XFig than a polyline. Well, I have to thank again all people that contribute with suggestions to solve the problem... this is the kind of thing that makes LyX so amazing! thank you all, j. b. oliveira
ld error compiling Lyx 1.3.0
hi folks, I am compiling LyX 1.3.0 for Debian, and everything went ok up to a point where ld is getting confused. It does not handle well two files, and the corresponding libraries seem to get corrupted. Does anyone has seen something like this? I am using gcc 3.2 and ld 1.23, everything was fine for the previous LyX version... Here is the critical output of make: ... g++ -O -fno-exceptions -o lyx BufferView.o BufferView_pimpl.o Bullet.o Chktex.o CutAndPaste.o DepTa ble.o FloatList.o Floating.o FuncStatus.o InsetList.o LColor.o LaTeX.o LaTeXFeatures.o LyXAction.o MenuBackend.o paragraph_funcs.o ParagraphList.o ParagraphParameters.o Spacing.o TextCache.o Thesaur us.o ToolbarDefaults.o boost.o boost-inst.o box.o buffer.o bufferlist.o bufferparams.o bufferview_f uncs.o chset.o converter.o counters.o debug.o encoding.o exporter.o gettext.o factory.o funcrequest .o importer.o intl.o iterators.o kbmap.o kbsequence.o language.o lastfiles.o lengthcommon.o lyx_cb. o lyx_main.o lyx_sty.o lyxcursor.o lyxfont.o lyxfind.o lyxfunc.o lyxgluelength.o lyxlayout.o lyxlen gth.o lyxlex.o lyxlex_pimpl.o lyxrc.o lyxrow.o lyxserver.o lyxtextclass.o lyxtextclasslist.o lyxvc. o main.o paragraph.o paragraph_pimpl.o ispell.o pspell.o sgml.o tabular.o tabular-old.o tabular_fun cs.o tex-accent.o tex-strings.o texrow.o text.o text2.o text3.o toc.o trans.o trans_mgr.! o undo.o un do_funcs.o vc-backend.o version.o vspace.o mathed/.libs/libmathed.a insets/.libs/libinsets.a front ends/.libs/libfrontends.a -lflimage /usr/local/lib/libjpeg.so -lforms -lXpm graphics/.libs/libgraph ics.a support/.libs/libsupport.a ../boost/libs/regex/src/.libs/libboostregex.a ../boost/libs/signal s/src/.libs/libboostsignals.a -lSM -lICE -lc -lm -L/usr/X11R6/lib -lX11 -Wl,--rpath -Wl,/usr/local/ lib -Wl,--rpath -Wl,/usr/local/lib chset.o(.rodata+0x8): relocation truncated to fit: GPREL32 *UND* chset.o(.rodata+0xc): relocation truncated to fit: GPREL32 *UND* chset.o(.rodata+0x10): relocation truncated to fit: GPREL32 *UND* chset.o(.rodata+0x14): relocation truncated to fit: GPREL32 *UND* chset.o(.rodata+0x18): relocation truncated to fit: GPREL32 *UND* chset.o(.rodata+0x1c): relocation truncated to fit: GPREL32 *UND* ... vc-backend.o(.rodata+0x8): relocation truncated to fit: GPREL32 *UND* vc-backend.o(.rodata+0xc): relocation truncated to fit: GPREL32 *UND* vc-backend.o(.rodata+0x10): relocation truncated to fit: GPREL32 *UND* vc-backend.o(.rodata+0x14): relocation truncated to fit: GPREL32 *UND* vc-backend.o(.rodata+0x18): relocation truncated to fit: GPREL32 *UND* ... support/.libs/libsupport.a(lstrings.o)(.rodata+0x10): relocation truncated to fit: GPREL32 *UND* support/.libs/libsupport.a(lstrings.o)(.rodata+0x14): relocation truncated to fit: GPREL32 *UND* support/.libs/libsupport.a(lstrings.o)(.rodata+0x18): relocation truncated to fit: GPREL32 *UND* support/.libs/libsupport.a(lstrings.o)(.rodata+0x1c): relocation truncated to fit: GPREL32 *UND* support/.libs/libsupport.a(lstrings.o)(.rodata+0x20): relocation truncated to fit: GPREL32 *UND* ... ../boost/libs/regex/src/.libs/libboostregex.a(cregex.o)(.rodata+0x2a4): relocation truncated to fit : GPREL32 *UND* ../boost/libs/regex/src/.libs/libboostregex.a(cregex.o)(.rodata+0x2a8): relocation truncated to fit : GPREL32 *UND* ../boost/libs/regex/src/.libs/libboostregex.a(cregex.o)(.rodata+0x2ac): relocation truncated to fit : GPREL32 *UND* ../boost/libs/regex/src/.libs/libboostregex.a(cregex.o)(.rodata+0x2b0): relocation truncated to fit : GPREL32 *UND* thanks for any hint, joao b. oliveira
ld problem solved
I was compiling LyX 1.3.0 for Debian, and everything went ok up to a point where ld got confused. It does not handle well two files, and the corresponding libraries seem to get corrupted. The problem occurred at this command: g++ -O -fno-exceptions -o lyx BufferView.o BufferView_pimpl.o Bullet.o Chktex.o CutAndPaste.o DepTa ble.o FloatList.o Floating.o FuncStatus.o InsetList.o LColor.o LaTeX.o LaTeXFeatures.o LyXAction.o MenuBackend.o paragraph_funcs.o ParagraphList.o ParagraphParameters.o Spacing.o TextCache.o Thesaur us.o ToolbarDefaults.o boost.o boost-inst.o box.o buffer.o bufferlist.o bufferparams.o bufferview_f uncs.o chset.o converter.o counters.o debug.o encoding.o exporter.o gettext.o factory.o funcrequest .o importer.o intl.o iterators.o kbmap.o kbsequence.o language.o lastfiles.o lengthcommon.o lyx_cb. o lyx_main.o lyx_sty.o lyxcursor.o lyxfont.o lyxfind.o lyxfunc.o lyxgluelength.o lyxlayout.o lyxlen gth.o lyxlex.o lyxlex_pimpl.o lyxrc.o lyxrow.o lyxserver.o lyxtextclass.o lyxtextclasslist.o lyxvc. o main.o paragraph.o paragraph_pimpl.o ispell.o pspell.o sgml.o tabular.o tabular-old.o tabular_fun cs.o tex-accent.o tex-strings.o texrow.o text.o text2.o text3.o toc.o trans.o trans_mgr.! o undo.o un do_funcs.o vc-backend.o version.o vspace.o mathed/.libs/libmathed.a insets/.libs/libinsets.a front ends/.libs/libfrontends.a -lflimage /usr/local/lib/libjpeg.so -lforms -lXpm graphics/.libs/libgraph ics.a support/.libs/libsupport.a ../boost/libs/regex/src/.libs/libboostregex.a ../boost/libs/signal s/src/.libs/libboostsignals.a -lSM -lICE -lc -lm -L/usr/X11R6/lib -lX11 -Wl,--rpath -Wl,/usr/local/ lib -Wl,--rpath -Wl,/usr/local/lib chset.o(.rodata+0x8): relocation truncated to fit: GPREL32 *UND* chset.o(.rodata+0xc): relocation truncated to fit: GPREL32 *UND* chset.o(.rodata+0x10): relocation truncated to fit: GPREL32 *UND* ... several error messages like that... Well, I do not know *why*, but adding a flag -Wl,-t at the end of the g++ command line did the job and everything went ok. The dummy thing is, it just says to the linker to trace the files, that is, print their names as they are processed. Should have no practical effect. For the sake of completeness, someone has any hints? j b oliveira
ld error compiling Lyx 1.3.0
hi folks, I am compiling LyX 1.3.0 for Debian, and everything went ok up to a point where ld is getting confused. It does not handle well two files, and the corresponding libraries seem to get corrupted. Does anyone has seen something like this? I am using gcc 3.2 and ld 1.23, everything was fine for the previous LyX version... Here is the critical output of make: ... g++ -O -fno-exceptions -o lyx BufferView.o BufferView_pimpl.o Bullet.o Chktex.o CutAndPaste.o DepTa ble.o FloatList.o Floating.o FuncStatus.o InsetList.o LColor.o LaTeX.o LaTeXFeatures.o LyXAction.o MenuBackend.o paragraph_funcs.o ParagraphList.o ParagraphParameters.o Spacing.o TextCache.o Thesaur us.o ToolbarDefaults.o boost.o boost-inst.o box.o buffer.o bufferlist.o bufferparams.o bufferview_f uncs.o chset.o converter.o counters.o debug.o encoding.o exporter.o gettext.o factory.o funcrequest .o importer.o intl.o iterators.o kbmap.o kbsequence.o language.o lastfiles.o lengthcommon.o lyx_cb. o lyx_main.o lyx_sty.o lyxcursor.o lyxfont.o lyxfind.o lyxfunc.o lyxgluelength.o lyxlayout.o lyxlen gth.o lyxlex.o lyxlex_pimpl.o lyxrc.o lyxrow.o lyxserver.o lyxtextclass.o lyxtextclasslist.o lyxvc. o main.o paragraph.o paragraph_pimpl.o ispell.o pspell.o sgml.o tabular.o tabular-old.o tabular_fun cs.o tex-accent.o tex-strings.o texrow.o text.o text2.o text3.o toc.o trans.o trans_mgr.! o undo.o un do_funcs.o vc-backend.o version.o vspace.o mathed/.libs/libmathed.a insets/.libs/libinsets.a front ends/.libs/libfrontends.a -lflimage /usr/local/lib/libjpeg.so -lforms -lXpm graphics/.libs/libgraph ics.a support/.libs/libsupport.a ../boost/libs/regex/src/.libs/libboostregex.a ../boost/libs/signal s/src/.libs/libboostsignals.a -lSM -lICE -lc -lm -L/usr/X11R6/lib -lX11 -Wl,--rpath -Wl,/usr/local/ lib -Wl,--rpath -Wl,/usr/local/lib chset.o(.rodata+0x8): relocation truncated to fit: GPREL32 *UND* chset.o(.rodata+0xc): relocation truncated to fit: GPREL32 *UND* chset.o(.rodata+0x10): relocation truncated to fit: GPREL32 *UND* chset.o(.rodata+0x14): relocation truncated to fit: GPREL32 *UND* chset.o(.rodata+0x18): relocation truncated to fit: GPREL32 *UND* chset.o(.rodata+0x1c): relocation truncated to fit: GPREL32 *UND* ... vc-backend.o(.rodata+0x8): relocation truncated to fit: GPREL32 *UND* vc-backend.o(.rodata+0xc): relocation truncated to fit: GPREL32 *UND* vc-backend.o(.rodata+0x10): relocation truncated to fit: GPREL32 *UND* vc-backend.o(.rodata+0x14): relocation truncated to fit: GPREL32 *UND* vc-backend.o(.rodata+0x18): relocation truncated to fit: GPREL32 *UND* ... support/.libs/libsupport.a(lstrings.o)(.rodata+0x10): relocation truncated to fit: GPREL32 *UND* support/.libs/libsupport.a(lstrings.o)(.rodata+0x14): relocation truncated to fit: GPREL32 *UND* support/.libs/libsupport.a(lstrings.o)(.rodata+0x18): relocation truncated to fit: GPREL32 *UND* support/.libs/libsupport.a(lstrings.o)(.rodata+0x1c): relocation truncated to fit: GPREL32 *UND* support/.libs/libsupport.a(lstrings.o)(.rodata+0x20): relocation truncated to fit: GPREL32 *UND* ... ../boost/libs/regex/src/.libs/libboostregex.a(cregex.o)(.rodata+0x2a4): relocation truncated to fit : GPREL32 *UND* ../boost/libs/regex/src/.libs/libboostregex.a(cregex.o)(.rodata+0x2a8): relocation truncated to fit : GPREL32 *UND* ../boost/libs/regex/src/.libs/libboostregex.a(cregex.o)(.rodata+0x2ac): relocation truncated to fit : GPREL32 *UND* ../boost/libs/regex/src/.libs/libboostregex.a(cregex.o)(.rodata+0x2b0): relocation truncated to fit : GPREL32 *UND* thanks for any hint, joao b. oliveira
ld problem solved
I was compiling LyX 1.3.0 for Debian, and everything went ok up to a point where ld got confused. It does not handle well two files, and the corresponding libraries seem to get corrupted. The problem occurred at this command: g++ -O -fno-exceptions -o lyx BufferView.o BufferView_pimpl.o Bullet.o Chktex.o CutAndPaste.o DepTa ble.o FloatList.o Floating.o FuncStatus.o InsetList.o LColor.o LaTeX.o LaTeXFeatures.o LyXAction.o MenuBackend.o paragraph_funcs.o ParagraphList.o ParagraphParameters.o Spacing.o TextCache.o Thesaur us.o ToolbarDefaults.o boost.o boost-inst.o box.o buffer.o bufferlist.o bufferparams.o bufferview_f uncs.o chset.o converter.o counters.o debug.o encoding.o exporter.o gettext.o factory.o funcrequest .o importer.o intl.o iterators.o kbmap.o kbsequence.o language.o lastfiles.o lengthcommon.o lyx_cb. o lyx_main.o lyx_sty.o lyxcursor.o lyxfont.o lyxfind.o lyxfunc.o lyxgluelength.o lyxlayout.o lyxlen gth.o lyxlex.o lyxlex_pimpl.o lyxrc.o lyxrow.o lyxserver.o lyxtextclass.o lyxtextclasslist.o lyxvc. o main.o paragraph.o paragraph_pimpl.o ispell.o pspell.o sgml.o tabular.o tabular-old.o tabular_fun cs.o tex-accent.o tex-strings.o texrow.o text.o text2.o text3.o toc.o trans.o trans_mgr.! o undo.o un do_funcs.o vc-backend.o version.o vspace.o mathed/.libs/libmathed.a insets/.libs/libinsets.a front ends/.libs/libfrontends.a -lflimage /usr/local/lib/libjpeg.so -lforms -lXpm graphics/.libs/libgraph ics.a support/.libs/libsupport.a ../boost/libs/regex/src/.libs/libboostregex.a ../boost/libs/signal s/src/.libs/libboostsignals.a -lSM -lICE -lc -lm -L/usr/X11R6/lib -lX11 -Wl,--rpath -Wl,/usr/local/ lib -Wl,--rpath -Wl,/usr/local/lib chset.o(.rodata+0x8): relocation truncated to fit: GPREL32 *UND* chset.o(.rodata+0xc): relocation truncated to fit: GPREL32 *UND* chset.o(.rodata+0x10): relocation truncated to fit: GPREL32 *UND* ... several error messages like that... Well, I do not know *why*, but adding a flag -Wl,-t at the end of the g++ command line did the job and everything went ok. The dummy thing is, it just says to the linker to trace the files, that is, print their names as they are processed. Should have no practical effect. For the sake of completeness, someone has any hints? j b oliveira
ld error compiling Lyx 1.3.0
hi folks, I am compiling LyX 1.3.0 for Debian, and everything went ok up to a point where ld is getting confused. It does not handle well two files, and the corresponding libraries seem to get corrupted. Does anyone has seen something like this? I am using gcc 3.2 and ld 1.23, everything was fine for the previous LyX version... Here is the critical output of make: ... g++ -O -fno-exceptions -o lyx BufferView.o BufferView_pimpl.o Bullet.o Chktex.o CutAndPaste.o DepTa ble.o FloatList.o Floating.o FuncStatus.o InsetList.o LColor.o LaTeX.o LaTeXFeatures.o LyXAction.o MenuBackend.o paragraph_funcs.o ParagraphList.o ParagraphParameters.o Spacing.o TextCache.o Thesaur us.o ToolbarDefaults.o boost.o boost-inst.o box.o buffer.o bufferlist.o bufferparams.o bufferview_f uncs.o chset.o converter.o counters.o debug.o encoding.o exporter.o gettext.o factory.o funcrequest .o importer.o intl.o iterators.o kbmap.o kbsequence.o language.o lastfiles.o lengthcommon.o lyx_cb. o lyx_main.o lyx_sty.o lyxcursor.o lyxfont.o lyxfind.o lyxfunc.o lyxgluelength.o lyxlayout.o lyxlen gth.o lyxlex.o lyxlex_pimpl.o lyxrc.o lyxrow.o lyxserver.o lyxtextclass.o lyxtextclasslist.o lyxvc. o main.o paragraph.o paragraph_pimpl.o ispell.o pspell.o sgml.o tabular.o tabular-old.o tabular_fun cs.o tex-accent.o tex-strings.o texrow.o text.o text2.o text3.o toc.o trans.o trans_mgr.! o undo.o un do_funcs.o vc-backend.o version.o vspace.o mathed/.libs/libmathed.a insets/.libs/libinsets.a front ends/.libs/libfrontends.a -lflimage /usr/local/lib/libjpeg.so -lforms -lXpm graphics/.libs/libgraph ics.a support/.libs/libsupport.a ../boost/libs/regex/src/.libs/libboostregex.a ../boost/libs/signal s/src/.libs/libboostsignals.a -lSM -lICE -lc -lm -L/usr/X11R6/lib -lX11 -Wl,--rpath -Wl,/usr/local/ lib -Wl,--rpath -Wl,/usr/local/lib chset.o(.rodata+0x8): relocation truncated to fit: GPREL32 *UND* chset.o(.rodata+0xc): relocation truncated to fit: GPREL32 *UND* chset.o(.rodata+0x10): relocation truncated to fit: GPREL32 *UND* chset.o(.rodata+0x14): relocation truncated to fit: GPREL32 *UND* chset.o(.rodata+0x18): relocation truncated to fit: GPREL32 *UND* chset.o(.rodata+0x1c): relocation truncated to fit: GPREL32 *UND* ... vc-backend.o(.rodata+0x8): relocation truncated to fit: GPREL32 *UND* vc-backend.o(.rodata+0xc): relocation truncated to fit: GPREL32 *UND* vc-backend.o(.rodata+0x10): relocation truncated to fit: GPREL32 *UND* vc-backend.o(.rodata+0x14): relocation truncated to fit: GPREL32 *UND* vc-backend.o(.rodata+0x18): relocation truncated to fit: GPREL32 *UND* ... support/.libs/libsupport.a(lstrings.o)(.rodata+0x10): relocation truncated to fit: GPREL32 *UND* support/.libs/libsupport.a(lstrings.o)(.rodata+0x14): relocation truncated to fit: GPREL32 *UND* support/.libs/libsupport.a(lstrings.o)(.rodata+0x18): relocation truncated to fit: GPREL32 *UND* support/.libs/libsupport.a(lstrings.o)(.rodata+0x1c): relocation truncated to fit: GPREL32 *UND* support/.libs/libsupport.a(lstrings.o)(.rodata+0x20): relocation truncated to fit: GPREL32 *UND* ... ../boost/libs/regex/src/.libs/libboostregex.a(cregex.o)(.rodata+0x2a4): relocation truncated to fit : GPREL32 *UND* ../boost/libs/regex/src/.libs/libboostregex.a(cregex.o)(.rodata+0x2a8): relocation truncated to fit : GPREL32 *UND* ../boost/libs/regex/src/.libs/libboostregex.a(cregex.o)(.rodata+0x2ac): relocation truncated to fit : GPREL32 *UND* ../boost/libs/regex/src/.libs/libboostregex.a(cregex.o)(.rodata+0x2b0): relocation truncated to fit : GPREL32 *UND* thanks for any hint, joao b. oliveira
ld problem solved
I was compiling LyX 1.3.0 for Debian, and everything went ok up to a point where ld got confused. It does not handle well two files, and the corresponding libraries seem to get corrupted. The problem occurred at this command: g++ -O -fno-exceptions -o lyx BufferView.o BufferView_pimpl.o Bullet.o Chktex.o CutAndPaste.o DepTa ble.o FloatList.o Floating.o FuncStatus.o InsetList.o LColor.o LaTeX.o LaTeXFeatures.o LyXAction.o MenuBackend.o paragraph_funcs.o ParagraphList.o ParagraphParameters.o Spacing.o TextCache.o Thesaur us.o ToolbarDefaults.o boost.o boost-inst.o box.o buffer.o bufferlist.o bufferparams.o bufferview_f uncs.o chset.o converter.o counters.o debug.o encoding.o exporter.o gettext.o factory.o funcrequest .o importer.o intl.o iterators.o kbmap.o kbsequence.o language.o lastfiles.o lengthcommon.o lyx_cb. o lyx_main.o lyx_sty.o lyxcursor.o lyxfont.o lyxfind.o lyxfunc.o lyxgluelength.o lyxlayout.o lyxlen gth.o lyxlex.o lyxlex_pimpl.o lyxrc.o lyxrow.o lyxserver.o lyxtextclass.o lyxtextclasslist.o lyxvc. o main.o paragraph.o paragraph_pimpl.o ispell.o pspell.o sgml.o tabular.o tabular-old.o tabular_fun cs.o tex-accent.o tex-strings.o texrow.o text.o text2.o text3.o toc.o trans.o trans_mgr.! o undo.o un do_funcs.o vc-backend.o version.o vspace.o mathed/.libs/libmathed.a insets/.libs/libinsets.a front ends/.libs/libfrontends.a -lflimage /usr/local/lib/libjpeg.so -lforms -lXpm graphics/.libs/libgraph ics.a support/.libs/libsupport.a ../boost/libs/regex/src/.libs/libboostregex.a ../boost/libs/signal s/src/.libs/libboostsignals.a -lSM -lICE -lc -lm -L/usr/X11R6/lib -lX11 -Wl,--rpath -Wl,/usr/local/ lib -Wl,--rpath -Wl,/usr/local/lib chset.o(.rodata+0x8): relocation truncated to fit: GPREL32 *UND* chset.o(.rodata+0xc): relocation truncated to fit: GPREL32 *UND* chset.o(.rodata+0x10): relocation truncated to fit: GPREL32 *UND* ... several error messages like that... Well, I do not know *why*, but adding a flag -Wl,-t at the end of the g++ command line did the job and everything went ok. The dummy thing is, it just says to the linker to trace the files, that is, print their names as they are processed. Should have no practical effect. For the sake of completeness, someone has any hints? j b oliveira
Re: LyX not rendering graphics
I had a similar problem, but I was under RH 7.0: graphics would *never* show up under Lyx 1.2.1. This weekend I got pissed about it and after a while I came to the idea of reinstalling ImageMagick, uploading from 5.3.3. to 5.5.*. It worked... seems that convert was failing before. In any case there is room for improvement in the way images are handled now, because the text jumps to the beginning when a new image is rendered, and the conversion process takes a long time in a document with several of them. Maybe the procedures should be reviewed somehow.. jb Since more than a year I have watched the list and the discussion concerning the problem that LyX renders graphics only sporadically on fast computers - I still have the problem and tried the sporadic tips to solve the problem - without success for SuSE 7.3 and SuSE 8.0. I have tried to update from 1.1.6 to 1.2.1, but was unable to compile the sources - because of the cc1plus error. Now I have succeeded in part and feel that there might be somebody ou t there knowing the ultimate solution. Here is what I did: When I asked to check the dependencies, the output was: # rpm -Uvh lyx-1.2.1-1rh8-xforms089.i386.rpm error: failed dependencies: tetex-xdvi is needed by lyx-1.2.1-1 tetex-latex is needed by lyx-1.2.1-1 libstdc++.so.5 is needed by lyx-1.2.1-1 libstdc++.so.5(GLIBCPP_3.2) is needed by lyx-1.2.1-1 perl(Cwd) is needed by lyx-1.2.1-1 perl(File::Basename) is needed by lyx-1.2.1-1 perl(FileHandle) is needed by lyx-1.2.1-1 perl(lib) is needed by lyx-1.2.1-1 perl(strict) is needed by lyx-1.2.1-1 perl(vars) is needed by lyx-1.2.1-1 So I installed 1.2.1 from the binary rpm using --nodeps and supplied both libstdc++.so.5.0.0 and libgcc_s.so.1 in /usr/lib (moreover, a symbolic link to libstdc++.so.5 was generated and ldconfig was run). Now LyX 1.2.1 works fine (even xdvi and PDF output), but I do not even see graphics sporadically any more. Instead I get an error message in each graphics box telling me that the conversion into a display format failed. In fact, the message is in German and reads Fehler bei der Konvertierung in ei n darstellbares Format Norbert I'm in a similar (sinking) boat. In previous versions of LyX, the graphics would almost always render. At most, I would just have to restart LyX and rendering would work again. Now that I've installed 1.2.1 for RH 8.0 and using xforms 0.89 (after upgrading to RH 8.0), rendering just does NOT work at all. (Not quite true - it doesn't work on eps files created by R.) This is on three Intel PCs all running RH 8.0 (one is a laptop, the other two are desktop systems). I can't be sure the problem doesn't have something to do with Redhat 8.0. Or it may be that all the eps files I'm creating come from R (they used to render OK and they are eps files.) But I cannot fix it and have seen NOTHING on the list that has helped. Someone did suggest turning on debuggind (lyx -dbg graphics or lyx -dbg any) but that just tells me the conversion doesn't work - even though all the software needed for the conversion is readily available on all three systems - I can do it manually - and if the conversion wasn't in the preferences I added it. LyX installed differently on each system. On at least one I had to even get it to just view in PS and PDF. Viewing in HTML gives a screwy message about the file name having more than one period and that dvips can't handle it. I have to rename the file so there is only one period. Fortunately I guess I can live without rendering in LyX just so long as it prints and views OK. Just for your information, I always use rpm -U --test before actually installing the binary. rpm never reported any problem either in test mode or when I actually installed the software. There were no conflicts and it didn't complain about any missing software - LyX installed (as it had in the past) without any error messages or warnings. Everything seems to work except for rendering (and viewing on one system) out of the box. At least for me, the rendering error message is in English. I miss the days when I could just install a new version of LyX and continue doing actual work. If anyone can explain how to fix this I would certainly appreciate it. Rick B.
Re: LyX not rendering graphics
I had a similar problem, but I was under RH 7.0: graphics would *never* show up under Lyx 1.2.1. This weekend I got pissed about it and after a while I came to the idea of reinstalling ImageMagick, uploading from 5.3.3. to 5.5.*. It worked... seems that convert was failing before. In any case there is room for improvement in the way images are handled now, because the text jumps to the beginning when a new image is rendered, and the conversion process takes a long time in a document with several of them. Maybe the procedures should be reviewed somehow.. jb Since more than a year I have watched the list and the discussion concerning the problem that LyX renders graphics only sporadically on fast computers - I still have the problem and tried the sporadic tips to solve the problem - without success for SuSE 7.3 and SuSE 8.0. I have tried to update from 1.1.6 to 1.2.1, but was unable to compile the sources - because of the cc1plus error. Now I have succeeded in part and feel that there might be somebody ou t there knowing the ultimate solution. Here is what I did: When I asked to check the dependencies, the output was: # rpm -Uvh lyx-1.2.1-1rh8-xforms089.i386.rpm error: failed dependencies: tetex-xdvi is needed by lyx-1.2.1-1 tetex-latex is needed by lyx-1.2.1-1 libstdc++.so.5 is needed by lyx-1.2.1-1 libstdc++.so.5(GLIBCPP_3.2) is needed by lyx-1.2.1-1 perl(Cwd) is needed by lyx-1.2.1-1 perl(File::Basename) is needed by lyx-1.2.1-1 perl(FileHandle) is needed by lyx-1.2.1-1 perl(lib) is needed by lyx-1.2.1-1 perl(strict) is needed by lyx-1.2.1-1 perl(vars) is needed by lyx-1.2.1-1 So I installed 1.2.1 from the binary rpm using --nodeps and supplied both libstdc++.so.5.0.0 and libgcc_s.so.1 in /usr/lib (moreover, a symbolic link to libstdc++.so.5 was generated and ldconfig was run). Now LyX 1.2.1 works fine (even xdvi and PDF output), but I do not even see graphics sporadically any more. Instead I get an error message in each graphics box telling me that the conversion into a display format failed. In fact, the message is in German and reads Fehler bei der Konvertierung in ei n darstellbares Format Norbert I'm in a similar (sinking) boat. In previous versions of LyX, the graphics would almost always render. At most, I would just have to restart LyX and rendering would work again. Now that I've installed 1.2.1 for RH 8.0 and using xforms 0.89 (after upgrading to RH 8.0), rendering just does NOT work at all. (Not quite true - it doesn't work on eps files created by R.) This is on three Intel PCs all running RH 8.0 (one is a laptop, the other two are desktop systems). I can't be sure the problem doesn't have something to do with Redhat 8.0. Or it may be that all the eps files I'm creating come from R (they used to render OK and they are eps files.) But I cannot fix it and have seen NOTHING on the list that has helped. Someone did suggest turning on debuggind (lyx -dbg graphics or lyx -dbg any) but that just tells me the conversion doesn't work - even though all the software needed for the conversion is readily available on all three systems - I can do it manually - and if the conversion wasn't in the preferences I added it. LyX installed differently on each system. On at least one I had to even get it to just view in PS and PDF. Viewing in HTML gives a screwy message about the file name having more than one period and that dvips can't handle it. I have to rename the file so there is only one period. Fortunately I guess I can live without rendering in LyX just so long as it prints and views OK. Just for your information, I always use rpm -U --test before actually installing the binary. rpm never reported any problem either in test mode or when I actually installed the software. There were no conflicts and it didn't complain about any missing software - LyX installed (as it had in the past) without any error messages or warnings. Everything seems to work except for rendering (and viewing on one system) out of the box. At least for me, the rendering error message is in English. I miss the days when I could just install a new version of LyX and continue doing actual work. If anyone can explain how to fix this I would certainly appreciate it. Rick B.
Re: LyX not rendering graphics
I had a similar problem, but I was under RH 7.0: graphics would
*never* show up under Lyx 1.2.1.
This weekend I got pissed about it and after a while I came to the
idea of reinstalling ImageMagick, uploading from 5.3.3. to 5.5.*.
It worked... seems that "convert" was failing before.
In any case there is room for improvement in the way images are
handled now, because the text jumps to the beginning when a new
image is rendered, and the conversion process takes a long time
in a document with several of them. Maybe the procedures should be
reviewed somehow..
jb
>
> >Since more than a year I have watched the list and the discussion concerning
> >the problem that LyX renders graphics only sporadically on fast computers -
> I
> >still have the problem and tried the sporadic tips to solve the problem -
> >without success for SuSE 7.3 and SuSE 8.0. I have tried to update from 1.1.6
>
> >to 1.2.1, but was unable to compile the sources - because of the cc1plus
> >error. Now I have succeeded in part and feel that there might be somebody ou
> t
> >there knowing the ultimate solution. Here is what I did:
> >
> >When I asked to check the dependencies, the output was:
> ># rpm -Uvh lyx-1.2.1-1rh8-xforms089.i386.rpm
> >error: failed dependencies:
> >tetex-xdvi is needed by lyx-1.2.1-1
> >tetex-latex is needed by lyx-1.2.1-1
> >libstdc++.so.5 is needed by lyx-1.2.1-1
> >libstdc++.so.5(GLIBCPP_3.2) is needed by lyx-1.2.1-1
> >perl(Cwd) is needed by lyx-1.2.1-1
> >perl(File::Basename) is needed by lyx-1.2.1-1
> >perl(FileHandle) is needed by lyx-1.2.1-1
> >perl(lib) is needed by lyx-1.2.1-1
> >perl(strict) is needed by lyx-1.2.1-1
> >perl(vars) is needed by lyx-1.2.1-1
> >
> >So I installed 1.2.1 from the binary rpm using --nodeps and supplied both
> >libstdc++.so.5.0.0 and libgcc_s.so.1 in /usr/lib (moreover, a symbolic link
> >to libstdc++.so.5 was generated and ldconfig was run).
> >
> >Now LyX 1.2.1 works fine (even xdvi and PDF output), but I do not even see
> >graphics sporadically any more. Instead I get an error message in each
> >graphics box telling me that the conversion into a display format failed. In
>
> >fact, the message is in German and reads "Fehler bei der Konvertierung in ei
> n
> >darstellbares Format"
> >
> >Norbert
> >
> >
> I'm in a similar (sinking) boat. In previous versions of LyX, the
> graphics would almost always render. At most, I would just have to
> restart LyX and rendering would work again. Now that I've installed
> 1.2.1 for RH 8.0 and using xforms 0.89 (after upgrading to RH 8.0),
> rendering just does NOT work at all. (Not quite true - it doesn't work
> on eps files created by R.) This is on three Intel PCs all running RH
> 8.0 (one is a laptop, the other two are desktop systems). I can't be
> sure the problem doesn't have something to do with Redhat 8.0. Or it may
> be that all the eps files I'm creating come from R (they used to render
> OK and they are eps files.) But I cannot fix it and have seen NOTHING on
> the list that has helped. Someone did suggest turning on debuggind ("lyx
> -dbg graphics" or "lyx -dbg any") but that just tells me the conversion
> doesn't work - even though all the software needed for the conversion is
> readily available on all three systems - I can do it manually - and if
> the conversion wasn't in the preferences I added it. LyX installed
> differently on each system. On at least one I had to even get it to just
> view in PS and PDF. Viewing in HTML gives a screwy message about the
> file name having more than one period and that dvips can't handle it. I
> have to rename the file so there is only one period. Fortunately I guess
> I can live without rendering in LyX just so long as it prints and views OK.
>
> Just for your information, I always use "rpm -U --test" before actually
> installing the binary. rpm never reported any problem either in test
> mode or when I actually installed the software. There were no conflicts
> and it didn't complain about any missing software - LyX installed (as it
> had in the past) without any error messages or warnings. Everything
> seems to work except for rendering (and viewing on one system) out of
> the box.
>
> At least for me, the rendering error message is in English. I miss the
> days when I could just install a new version of LyX and continue doing
> actual work.
>
> If anyone can explain how to fix this I would certainly appreciate it.
>
> Rick B.
>
>
Re: figures in Lyx 1.2.1
I have the same problem, and Takashi Soma told me that a solution would be downgrading to gs 4.03. I did not try it yet, however. In any case, I can get the lyx -version info at home and add it to the discussion to find out why loading images fails... joao R Hi, R I am using Lyx 1.2.1 in Sun OS 5.6. When a document is opened, I R cannot see the figures; instead it says Error scaling etc inside R the figure box. Also, I get the following error message in the R command prompt: R Error creating pixmap from xpm_image 'XpmColorFailed' R I could see the figures under Lyx 1.1.6 and this happened after R installing 1.2.1. R Could somebody help. What does 'lyx -version' say? (what I want to know is your version of xforms, and whethe rthe xforms image loader is in use) JMarc
Re: figures in Lyx 1.2.1
I have the same problem, and Takashi Soma told me that a solution would be downgrading to gs 4.03. I did not try it yet, however. In any case, I can get the lyx -version info at home and add it to the discussion to find out why loading images fails... joao R Hi, R I am using Lyx 1.2.1 in Sun OS 5.6. When a document is opened, I R cannot see the figures; instead it says Error scaling etc inside R the figure box. Also, I get the following error message in the R command prompt: R Error creating pixmap from xpm_image 'XpmColorFailed' R I could see the figures under Lyx 1.1.6 and this happened after R installing 1.2.1. R Could somebody help. What does 'lyx -version' say? (what I want to know is your version of xforms, and whethe rthe xforms image loader is in use) JMarc
Re: figures in Lyx 1.2.1
I have the same problem, and Takashi Soma told me that a solution would be downgrading to gs 4.03. I did not try it yet, however. In any case, I can get the "lyx -version" info at home and add it to the discussion to find out why loading images fails... joao > R> Hi, > > R> I am using Lyx 1.2.1 in Sun OS 5.6. When a document is opened, I > R> cannot see the figures; instead it says "Error scaling etc" inside > R> the figure box. Also, I get the following error message in the > R> command prompt: > > R> Error creating pixmap from xpm_image 'XpmColorFailed' > > > R> I could see the figures under Lyx 1.1.6 and this happened after > R> installing 1.2.1. > > R> Could somebody help. > > What does 'lyx -version' say? (what I want to know is your version of > xforms, and whethe rthe xforms image loader is in use) > > JMarc
Re: Problem adding figure to figure float
Jochen Wurster wrote: Now inserting pictures works and the picture is show correct in the pdf/dvi output, but in lyx it shows an error message (error converting ro loadable format) instead of the picture. I have tried png and ps files. Do you have converters for PNG-EPS and EPS-XPM in Edit-Preferences? If it is convert, do you have ImageMagick installed? I have a similar problem under RH 7.0: everything was ok for version 1.1.6p4, but under 1.2.0 I keep getting an error like this (I got this with -dbg any) : Error creating pixmap from xpm_image ... That is, something is going wrong after the conversion is made. Reconfiguring did not help, and I have no clue about the cause of the problem. j. b. oliveira
Re: Problem adding figure to figure float
Jochen Wurster wrote: Now inserting pictures works and the picture is show correct in the pdf/dvi output, but in lyx it shows an error message (error converting ro loadable format) instead of the picture. I have tried png and ps files. Do you have converters for PNG-EPS and EPS-XPM in Edit-Preferences? If it is convert, do you have ImageMagick installed? I have a similar problem under RH 7.0: everything was ok for version 1.1.6p4, but under 1.2.0 I keep getting an error like this (I got this with -dbg any) : Error creating pixmap from xpm_image ... That is, something is going wrong after the conversion is made. Reconfiguring did not help, and I have no clue about the cause of the problem. j. b. oliveira
Re: Problem adding figure to figure float
> Jochen Wurster wrote:
> > Now inserting pictures works and the picture is show correct in the pdf/dvi
> > output, but in lyx it shows an error message ("error converting ro loadable
> > format") instead of the picture.
> > I have tried png and ps files.
>
> Do you have converters for PNG->EPS and EPS->XPM in Edit->Preferences?
> If it is convert, do you have ImageMagick installed?
I have a similar problem under RH 7.0: everything was ok for version
1.1.6p4, but under 1.2.0 I keep getting an error like this (I got
this with -dbg any) :
Error creating pixmap from xpm_image ...
That is, something is going wrong after the conversion is
made. Reconfiguring did not help, and I have no clue about the
cause of the problem.
j. b. oliveira
Re: libXpm causing problems?
I have the same problem. I found that eps files by GNUPLOT works fine but not by IDL. What do you mean by IDL? In any case, even EPS files from gnuplot are not rendered ok. They are converted to xpm (don't know why) and an error occurs when they are to be loaded. There is a twist: I have installed LyX on two machines, both RH 7.0. This Xpm pixmap error appears in both. On the same day I installed LyX on a Debian Alpha, and it works properly, but I cannot find a difference between them. j. b. oliveira
Re: libXpm causing problems?
I have the same problem. I found that eps files by GNUPLOT works fine but not by IDL. What do you mean by IDL? In any case, even EPS files from gnuplot are not rendered ok. They are converted to xpm (don't know why) and an error occurs when they are to be loaded. There is a twist: I have installed LyX on two machines, both RH 7.0. This Xpm pixmap error appears in both. On the same day I installed LyX on a Debian Alpha, and it works properly, but I cannot find a difference between them. j. b. oliveira
Re: libXpm causing problems?
> I have the same problem. I found that eps files by GNUPLOT works fine but > not by IDL. What do you mean by IDL? In any case, even EPS files from gnuplot are not rendered ok. They are converted to xpm (don't know why) and an error occurs when they are to be loaded. There is a twist: I have installed LyX on two machines, both RH 7.0. This "Xpm pixmap" error appears in both. On the same day I installed LyX on a Debian Alpha, and it works properly, but I cannot find a difference between them. j. b. oliveira
Re: Why LyX?
On Wednesday 05 September 2001 16:09, you wrote: John Levon writes: I've turned tens of normal students onto lyx instead of word (even unix-hating students) entirely as a result of the output. Yes, but ... My two bits: The effect on my students has been the same. Two years ago we started pushing them to LaTeX/LyX. At first they were rather reluctant, but they learned that they can write rather large documents WITHOUT: 1) Getting ridiculously large .doc files 2) Losing all formatting because W*rd gets suddenly insane. 3) Losing pictures, references, numbering, etc due to the same reasons. 4) blah-blah-blah: all bugs that W*rd has. In fact, one year ago just one work (out of 20) was written in LyX, a rather bad record. This year, there were 8 out of 12. Next year we plan to crush the W*rd users, as people are learning that the effort to learn a new editor completely pays itself. Our price to have such results: we had to provide .cls and .layout files for our written works (took a few days to adapt from report.cls) and support them. Not such a terrible job. Our advantage: all written works using such a format seem alike, and there are NO formatting wars: everyone gets the same results and nobody cares about making it more beautiful than the others or such a crap. Gluing them all together to produce a volume is simple. The students notice that they do not have to format their documents for hours, or produce title pages by themselves, or many other things that are done automatically. They notice that they are free to concentrate on the thinking part of their texts. This is all referent to LyX, but there is a point that specifically refers to LaTeX: one CAN write programs that automatically produce LaTeX files as output. I have already done that in my thesis long ago, and it is a \HUGE satisfaction to have a program that runs and produces TeX output automatically, formatted and ready to be included into another document. There is no copy and paste, no nothing. I have been using this to produce random exercise lists, so that every student gets different tasks. You just need a lot of tasks, a program to produce a .tex context around the task to be done, and run LaTeX automatically. Couldn't be smoother, and in three minutes I get 50 high-quality documents ready for distribution. Yes, in this list we have all those little formatting problems: How do I enlarge this, or reduce that, or insert this other, or change all of about this, there are two things that may be said: -- Solving such things is fun, and one learns a lot from them. -- There are such discussions because LaTeX allows us to make such special demands (and we are free to try it), although a typical user does not need to care about it. Thousands of LyX users don't care. To sum it up, the best thing is to see a formerly reluctant student come proudly to you to show the document he has produced, and saying This is so much better to work with, and results are better too. I think this is the joy of doing it all. jb
Re: Why LyX?
On Wednesday 05 September 2001 16:09, you wrote: John Levon writes: I've turned tens of normal students onto lyx instead of word (even unix-hating students) entirely as a result of the output. Yes, but ... My two bits: The effect on my students has been the same. Two years ago we started pushing them to LaTeX/LyX. At first they were rather reluctant, but they learned that they can write rather large documents WITHOUT: 1) Getting ridiculously large .doc files 2) Losing all formatting because W*rd gets suddenly insane. 3) Losing pictures, references, numbering, etc due to the same reasons. 4) blah-blah-blah: all bugs that W*rd has. In fact, one year ago just one work (out of 20) was written in LyX, a rather bad record. This year, there were 8 out of 12. Next year we plan to crush the W*rd users, as people are learning that the effort to learn a new editor completely pays itself. Our price to have such results: we had to provide .cls and .layout files for our written works (took a few days to adapt from report.cls) and support them. Not such a terrible job. Our advantage: all written works using such a format seem alike, and there are NO formatting wars: everyone gets the same results and nobody cares about making it more beautiful than the others or such a crap. Gluing them all together to produce a volume is simple. The students notice that they do not have to format their documents for hours, or produce title pages by themselves, or many other things that are done automatically. They notice that they are free to concentrate on the thinking part of their texts. This is all referent to LyX, but there is a point that specifically refers to LaTeX: one CAN write programs that automatically produce LaTeX files as output. I have already done that in my thesis long ago, and it is a \HUGE satisfaction to have a program that runs and produces TeX output automatically, formatted and ready to be included into another document. There is no copy and paste, no nothing. I have been using this to produce random exercise lists, so that every student gets different tasks. You just need a lot of tasks, a program to produce a .tex context around the task to be done, and run LaTeX automatically. Couldn't be smoother, and in three minutes I get 50 high-quality documents ready for distribution. Yes, in this list we have all those little formatting problems: How do I enlarge this, or reduce that, or insert this other, or change all of about this, there are two things that may be said: -- Solving such things is fun, and one learns a lot from them. -- There are such discussions because LaTeX allows us to make such special demands (and we are free to try it), although a typical user does not need to care about it. Thousands of LyX users don't care. To sum it up, the best thing is to see a formerly reluctant student come proudly to you to show the document he has produced, and saying This is so much better to work with, and results are better too. I think this is the joy of doing it all. jb
Re: Why LyX?
> On Wednesday 05 September 2001 16:09, you wrote: > > John Levon writes: > > > > I've turned tens of normal students onto lyx instead > > of word (even unix-hating students) entirely as a result of the output. > > > > Yes, but ... My two bits: The effect on my students has been the same. Two years ago we started pushing them to LaTeX/LyX. At first they were rather reluctant, but they learned that they can write rather large documents WITHOUT: 1) Getting ridiculously large .doc files 2) Losing all formatting because W*rd gets suddenly insane. 3) Losing pictures, references, numbering, etc due to the same reasons. 4) blah-blah-blah: all bugs that W*rd has. In fact, one year ago just one work (out of 20) was written in LyX, a rather bad record. This year, there were 8 out of 12. Next year we plan to crush the W*rd users, as people are learning that the effort to learn a new editor completely pays itself. Our price to have such results: we had to provide .cls and .layout files for our written works (took a few days to adapt from report.cls) and support them. Not such a terrible job. Our advantage: all written works using such a format seem alike, and there are NO formatting wars: everyone gets the same results and nobody cares about "making it more beautiful than the others" or such a crap. Gluing them all together to produce a volume is simple. The students notice that they do not have to format their documents for hours, or produce title pages by themselves, or many other things that are done automatically. They notice that they are free to concentrate on the thinking part of their texts. This is all referent to LyX, but there is a point that specifically refers to LaTeX: one CAN write programs that automatically produce LaTeX files as output. I have already done that in my thesis long ago, and it is a \HUGE satisfaction to have a program that runs and produces TeX output automatically, formatted and ready to be included into another document. There is no copy and paste, no nothing. I have been using this to produce random exercise lists, so that every student gets different tasks. You just need a lot of tasks, a program to produce a .tex context around the task to be done, and run LaTeX automatically. Couldn't be smoother, and in three minutes I get 50 high-quality documents ready for distribution. Yes, in this list we have all those little formatting problems: How do I enlarge this, or reduce that, or insert this other, or change all of about this, there are two things that may be said: -- Solving such things is fun, and one learns a lot from them. -- There are such discussions because LaTeX allows us to make such special demands (and we are free to try it), although a typical user does not need to care about it. Thousands of LyX users don't care. To sum it up, the best thing is to see a formerly reluctant student come proudly to you to show the document he has produced, and saying "This is so much better to work with, and results are better too." I think this is the joy of doing it all. jb
Re: German LyX-Version
I'm using a german version of lyx 1.1.2. When i insert a float, the table- and the figure-floats will be named correctly (Tabelle xxx, Abbildung xxx), but t he algorithm-floats get the english name (Algorithm xxx). May I change this behaviour manually, so that the algorithm-floats (Algorithm us xxx) and the list of algorithms (Verzeichnis der Algorithmen) will be nam ed with their german terms? You can change it, but these names seem not to be affected by changes in the document language. They are explicitly defined in algorithm.sty. So, you have to make a second version of algorithm.sty, say alggerman.sty and change the names in the file. Use this new style, instead of the old one. There should be a more elegant way, tough. j. b. oliveira
Re: German LyX-Version
I'm using a german version of lyx 1.1.2. When i insert a float, the table- and the figure-floats will be named correctly (Tabelle xxx, Abbildung xxx), but t he algorithm-floats get the english name (Algorithm xxx). May I change this behaviour manually, so that the algorithm-floats (Algorithm us xxx) and the list of algorithms (Verzeichnis der Algorithmen) will be nam ed with their german terms? You can change it, but these names seem not to be affected by changes in the document language. They are explicitly defined in algorithm.sty. So, you have to make a second version of algorithm.sty, say alggerman.sty and change the names in the file. Use this new style, instead of the old one. There should be a more elegant way, tough. j. b. oliveira
Re: German LyX-Version
> I'm using a german version of lyx 1.1.2. When i insert a float, the table- and
> the figure-floats will be named correctly (Tabelle xxx, Abbildung xxx), but t
> he algorithm-floats get the english name (Algorithm xxx).
>
> May I change this behaviour manually, so that the algorithm-floats (Algorithm
> us xxx) and the "list of algorithms" ("Verzeichnis der Algorithmen") will be nam
> ed with their german terms?
You can change it, but these names seem not to be affected by
changes in the document language. They are explicitly defined in
algorithm.sty.
So, you have to make a second version of algorithm.sty, say
alggerman.sty and change the names in the file. Use this new style,
instead of the old one.
There should be a more elegant way, tough.
j. b. oliveira
Creating new output filter?
Hi! I have a question concerning the output conversion from LyX: I would like to create a new output filter (say, PSNUP) that produces PS files as usual and pipes them to psnup, so that I get two logical pages on paper. I was looking at the preferences panel, and it seems that there is no way of defining new filters, only by changind old ones. Of course I could adapt some unused filter, but first I just wish to confirm that a new filter cannot be created by the user. Is that true? Thanks for any hint! j.b. oliveira
Creating new output filter?
Hi! I have a question concerning the output conversion from LyX: I would like to create a new output filter (say, PSNUP) that produces PS files as usual and pipes them to psnup, so that I get two logical pages on paper. I was looking at the preferences panel, and it seems that there is no way of defining new filters, only by changind old ones. Of course I could adapt some unused filter, but first I just wish to confirm that a new filter cannot be created by the user. Is that true? Thanks for any hint! j.b. oliveira
Creating new output filter?
Hi! I have a question concerning the output conversion from LyX: I would like to create a new output filter (say, PSNUP) that produces PS files as usual and pipes them to psnup, so that I get two logical pages on paper. I was looking at the preferences panel, and it seems that there is no way of defining new filters, only by changind old ones. Of course I could "adapt" some unused filter, but first I just wish to confirm that a new filter cannot be created by the user. Is that true? Thanks for any hint! j.b. oliveira
Table problem in 6fix2 ?
Hi, we know that the table code has been changing a lot in the past versions, and I just want to report a bug. The thing is: when I am in the last column of a table and try to append another column, LyX crashe with SEGSEV. This does not happen when columns are appended inside the table. I suppose more people have noticed this? j. b.
Table problem in 6fix2 ?
Hi, we know that the table code has been changing a lot in the past versions, and I just want to report a bug. The thing is: when I am in the last column of a table and try to append another column, LyX crashe with SEGSEV. This does not happen when columns are appended inside the table. I suppose more people have noticed this? j. b.
Table problem in 6fix2 ?
Hi, we know that the table code has been changing a lot in the past versions, and I just want to report a bug. The thing is: when I am in the last column of a table and try to append another column, LyX crashe with SEGSEV. This does not happen when columns are appended "inside" the table. I suppose more people have noticed this? j. b.
Re: [mbmarduk@lycos.nl] Feedback from www.lyx.org
On Tue, 29 May 2001, Niklas Werner wrote: In my opinion the stability of a GNU/Linux system + Lyx is a major advantage. I'm working on a big document (200 pages, about 100 figures) I don't dare to imagine what would have become of me when I would have started this in Vord! Should we talk about the strange phenomena in Vord, such like changing all formatting information when you open your document in another place, or mixing up ALL figures suddenly, and they were all ok just two minutes ago and you changed *nothing*? - lyx-files are small and human-readable (ie UNIX-tool-parseable ,-)): long live sed, awk an Perl!) Compare this to the horrible M$Vord-format (which becomes even more horrible when it gets corrupted during a failed write operation, via e.g. a spurious network connection)... BTW, lyx files are much smaller (lastly, the new table format has significantly enlarged files, but they are still small.) Usually you can SEE if something went wrong, and if necessary you can make a little correction on the lyx files themselves, reading them again into lyx and working normally. Unusual, but efficient. For example, two weeks ago I had to insert a small text in about 30 different texts. It was just a matter of writing a ridiculously small shell script to append the new text into the files, and automatically open them under LyX for a small correction (if necessary). Do that with Vord, with all point and click and paste and point again... j. b. Vord was intentionally (and disrespectfully) spelled Vord.
Re: [mbmarduk@lycos.nl] Feedback from www.lyx.org
On Tue, 29 May 2001, Niklas Werner wrote: In my opinion the stability of a GNU/Linux system + Lyx is a major advantage. I'm working on a big document (200 pages, about 100 figures) I don't dare to imagine what would have become of me when I would have started this in Vord! Should we talk about the strange phenomena in Vord, such like changing all formatting information when you open your document in another place, or mixing up ALL figures suddenly, and they were all ok just two minutes ago and you changed *nothing*? - lyx-files are small and human-readable (ie UNIX-tool-parseable ,-)): long live sed, awk an Perl!) Compare this to the horrible M$Vord-format (which becomes even more horrible when it gets corrupted during a failed write operation, via e.g. a spurious network connection)... BTW, lyx files are much smaller (lastly, the new table format has significantly enlarged files, but they are still small.) Usually you can SEE if something went wrong, and if necessary you can make a little correction on the lyx files themselves, reading them again into lyx and working normally. Unusual, but efficient. For example, two weeks ago I had to insert a small text in about 30 different texts. It was just a matter of writing a ridiculously small shell script to append the new text into the files, and automatically open them under LyX for a small correction (if necessary). Do that with Vord, with all point and click and paste and point again... j. b. Vord was intentionally (and disrespectfully) spelled Vord.
Re: [mbmarduk@lycos.nl] Feedback from www.lyx.org
> On Tue, 29 May 2001, Niklas Werner wrote: > > In my opinion the stability of a GNU/Linux system + Lyx is a major > advantage. I'm working on a big document (>200 pages, about 100 figures) > I don't dare to imagine what would have become of me when I would > have started this in Vord! Should we talk about the strange phenomena in Vord, such like changing all formatting information when you open your document in another place, or mixing up ALL figures suddenly, and they were all ok just two minutes ago and you changed *nothing*? > > - lyx-files are small and human-readable (ie UNIX-tool-parseable ,-)): > > long live sed, awk an Perl!) > > Compare this to the horrible M$Vord-format (which becomes even more > horrible when it gets corrupted during a failed write operation, via > e.g. a spurious network connection)... BTW, lyx files are much smaller (lastly, the new table format has significantly enlarged files, but they are still small.) Usually you can SEE if something went wrong, and if necessary you can make a little correction on the lyx files themselves, reading them again into lyx and working normally. Unusual, but efficient. For example, two weeks ago I had to insert a small text in about 30 different texts. It was just a matter of writing a ridiculously small shell script to append the new text into the files, and automatically open them under LyX for a small correction (if necessary). Do that with Vord, with all point and click and paste and point again... j. b. Vord was intentionally (and disrespectfully) spelled Vord.
Re: sorting tables?
On Wed, May 23, 2001 at 07:17:08PM +0300, Baruch Even wrote: To follow up on these comments and enthusiasm (and a developers discussion), what is the language of choice for such an embedded scripting language is from your perspective? Several options that were raised (and I rememeber) include Icon, Lisp, Scheme and Python. I have a question on this (and I do not work with any of these languages, so I cannot be accused of being unfair!!): Before choosing a language that will affect our (happy) LyX lives, what requirements are really being made on this language? I mean, what do we really need? If we can decide what kinds of things are necessary, we can choose the language best supporting these capabilities... does anyone can give a few details of the capabilities that the LyX Behavioral Language should have? Do we need (easy) string capabilities? Environment descriptions? Macro expansions like TeX? Other things I do not even dream about? Other question: what about enlarging (if necessary) the language already used in the minibuffer? It would be nice to have the same language being used twice. j. b.
Re: sorting tables?
On Wed, May 23, 2001 at 07:17:08PM +0300, Baruch Even wrote: To follow up on these comments and enthusiasm (and a developers discussion), what is the language of choice for such an embedded scripting language is from your perspective? Several options that were raised (and I rememeber) include Icon, Lisp, Scheme and Python. I have a question on this (and I do not work with any of these languages, so I cannot be accused of being unfair!!): Before choosing a language that will affect our (happy) LyX lives, what requirements are really being made on this language? I mean, what do we really need? If we can decide what kinds of things are necessary, we can choose the language best supporting these capabilities... does anyone can give a few details of the capabilities that the LyX Behavioral Language should have? Do we need (easy) string capabilities? Environment descriptions? Macro expansions like TeX? Other things I do not even dream about? Other question: what about enlarging (if necessary) the language already used in the minibuffer? It would be nice to have the same language being used twice. j. b.
Re: sorting tables?
> On Wed, May 23, 2001 at 07:17:08PM +0300, Baruch Even wrote: > > To follow up on these comments and enthusiasm (and a developers > > discussion), what is the language of choice for such an embedded > > scripting language is from your perspective? > > > > Several options that were raised (and I rememeber) include Icon, > > Lisp, Scheme and Python. I have a question on this (and I do not work with any of these languages, so I cannot be accused of being unfair!!): Before choosing a language that will affect our (happy) LyX lives, what requirements are really being made on this language? I mean, what do we really need? If we can decide what kinds of things are necessary, we can choose the language best supporting these capabilities... does anyone can give a few details of the capabilities that the LyX Behavioral Language should have? Do we need (easy) string capabilities? Environment descriptions? Macro expansions like TeX? Other things I do not even dream about? Other question: what about enlarging (if necessary) the language already used in the minibuffer? It would be nice to have the same language being used twice. j. b.
Re: sorting tables?
On Wednesday 23 May 2001 14:56, Baruch Even wrote: Hopefully in the future we will have an embedded scripting language in LyX and features like this one will be implementable with it. This will satisfy the feature-bloat proponents and the feature-bloat opponents, you will be able to use such features if you want and you will be able to disable the scripting language altogether if you dont want any of this. Now _that_ would really rock! And we could exchange bits of LyX code as today we exchange pieces of LaTeX!!! The True Light strikes again!! j. b.
Re: sorting tables?
On Wednesday 23 May 2001 14:56, Baruch Even wrote: Hopefully in the future we will have an embedded scripting language in LyX and features like this one will be implementable with it. This will satisfy the feature-bloat proponents and the feature-bloat opponents, you will be able to use such features if you want and you will be able to disable the scripting language altogether if you dont want any of this. Now _that_ would really rock! And we could exchange bits of LyX code as today we exchange pieces of LaTeX!!! The True Light strikes again!! j. b.
Re: sorting tables?
> On Wednesday 23 May 2001 14:56, Baruch Even wrote: > > Hopefully in the future we will have an embedded scripting language in LyX > > and features like this one will be implementable with it. This will > > satisfy the feature-bloat proponents and the feature-bloat opponents, you > > will be able to use such features if you want and you will be able to > > disable the scripting language altogether if you dont want any of this. > > Now _that_ would really rock! And we could exchange bits of LyX code as today we exchange pieces of LaTeX!!! The True Light strikes again!! j. b.
Re: math environments
Lars Gullik Bjønnes wrote: Andre Poenitz [EMAIL PROTECTED] writes: | $...$- inlined | \(...\) - inlined differs from $...$ by ??? | |The $ are PROTECTED environments, and \( is unprotected. That |means that strange things may happen to the arguments of \(...\) | due to moving arguments around. | | This sounds like a disadvantage... So why do we use \(...\) at all? AFAIK \( \) is advised in LaTeX instead of $ $ as Joao in his mail said: if you want some mathstuff in a \section or something else you always have to use \protect$...$. same with \protect\(...\) doesn't work. I do not think that this is right. I tested a $...$ in a \section and it works ok. The toc entry is ok, everything seems fine. As I understood it, $...$ is protected by default, and an extra \protect adds nothing to it. BTW, about $...$...$ it is rather simple (I hope): the first pair defines a math environment, the third $ starts a second math environment that will never be closed. joao
Re: math environments
Lars Gullik Bjønnes wrote: Andre Poenitz [EMAIL PROTECTED] writes: | $...$- inlined | \(...\) - inlined differs from $...$ by ??? | |The $ are PROTECTED environments, and \( is unprotected. That |means that strange things may happen to the arguments of \(...\) | due to moving arguments around. | | This sounds like a disadvantage... So why do we use \(...\) at all? AFAIK \( \) is advised in LaTeX instead of $ $ as Joao in his mail said: if you want some mathstuff in a \section or something else you always have to use \protect$...$. same with \protect\(...\) doesn't work. I do not think that this is right. I tested a $...$ in a \section and it works ok. The toc entry is ok, everything seems fine. As I understood it, $...$ is protected by default, and an extra \protect adds nothing to it. BTW, about $...$...$ it is rather simple (I hope): the first pair defines a math environment, the third $ starts a second math environment that will never be closed. joao
Re: math environments
> Lars Gullik Bjønnes wrote: > > > > Andre Poenitz <[EMAIL PROTECTED]> writes: > > > > | > > $...$- inlined > > | > > \(...\) - inlined differs from $...$ by ??? > > | > > > | > The $ are PROTECTED environments, and \( is unprotected. That > > | > means that strange things may happen to the arguments of \(...\) > > | > due to moving arguments around. > > | > > | This sounds like a disadvantage... So why do we use \(...\) at all? > > > > AFAIK \( \) is advised in LaTeX instead of $ $ > > as Joao in his mail said: > if you want some mathstuff in a \section or something > else you always have to use \protect$...$. > same with \protect\(...\) doesn't work. I do not think that this is right. I tested a $...$ in a \section and it works ok. The toc entry is ok, everything seems fine. As I understood it, $...$ is protected by default, and an extra \protect adds nothing to it. BTW, about $...$...$ it is rather simple (I hope): the first pair defines a math environment, the third $ starts a second math environment that will never be closed. joao
Re: Concerning \(...\) and $...$
Joao After producing quite acceptable .layout and .cls files for our
Joao students, someone needed a List of Abbreviations. I managed to
Joao produce all entries with a nice macro like this
Joao \abbrev {SVD] {Singular Value Decomposition}
On a relative point, we could probably decide to use $...$ for inline
formulas, while keeping \[...\] for displayed formulas. It seems that
it's what the latex docs suggest.
This would be a good change, trading \(...\) for $...$. In fact,
I could implement my \abbrev code after REDEFINING \(...\) as
$...$. Look at the code:
\newcommand\abbrev[2]{%
\def\({$} % HACK...
\def\){$}
\addcontentsline{loa}{chapter}{%
\rm%
\protect\parbox[t]{.2\textwidth}{#1}%
\hspace{0.025\textwidth}%
\protect\parbox[t]{.7\textwidth}{#2}
}
}
Doing this, expansion goes well and everything fits in place. Was
there any special reason to use \(...\) as inline math, in the
first place?
jb
Re: math environments
I need a (more or less complete) list of math environments together with some description of their special properties. $...$- inlined \(...\) - inlined differs from $...$ by ??? The $ are PROTECTED environments, and \( is unprotected. That means that strange things may happen to the arguments of \(...\) due to moving arguments around. jb
Re: Concerning \(...\) and $...$
Joao After producing quite acceptable .layout and .cls files for our
Joao students, someone needed a List of Abbreviations. I managed to
Joao produce all entries with a nice macro like this
Joao \abbrev {SVD] {Singular Value Decomposition}
On a relative point, we could probably decide to use $...$ for inline
formulas, while keeping \[...\] for displayed formulas. It seems that
it's what the latex docs suggest.
This would be a good change, trading \(...\) for $...$. In fact,
I could implement my \abbrev code after REDEFINING \(...\) as
$...$. Look at the code:
\newcommand\abbrev[2]{%
\def\({$} % HACK...
\def\){$}
\addcontentsline{loa}{chapter}{%
\rm%
\protect\parbox[t]{.2\textwidth}{#1}%
\hspace{0.025\textwidth}%
\protect\parbox[t]{.7\textwidth}{#2}
}
}
Doing this, expansion goes well and everything fits in place. Was
there any special reason to use \(...\) as inline math, in the
first place?
jb
Re: math environments
I need a (more or less complete) list of math environments together with some description of their special properties. $...$- inlined \(...\) - inlined differs from $...$ by ??? The $ are PROTECTED environments, and \( is unprotected. That means that strange things may happen to the arguments of \(...\) due to moving arguments around. jb
Re: Concerning \(...\) and $...$
>
> Joao> After producing quite acceptable .layout and .cls files for our
> Joao> students, someone needed a List of Abbreviations. I managed to
> Joao> produce all entries with a nice macro like this
>
> Joao> \abbrev {SVD] {Singular Value Decomposition}
> On a relative point, we could probably decide to use $...$ for inline
> formulas, while keeping \[...\] for displayed formulas. It seems that
> it's what the latex docs suggest.
This would be a good change, trading \(...\) for $...$. In fact,
I could implement my \abbrev code after REDEFINING \(...\) as
$...$. Look at the code:
\newcommand\abbrev[2]{%
\def\({$} % HACK...
\def\){$}
\addcontentsline{loa}{chapter}{%
\rm%
\protect\parbox[t]{.2\textwidth}{#1}%
\hspace{0.025\textwidth}%
\protect\parbox[t]{.7\textwidth}{#2}
}
}
Doing this, expansion goes well and everything fits in place. Was
there any special reason to use \(...\) as inline math, in the
first place?
jb
Re: math environments
> > I need a (more or less complete) list of math "environments" together with > some description of their "special properties". > > $...$- inlined > \(...\) - inlined differs from $...$ by ??? The $ are PROTECTED environments, and \( is unprotected. That means that strange things may happen to the arguments of \(...\) due to moving arguments around. jb
Concerning \(...\) and $...$
Hi!
I have a question that starts as a TeX question, but ends up at LyX:
After producing quite acceptable .layout and .cls files for our
students, someone needed a List of Abbreviations. I managed to
produce all entries with a nice macro like this
\abbrev {SVD] {Singular Value Decomposition}
The \abbrev is ERT, as I did not manage to send two separate
arguments to a LyX Style... (yes, this would solve the problem)
This ERT solution works quite well, but there is a catch: many
times students want to put also math abbreviations in their text:
\abbrev { $ x^2 + y^2 $ } {Something interesting...}
The problem is the following: using Meta-m or Meta-c m, for
example, LyX does NOT produce a $...$ pair, but \(...\) and this
is an UNprotected environment. So, as the macro receives the first
argument, it is completely messed up.
I tried to \protect the argument, to no avail.
Does anyone have any hints on solving this? The best solution
would be to find a command that produces math environments with $
delimiters, but I was unable to find it.
Thanks for any help,
j. b. oliveira
Re: Concerning \(...\) and $...$
Once again Herbert scores a point... I was using another form of abbreviation,
including it in a .loa file:
\newcommand{\abbrev}[2]{%
\if@abbrlistmissing
\listofabbreviations
\@abbrlistmissingfalse
\fi
\addtocontents{loa}{\protect\makebox[8em][l]{#1}{#2}\newline}
}
The problem was that calling \addtocontents with the unprotected first
argument did not work at all. Interestingly, Herbert's solution works
quite differently and avoids the problem.
On the other hand, now all abbreviations must be together in the
beginning of the file, and cannot be apreaded around the text.
I'll try to solve that, but this is already a much better situation!
thank you!
jb
Joao B. Oliveira wrote:
\abbrev {SVD] {Singular Value Decomposition}
This ERT solution works quite well, but there is a catch: many
times students want to put also math abbreviations in their text:
\abbrev { $ x^2 + y^2 $ } {Something interesting...}
The problem is the following: using Meta-m or Meta-c m, for
example, LyX does NOT produce a $...$ pair, but \(...\) and this
is an UNprotected environment. So, as the macro receives the first
argument, it is completely messed up.
i don't really understand, why you need an protected argument.
can you send your whole preamble, because I can do something like
this without any error when using alt-m-m
\newcommand\abbr[2]{%
\parbox{.3\textwidth}{%
#1}%
\hspace{0.05\textwidth}%
\parbox{.65\textwidth}{%
#2}%
}
Herbert
--
http://www.educat.hu-berlin.de/~voss/lyx/
Concerning \(...\) and $...$
Hi!
I have a question that starts as a TeX question, but ends up at LyX:
After producing quite acceptable .layout and .cls files for our
students, someone needed a List of Abbreviations. I managed to
produce all entries with a nice macro like this
\abbrev {SVD] {Singular Value Decomposition}
The \abbrev is ERT, as I did not manage to send two separate
arguments to a LyX Style... (yes, this would solve the problem)
This ERT solution works quite well, but there is a catch: many
times students want to put also math abbreviations in their text:
\abbrev { $ x^2 + y^2 $ } {Something interesting...}
The problem is the following: using Meta-m or Meta-c m, for
example, LyX does NOT produce a $...$ pair, but \(...\) and this
is an UNprotected environment. So, as the macro receives the first
argument, it is completely messed up.
I tried to \protect the argument, to no avail.
Does anyone have any hints on solving this? The best solution
would be to find a command that produces math environments with $
delimiters, but I was unable to find it.
Thanks for any help,
j. b. oliveira
Re: Concerning \(...\) and $...$
Once again Herbert scores a point... I was using another form of abbreviation,
including it in a .loa file:
\newcommand{\abbrev}[2]{%
\if@abbrlistmissing
\listofabbreviations
\@abbrlistmissingfalse
\fi
\addtocontents{loa}{\protect\makebox[8em][l]{#1}{#2}\newline}
}
The problem was that calling \addtocontents with the unprotected first
argument did not work at all. Interestingly, Herbert's solution works
quite differently and avoids the problem.
On the other hand, now all abbreviations must be together in the
beginning of the file, and cannot be apreaded around the text.
I'll try to solve that, but this is already a much better situation!
thank you!
jb
Joao B. Oliveira wrote:
\abbrev {SVD] {Singular Value Decomposition}
This ERT solution works quite well, but there is a catch: many
times students want to put also math abbreviations in their text:
\abbrev { $ x^2 + y^2 $ } {Something interesting...}
The problem is the following: using Meta-m or Meta-c m, for
example, LyX does NOT produce a $...$ pair, but \(...\) and this
is an UNprotected environment. So, as the macro receives the first
argument, it is completely messed up.
i don't really understand, why you need an protected argument.
can you send your whole preamble, because I can do something like
this without any error when using alt-m-m
\newcommand\abbr[2]{%
\parbox{.3\textwidth}{%
#1}%
\hspace{0.05\textwidth}%
\parbox{.65\textwidth}{%
#2}%
}
Herbert
--
http://www.educat.hu-berlin.de/~voss/lyx/
Concerning \(...\) and $...$
Hi!
I have a question that starts as a TeX question, but ends up at LyX:
After producing quite acceptable .layout and .cls files for our
students, someone needed a List of Abbreviations. I managed to
produce all entries with a nice macro like this
\abbrev {SVD] {Singular Value Decomposition}
The \abbrev is ERT, as I did not manage to send two separate
arguments to a LyX Style... (yes, this would solve the problem)
This ERT solution works quite well, but there is a catch: many
times students want to put also math abbreviations in their text:
\abbrev { $ x^2 + y^2 $ } {Something interesting...}
The problem is the following: using Meta-m or Meta-c m, for
example, LyX does NOT produce a $...$ pair, but \(...\) and this
is an UNprotected environment. So, as the macro receives the first
argument, it is completely messed up.
I tried to \protect the argument, to no avail.
Does anyone have any hints on solving this? The best solution
would be to find a command that produces math environments with $
delimiters, but I was unable to find it.
Thanks for any help,
j. b. oliveira
Re: Concerning \(...\) and $...$
Once again Herbert scores a point... I was using another form of abbreviation,
including it in a .loa file:
\newcommand{\abbrev}[2]{%
\if@abbrlistmissing
\listofabbreviations
\@abbrlistmissingfalse
\fi
\addtocontents{loa}{\protect\makebox[8em][l]{#1}{#2}\newline}
}
The problem was that calling \addtocontents with the unprotected first
argument did not work at all. Interestingly, Herbert's solution works
quite differently and avoids the problem.
On the other hand, now all abbreviations must be together in the
beginning of the file, and cannot be apreaded around the text.
I'll try to solve that, but this is already a much better situation!
thank you!
jb
> "Joao B. Oliveira" wrote:
> >
> > \abbrev {SVD] {Singular Value Decomposition}
> >
> > This ERT solution works quite well, but there is a catch: many
> > times students want to put also math abbreviations in their text:
> >
> > \abbrev { $ x^2 + y^2 $ } {Something interesting...}
> >
> > The problem is the following: using Meta-m or Meta-c m, for
> > example, LyX does NOT produce a $...$ pair, but \(...\) and this
> > is an UNprotected environment. So, as the macro receives the first
> > argument, it is completely messed up.
>
> i don't really understand, why you need an protected argument.
> can you send your whole preamble, because I can do something like
> this without any error when using alt-m-m
>
> \newcommand\abbr[2]{%
> \parbox{.3\textwidth}{%
> #1}%
> \hspace{0.05\textwidth}%
> \parbox{.65\textwidth}{%
> #2}%
> }
>
>
> Herbert
>
> --
> http://www.educat.hu-berlin.de/~voss/lyx/
Problem at www.lyx.org?
Hi folks, I have been trying to access www.lyx.org since Monday, but there seems to be some problem in the way. The site gets contacted but the "Waiting for reply" takes forever. Any other sites I try are ok... just lyx.org is behaving strangely. Is anyone also experiencing that? BTW, I was trying to access the mail list from the last weeks. Are they mirrored somewhere? thanks, j. b. oliveira
up again...
hi folks, lyx.org was suddenly up again, a few minutes af ter I posted my mail message... did someone knows what happened (just for the sake of knowledge...) jb
Problem at www.lyx.org?
Hi folks, I have been trying to access www.lyx.org since Monday, but there seems to be some problem in the way. The site gets contacted but the "Waiting for reply" takes forever. Any other sites I try are ok... just lyx.org is behaving strangely. Is anyone also experiencing that? BTW, I was trying to access the mail list from the last weeks. Are they mirrored somewhere? thanks, j. b. oliveira
up again...
hi folks, lyx.org was suddenly up again, a few minutes af ter I posted my mail message... did someone knows what happened (just for the sake of knowledge...) jb
Problem at www.lyx.org?
Hi folks, I have been trying to access www.lyx.org since Monday, but there seems to be some problem in the way. The site gets contacted but the "Waiting for reply" takes forever. Any other sites I try are ok... just lyx.org is behaving strangely. Is anyone also experiencing that? BTW, I was trying to access the mail list from the last weeks. Are they mirrored somewhere? thanks, j. b. oliveira
up again...
hi folks, lyx.org was suddenly up again, a few minutes af ter I posted my mail message... did someone knows what happened (just for the sake of knowledge...) jb
on widgets
Hi! The LyX menu fonts are quite large on my installation, so I tried to configure them in my .Xresources file, but I am unable to get the names of the widgets right. Even doing *font: 8x13 or something does not change the LyX menu fonts, although most other programs are changed. I tried to get the widget tree with editres, but LyX does not answer to it. Does anyone know how to get the information about LyX's widget tree, or how to set the menu fonts explicitly? Thanks for any hint, j. b. oliveira
on widgets
Hi! The LyX menu fonts are quite large on my installation, so I tried to configure them in my .Xresources file, but I am unable to get the names of the widgets right. Even doing *font: 8x13 or something does not change the LyX menu fonts, although most other programs are changed. I tried to get the widget tree with editres, but LyX does not answer to it. Does anyone know how to get the information about LyX's widget tree, or how to set the menu fonts explicitly? Thanks for any hint, j. b. oliveira
on widgets
Hi! The LyX menu fonts are quite large on my installation, so I tried to configure them in my .Xresources file, but I am unable to get the names of the widgets right. Even doing *font: 8x13 or something does not change the LyX menu fonts, although most other programs are changed. I tried to get the widget tree with editres, but LyX does not answer to it. Does anyone know how to get the information about LyX's widget tree, or how to set the menu fonts explicitly? Thanks for any hint, j. b. oliveira
using -x and TWO commands
Hi! I am trying to convert a large lot of files from LyX 1.1.5 to 1.1.6, and tried to read each file, save it and leave LyX: for each file: lyx -x "buffer-write" file.lyx This loads the file and saves in the new format, but LyX does not quit thereafter. That is, windows remain open and so on. so the question: is it possible to execute TWO commands, like in lyx -x "buffer-write lyx-quit" file.lyx The above form does not work, but is there a way to do something similar, so that LyX exits after performing the action? Thanks, j. b. oliveira
using -x and TWO commands
Hi! I am trying to convert a large lot of files from LyX 1.1.5 to 1.1.6, and tried to read each file, save it and leave LyX: for each file: lyx -x "buffer-write" file.lyx This loads the file and saves in the new format, but LyX does not quit thereafter. That is, windows remain open and so on. so the question: is it possible to execute TWO commands, like in lyx -x "buffer-write lyx-quit" file.lyx The above form does not work, but is there a way to do something similar, so that LyX exits after performing the action? Thanks, j. b. oliveira
using -x and TWO commands
Hi! I am trying to convert a large lot of files from LyX 1.1.5 to 1.1.6, and tried to read each file, save it and leave LyX: for each file: lyx -x "buffer-write" file.lyx This loads the file and saves in the new format, but LyX does not quit thereafter. That is, windows remain open and so on. so the question: is it possible to execute TWO commands, like in lyx -x "buffer-write lyx-quit" file.lyx The above form does not work, but is there a way to do something similar, so that LyX exits after performing the action? Thanks, j. b. oliveira
problems saving \ldots ??
Hi folks, last weekend I installed RedHat 7.0 from scrach in a computer, and one of the first programs I compiled there was LyX 1.1.6fix1. All went weel until the moment I tried to save a file with \ldots within a Macro (or Math Inset, it does not matter). At first I though that there were wrong libraries around, but after some debugging it seems that the saving of the \ldots operator sends a NULL pointer to the operator, and LyX crashes. The error was reproduced several times in two different machines, both under RH 7.0. Does anybody know something about it, or how to fix it? thanks for the help, j. b. oliveira
