Re: 'subfigure' package on windows
John Pye wrote: Hi again, I did try the Repository menu. I just pointed it to a directory where I had placed the single file, subfigure.cab. Obviously it requires some kind of index file in addition, but i can't find out what that should be. It seems silly to download the whole repository just for this one file -- a file that I already have. Cheers JP I tested this and to my surprise it didn't work as expected. So you were right. I used Google and found that this was an error message reported often enough to provoke the ire of a list maintainer who said read the FAQ. But it is not in any FAQ. The answer was that *the* Readme.txt is needed. --- does not seem to be a local package repository Does the file README.TXT exist in the local package repository? Setup Wizard reads the first line of README.TXT. It should be sufficient to say echo This folder contains the Small MiKTeX package set. README.TXT Hope this helps, Christian Schenk -- I don't think Miktex2.5 has a localtexmf anymore. If this method of adding README.TXT doesn't work, I would unpack subfigure.cab (winrar,winzip) into a temp folder and then copy the files manually into C:\program files\miktex 2.5 , to the appropriate directories. Then update the fndb (there is a inittex syntax if you don't have the wizard, I don't know what the LyX installer provides) and LyX. Type doskey from the command prompt. Then your previous typing will be repeated using the up arrow (like Linux). So you will have most of the typing done from you after you copy the first file to the right place in C:\program files\miktex 2.5\...\...\ Use the left arrow to go back to where you want to change a filename or directory path and then use backspace and retype it. It's possible that Winrar would extract the files to the right place but I'm not sure of that. Notice that there are two subfigure directories shown in the image below. I'll provide their contents, also shown in the png Directory of C:\Program Files\MiKTeX 2.5\doc\latex\subfigure 08/22/2006 11:02 AMDIR . 08/22/2006 11:02 AMDIR .. 07/02/2002 05:05 PM 2,207 README 04/23/2005 08:56 PM 172,944 subfigure.dvi - [SH: These files must go to this location.] Directory of C:\Program Files\MiKTeX 2.5\tex\latex\subfigure 08/22/2006 11:02 AMDIR . 08/22/2006 11:02 AMDIR .. 04/23/2005 08:56 PM 2,114 subfigure.cfg 04/23/2005 08:56 PM14,815 subfigure.sty - This method involves copy six files using doskey and making two subfigure directories and it more certain than including the README.TXT (in one post I saw a .log file mentioned also) which didn't work for me. Regards, Stephen
Re: 'subfigure' package on windows
John Pye wrote: Hi again, I did try the Repository menu. I just pointed it to a directory where I had placed the single file, subfigure.cab. Obviously it requires some kind of index file in addition, but i can't find out what that should be. It seems silly to download the whole repository just for this one file -- a file that I already have. Cheers JP I tested this and to my surprise it didn't work as expected. So you were right. I used Google and found that this was an error message reported often enough to provoke the ire of a list maintainer who said read the FAQ. But it is not in any FAQ. The answer was that *the* Readme.txt is needed. --- does not seem to be a local package repository Does the file README.TXT exist in the local package repository? Setup Wizard reads the first line of README.TXT. It should be sufficient to say echo This folder contains the Small MiKTeX package set. README.TXT Hope this helps, Christian Schenk -- I don't think Miktex2.5 has a localtexmf anymore. If this method of adding README.TXT doesn't work, I would unpack subfigure.cab (winrar,winzip) into a temp folder and then copy the files manually into C:\program files\miktex 2.5 , to the appropriate directories. Then update the fndb (there is a inittex syntax if you don't have the wizard, I don't know what the LyX installer provides) and LyX. Type doskey from the command prompt. Then your previous typing will be repeated using the up arrow (like Linux). So you will have most of the typing done from you after you copy the first file to the right place in C:\program files\miktex 2.5\...\...\ Use the left arrow to go back to where you want to change a filename or directory path and then use backspace and retype it. It's possible that Winrar would extract the files to the right place but I'm not sure of that. Notice that there are two subfigure directories shown in the image below. I'll provide their contents, also shown in the png Directory of C:\Program Files\MiKTeX 2.5\doc\latex\subfigure 08/22/2006 11:02 AMDIR . 08/22/2006 11:02 AMDIR .. 07/02/2002 05:05 PM 2,207 README 04/23/2005 08:56 PM 172,944 subfigure.dvi - [SH: These files must go to this location.] Directory of C:\Program Files\MiKTeX 2.5\tex\latex\subfigure 08/22/2006 11:02 AMDIR . 08/22/2006 11:02 AMDIR .. 04/23/2005 08:56 PM 2,114 subfigure.cfg 04/23/2005 08:56 PM14,815 subfigure.sty - This method involves copy six files using doskey and making two subfigure directories and it more certain than including the README.TXT (in one post I saw a .log file mentioned also) which didn't work for me. Regards, Stephen
Re: 'subfigure' package on windows
John Pye wrote: Hi again, I did try the Repository menu. I just pointed it to a directory where I had placed the single file, "subfigure.cab". Obviously it requires some kind of index file in addition, but i can't find out what that should be. It seems silly to download the whole repository just for this one file -- a file that I already have. Cheers JP I tested this and to my surprise it didn't work as expected. So you were right. I used Google and found that this was an error message reported often enough to provoke the ire of a list maintainer who said read the FAQ. But it is not in any FAQ. The answer was that *the* Readme.txt is needed. --- does not seem to be a local package repository Does the file README.TXT exist in the local package repository? Setup Wizard reads the first line of README.TXT. It should be sufficient to say echo This folder contains the "Small MiKTeX" package set.> README.TXT Hope this helps, Christian Schenk -- I don't think Miktex2.5 has a localtexmf anymore. If this method of adding README.TXT doesn't work, I would unpack subfigure.cab (winrar,winzip) into a temp folder and then copy the files manually into C:\program files\miktex 2.5 , to the appropriate directories. Then update the fndb (there is a inittex syntax if you don't have the wizard, I don't know what the LyX installer provides) and LyX. Type "doskey" from the command prompt. Then your previous typing will be repeated using the up arrow (like Linux). So you will have most of the typing done from you after you copy the first file to the right place in C:\program files\miktex 2.5\...\...\ Use the left arrow to go back to where you want to change a filename or directory path and then use backspace and retype it. It's possible that Winrar would extract the files to the right place but I'm not sure of that. Notice that there are two subfigure directories shown in the image below. I'll provide their contents, also shown in the png Directory of C:\Program Files\MiKTeX 2.5\doc\latex\subfigure 08/22/2006 11:02 AM . 08/22/2006 11:02 AM .. 07/02/2002 05:05 PM 2,207 README 04/23/2005 08:56 PM 172,944 subfigure.dvi - [SH: These files must go to this location.] Directory of C:\Program Files\MiKTeX 2.5\tex\latex\subfigure 08/22/2006 11:02 AM . 08/22/2006 11:02 AM .. 04/23/2005 08:56 PM 2,114 subfigure.cfg 04/23/2005 08:56 PM14,815 subfigure.sty - This method involves copy six files using doskey and making two "subfigure" directories and it more certain than including the README.TXT (in one post I saw a .log file mentioned also) which didn't work for me. Regards, Stephen
Re: Fw: Postscript preview
Paul A. Rubin wrote: LB wrote: Ok, it tried this. I commented out SET LC_ALL=en_EN. This resulted in a different image having the preview problem. I placed SET XX=Y in lyx.bat and the preview problem moved back to the original image. The same happens when I comment out the other line in the lyx.bat. I also added extra lines in lyx.bat such as SET XX=Y this however did not make any difference as far as image preview is concerned. This is again confusing, though perhaps no more confusing than the fact that deleting unneeded environment variables (other than LC_ALL and the aiksaurus one) did not help. Another puzzling thing is that the preview problem jumps between two specific figures eventhough I have many figures in the document and many of them are generated with Matlab. The preview problem however never affects figures generated with other programs. Is there anything that the names/paths of the two affected figures have in common which is not shared by the other files. For instance, are they the longest paths, do they lie deeper in the directory tree than other figures, ... ? Stephen's idea of a second Ghostscript installation strikes me as possible but unlikely (and unlikely to be the culprit), since there would need to be something causing ImageMagick to alternate between the two GS installations on a figure-by-figure basis within the document (meaning that something in the figure names/paths would have to be triggering the switching). Also, Mathematica exports EPS without using GS and without installing its own GS, so I suspect the same might be true of MATLAB. Still, the whole bug is unlikely, so we shouldn't presume anything. It would be nice if we could intercept the call from IM to GS and see what's being passed, but so far I have not figured out how. /Paul - http://www.mathworks.com/support/solutions/data/1-ZBALJ.html?solution=1-ZBALJ The MATLAB Component Runtime (MCR) 7.0 and 7.1 do not contain a copy of the GhostScript program included with MATLAB. Therefore, applications deployed on a target machine rely on a locally- installed version of GhostScript, if one exists, for exporting some graphics. Since the version of GhostScript installed on the target machine may be different than the one included with MATLAB, the command line parameters potentially may be different as well. This difference causes an error in some instances. I think this supports the possibility of a Ghostscript conflict and that Matlab comes with its own version of Gs. With an earlier distro of LyX I also had XemTeX installed which comes with its own Gs. It had a different version of Gs and the .dlls conflicted with LyX which was solved by moving Xemtex to the end of Windows Path. I'm pretty sure that lyx.exe checks the LyX directory for various executables because Enrico's batfiles seem to use this principle. I'm not so sure about lyx.bat because I thought it was possible that those set commands could change which Gs was invoked. I don't know what they do, the consequences of their mechanism. One major difference in the our environments and Leo's is that he has Matlab installed and we don't. I'm pretty sure that Matlab has Gs installed since I've googled and seen it listed as a sub-dir of Matlab's directory structure (though only for Linux). It should take Leo less than thirty seconds to find out with Win Explorer. I 've a hunch that his Matlab Gs version is earlier than his system Gs, supposing that there are two instances. My troubleshooting idea was to eliminate both ways a Gs version conflict could happen and to use lyx.exe first before lyx.bat to see if the .eps file itself (command line parameters used) perhaps had a version glitch and I thought it would take about 5 minutes (without Matlab running) to see if this affected the problem. I think the Matlab doc I just reported upon supports this possibility. We also have a more recent version of system Ghostscript. My Sherlock Holmes sig, (inmates on death row tell jokes by #) Stephen
Re: openoffice
Juergen Fenn wrote: Stephen Harris [EMAIL PROTECTED] writes: Nick Thomas developed a script to convert LyX to OpenOffice called ConvTeX: http://wiki.lyx.org/Tools/LyX2OpenOffice [.sxw OOo ext.?] Yes, it still uses the OOo1 format sxw. which probably works a bit better on Linux than Windows. I've just tried it out on my Win98 box. There seem to be commands in the convtex.bat file that do not work under Win98. There also seem to be problems with handling paths. I've rewritten the batch file and the two other config files provided in the package to fit to my system, but it still doesn't work. :-( I'll keep on trying. 8-) Thanks for the hint, anyway. Didn't know about the project yet. Seems an interesting idea because the only other project for converting TeX OOo that I know of is oolatex from tex4ht, and this doesn't work either in MiKTeX 2.4... Regards, Jürgen. You mention Win98. I have Enrico's production of CygLyX1.4.1 working on Win98 in case there is version capability limitation. He has also released CygLyx1.4.2 but I haven't tested that yet. I haven't tried Convtex on Win98 either (it has a sick cdrom drive). Nick Thomas is actively working on this and wants testers and I'm sure he would appreciate somebody with some scripting knowledge as a tester. oolatex is a variant of htlatex with certain command line switches. The command htlatex foo.tex = foo.html which can be imported into Word, and changed to .doc, which OpenOffice can import works in WinXP, untested in Win98(my mother has its mouse). The unpolished output of htlatex: http://www.mathematik.uni-marburg.de/~gumm/LyX/Using_XYpic_in_LyX.htm The spaces in LY X can be fixed/typeset, see Ares http://wiki.lyx.org/LyX/Links or to go directly: http://www.webalice.it/ares001/job/tips.html TipsTricks I will send a copy of this post to Nick Thomas to introduce you. Regards, Stephen* http://www.webalice.it/ares001/job/tips.html *
Re: Fw: Postscript preview
Paul A. Rubin wrote: Stephen Harris wrote: The MATLAB Component Runtime (MCR) 7.0 and 7.1 do not contain a copy of the GhostScript program included with MATLAB. Therefore, applications deployed on a target machine rely on a locally- installed version of GhostScript, if one exists, for exporting some graphics. Since the version of GhostScript installed on the target machine may be different than the one included with MATLAB, the command line parameters potentially may be different as well. This difference causes an error in some instances. I think this supports the possibility of a Ghostscript conflict and that Matlab comes with its own version of Gs. It does indeed. So I agree that hypothetically Leo's MATLAB installation could be generating PS files (using it's own copy of GS) that would be indigestible to LyX-ImageMagick-GS (using a different copy of GS in the last step). That still raises the question of why those images would be successfully displayed in LyX (same LyX-ImageMagick-GS sequence) if an environment variable is deleted ... unless deletion of the environment variable affected which copy of GS was used (both on the command path?) ... in which case the bug would disappear, not switch to a different image. All that said, this bug is clearly not playing fair, so it would be a good idea for Leo to check into this just to rule it out. /Paul Yes there has to be another dimension to this. Recall he reinstalled LyX to C:\Lyx\lyx14 and the original problem files, I think it was test.ps, displayed Ok, but then another figure reared its ugly wolverine head. I would think that means that only some files are produced with the problem--either the same gs executable produces files which vary in compatibility or maybe system gs is producing the eps and it sometimes can't be read by an older matlab gs executable. Well, that is getting pretty thin. Maybe he could use the 1.4.1 lyx.bat and put Python at the beginning of the Path_prefix and try it and if it doesn't work, then try ghostscript at the beginning of Path_prefix also, but I think it is already. It would seem that the set variables in lyx1.4.2 batfile would have to part of it, but I don't know what they mean and they don't show up LC_ALL I will google one more time matlab and aikasaurus but I think that is just for Aspell. I'm not feeling well and can't concentrate. I've been up for two days fighting with a virus and am tired and have lost one partition on my hard drive. I guess its a trojan. Nope, I got a hit on allosaurus and matlab, but no aikasaurus. It's a Linux critter anyway. Regards, Stephen
Re: Fw: Postscript preview
Paul A. Rubin wrote: LB wrote: Ok, it tried this. I commented out SET LC_ALL=en_EN. This resulted in a different image having the preview problem. I placed SET XX=Y in lyx.bat and the preview problem moved back to the original image. The same happens when I comment out the other line in the lyx.bat. I also added extra lines in lyx.bat such as SET XX=Y this however did not make any difference as far as image preview is concerned. This is again confusing, though perhaps no more confusing than the fact that deleting unneeded environment variables (other than LC_ALL and the aiksaurus one) did not help. Another puzzling thing is that the preview problem jumps between two specific figures eventhough I have many figures in the document and many of them are generated with Matlab. The preview problem however never affects figures generated with other programs. Is there anything that the names/paths of the two affected figures have in common which is not shared by the other files. For instance, are they the longest paths, do they lie deeper in the directory tree than other figures, ... ? Stephen's idea of a second Ghostscript installation strikes me as possible but unlikely (and unlikely to be the culprit), since there would need to be something causing ImageMagick to alternate between the two GS installations on a figure-by-figure basis within the document (meaning that something in the figure names/paths would have to be triggering the switching). Also, Mathematica exports EPS without using GS and without installing its own GS, so I suspect the same might be true of MATLAB. Still, the whole bug is unlikely, so we shouldn't presume anything. It would be nice if we could intercept the call from IM to GS and see what's being passed, but so far I have not figured out how. /Paul - http://www.mathworks.com/support/solutions/data/1-ZBALJ.html?solution=1-ZBALJ The MATLAB Component Runtime (MCR) 7.0 and 7.1 do not contain a copy of the GhostScript program included with MATLAB. Therefore, applications deployed on a target machine rely on a locally- installed version of GhostScript, if one exists, for exporting some graphics. Since the version of GhostScript installed on the target machine may be different than the one included with MATLAB, the command line parameters potentially may be different as well. This difference causes an error in some instances. I think this supports the possibility of a Ghostscript conflict and that Matlab comes with its own version of Gs. With an earlier distro of LyX I also had XemTeX installed which comes with its own Gs. It had a different version of Gs and the .dlls conflicted with LyX which was solved by moving Xemtex to the end of Windows Path. I'm pretty sure that lyx.exe checks the LyX directory for various executables because Enrico's batfiles seem to use this principle. I'm not so sure about lyx.bat because I thought it was possible that those set commands could change which Gs was invoked. I don't know what they do, the consequences of their mechanism. One major difference in the our environments and Leo's is that he has Matlab installed and we don't. I'm pretty sure that Matlab has Gs installed since I've googled and seen it listed as a sub-dir of Matlab's directory structure (though only for Linux). It should take Leo less than thirty seconds to find out with Win Explorer. I 've a hunch that his Matlab Gs version is earlier than his system Gs, supposing that there are two instances. My troubleshooting idea was to eliminate both ways a Gs version conflict could happen and to use lyx.exe first before lyx.bat to see if the .eps file itself (command line parameters used) perhaps had a version glitch and I thought it would take about 5 minutes (without Matlab running) to see if this affected the problem. I think the Matlab doc I just reported upon supports this possibility. We also have a more recent version of system Ghostscript. My Sherlock Holmes sig, (inmates on death row tell jokes by #) Stephen
Re: openoffice
Juergen Fenn wrote: Stephen Harris [EMAIL PROTECTED] writes: Nick Thomas developed a script to convert LyX to OpenOffice called ConvTeX: http://wiki.lyx.org/Tools/LyX2OpenOffice [.sxw OOo ext.?] Yes, it still uses the OOo1 format sxw. which probably works a bit better on Linux than Windows. I've just tried it out on my Win98 box. There seem to be commands in the convtex.bat file that do not work under Win98. There also seem to be problems with handling paths. I've rewritten the batch file and the two other config files provided in the package to fit to my system, but it still doesn't work. :-( I'll keep on trying. 8-) Thanks for the hint, anyway. Didn't know about the project yet. Seems an interesting idea because the only other project for converting TeX OOo that I know of is oolatex from tex4ht, and this doesn't work either in MiKTeX 2.4... Regards, Jürgen. You mention Win98. I have Enrico's production of CygLyX1.4.1 working on Win98 in case there is version capability limitation. He has also released CygLyx1.4.2 but I haven't tested that yet. I haven't tried Convtex on Win98 either (it has a sick cdrom drive). Nick Thomas is actively working on this and wants testers and I'm sure he would appreciate somebody with some scripting knowledge as a tester. oolatex is a variant of htlatex with certain command line switches. The command htlatex foo.tex = foo.html which can be imported into Word, and changed to .doc, which OpenOffice can import works in WinXP, untested in Win98(my mother has its mouse). The unpolished output of htlatex: http://www.mathematik.uni-marburg.de/~gumm/LyX/Using_XYpic_in_LyX.htm The spaces in LY X can be fixed/typeset, see Ares http://wiki.lyx.org/LyX/Links or to go directly: http://www.webalice.it/ares001/job/tips.html TipsTricks I will send a copy of this post to Nick Thomas to introduce you. Regards, Stephen* http://www.webalice.it/ares001/job/tips.html *
Re: Fw: Postscript preview
Paul A. Rubin wrote: Stephen Harris wrote: The MATLAB Component Runtime (MCR) 7.0 and 7.1 do not contain a copy of the GhostScript program included with MATLAB. Therefore, applications deployed on a target machine rely on a locally- installed version of GhostScript, if one exists, for exporting some graphics. Since the version of GhostScript installed on the target machine may be different than the one included with MATLAB, the command line parameters potentially may be different as well. This difference causes an error in some instances. I think this supports the possibility of a Ghostscript conflict and that Matlab comes with its own version of Gs. It does indeed. So I agree that hypothetically Leo's MATLAB installation could be generating PS files (using it's own copy of GS) that would be indigestible to LyX-ImageMagick-GS (using a different copy of GS in the last step). That still raises the question of why those images would be successfully displayed in LyX (same LyX-ImageMagick-GS sequence) if an environment variable is deleted ... unless deletion of the environment variable affected which copy of GS was used (both on the command path?) ... in which case the bug would disappear, not switch to a different image. All that said, this bug is clearly not playing fair, so it would be a good idea for Leo to check into this just to rule it out. /Paul Yes there has to be another dimension to this. Recall he reinstalled LyX to C:\Lyx\lyx14 and the original problem files, I think it was test.ps, displayed Ok, but then another figure reared its ugly wolverine head. I would think that means that only some files are produced with the problem--either the same gs executable produces files which vary in compatibility or maybe system gs is producing the eps and it sometimes can't be read by an older matlab gs executable. Well, that is getting pretty thin. Maybe he could use the 1.4.1 lyx.bat and put Python at the beginning of the Path_prefix and try it and if it doesn't work, then try ghostscript at the beginning of Path_prefix also, but I think it is already. It would seem that the set variables in lyx1.4.2 batfile would have to part of it, but I don't know what they mean and they don't show up LC_ALL I will google one more time matlab and aikasaurus but I think that is just for Aspell. I'm not feeling well and can't concentrate. I've been up for two days fighting with a virus and am tired and have lost one partition on my hard drive. I guess its a trojan. Nope, I got a hit on allosaurus and matlab, but no aikasaurus. It's a Linux critter anyway. Regards, Stephen
Re: Fw: Postscript preview
Paul A. Rubin wrote: LB wrote: Ok, it tried this. I commented out SET LC_ALL=en_EN. This resulted in a different image having the preview problem. I placed SET XX=Y in lyx.bat and the preview problem moved back to the original image. The same happens when I comment out the other line in the lyx.bat. I also added extra lines in lyx.bat such as SET XX=Y this however did not make any difference as far as image preview is concerned. This is again confusing, though perhaps no more confusing than the fact that deleting unneeded environment variables (other than LC_ALL and the aiksaurus one) did not help. Another puzzling thing is that the preview problem jumps between two specific figures eventhough I have many figures in the document and many of them are generated with Matlab. The preview problem however never affects figures generated with other programs. Is there anything that the names/paths of the two affected figures have in common which is not shared by the other files. For instance, are they the longest paths, do they lie deeper in the directory tree than other figures, ... ? Stephen's idea of a second Ghostscript installation strikes me as possible but unlikely (and unlikely to be the culprit), since there would need to be something causing ImageMagick to alternate between the two GS installations on a figure-by-figure basis within the document (meaning that something in the figure names/paths would have to be triggering the switching). Also, Mathematica exports EPS without using GS and without installing its own GS, so I suspect the same might be true of MATLAB. Still, the whole bug is unlikely, so we shouldn't presume anything. It would be nice if we could intercept the call from IM to GS and see what's being passed, but so far I have not figured out how. /Paul - http://www.mathworks.com/support/solutions/data/1-ZBALJ.html?solution=1-ZBALJ "The MATLAB Component Runtime (MCR) 7.0 and 7.1 do not contain a copy of the GhostScript program included with MATLAB. Therefore, applications deployed on a target machine rely on a locally- installed version of GhostScript, if one exists, for exporting some graphics. Since the version of GhostScript installed on the target machine may be different than the one included with MATLAB, the command line parameters potentially may be different as well. This difference causes an error in some instances." I think this supports the possibility of a Ghostscript conflict and that Matlab comes with its own version of Gs. With an earlier distro of LyX I also had XemTeX installed which comes with its own Gs. It had a different version of Gs and the .dlls conflicted with LyX which was solved by moving Xemtex to the end of Windows Path. I'm pretty sure that lyx.exe checks the LyX directory for various executables because Enrico's batfiles seem to use this principle. I'm not so sure about lyx.bat because I thought it was possible that those set commands could change which Gs was invoked. I don't know what they do, the consequences of their mechanism. One major difference in the our environments and Leo's is that he has Matlab installed and we don't. I'm pretty sure that Matlab has Gs installed since I've googled and seen it listed as a sub-dir of Matlab's directory structure (though only for Linux). It should take Leo less than thirty seconds to find out with Win Explorer. I 've a hunch that his Matlab Gs version is earlier than his system Gs, supposing that there are two instances. My troubleshooting idea was to eliminate both ways a Gs version conflict could happen and to use lyx.exe first before lyx.bat to see if the .eps file itself (command line parameters used) perhaps had a version glitch and I thought it would take about 5 minutes (without Matlab running) to see if this affected the problem. I think the Matlab doc I just reported upon supports this possibility. We also have a more recent version of system Ghostscript. My Sherlock Holmes sig, (inmates on death row tell jokes by #) Stephen
Re: openoffice
Juergen Fenn wrote: Stephen Harris <[EMAIL PROTECTED]> writes: Nick Thomas developed a script to convert LyX to OpenOffice called ConvTeX: http://wiki.lyx.org/Tools/LyX2OpenOffice [.sxw OOo ext.?] Yes, it still uses the OOo1 format sxw. which probably works a bit better on Linux than Windows. I've just tried it out on my Win98 box. There seem to be commands in the convtex.bat file that do not work under Win98. There also seem to be problems with handling paths. I've rewritten the batch file and the two other config files provided in the package to fit to my system, but it still doesn't work. :-( I'll keep on trying. 8-) Thanks for the hint, anyway. Didn't know about the project yet. Seems an interesting idea because the only other project for converting TeX > OOo that I know of is oolatex from tex4ht, and this doesn't work either in MiKTeX 2.4... Regards, Jürgen. You mention Win98. I have Enrico's production of CygLyX1.4.1 working on Win98 in case there is version capability limitation. He has also released CygLyx1.4.2 but I haven't tested that yet. I haven't tried Convtex on Win98 either (it has a sick cdrom drive). Nick Thomas is actively working on this and wants testers and I'm sure he would appreciate somebody with some scripting knowledge as a tester. oolatex is a variant of htlatex with certain command line switches. The command "htlatex foo.tex" = foo.html which can be imported into Word, and changed to .doc, which OpenOffice can import works in WinXP, untested in Win98(my mother has its mouse). The unpolished output of htlatex: http://www.mathematik.uni-marburg.de/~gumm/LyX/Using_XYpic_in_LyX.htm The spaces in LY X can be fixed/typeset, see Ares http://wiki.lyx.org/LyX/Links or to go directly: http://www.webalice.it/ares001/job/tips.html Tips I will send a copy of this post to Nick Thomas to introduce you. Regards, Stephen* <http://www.webalice.it/ares001/job/tips.html> *
Re: Fw: Postscript preview
Paul A. Rubin wrote: Stephen Harris wrote: "The MATLAB Component Runtime (MCR) 7.0 and 7.1 do not contain a copy of the GhostScript program included with MATLAB. Therefore, applications deployed on a target machine rely on a locally- installed version of GhostScript, if one exists, for exporting some graphics. Since the version of GhostScript installed on the target machine may be different than the one included with MATLAB, the command line parameters potentially may be different as well. This difference causes an error in some instances." I think this supports the possibility of a Ghostscript conflict and that Matlab comes with its own version of Gs. It does indeed. So I agree that hypothetically Leo's MATLAB installation could be generating PS files (using it's own copy of GS) that would be indigestible to LyX->ImageMagick->GS (using a different copy of GS in the last step). That still raises the question of why those images would be successfully displayed in LyX (same LyX->ImageMagick->GS sequence) if an environment variable is deleted ... unless deletion of the environment variable affected which copy of GS was used (both on the command path?) ... in which case the bug would disappear, not switch to a different image. All that said, this bug is clearly not playing fair, so it would be a good idea for Leo to check into this just to rule it out. /Paul Yes there has to be another dimension to this. Recall he reinstalled LyX to C:\Lyx\lyx14 and the original problem files, I think it was test.ps, displayed Ok, but then another figure reared its ugly wolverine head. I would think that means that only some files are produced with the problem--either the same gs executable produces files which vary in compatibility or maybe system gs is producing the eps and it sometimes can't be read by an older matlab gs executable. Well, that is getting pretty thin. Maybe he could use the 1.4.1 lyx.bat and put Python at the beginning of the Path_prefix and try it and if it doesn't work, then try ghostscript at the beginning of Path_prefix also, but I think it is already. It would seem that the set variables in lyx1.4.2 batfile would have to part of it, but I don't know what they mean and they don't show up LC_ALL I will google one more time matlab and aikasaurus but I think that is just for Aspell. I'm not feeling well and can't concentrate. I've been up for two days fighting with a virus and am tired and have lost one partition on my hard drive. I guess its a trojan. Nope, I got a hit on allosaurus and matlab, but no aikasaurus. It's a Linux critter anyway. Regards, Stephen
Re: openoffice
Rainer M Krug wrote: This sounds interesting - where can I find this functionality? Because in LyX 1.4.2 in Linux there is no option under Export for this and I would be interested in using it. Rainer jouke hijlkema wrote: Hello all, I just tried to export a lyx document to openoffice writer format. All seems to work well but when I try to open the resulting document with openoffice 2.0 it complains about a format error in Content.xml. Any idea what that might be ?? Thanks, Jouke Nick Thomas developed a script to convert LyX to OpenOffice called ConvTeX: http://wiki.lyx.org/Tools/LyX2OpenOffice [.sxw OOo ext.?] which probably works a bit better on Linux than Windows. -- An ambient confluence of mapped coherence ~ Stephen
Re: openoffice
Paul Smith wrote: On 8/4/06, Stephen Harris [EMAIL PROTECTED] wrote: Nick Thomas developed a script to convert LyX to OpenOffice called ConvTeX: http://wiki.lyx.org/Tools/LyX2OpenOffice [.sxw OOo ext.?] which probably works a bit better on Linux than Windows. Maybe, it would be helpful to have it integrated in LyX itself. Does Nick Thomas' script convert formulas? Paul It did in the example file he sent me, ptolemy.sxw, but I don't know how consistent it is. -- Stephen
Re: Flow Chart Drawing For LaTeX/LyX
Rich Shepard wrote: On Fri, 4 Aug 2006, Paul Smith wrote: As you may see, the beamer fonts are respected in the xfig inset. IMNSHO, the major point is that we have multiple ways of accomplishing the same tasks and reaching the same goals. In the end -- on paper or projected on a screen -- they all work. None is better or worse, they're just all different. Is it Emacs or Vi? Xfce, Gnome, or KDE? One of the 200+ distributions? Who really cares? Perhaps some, but not me. You're both correct, and I am grateful to learn from both of you how you use your tool of choice. Thank you very much for that. Carpe weekend, Rich Many roads lead to Rome but that doesn't mean they all take the same time to get there or are equally as free of bumps. http://www.maa.org/editorial/mathgames/mathgames_08_01_05.html Lists a lot of drawing programs. The program I read most recommended is OmniGraffle (4 Pro) which comes with Macs. I'm also envious of BBedit. -- Stephen
Re: Fw: Postscript preview
LB wrote: One more little experiment, if you don't mind, just to confirm symptoms: if you comment out one of the SET commands in lyx.bat, but replace it with a line of equal length (SET XXX=Y... with enough Xs and Ys to match the line you commented out), does the bug move to a different image (or disappear)? Ok, it tried this. I commented out SET LC_ALL=en_EN. This resulted in a different image having the preview problem. I placed SET XX=Y in lyx.bat and the preview problem moved back to the original image. The same happens when I comment out the other line in the lyx.bat. I also added extra lines in lyx.bat such as SET XX=Y this however did not make any difference as far as image preview is concerned. Another puzzling thing is that the preview problem jumps between two specific figures eventhough I have many figures in the document and many of them are generated with Matlab. The preview problem however never affects figures generated with other programs. Thanks Leo Do you have two installations of ghostscript on your machine? One in a sub-directory for Matlab and another one in a sub-dir of LyX or maybe a system-wide Ghostscript? If so, that means if you rename the ghostscript executables, maybe they are gs.exe and gswin32.exe, to gs.bak and gswin32.bak, under the Matlab install of Ghostscript, then lyx.exe and lyx.bat should work the same. Try it first with lyx.exe which you know works and if it still works then the correct gs executable has been renamed. Then lyx.bat will have to use the same gs executable since the one under Matlab has been renamed and won't answer the call. It dawned on me that Matlab might have its own gs to make eps' Stephen -- An ambient confluence of mapped coherence ~ Stephen
Re: openoffice
Rainer M Krug wrote: This sounds interesting - where can I find this functionality? Because in LyX 1.4.2 in Linux there is no option under Export for this and I would be interested in using it. Rainer jouke hijlkema wrote: Hello all, I just tried to export a lyx document to openoffice writer format. All seems to work well but when I try to open the resulting document with openoffice 2.0 it complains about a format error in Content.xml. Any idea what that might be ?? Thanks, Jouke Nick Thomas developed a script to convert LyX to OpenOffice called ConvTeX: http://wiki.lyx.org/Tools/LyX2OpenOffice [.sxw OOo ext.?] which probably works a bit better on Linux than Windows. -- An ambient confluence of mapped coherence ~ Stephen
Re: openoffice
Paul Smith wrote: On 8/4/06, Stephen Harris [EMAIL PROTECTED] wrote: Nick Thomas developed a script to convert LyX to OpenOffice called ConvTeX: http://wiki.lyx.org/Tools/LyX2OpenOffice [.sxw OOo ext.?] which probably works a bit better on Linux than Windows. Maybe, it would be helpful to have it integrated in LyX itself. Does Nick Thomas' script convert formulas? Paul It did in the example file he sent me, ptolemy.sxw, but I don't know how consistent it is. -- Stephen
Re: Flow Chart Drawing For LaTeX/LyX
Rich Shepard wrote: On Fri, 4 Aug 2006, Paul Smith wrote: As you may see, the beamer fonts are respected in the xfig inset. IMNSHO, the major point is that we have multiple ways of accomplishing the same tasks and reaching the same goals. In the end -- on paper or projected on a screen -- they all work. None is better or worse, they're just all different. Is it Emacs or Vi? Xfce, Gnome, or KDE? One of the 200+ distributions? Who really cares? Perhaps some, but not me. You're both correct, and I am grateful to learn from both of you how you use your tool of choice. Thank you very much for that. Carpe weekend, Rich Many roads lead to Rome but that doesn't mean they all take the same time to get there or are equally as free of bumps. http://www.maa.org/editorial/mathgames/mathgames_08_01_05.html Lists a lot of drawing programs. The program I read most recommended is OmniGraffle (4 Pro) which comes with Macs. I'm also envious of BBedit. -- Stephen
Re: Fw: Postscript preview
LB wrote: One more little experiment, if you don't mind, just to confirm symptoms: if you comment out one of the SET commands in lyx.bat, but replace it with a line of equal length (SET XXX=Y... with enough Xs and Ys to match the line you commented out), does the bug move to a different image (or disappear)? Ok, it tried this. I commented out SET LC_ALL=en_EN. This resulted in a different image having the preview problem. I placed SET XX=Y in lyx.bat and the preview problem moved back to the original image. The same happens when I comment out the other line in the lyx.bat. I also added extra lines in lyx.bat such as SET XX=Y this however did not make any difference as far as image preview is concerned. Another puzzling thing is that the preview problem jumps between two specific figures eventhough I have many figures in the document and many of them are generated with Matlab. The preview problem however never affects figures generated with other programs. Thanks Leo Do you have two installations of ghostscript on your machine? One in a sub-directory for Matlab and another one in a sub-dir of LyX or maybe a system-wide Ghostscript? If so, that means if you rename the ghostscript executables, maybe they are gs.exe and gswin32.exe, to gs.bak and gswin32.bak, under the Matlab install of Ghostscript, then lyx.exe and lyx.bat should work the same. Try it first with lyx.exe which you know works and if it still works then the correct gs executable has been renamed. Then lyx.bat will have to use the same gs executable since the one under Matlab has been renamed and won't answer the call. It dawned on me that Matlab might have its own gs to make eps' Stephen -- An ambient confluence of mapped coherence ~ Stephen
Re: openoffice
Rainer M Krug wrote: This sounds interesting - where can I find this functionality? Because in LyX 1.4.2 in Linux there is no option under Export for this and I would be interested in using it. Rainer jouke hijlkema wrote: Hello all, I just tried to export a lyx document to openoffice writer format. All seems to work well but when I try to open the resulting document with openoffice 2.0 it complains about a format error in Content.xml. Any idea what that might be ?? Thanks, Jouke Nick Thomas developed a script to convert LyX to OpenOffice called ConvTeX: http://wiki.lyx.org/Tools/LyX2OpenOffice [.sxw OOo ext.?] which probably works a bit better on Linux than Windows. -- An ambient confluence of mapped coherence ~ Stephen
Re: openoffice
Paul Smith wrote: On 8/4/06, Stephen Harris <[EMAIL PROTECTED]> wrote: Nick Thomas developed a script to convert LyX to OpenOffice called ConvTeX: http://wiki.lyx.org/Tools/LyX2OpenOffice [.sxw OOo ext.?] which probably works a bit better on Linux than Windows. Maybe, it would be helpful to have it integrated in LyX itself. Does Nick Thomas' script convert formulas? Paul It did in the example file he sent me, ptolemy.sxw, but I don't know how consistent it is. -- Stephen
Re: Flow Chart Drawing For LaTeX/LyX
Rich Shepard wrote: On Fri, 4 Aug 2006, Paul Smith wrote: As you may see, the beamer fonts are respected in the xfig inset. IMNSHO, the major point is that we have multiple ways of accomplishing the same tasks and reaching the same goals. In the end -- on paper or projected on a screen -- they all work. None is better or worse, they're just all different. Is it Emacs or Vi? Xfce, Gnome, or KDE? One of the 200+ distributions? Who really cares? Perhaps some, but not me. You're both correct, and I am grateful to learn from both of you how you use your tool of choice. Thank you very much for that. Carpe weekend, Rich Many roads lead to Rome but that doesn't mean they all take the same time to get there or are equally as free of bumps. http://www.maa.org/editorial/mathgames/mathgames_08_01_05.html Lists a lot of drawing programs. The program I read most recommended is OmniGraffle (4 Pro) which comes with Macs. I'm also envious of BBedit. -- Stephen
Re: Fw: Postscript preview
LB wrote: One more little experiment, if you don't mind, just to confirm symptoms: if you comment out one of the SET commands in lyx.bat, but replace it with a line of equal length (SET XXX=Y... with enough Xs and Ys to match the line you commented out), does the bug move to a different image (or disappear)? Ok, it tried this. I commented out SET LC_ALL=en_EN. This resulted in a different image having the preview problem. I placed SET XX=Y in lyx.bat and the preview problem moved back to the original image. The same happens when I comment out the other line in the lyx.bat. I also added extra lines in lyx.bat such as SET XX=Y this however did not make any difference as far as image preview is concerned. Another puzzling thing is that the preview problem jumps between two specific figures eventhough I have many figures in the document and many of them are generated with Matlab. The preview problem however never affects figures generated with other programs. Thanks Leo Do you have two installations of ghostscript on your machine? One in a sub-directory for Matlab and another one in a sub-dir of LyX or maybe a system-wide Ghostscript? If so, that means if you rename the ghostscript executables, maybe they are gs.exe and gswin32.exe, to gs.bak and gswin32.bak, under the Matlab install of Ghostscript, then lyx.exe and lyx.bat should work the same. Try it first with lyx.exe which you know works and if it still works then the correct gs executable has been renamed. Then lyx.bat will have to use the same gs executable since the one under Matlab has been renamed and won't answer the call. It dawned on me that Matlab might have its own gs to make eps' Stephen -- An ambient confluence of mapped coherence ~ Stephen
Re: tex4ht just doesn't work for me ...
Matej Cepl wrote: Hi, couple of people mentioned htlatex as tool for conversion from LaTeX to HTML. I have long history (at least 2 years) of not being able to convert even quite simple LaTeX to HTML with tex4ht stuff. Using Debian/testing, I have tex4ht 20060619-1 and when I tried to convert my dissertation proposal, I got just garbage -- certainly not correct HTML. You can see record of my attempts on http://www.ceplovi.cz/matej/tmp/htlatex-record.zip . Could anybody explain me what's wrong with me, please? Thanks a lot, Matěj Perhaps you've been bitten by a mad wolverine? Your files worked on Windows with just htlatex dissertation-proposal and I sent the conversion in IE and Firefox formats to you. So the files are Ok, I would imagine... Regards, Stephen
Re: installing lyx on windows
Eric Inazaki wrote: Bo Peng [EMAIL PROTECTED] writes: On 8/2/06, Eric Inazaki [EMAIL PROTECTED] wrote: Does lyx choke (i.e. fail to start) when it's installed in C:\Program Files directory? This is with lyx 1.4.2 and Windows 2000, by the way. This happened to me on my first installation attempt. I tried reinstalling to C:\ and that works okay. Looking through some of these older messages, it seems that some folks don't have a problem installing to Program Files. If that's true, then what gives? Due to the anti-space nature of latex, it is safer to install lyx under a path without space. However, the developers have tried their best to let lyx works as *usual* (?) under windows. As a result, lyx 1.4.2 should work under c:\program files. If lyx can not start under your machines, it should be investigated. So, what exactly happened when you start lyx when it is installed under c:\program files? Bo I launch lyx from the Start/Program menu, a command window appears then disappears a split second later and that's it. No alert dialog, no nothing. As far a I'm concerned, lyx doesn't _have to_ be installed in program files. Installing it in c:\ is okay. Would've been nice to have had a heads-up is all. It's starting to sound like I might have done something screwy. Bet if I tried again from scratch I won't see this problem. eric Eric: A suggestion, if lyx really does have a problem being installed in Program Files then it'd be nice if that fact were well publicized (I found no mention of it on the lyx homepage, nor on the wiki). Also, when I did it, the default installation directory was C:\Program Files, this should probably be changed. SH: Installation and the path with spaces problem is mentioned on the Wiki, but you have to know where to look, but just searching for installation is going to produce over 60 hits and the new user isn't likely to know the paths with spaces keyword phrase. http://wiki.lyx.org/LyX/NewInLyX14?n=LyX.NewInLyX14action=searchq=installation#toc5http: lists the 2/60+ articles which mention installation and paths with spaces but how is the new user to know to choose them? The answer is an index with: Installation, see Paths with spaces; Paths with spaces, see Installation and a pointer in the FAQ to look at the Index. Methods like establishing layout files for LyX after adding .cls files would be in cross-referenced in the index and make new users aware of it. A search engine doesn't take the place of a well-designed index because the search engine doesn't inform one of the keyword used to describe the concept or provide a hint for related issues without reading a lot of documentation. I think a lot of stuff is present in the Wiki, just hard to find. Hooray for a source condensed information (milk of wisdom), Stephen - http://wiki.lyx.org/Windows/LyX136 Ekkehart Schlicht: Although LyX swallows path and folder names with blanks (such as C:\Program Files\...) this is not necessarily true for the other programs, and it is recommended to install them in the default locations suggested by the programs, or in paths without blanks (such as C:\Programs\...), just to be on the safe side. --- http://wiki.lyx.org/Windows/InstallationTipsForLyXWithAnAlternativeLaTeXDistribution It is good practice for LyX and its associated programs to be included in the Windows Path statement, whichever Latex distribution you are using. Choosing directories without spaces in them like C:\LyX rather than the default, C:\Program files\LyX is likely still the safer practice, unless the installer balks at changing the default and the install fails. --
Re: tex4ht just doesn't work for me ...
Matej Cepl wrote: Hi, couple of people mentioned htlatex as tool for conversion from LaTeX to HTML. I have long history (at least 2 years) of not being able to convert even quite simple LaTeX to HTML with tex4ht stuff. Using Debian/testing, I have tex4ht 20060619-1 and when I tried to convert my dissertation proposal, I got just garbage -- certainly not correct HTML. You can see record of my attempts on http://www.ceplovi.cz/matej/tmp/htlatex-record.zip . Could anybody explain me what's wrong with me, please? Thanks a lot, Matěj Perhaps you've been bitten by a mad wolverine? Your files worked on Windows with just htlatex dissertation-proposal and I sent the conversion in IE and Firefox formats to you. So the files are Ok, I would imagine... Regards, Stephen
Re: installing lyx on windows
Eric Inazaki wrote: Bo Peng [EMAIL PROTECTED] writes: On 8/2/06, Eric Inazaki [EMAIL PROTECTED] wrote: Does lyx choke (i.e. fail to start) when it's installed in C:\Program Files directory? This is with lyx 1.4.2 and Windows 2000, by the way. This happened to me on my first installation attempt. I tried reinstalling to C:\ and that works okay. Looking through some of these older messages, it seems that some folks don't have a problem installing to Program Files. If that's true, then what gives? Due to the anti-space nature of latex, it is safer to install lyx under a path without space. However, the developers have tried their best to let lyx works as *usual* (?) under windows. As a result, lyx 1.4.2 should work under c:\program files. If lyx can not start under your machines, it should be investigated. So, what exactly happened when you start lyx when it is installed under c:\program files? Bo I launch lyx from the Start/Program menu, a command window appears then disappears a split second later and that's it. No alert dialog, no nothing. As far a I'm concerned, lyx doesn't _have to_ be installed in program files. Installing it in c:\ is okay. Would've been nice to have had a heads-up is all. It's starting to sound like I might have done something screwy. Bet if I tried again from scratch I won't see this problem. eric Eric: A suggestion, if lyx really does have a problem being installed in Program Files then it'd be nice if that fact were well publicized (I found no mention of it on the lyx homepage, nor on the wiki). Also, when I did it, the default installation directory was C:\Program Files, this should probably be changed. SH: Installation and the path with spaces problem is mentioned on the Wiki, but you have to know where to look, but just searching for installation is going to produce over 60 hits and the new user isn't likely to know the paths with spaces keyword phrase. http://wiki.lyx.org/LyX/NewInLyX14?n=LyX.NewInLyX14action=searchq=installation#toc5http: lists the 2/60+ articles which mention installation and paths with spaces but how is the new user to know to choose them? The answer is an index with: Installation, see Paths with spaces; Paths with spaces, see Installation and a pointer in the FAQ to look at the Index. Methods like establishing layout files for LyX after adding .cls files would be in cross-referenced in the index and make new users aware of it. A search engine doesn't take the place of a well-designed index because the search engine doesn't inform one of the keyword used to describe the concept or provide a hint for related issues without reading a lot of documentation. I think a lot of stuff is present in the Wiki, just hard to find. Hooray for a source condensed information (milk of wisdom), Stephen - http://wiki.lyx.org/Windows/LyX136 Ekkehart Schlicht: Although LyX swallows path and folder names with blanks (such as C:\Program Files\...) this is not necessarily true for the other programs, and it is recommended to install them in the default locations suggested by the programs, or in paths without blanks (such as C:\Programs\...), just to be on the safe side. --- http://wiki.lyx.org/Windows/InstallationTipsForLyXWithAnAlternativeLaTeXDistribution It is good practice for LyX and its associated programs to be included in the Windows Path statement, whichever Latex distribution you are using. Choosing directories without spaces in them like C:\LyX rather than the default, C:\Program files\LyX is likely still the safer practice, unless the installer balks at changing the default and the install fails. --
Re: tex4ht just doesn't work for me ...
Matej Cepl wrote: Hi, couple of people mentioned htlatex as tool for conversion from LaTeX to HTML. I have long history (at least 2 years) of not being able to convert even quite simple LaTeX to HTML with tex4ht stuff. Using Debian/testing, I have tex4ht 20060619-1 and when I tried to convert my dissertation proposal, I got just garbage -- certainly not correct HTML. You can see record of my attempts on http://www.ceplovi.cz/matej/tmp/htlatex-record.zip . Could anybody explain me what's wrong with me, please? Thanks a lot, Matěj Perhaps you've been bitten by a mad wolverine? Your files worked on Windows with just "htlatex dissertation-proposal" and I sent the conversion in IE and Firefox formats to you. So the files are Ok, I would imagine... Regards, Stephen
Re: installing lyx on windows
Eric Inazaki wrote: Bo Peng <[EMAIL PROTECTED]> writes: On 8/2/06, Eric Inazaki <[EMAIL PROTECTED]> wrote: Does lyx choke (i.e. fail to start) when it's installed in "C:\Program Files" directory? This is with lyx 1.4.2 and Windows 2000, by the way. This happened to me on my first installation attempt. I tried reinstalling to "C:\" and that works okay. Looking through some of these older messages, it seems that some folks don't have a problem installing to "Program Files". If that's true, then what gives? Due to the anti-space nature of latex, it is safer to install lyx under a path without space. However, the developers have tried their best to let lyx works as *usual* (?) under windows. As a result, lyx 1.4.2 should work under c:\program files. If lyx can not start under your machines, it should be investigated. So, what exactly happened when you start lyx when it is installed under c:\program files? Bo I launch lyx from the Start/Program menu, a command window appears then disappears a split second later and that's it. No alert dialog, no nothing. As far a I'm concerned, lyx doesn't _have to_ be installed in "program files". Installing it in "c:\" is okay. Would've been nice to have had a heads-up is all. It's starting to sound like I might have done something screwy. Bet if I tried again from scratch I won't see this problem. eric Eric: A suggestion, if lyx really does have a problem being installed in > > "Program Files" then it'd be nice if that fact were well publicized > > (I found no mention of it on the lyx homepage, nor on the wiki). > > Also, when I did it, the default installation directory was > > "C:\Program Files", this should probably be changed. SH: Installation and the path with spaces problem is mentioned on the Wiki, but you have to know where to look, but just searching for installation is going to produce over 60 hits and the new user isn't likely to know the "paths with spaces" keyword phrase. http://wiki.lyx.org/LyX/NewInLyX14?n=LyX.NewInLyX14=search=installation#toc5http: lists the 2/60+ articles which mention installation and paths with spaces but how is the new user to know to choose them? The answer is an index with: Installation, see Paths with spaces; Paths with spaces, see Installation and a pointer in the FAQ to look at the Index. Methods like establishing layout files for LyX after adding .cls files would be in cross-referenced in the index and make new users aware of it. A search engine doesn't take the place of a well-designed index because the search engine doesn't inform one of the keyword used to describe the concept or provide a hint for related issues without reading a lot of documentation. I think a lot of stuff is present in the Wiki, just hard to find. Hooray for a source condensed information (milk of wisdom), Stephen - http://wiki.lyx.org/Windows/LyX136 Ekkehart Schlicht: "Although LyX swallows path and folder names with blanks (such as C:\Program Files\...) this is not necessarily true for the other programs, and it is recommended to install them in the default locations suggested by the programs, or in paths without blanks (such as C:\Programs\...), just to be on the safe side." --- http://wiki.lyx.org/Windows/InstallationTipsForLyXWithAnAlternativeLaTeXDistribution "It is good practice for LyX and its associated programs to be included in the Windows Path statement, whichever Latex distribution you are using. Choosing directories without spaces in them like C:\LyX rather than the default, C:\Program files\LyX is likely still the safer practice, unless the installer balks at changing the default and the install fails." --
Re: Fw: Postscript preview
LB wrote: I uninstalled Lyx and reinstalled it into c:\lyx\lyx14. This solved my figure problem!!! Thank you. I can now use 1.4.2 Looks like I spoke too soon. Now a different figure does not want to be displayed. Leo Does it display the same old symptoms; it works with lyx.exe or if you delete one of the set commands in lyx.bat? If the figure doesn't work with lyx.exe then it is the file. Try it with both (the old one which now works and the broken new one) in the same directory. A rather inexplicable matter. Perplexed, Stephen
Re: Fw: Postscript preview
LB wrote: I uninstalled Lyx and reinstalled it into c:\lyx\lyx14. This solved my figure problem!!! Thank you. I can now use 1.4.2 Looks like I spoke too soon. Now a different figure does not want to be displayed. Leo Does it display the same old symptoms; it works with lyx.exe or if you delete one of the set commands in lyx.bat? If the figure doesn't work with lyx.exe then it is the file. Try it with both (the old one which now works and the broken new one) in the same directory. A rather inexplicable matter. Perplexed, Stephen
Re: Fw: Postscript preview
LB wrote: I uninstalled Lyx and reinstalled it into c:\lyx\lyx14. This solved my figure problem!!! Thank you. I can now use 1.4.2 Looks like I spoke too soon. Now a different figure does not want to be displayed. Leo Does it display the same old symptoms; it works with lyx.exe or if you delete one of the "set" commands in lyx.bat? If the figure doesn't work with lyx.exe then it is the file. Try it with both (the old one which now works and the broken new one) in the same directory. A rather inexplicable matter. Perplexed, Stephen
Re: index in tex file
Wolfgang Engelmann wrote: What is the best way to get the index (.idx) into the tex file of my document? Unfortunately the publisher wants a .doc file ... (ConvTex - swx - OO - word) Wolfgang I've tested ConvTex and it works, but not consistently from what I've seen for equations, so it depends upon the content of your document. So I would try ConvTex and also export your .lyx file as .tex and try htlatex yourdoc.tex = yourdoc.html then use Word to open the yourdoc.html and convert it to .doc. This last works the best for me but others have had trouble getting htlatex to run. I think the .html conversion into Word/doc is slightly better than OOo/sxw/doc but I'm not sure about a humanities/text document. Both conversions are rather easy so you could try both and compare them. Nick Thomas has done a good job getting this to work on Windows and I think ConvTex may perform still a bit better on Linux. Incidentally oolatex is an htlatex variant with swithces and I've always had trouble getting it to work in OOo. Regards, Stephen -- An ambient confluence of mapped coherence ~ Stephen
Re: Fw: Postscript preview
LB wrote: Hi one more idea: if this is really a PATH problem and things worked normally under lyx 1.4.1, then I would do the following simple steps (unless you already tried this and I didn't see it in the earlier messages): (a) Revert to LyX 1.4.1 and open the Preferences dialog to find out EXACTLY what your PATH setting is in that program. The path in 1.4.1: C:\LyX\Python24;C:\LyX\msys\1.0\bin;C:\LyX\texmf\miktex\bin;c:\lyx\gs\gs8.14\bin;C:\LyX\ImageMagick (b) Copy that string. (c) Re-install LyX 1.4.2 and open the Prefs dialog there to see its PATH settings. I would strongly suspect that this is somehow different from 1.4.1. Reinstalled Lyx 1.4.2 Its PATH is: C:\LyX\Python24;C:\LyX\msys\1.0\bin;C:\LyX\texmf\miktex\bin;c:\lyx\gs\gs8.14\bin;C:\LyX\ImageMagick (d) Enter the previously copied PATH from 1.4.1 into the PATH box in 1.4.2. The paths are exactly the same; (e) Restart LyX 1.4.2 (just to be safe), and see if the preview works now.This also did not work.Thank youLeo The paths are not supposed to be the same. LyX 1.4.1 did not install a python directory under LyX. Also the batfiles are not the same. This usually happens when the preferences files under c:\documents and settings\yourusername~~~\~ are not deleted during the uninstall. Then the next version picks up the old preferences and sometimes doesn't work right. Maybe you have more than just two copies of LyX installed, 1.4.1 and 1.4.2. You can do a Windows Search for the filename lyx.exe and see if if reports more than two instances on your C drive. Also do a search for preferences. Regards, Stephen
Re: Fw: Postscript preview
LB wrote: The paths are not supposed to be the same. LyX 1.4.1 did not install a python directory under LyX. Also the batfiles are not the same. This usually happens when the preferences files under c:\documents and settings\yourusername~~~\~ are not deleted during the uninstall. Then the next version picks up the old preferences and sometimes doesn't work right. Maybe you have more than just two copies of LyX installed, 1.4.1 and 1.4.2. You can do a Windows Search for the filename lyx.exe and see if if reports more than two instances on your C drive. Also do a search for preferences. Ok. I did not uninstall old versions of Lyx because I'm always worried about upgrading to a new version when an old one is working fine and not being able to open older documents with the new versions. So I have in the Lyx directory four subdirectories Lyx1.3.3, Lyx1.3.5, Lyx1.4.1 and Lyx1.4.2 that contain the four different installs. I only have one preferences file in .lyx directory though. Leo C:\Documents and Settings\Stephen\Application Data\LyX I have a preference file (your^username) and lyxrc.defaults in this directory. WinXP hides some directories; so your ~\Application Data directory contains no LyX* sub-directory? I have CygwinLyX1.4.1 and native Windows Lyx1.4.2 both installed without conflict. In the past I've had trouble with Cygwin's version of Ghostscript conflicting with the Windows version of Ghostscript. And when I tried to install TexLive2005 which is very much like Miktex, I had to fix a conflict with environmental variables, Texmfdir, I think. Your files test OK on my system. I think you should try uninstalling LyX1.4.2 (there is a Cygwin1.4.2 available) and installing it to the default C:\LyX\lyx14 directory, it is designed not to conflict with concurrent versions. Windows doesn't like a dot, . , prefix to directories and you can't make them in Windows Explorer, just Dos. If you do, remember to put the system Python installation at the front of Path_prefix, the local lyx one is tired. You've noticed the batfiles are different, 141 to 142... I don't understand what the 142 batfile does well enough to suggest using the 141 batfile instead of the 142 bat. SET LC_ALL=en_EN versus SET LANG=en_EN which used to work. Stephen
Re: index in tex file
Wolfgang Engelmann wrote: What is the best way to get the index (.idx) into the tex file of my document? Unfortunately the publisher wants a .doc file ... (ConvTex - swx - OO - word) Wolfgang I've tested ConvTex and it works, but not consistently from what I've seen for equations, so it depends upon the content of your document. So I would try ConvTex and also export your .lyx file as .tex and try htlatex yourdoc.tex = yourdoc.html then use Word to open the yourdoc.html and convert it to .doc. This last works the best for me but others have had trouble getting htlatex to run. I think the .html conversion into Word/doc is slightly better than OOo/sxw/doc but I'm not sure about a humanities/text document. Both conversions are rather easy so you could try both and compare them. Nick Thomas has done a good job getting this to work on Windows and I think ConvTex may perform still a bit better on Linux. Incidentally oolatex is an htlatex variant with swithces and I've always had trouble getting it to work in OOo. Regards, Stephen -- An ambient confluence of mapped coherence ~ Stephen
Re: Fw: Postscript preview
LB wrote: Hi one more idea: if this is really a PATH problem and things worked normally under lyx 1.4.1, then I would do the following simple steps (unless you already tried this and I didn't see it in the earlier messages): (a) Revert to LyX 1.4.1 and open the Preferences dialog to find out EXACTLY what your PATH setting is in that program. The path in 1.4.1: C:\LyX\Python24;C:\LyX\msys\1.0\bin;C:\LyX\texmf\miktex\bin;c:\lyx\gs\gs8.14\bin;C:\LyX\ImageMagick (b) Copy that string. (c) Re-install LyX 1.4.2 and open the Prefs dialog there to see its PATH settings. I would strongly suspect that this is somehow different from 1.4.1. Reinstalled Lyx 1.4.2 Its PATH is: C:\LyX\Python24;C:\LyX\msys\1.0\bin;C:\LyX\texmf\miktex\bin;c:\lyx\gs\gs8.14\bin;C:\LyX\ImageMagick (d) Enter the previously copied PATH from 1.4.1 into the PATH box in 1.4.2. The paths are exactly the same; (e) Restart LyX 1.4.2 (just to be safe), and see if the preview works now.This also did not work.Thank youLeo The paths are not supposed to be the same. LyX 1.4.1 did not install a python directory under LyX. Also the batfiles are not the same. This usually happens when the preferences files under c:\documents and settings\yourusername~~~\~ are not deleted during the uninstall. Then the next version picks up the old preferences and sometimes doesn't work right. Maybe you have more than just two copies of LyX installed, 1.4.1 and 1.4.2. You can do a Windows Search for the filename lyx.exe and see if if reports more than two instances on your C drive. Also do a search for preferences. Regards, Stephen
Re: Fw: Postscript preview
LB wrote: The paths are not supposed to be the same. LyX 1.4.1 did not install a python directory under LyX. Also the batfiles are not the same. This usually happens when the preferences files under c:\documents and settings\yourusername~~~\~ are not deleted during the uninstall. Then the next version picks up the old preferences and sometimes doesn't work right. Maybe you have more than just two copies of LyX installed, 1.4.1 and 1.4.2. You can do a Windows Search for the filename lyx.exe and see if if reports more than two instances on your C drive. Also do a search for preferences. Ok. I did not uninstall old versions of Lyx because I'm always worried about upgrading to a new version when an old one is working fine and not being able to open older documents with the new versions. So I have in the Lyx directory four subdirectories Lyx1.3.3, Lyx1.3.5, Lyx1.4.1 and Lyx1.4.2 that contain the four different installs. I only have one preferences file in .lyx directory though. Leo C:\Documents and Settings\Stephen\Application Data\LyX I have a preference file (your^username) and lyxrc.defaults in this directory. WinXP hides some directories; so your ~\Application Data directory contains no LyX* sub-directory? I have CygwinLyX1.4.1 and native Windows Lyx1.4.2 both installed without conflict. In the past I've had trouble with Cygwin's version of Ghostscript conflicting with the Windows version of Ghostscript. And when I tried to install TexLive2005 which is very much like Miktex, I had to fix a conflict with environmental variables, Texmfdir, I think. Your files test OK on my system. I think you should try uninstalling LyX1.4.2 (there is a Cygwin1.4.2 available) and installing it to the default C:\LyX\lyx14 directory, it is designed not to conflict with concurrent versions. Windows doesn't like a dot, . , prefix to directories and you can't make them in Windows Explorer, just Dos. If you do, remember to put the system Python installation at the front of Path_prefix, the local lyx one is tired. You've noticed the batfiles are different, 141 to 142... I don't understand what the 142 batfile does well enough to suggest using the 141 batfile instead of the 142 bat. SET LC_ALL=en_EN versus SET LANG=en_EN which used to work. Stephen
Re: index in tex file
Wolfgang Engelmann wrote: What is the best way to get the index (.idx) into the tex file of my document? Unfortunately the publisher wants a .doc file ... (ConvTex -> swx -> OO -> word) Wolfgang I've tested ConvTex and it works, but not consistently from what I've seen for equations, so it depends upon the content of your document. So I would try ConvTex and also export your .lyx file as .tex and try "htlatex yourdoc.tex" = yourdoc.html then use Word to open the yourdoc.html and convert it to .doc. This last works the best for me but others have had trouble getting htlatex to run. I think the .html conversion into Word/doc is slightly better than OOo/sxw/doc but I'm not sure about a humanities/text document. Both conversions are rather easy so you could try both and compare them. Nick Thomas has done a good job getting this to work on Windows and I think ConvTex may perform still a bit better on Linux. Incidentally oolatex is an htlatex variant with swithces and I've always had trouble getting it to work in OOo. Regards, Stephen -- An ambient confluence of mapped coherence ~ Stephen
Re: Fw: Postscript preview
LB wrote: Hi one more idea: if this is really a PATH problem and things worked normally under lyx 1.4.1, then I would do the following simple steps (unless you already tried this and I didn't see it in the earlier messages): (a) Revert to LyX 1.4.1 and open the Preferences dialog to find out EXACTLY what your PATH setting is in that program. The path in 1.4.1: C:\LyX\Python24;C:\LyX\msys\1.0\bin;C:\LyX\texmf\miktex\bin;c:\lyx\gs\gs8.14\bin;C:\LyX\ImageMagick (b) Copy that string. (c) Re-install LyX 1.4.2 and open the Prefs dialog there to see its PATH settings. I would strongly suspect that this is somehow different from 1.4.1. Reinstalled Lyx 1.4.2 Its PATH is: C:\LyX\Python24;C:\LyX\msys\1.0\bin;C:\LyX\texmf\miktex\bin;c:\lyx\gs\gs8.14\bin;C:\LyX\ImageMagick>>> (d)>> Enter the previously copied PATH from 1.4.1 into the PATH box in 1.4.2.> The paths are exactly the same;>>> (e)>> Restart LyX 1.4.2 (just to be safe), and see if the preview works now.>This also did not work.Thank youLeo The paths are not supposed to be the same. LyX 1.4.1 did not install a python directory under LyX. Also the batfiles are not the same. This usually happens when the preferences files under c:\documents and settings\yourusername~~~\~ are not deleted during the uninstall. Then the next version picks up the old preferences and sometimes doesn't work right. Maybe you have more than just two copies of LyX installed, 1.4.1 and 1.4.2. You can do a Windows Search for the filename lyx.exe and see if if reports more than two instances on your C drive. Also do a search for "preferences". Regards, Stephen
Re: Fw: Postscript preview
LB wrote: The paths are not supposed to be the same. LyX 1.4.1 did not install a python directory under LyX. Also the batfiles are not the same. This usually happens when the preferences files under c:\documents and settings\yourusername~~~\~ are not deleted during the uninstall. Then the next version picks up the old preferences and sometimes doesn't work right. Maybe you have more than just two copies of LyX installed, 1.4.1 and 1.4.2. You can do a Windows Search for the filename lyx.exe and see if if reports more than two instances on your C drive. Also do a search for "preferences". Ok. I did not uninstall old versions of Lyx because I'm always worried about upgrading to a new version when an old one is working fine and not being able to open older documents with the new versions. So I have in the Lyx directory four subdirectories Lyx1.3.3, Lyx1.3.5, Lyx1.4.1 and Lyx1.4.2 that contain the four different installs. I only have one "preferences" file in .lyx directory though. Leo C:\Documents and Settings\Stephen\Application Data\LyX I have a preference file (your^username) and lyxrc.defaults in this directory. WinXP hides some directories; so your ~\Application Data directory contains no LyX* sub-directory? I have CygwinLyX1.4.1 and native Windows Lyx1.4.2 both installed without conflict. In the past I've had trouble with Cygwin's version of Ghostscript conflicting with the Windows version of Ghostscript. And when I tried to install TexLive2005 which is very much like Miktex, I had to fix a conflict with environmental variables, Texmfdir, I think. Your files test OK on my system. I think you should try uninstalling LyX1.4.2 (there is a Cygwin1.4.2 available) and installing it to the default C:\LyX\lyx14 directory, it is designed not to conflict with concurrent versions. Windows doesn't like a dot, . , prefix to directories and you can't make them in Windows Explorer, just Dos. If you do, remember to put the system Python installation at the front of Path_prefix, the local lyx one is tired. You've noticed the batfiles are different, 141 to 142... I don't understand what the 142 batfile does well enough to suggest using the 141 batfile instead of the 142 bat. SET LC_ALL=en_EN versus SET LANG=en_EN which used to work. Stephen
Re: please consolidate the documentation
Helge Hafting wrote: On Fri, Jul 21, 2006 at 12:08:48AM +1000, John Pye wrote: I don't think that we should expect people to use LyX as their documentation browser. Sure, LyX is not my choice for a browser. But documentation for LyX itself is a special case, see below: Operating systems all provide good standard ways of accessing help: Installed LyX documentation should play nice with those so that there's one less thing for new users to learn. Well, supplying LyX docs in pdf and html is nice, of course. Still, the main format for LyX documentation must be LyX files. LyX is supposed to be a document processor good for just this sort of documents, so using anything else would show a worrisome lack of confidence in our own software. The User's Guide is a nice showcase for what can be done with LyX, and it is a quick demonstration of how well LyX handles long documents. (It is quite a few pages, and for demonstration purposes, try copy-pasting the entire thing several times . . . no crash.) Helge Hafting I can't imagine first writing LyX documentation in any other format than .lyx. Most people don't read the docs first, but turn to them when they need to find solutions. So suppose they want to know what the User's Guide has to say about margins. Do you think that the LyX: Find Replace has been designed for the purpose of finding information for solving problems or as an editing tool? The .pdf format doesn't normally allow editing of the content so searching is designed for finding keywords to solve problems with a more evolved interface. Because LyX can serve in this capacity doesn't mean it is optimal in comparison to a tool made for this purpose. I think a fair estimate is that the documentation is initially read by people who have not learned that it is cost effective to read the documentation first, and that a huge majority of users will be reading and searching for keywords while troubleshooting. I think the strength of LyX is that it can convert from the .lyx format to *other* user preferred formats which might have small features like a magnifying glass for reading the small print of a diagram, which isn't (AFAIK) included in LyX because it has so little application to the focus of LyX. The Windows LyX display is only about 90-95% of the quality of LyX displayed on Linux or Cygwin, which is another small reason to convert it to a format that maintains quality equality for longer readings. It can be said that a user could glean some information by inspecting the structure of a LyX guide self-referentially gathering some visual clues. This seems to be a strength of using LyX for reading documentation when compared to a pdf reader. But if you compare LyX to the Visual FAQ by Scott Pakin, tug.ctan.org/tex-archive/info/visualFAQ/ , you will see a tool designed for a function LyX stretches to fill. LyX is like a pair of pliers that can be pressed into doing the job extemes of a couple of different size wrenches like the Visual FAQ, and Reader with its advanced search options. LyX is supposed to be a document processor good for just this sort of documents, so using anything else would show a worrisome lack of confidence in our own software. I think the claim that Lyx is the best tool for creating help guides etc. is not the same claim as that LyX is the best tool for reading such documents it creates, and matches or surpasses a mature pdf reader which is dedicated to displaying and searches. The subject: please consolidate the documentation, is I think motivated by difficulty in finding a solution to some problem. If the Wiki were converted to one huge .lyx file, I doubt that it would be that helpful, though you could do time consuming searches for some keyword, if the user knew the right keyword. Building a faster internal storage of keywords found on the Wiki will not be so useful to the new user, but will more serve the experienced user who knows what concept to look for. So a detailed back of the book type index is in a more usable format than a list of words and their locations produced by the search engine and it is also a faster search. The new user perusing such an index replete with see and see also opens the door for a serendipitous juxtaposition of chance into design. A few shorter LyX visual faqs, each covering some major topic, with the potential of being merged later, would stifle any complaints about inadequate documentation being too spread out. If wishes were horses, beggars would ride (wishlist), Stephen
Re: Postscript preview
LB wrote: When you added the GS path in lyx.bat, did you add the path to the lib directory as well as to the bin directory? Yes I did. I'm giving up and going back to use version 1.4.1. Well, I can't say I blame you ... 1.4.1 worked pretty well for me. I just hope this problem does not recur when we get to 1.5 and there is some must have new feature. BTW, I generated another figure with Matlab that has the same problem. It looks like when I generate figures with Matlab I run into trouble with previewing figure with 1.4.2 but not with any other versions. I have tried 1.4.1, 1.3.7 and 1.3.5. Cheers Leo I didn't have any bright ideas. But since it seems you are close to giving up, I thought I would toss out some longshots. PROGRA~1\MENTOR~1\PADS\2005_1\Programs;c:\lyx\ly (from 7/28/2006 12:03 pm, PATH report) SH: Maybe that is a typo the ly looks wrong. As Jose mentions, upgrading Ghostscript might help, because version 7.07 had a bug with paths with spaces. A very longshot is that the local LyX Python is buggy with utf8 support but those files don't cure it. Do you have the full Python installed? If so put it at the front of Path_prefix statement in LyX and it will supersede the local partial version of Python. Vaguely, the locale might connect to the set commands. I said it was a longshot. The set command used to say set lang=en_US if one used English. I couldn't find info on what LC does... Anyway replacing GS is a good idea, and if you already have the full Python, it is easy to *_prepend_* C:\Python243 to the LyX Path_prefix and have a fully functioning Python, since the extent of the local Python, mostly successful, may have other gaps. I've had a problem with set environmental variables once before. Another departed version of *tex had left its value behind and conflicted with the new version which wanted to set the same variable to a new place. (Cygwin and TexLive2005). Well, that was just rambling. -- An ambient confluence of mapped coherence ~ Stephen
Re: please consolidate the documentation
Helge Hafting wrote: On Fri, Jul 21, 2006 at 12:08:48AM +1000, John Pye wrote: I don't think that we should expect people to use LyX as their documentation browser. Sure, LyX is not my choice for a browser. But documentation for LyX itself is a special case, see below: Operating systems all provide good standard ways of accessing help: Installed LyX documentation should play nice with those so that there's one less thing for new users to learn. Well, supplying LyX docs in pdf and html is nice, of course. Still, the main format for LyX documentation must be LyX files. LyX is supposed to be a document processor good for just this sort of documents, so using anything else would show a worrisome lack of confidence in our own software. The User's Guide is a nice showcase for what can be done with LyX, and it is a quick demonstration of how well LyX handles long documents. (It is quite a few pages, and for demonstration purposes, try copy-pasting the entire thing several times . . . no crash.) Helge Hafting I can't imagine first writing LyX documentation in any other format than .lyx. Most people don't read the docs first, but turn to them when they need to find solutions. So suppose they want to know what the User's Guide has to say about margins. Do you think that the LyX: Find Replace has been designed for the purpose of finding information for solving problems or as an editing tool? The .pdf format doesn't normally allow editing of the content so searching is designed for finding keywords to solve problems with a more evolved interface. Because LyX can serve in this capacity doesn't mean it is optimal in comparison to a tool made for this purpose. I think a fair estimate is that the documentation is initially read by people who have not learned that it is cost effective to read the documentation first, and that a huge majority of users will be reading and searching for keywords while troubleshooting. I think the strength of LyX is that it can convert from the .lyx format to *other* user preferred formats which might have small features like a magnifying glass for reading the small print of a diagram, which isn't (AFAIK) included in LyX because it has so little application to the focus of LyX. The Windows LyX display is only about 90-95% of the quality of LyX displayed on Linux or Cygwin, which is another small reason to convert it to a format that maintains quality equality for longer readings. It can be said that a user could glean some information by inspecting the structure of a LyX guide self-referentially gathering some visual clues. This seems to be a strength of using LyX for reading documentation when compared to a pdf reader. But if you compare LyX to the Visual FAQ by Scott Pakin, tug.ctan.org/tex-archive/info/visualFAQ/ , you will see a tool designed for a function LyX stretches to fill. LyX is like a pair of pliers that can be pressed into doing the job extemes of a couple of different size wrenches like the Visual FAQ, and Reader with its advanced search options. LyX is supposed to be a document processor good for just this sort of documents, so using anything else would show a worrisome lack of confidence in our own software. I think the claim that Lyx is the best tool for creating help guides etc. is not the same claim as that LyX is the best tool for reading such documents it creates, and matches or surpasses a mature pdf reader which is dedicated to displaying and searches. The subject: please consolidate the documentation, is I think motivated by difficulty in finding a solution to some problem. If the Wiki were converted to one huge .lyx file, I doubt that it would be that helpful, though you could do time consuming searches for some keyword, if the user knew the right keyword. Building a faster internal storage of keywords found on the Wiki will not be so useful to the new user, but will more serve the experienced user who knows what concept to look for. So a detailed back of the book type index is in a more usable format than a list of words and their locations produced by the search engine and it is also a faster search. The new user perusing such an index replete with see and see also opens the door for a serendipitous juxtaposition of chance into design. A few shorter LyX visual faqs, each covering some major topic, with the potential of being merged later, would stifle any complaints about inadequate documentation being too spread out. If wishes were horses, beggars would ride (wishlist), Stephen
Re: Postscript preview
LB wrote: When you added the GS path in lyx.bat, did you add the path to the lib directory as well as to the bin directory? Yes I did. I'm giving up and going back to use version 1.4.1. Well, I can't say I blame you ... 1.4.1 worked pretty well for me. I just hope this problem does not recur when we get to 1.5 and there is some must have new feature. BTW, I generated another figure with Matlab that has the same problem. It looks like when I generate figures with Matlab I run into trouble with previewing figure with 1.4.2 but not with any other versions. I have tried 1.4.1, 1.3.7 and 1.3.5. Cheers Leo I didn't have any bright ideas. But since it seems you are close to giving up, I thought I would toss out some longshots. PROGRA~1\MENTOR~1\PADS\2005_1\Programs;c:\lyx\ly (from 7/28/2006 12:03 pm, PATH report) SH: Maybe that is a typo the ly looks wrong. As Jose mentions, upgrading Ghostscript might help, because version 7.07 had a bug with paths with spaces. A very longshot is that the local LyX Python is buggy with utf8 support but those files don't cure it. Do you have the full Python installed? If so put it at the front of Path_prefix statement in LyX and it will supersede the local partial version of Python. Vaguely, the locale might connect to the set commands. I said it was a longshot. The set command used to say set lang=en_US if one used English. I couldn't find info on what LC does... Anyway replacing GS is a good idea, and if you already have the full Python, it is easy to *_prepend_* C:\Python243 to the LyX Path_prefix and have a fully functioning Python, since the extent of the local Python, mostly successful, may have other gaps. I've had a problem with set environmental variables once before. Another departed version of *tex had left its value behind and conflicted with the new version which wanted to set the same variable to a new place. (Cygwin and TexLive2005). Well, that was just rambling. -- An ambient confluence of mapped coherence ~ Stephen
Re: please consolidate the documentation
Helge Hafting wrote: On Fri, Jul 21, 2006 at 12:08:48AM +1000, John Pye wrote: I don't think that we should expect people to use LyX as their documentation browser. Sure, LyX is not my choice for a browser. But documentation for LyX itself is a special case, see below: Operating systems all provide good standard ways of accessing help: Installed LyX documentation should play nice with those so that there's one less thing for new users to learn. Well, supplying LyX docs in pdf and html is nice, of course. Still, the main format for LyX documentation must be LyX files. LyX is supposed to be a document processor good for just this sort of documents, so using anything else would show a worrisome lack of confidence in our own software. The User's Guide is a nice showcase for what can be done with LyX, and it is a quick demonstration of how well LyX handles long documents. (It is quite a few pages, and for demonstration purposes, try copy-pasting the entire thing several times . . . no crash.) Helge Hafting I can't imagine first writing LyX documentation in any other format than .lyx. Most people don't read the docs first, but turn to them when they need to find solutions. So suppose they want to know what the User's Guide has to say about "margins". Do you think that the LyX: Find & Replace has been designed for the purpose of finding information for solving problems or as an editing tool? The .pdf format doesn't normally allow editing of the content so searching is designed for finding keywords to solve problems with a more evolved interface. Because LyX can serve in this capacity doesn't mean it is optimal in comparison to a tool made for this purpose. I think a fair estimate is that the documentation is initially read by people who have not learned that it is cost effective to read the documentation first, and that a huge majority of users will be reading and searching for keywords while troubleshooting. I think the strength of LyX is that it can convert from the .lyx format to *other* user preferred formats which might have small features like a magnifying glass for reading the small print of a diagram, which isn't (AFAIK) included in LyX because it has so little application to the focus of LyX. The Windows LyX display is only about 90-95% of the quality of LyX displayed on Linux or Cygwin, which is another small reason to convert it to a format that maintains quality equality for longer readings. It can be said that a user could glean some information by inspecting the structure of a LyX guide self-referentially gathering some visual clues. This seems to be a strength of using LyX for reading documentation when compared to a pdf reader. But if you compare LyX to the Visual FAQ by Scott Pakin, tug.ctan.org/tex-archive/info/visualFAQ/ , you will see a tool designed for a function LyX stretches to fill. LyX is like a pair of pliers that can be pressed into doing the job extemes of a couple of different size wrenches like the Visual FAQ, and Reader with its advanced search options. > LyX is supposed to be a document processor good for just this sort > of documents, so using anything else would show a worrisome lack > of confidence in our own software. I think the claim that Lyx is the best tool for creating help guides etc. is not the same claim as that LyX is the best tool for reading such documents it creates, and matches or surpasses a mature pdf reader which is dedicated to displaying and searches. The subject: please consolidate the documentation, is I think motivated by difficulty in finding a solution to some problem. If the Wiki were converted to one huge .lyx file, I doubt that it would be that helpful, though you could do time consuming searches for some keyword, if the user knew the right keyword. Building a faster internal storage of keywords found on the Wiki will not be so useful to the new user, but will more serve the experienced user who knows what concept to look for. So a detailed back of the book type index is in a more usable format than a list of words and their locations produced by the search engine and it is also a faster search. The new user perusing such an index replete with "see" and "see also" opens the door for a serendipitous juxtaposition of chance into design. A few shorter LyX visual faqs, each covering some major topic, with the potential of being merged later, would stifle any complaints about inadequate documentation being too spread out. If wishes were horses, beggars would ride (wishlist), Stephen
Re: Postscript preview
LB wrote: When you added the GS path in lyx.bat, did you add the path to the lib directory as well as to the bin directory? Yes I did. I'm giving up and going back to use version 1.4.1. Well, I can't say I blame you ... 1.4.1 worked pretty well for me. I just hope this problem does not recur when we get to 1.5 and there is some "must have" new feature. BTW, I generated another figure with Matlab that has the same problem. It looks like when I generate figures with Matlab I run into trouble with previewing figure with 1.4.2 but not with any other versions. I have tried 1.4.1, 1.3.7 and 1.3.5. Cheers Leo I didn't have any bright ideas. But since it seems you are close to giving up, I thought I would toss out some longshots. " PROGRA~1\MENTOR~1\PADS\2005_1\Programs;c:\lyx\ly " (from 7/28/2006 12:03 pm, PATH report) SH: Maybe that is a typo the "ly" looks wrong. As Jose mentions, upgrading Ghostscript might help, because version 7.07 had a bug with paths with spaces. A very longshot is that the local LyX Python is buggy with utf8 support but those files don't cure it. Do you have the full Python installed? If so put it at the front of Path_prefix statement in LyX and it will supersede the local partial version of Python. Vaguely, the locale might connect to the set commands. I said it was a longshot. The set command used to say set lang=en_US if one used English. I couldn't find info on what LC does... Anyway replacing GS is a good idea, and if you already have the full Python, it is easy to *_prepend_* C:\Python243 to the LyX Path_prefix and have a fully functioning Python, since the extent of the local Python, mostly successful, may have other gaps. I've had a problem with set environmental variables once before. Another departed version of *tex had left its value behind and conflicted with the new version which wanted to set the same variable to a new place. (Cygwin and TexLive2005). Well, that was just rambling. -- An ambient confluence of mapped coherence ~ Stephen
Re: citation style
Wolfgang Engelmann wrote:
Good morning
Is there an easier way to replace
cite{
with
citealt{
as to run a replace in the lyx document?
The publisher wants
(Miller 2001) instead of (Miller (2001))
I am thinking of \bibpunct in the preamble, but am not sure whether
appropriate here and how to use it
Wolfgang
There is probably a script in a repository which allows
you to specify a find term/replace term, recursively, in
a designated input file. I've seen a recommendation to
use a powerful text editor since the .lyx file is text.
I have used Xemacs on large dictionary text files. But
perhaps it is more convenient to change your package.
I was just reading about this earlier today:
That is, a bibliographical entry like
\bibitem[Donald~E. Knuth 1986]{Knuth–CT–a} Donald~E. Knuth.
\newblock \emph{The {\TeX}book}, volume~A of \emph{Computers and
Typesetting}. \newblock Addison–Wesley, Reading, MA, USA, 1986.
will allow the \cite command to produce (Donald E. Knuth 1986)
but not Donald E. Knuth (1986) or just Knuth or just 1986
as well. You also have to ensure that \bibitem does not display
the label, but that outcome can be fairly easily arranged.
The solution used by all implementations for author-date support
is to introduce a special syntax within the optional argument of
\bibitem. In some implementations this structure is fairly simple.
For instance, chicago requires only
\bibitem[\protect\citeauthoryear{Goossens, Rahtz, and Mittelbach}
{Goossens et~al.}{1997}]{LGC97}
---TLC2,12.3.1
For example, the chicago package, which aimed to implement the
recommendations of The Chicago Manual of Style [38], offers the
following list of commands (plus variants all ending in NP to
omit the parentheses—for example, \citeNP):
\usepackage{chicago}
\bibliographystyle{chicago}
(Goosens, Rahtz, and Mittelback 1997) \cite{LGC97} \\
(Goosens, Rahtz, and Mittelback) \citeA{LGC97} \\
Goosens, Rahtz, and Mittelback (1997) \citeN{LGC97} \\
(Goosens and Rahtz 1999) \shortcite{LWC99} \\
(Goosens and Rahtz) \shortciteA{LWC99} \\
Goossens and Rahtz (1999) \shortciteN{LWC99} \\
(1999), \citeyear{LWC99}, \\
1999 \citeyearNP{LWC99} \\
--
An ambient confluence
of mapped coherence ~
Stephen
Re: citation style
Wolfgang Engelmann wrote:
Good morning
Is there an easier way to replace
cite{
with
citealt{
as to run a replace in the lyx document?
The publisher wants
(Miller 2001) instead of (Miller (2001))
I am thinking of \bibpunct in the preamble, but am not sure whether
appropriate here and how to use it
Wolfgang
There is probably a script in a repository which allows
you to specify a find term/replace term, recursively, in
a designated input file. I've seen a recommendation to
use a powerful text editor since the .lyx file is text.
I have used Xemacs on large dictionary text files. But
perhaps it is more convenient to change your package.
I was just reading about this earlier today:
That is, a bibliographical entry like
\bibitem[Donald~E. Knuth 1986]{Knuth–CT–a} Donald~E. Knuth.
\newblock \emph{The {\TeX}book}, volume~A of \emph{Computers and
Typesetting}. \newblock Addison–Wesley, Reading, MA, USA, 1986.
will allow the \cite command to produce (Donald E. Knuth 1986)
but not Donald E. Knuth (1986) or just Knuth or just 1986
as well. You also have to ensure that \bibitem does not display
the label, but that outcome can be fairly easily arranged.
The solution used by all implementations for author-date support
is to introduce a special syntax within the optional argument of
\bibitem. In some implementations this structure is fairly simple.
For instance, chicago requires only
\bibitem[\protect\citeauthoryear{Goossens, Rahtz, and Mittelbach}
{Goossens et~al.}{1997}]{LGC97}
---TLC2,12.3.1
For example, the chicago package, which aimed to implement the
recommendations of The Chicago Manual of Style [38], offers the
following list of commands (plus variants all ending in NP to
omit the parentheses—for example, \citeNP):
\usepackage{chicago}
\bibliographystyle{chicago}
(Goosens, Rahtz, and Mittelback 1997) \cite{LGC97} \\
(Goosens, Rahtz, and Mittelback) \citeA{LGC97} \\
Goosens, Rahtz, and Mittelback (1997) \citeN{LGC97} \\
(Goosens and Rahtz 1999) \shortcite{LWC99} \\
(Goosens and Rahtz) \shortciteA{LWC99} \\
Goossens and Rahtz (1999) \shortciteN{LWC99} \\
(1999), \citeyear{LWC99}, \\
1999 \citeyearNP{LWC99} \\
--
An ambient confluence
of mapped coherence ~
Stephen
Re: citation style
Wolfgang Engelmann wrote:
Good morning
Is there an easier way to replace
cite{
with
citealt{
as to run a replace in the lyx document?
The publisher wants
(Miller 2001) instead of (Miller (2001))
I am thinking of \bibpunct in the preamble, but am not sure whether
appropriate here and how to use it
Wolfgang
There is probably a script in a repository which allows
you to specify a find term/replace term, recursively, in
a designated input file. I've seen a recommendation to
use a powerful text editor since the .lyx file is text.
I have used Xemacs on large dictionary text files. But
perhaps it is more convenient to change your package.
I was just reading about this earlier today:
"That is, a bibliographical entry like
\bibitem[Donald~E. Knuth 1986]{Knuth–CT–a} Donald~E. Knuth.
\newblock \emph{The {\TeX}book}, volume~A of \emph{Computers and
Typesetting}. \newblock Addison–Wesley, Reading, MA, USA, 1986.
will allow the \cite command to produce "(Donald E. Knuth 1986)"
but not "Donald E. Knuth (1986)" or just "Knuth" or just "1986"
as well. You also have to ensure that \bibitem does not display
the label, but that outcome can be fairly easily arranged.
The solution used by all implementations for author-date support
is to introduce a special syntax within the optional argument of
\bibitem. In some implementations this structure is fairly simple.
For instance, chicago requires only
\bibitem[\protect\citeauthoryear{Goossens, Rahtz, and Mittelbach}
{Goossens et~al.}{1997}]{LGC97}"
---TLC2,12.3.1
For example, the chicago package, which aimed to implement the
recommendations of The Chicago Manual of Style [38], offers the
following list of commands (plus variants all ending in NP to
omit the parentheses—for example, \citeNP):
\usepackage{chicago}
\bibliographystyle{chicago}
(Goosens, Rahtz, and Mittelback 1997) \cite{LGC97} \\
(Goosens, Rahtz, and Mittelback) \citeA{LGC97} \\
Goosens, Rahtz, and Mittelback (1997) \citeN{LGC97} \\
(Goosens and Rahtz 1999) \shortcite{LWC99} \\
(Goosens and Rahtz) \shortciteA{LWC99} \\
Goossens and Rahtz (1999) \shortciteN{LWC99} \\
(1999), \citeyear{LWC99}, \\
1999 \citeyearNP{LWC99} \\
--
An ambient confluence
of mapped coherence ~
Stephen
Re: More class files by default
Ed Gatzke wrote: I have run into problems adding extra class files into my latex installation and getting them to work with lyx. (I know, install, run something to reconfigure latex, reconfigure lyx, but it is never smooth sailing for me) It may be nice to have a boatload installed by default or as an option. Some to consider include things like prosper (for pretty powerpoint slides) or some widely used professional styles (IEEE, IFAC, others). 1.4.2 already has .layout files for a lot of things that apparently did not get installed in the latex default package (or maybe 1.42 added more layouts that were not included in the 1.4.1 latex I am using). Why not have a install option for extended latex. I know originally they limited the extra stuff in LaTeX distributions, but the way HD space and bandwidth is now days, how much does an extra few MB cost us... There are a few more on the Wiki and instruction on how to make a simple one that will probably work for you. Layout files aren't as abundant as you might think because authors don't make them. The Wiki has Beamer and Powerdot layouts and a small collection. http://wiki.lyx.org/Layouts/CreatingLayouts [roll your own] Regards, Stephen
Re: Big problem with notes - Add content to the table of content
Isaac Pante wrote: I've found the answer. The notes with this problem were created highlighting the content of the footnote THEN by pressing the footnote button. It should be a good idea to disable this possibility for the following versions of lyx. So, let's go with another question: How can I add content to the table of content (Name and page number). Is there a TeX command for this? Thanks for your help. Isaac Pante Le 25 juil. 06 à 18:16, Isaac Pante a écrit : Hello everybody! I dont' know why, but I get an orrendous rendering of my footnotes, as you can see in the file joined. Please, tell me there is an easy way to solve this. Isaac Pante Image 3.png I've heard people recommending The Latex Companion 2nd Edition for awhile now. I noticed it on the Safari ebook service. There is a 14 day free trial period. A person can download several sections or a chapter, it is allowed. Also in the US, most libraries have a subscription and many educational institutions (international too) have access. I downloaded all of Chapter 11 because the Xindy people said that was the best Howto around, using the browser's save as. There is a keyword search engine for the book. Knuth used to give $2.56 to anyone who caught an error in his book/Tex. The authors give away a computer book every six months to whoever finds the most errors. I already found a typo just reading the book online. Chapter 6. There is no implication about asking on the list, just sharing a way I found to spread my hustle. Regards, Stephen
Re: More class files by default
Ed Gatzke wrote: I have run into problems adding extra class files into my latex installation and getting them to work with lyx. (I know, install, run something to reconfigure latex, reconfigure lyx, but it is never smooth sailing for me) It may be nice to have a boatload installed by default or as an option. Some to consider include things like prosper (for pretty powerpoint slides) or some widely used professional styles (IEEE, IFAC, others). 1.4.2 already has .layout files for a lot of things that apparently did not get installed in the latex default package (or maybe 1.42 added more layouts that were not included in the 1.4.1 latex I am using). Why not have a install option for extended latex. I know originally they limited the extra stuff in LaTeX distributions, but the way HD space and bandwidth is now days, how much does an extra few MB cost us... There are a few more on the Wiki and instruction on how to make a simple one that will probably work for you. Layout files aren't as abundant as you might think because authors don't make them. The Wiki has Beamer and Powerdot layouts and a small collection. http://wiki.lyx.org/Layouts/CreatingLayouts [roll your own] Regards, Stephen
Re: Big problem with notes - Add content to the table of content
Isaac Pante wrote: I've found the answer. The notes with this problem were created highlighting the content of the footnote THEN by pressing the footnote button. It should be a good idea to disable this possibility for the following versions of lyx. So, let's go with another question: How can I add content to the table of content (Name and page number). Is there a TeX command for this? Thanks for your help. Isaac Pante Le 25 juil. 06 à 18:16, Isaac Pante a écrit : Hello everybody! I dont' know why, but I get an orrendous rendering of my footnotes, as you can see in the file joined. Please, tell me there is an easy way to solve this. Isaac Pante Image 3.png I've heard people recommending The Latex Companion 2nd Edition for awhile now. I noticed it on the Safari ebook service. There is a 14 day free trial period. A person can download several sections or a chapter, it is allowed. Also in the US, most libraries have a subscription and many educational institutions (international too) have access. I downloaded all of Chapter 11 because the Xindy people said that was the best Howto around, using the browser's save as. There is a keyword search engine for the book. Knuth used to give $2.56 to anyone who caught an error in his book/Tex. The authors give away a computer book every six months to whoever finds the most errors. I already found a typo just reading the book online. Chapter 6. There is no implication about asking on the list, just sharing a way I found to spread my hustle. Regards, Stephen
Re: More class files by default
Ed Gatzke wrote: I have run into problems adding extra class files into my latex installation and getting them to work with lyx. (I know, install, run something to reconfigure latex, reconfigure lyx, but it is never smooth sailing for me) It may be nice to have a boatload installed by default or as an option. Some to consider include things like prosper (for pretty powerpoint slides) or some widely used professional styles (IEEE, IFAC, others). 1.4.2 already has .layout files for a lot of things that apparently did not get installed in the latex default package (or maybe 1.42 added more layouts that were not included in the 1.4.1 latex I am using). Why not have a install option for "extended latex". I know originally they limited the extra stuff in LaTeX distributions, but the way HD space and bandwidth is now days, how much does an extra few MB cost us... There are a few more on the Wiki and instruction on how to make a simple one that will probably work for you. Layout files aren't as abundant as you might think because authors don't make them. The Wiki has Beamer and Powerdot layouts and a small collection. http://wiki.lyx.org/Layouts/CreatingLayouts [roll your own] Regards, Stephen
Re: Big problem with notes - Add content to the table of content
Isaac Pante wrote: I've found the answer. The notes with this problem were created highlighting the content of the footnote THEN by pressing the footnote button. It should be a good idea to disable this possibility for the following versions of lyx. So, let's go with another question: How can I add content to the table of content (Name and page number). Is there a TeX command for this? Thanks for your help. Isaac Pante Le 25 juil. 06 à 18:16, Isaac Pante a écrit : Hello everybody! I dont' know why, but I get an orrendous rendering of my footnotes, as you can see in the file joined. Please, tell me there is an easy way to solve this. Isaac Pante I've heard people recommending "The Latex Companion" 2nd Edition for awhile now. I noticed it on the Safari ebook service. There is a 14 day free trial period. A person can download several sections or a chapter, it is allowed. Also in the US, most libraries have a subscription and many educational institutions (international too) have access. I downloaded all of Chapter 11 because the Xindy people said that was the best Howto around, using the browser's "save as". There is a keyword search engine for the book. Knuth used to give $2.56 to anyone who caught an error in his book/Tex. The authors give away a computer book every six months to whoever finds the most errors. I already found a typo just reading the book online. Chapter 6. There is no implication about asking on the list, just sharing a way I found to spread my hustle. Regards, Stephen
Re: please consolidate the documentation
Jean-Pierre Chretien wrote: Date: Wed, 19 Jul 2006 09:37:55 -0700 To: lyx-users@lists.lyx.org Subject: Re: please consolidate the documentation From: Stephen Harris [EMAIL PROTECTED] Ingo Klöcker wrote: Am Mittwoch, 19. Juli 2006 08:58 schrieb Martin A. Hansen: [...] In any case, I'm pretty sure we can discuss this to death. Some people prefer a several megabyte large HTML file and other people prefer the same information nicely split up into several HTML files per chapter or even section (with nice navigation buttons of course). While the first approach is only feasible for people with a fast internet connection the second approach is feasible for anyone. There used to be a splitted HTML version of the doc. I found this while googling for lyx verbatim 1.4 :-) http://www.lyx.org/~jug/lyx/lyxdoc/Extended/node6.html It's lyx-1.1.6 apparently, 1.4 is the section number. The toc is here: http://www.lyx.org/~jug/lyx/lyxdoc However a local indexing is needed (btw, lyx.org does not seem to be indexed) as googling retrieves a lot of noise. Turning the doc into a wiki seems complicated, as only two levels are allowed, but maybe there are tools to do so ? The indexing problem is solved this way. Wolfram's indexes are very detailed and I like the hyperlink feature but I suppose that requires html. http://documents.wolfram.com/v4/MainBook/Index/ This webpage index shows the 'see also' feature. For instance layouts would probably have several 'see alsos' and also appear in several references -each given a short code, which could be listed alphabetically with page numbers. I want it to be detailed enough to provide clues to inexperienced users. http://www.indexers.org.uk/site/index.htm swish-e is supposed to be capable of indexing a Wiki. Perhaps this categorizing scheme will be quite productive. Regards, Stephen If layouts were mentioned in several documents
Re: please consolidate the documentation
Jean-Pierre Chretien wrote: Date: Thu, 20 Jul 2006 03:05:50 -0700 To: Jean-Pierre Chretien [EMAIL PROTECTED] CC: lyx-users@lists.lyx.org Subject: Re: please consolidate the documentation From: Stephen Harris [EMAIL PROTECTED] [...] swish-e is supposed to be capable of indexing a Wiki. Perhaps this categorizing scheme will be quite productive. PmWiki includes it own indexing scheme: the search field in each page is able to retrieve match in wiki pages. swish-e (or similar, htdig e.g.) are useful for segmented HTML publication indexing. I am under the impression that the indexing you speak of just accelerates PmWikis normal searchbox function which doesn't include the content of the pdf files on the Wiki? I'm thinking that the PmWiki indexing scheme will report text Wiki matches of say layout but not .pdf content? That is the reason behind tagging pages with categories? swish-e will index pdf files on the wiki and the wiki. I would like to see a complete file, visually, like a TOC. The purpose behind the Index was to benefit inexperienced users who did not already know the keyword needed for the search; making the Wiki more accessible for new users. Precompiled special searchindex files don't do that, they make it faster, but do not include new content-- meaning something not available to you if you already know the right keyword, using the normal search function. Indexing pdf files provides new content, keywords are listed from a new domain. I didn't get the idea that the Pmwiki index would include see also(s). Increasing internet exposure had no priority so perhaps you developed the index idea for the Wiki, independently of the categorization origin. Regards, Stephen
Re: please consolidate the documentation
John Pye wrote: Hi all, I'd like to say congratulations to all on the re-inauguration of the LyX documentation team ;-) ! The scattered documentation of LyX has frustrated me too. I have some thoughts and ideas to mention... First, I think that the shining example of the *delivery* of software documentation is the PHP manual, which is at http://www.php.net/manual/en/. SH: It seems good to me and other people hold it as an example. In its favour: anyone can annotate a page in the manual with their own tips and clarifications. This is great and it prevents quite the same degree of random organic growth that occurs when people feel that they should jot things into a wiki. I would imagine it makes things easier for editors too: the community tells you where information is missing or unclear. Here is an example of an annotated page: http://au.php.net/manual/en/function.array-sum.php This is my concern about the Wiki method too. When discussing what is good for LyX one needs to factor in the available resources. A limited number of developers already committed to high priority projects, no dedicated Editor, and a small documentation team. Perhaps a limitation of the PHP manual's user-notes feature is that whole new pages are hard for people to add. So there's still a place for Wiki but it shouldn't be one of the primary resources, I don't think. The PHP people have also done a great job of providing translations of their manual, and also provide the documentation in lots of different formats, eg CHM for reading online with Windows, and online/offline HTML and PDF, eg see http://au.php.net/docs.php. There is a Linux documentation format standard over at freedesktop.org that we should comply with too. I think these ideas serve a much larger project with much greater resources. LyX is cross-platform itself. It is readable in DVI, Postscript and pdf. The conversion to html is straightforward and XML is the next LyX major goal. htlatex foo.tex - foo.html The problem with OS specific documentation is that it is only going to benefit about ~half of the users at most, and they already have several formats available. The left margin toc is perhaps slightly better/readable for chm than pdf but I don't know of a free .tex or .pdf converter to .chm. Problems with .chm or say kde are outside the scope of LyX and only benefit about half the users. LyX doesn't have a reource luxury. I don't think that we should expect people to use LyX as their documentation browser. Operating systems all provide good standard ways of accessing help: Installed LyX documentation should play nice with those so that there's one less thing for new users to learn. I think that the LyX manual should serve as a model example of a well-published document, with HTML and PDF versions, downloadable in various formats, etc. It should be the type of end-result document that a person setting out to write a book or a software manunal with LyX would aspire to produce, not an exposition of the LyX GUI. I certainly agree, showcase comes to mind. The exposition of the Lyx GUI could be done like the Latex Visual FAQ, the LyX Visual FAQ. One person produced this remarkable package! There should be a good self-updating HTML version of the LyX manual. Ideally a local search engine could be installed that would search both the HTML manual and the Wiki side-by-side with a single installation of lucene, xapian, swish-e, etc. As I understand it, this will work better with XML. Updating comes to mind also with the Wiki index project (searchindex). We should aspire to the PDF version of the manual being a last port of call: online searching, CHM, Yelp (under GNOME), etc should be able to provide nicer and more efficient ways to read and search. Although, given what LyX is, it's important to produce a good looking PDF to prove what LyX can do. It took me less than 3 minutes to convert those 4 LyX guides which come with LyX-Help into pdfs and combine them into 1 searchable file. How long to convert those 4 .lyx files and combine them into 1 .chm with the left margin toc or then without it? How about Yelp? We're meanwhile trying to use LyX for documenting a project I've worked on: the ASCEND modelling environment. So we're very interested in taking the right approach here. I'm sure a lot of other writers, especially of software documentation, must be as well. Cheers JP I would like to the LyX Wiki displayed like a book. Wolfram does a great job of indexing, here is an online, hyperlinked, searchable index: http://www.wolframscience.com/nksonline/page-852d-text General Note/Intro to the Index http://www.wolframscience.com/nksonline/toc.html the toc which links to the index http://www.wolframscience.com/nksonline/index/ I am not as experienced as you are with the nitty gritty. But I am a good judge of books and their indexes. (ices) Wolfram's A New Kind of Science is over 1200 pages long. And if you are exploring a topic like,
Re: please consolidate the documentation
Jean-Pierre Chretien wrote: Date: Wed, 19 Jul 2006 09:37:55 -0700 To: lyx-users@lists.lyx.org Subject: Re: please consolidate the documentation From: Stephen Harris [EMAIL PROTECTED] Ingo Klöcker wrote: Am Mittwoch, 19. Juli 2006 08:58 schrieb Martin A. Hansen: [...] In any case, I'm pretty sure we can discuss this to death. Some people prefer a several megabyte large HTML file and other people prefer the same information nicely split up into several HTML files per chapter or even section (with nice navigation buttons of course). While the first approach is only feasible for people with a fast internet connection the second approach is feasible for anyone. There used to be a splitted HTML version of the doc. I found this while googling for lyx verbatim 1.4 :-) http://www.lyx.org/~jug/lyx/lyxdoc/Extended/node6.html It's lyx-1.1.6 apparently, 1.4 is the section number. The toc is here: http://www.lyx.org/~jug/lyx/lyxdoc However a local indexing is needed (btw, lyx.org does not seem to be indexed) as googling retrieves a lot of noise. Turning the doc into a wiki seems complicated, as only two levels are allowed, but maybe there are tools to do so ? The indexing problem is solved this way. Wolfram's indexes are very detailed and I like the hyperlink feature but I suppose that requires html. http://documents.wolfram.com/v4/MainBook/Index/ This webpage index shows the 'see also' feature. For instance layouts would probably have several 'see alsos' and also appear in several references -each given a short code, which could be listed alphabetically with page numbers. I want it to be detailed enough to provide clues to inexperienced users. http://www.indexers.org.uk/site/index.htm swish-e is supposed to be capable of indexing a Wiki. Perhaps this categorizing scheme will be quite productive. Regards, Stephen If layouts were mentioned in several documents
Re: please consolidate the documentation
Jean-Pierre Chretien wrote: Date: Thu, 20 Jul 2006 03:05:50 -0700 To: Jean-Pierre Chretien [EMAIL PROTECTED] CC: lyx-users@lists.lyx.org Subject: Re: please consolidate the documentation From: Stephen Harris [EMAIL PROTECTED] [...] swish-e is supposed to be capable of indexing a Wiki. Perhaps this categorizing scheme will be quite productive. PmWiki includes it own indexing scheme: the search field in each page is able to retrieve match in wiki pages. swish-e (or similar, htdig e.g.) are useful for segmented HTML publication indexing. I am under the impression that the indexing you speak of just accelerates PmWikis normal searchbox function which doesn't include the content of the pdf files on the Wiki? I'm thinking that the PmWiki indexing scheme will report text Wiki matches of say layout but not .pdf content? That is the reason behind tagging pages with categories? swish-e will index pdf files on the wiki and the wiki. I would like to see a complete file, visually, like a TOC. The purpose behind the Index was to benefit inexperienced users who did not already know the keyword needed for the search; making the Wiki more accessible for new users. Precompiled special searchindex files don't do that, they make it faster, but do not include new content-- meaning something not available to you if you already know the right keyword, using the normal search function. Indexing pdf files provides new content, keywords are listed from a new domain. I didn't get the idea that the Pmwiki index would include see also(s). Increasing internet exposure had no priority so perhaps you developed the index idea for the Wiki, independently of the categorization origin. Regards, Stephen
Re: please consolidate the documentation
John Pye wrote: Hi all, I'd like to say congratulations to all on the re-inauguration of the LyX documentation team ;-) ! The scattered documentation of LyX has frustrated me too. I have some thoughts and ideas to mention... First, I think that the shining example of the *delivery* of software documentation is the PHP manual, which is at http://www.php.net/manual/en/. SH: It seems good to me and other people hold it as an example. In its favour: anyone can annotate a page in the manual with their own tips and clarifications. This is great and it prevents quite the same degree of random organic growth that occurs when people feel that they should jot things into a wiki. I would imagine it makes things easier for editors too: the community tells you where information is missing or unclear. Here is an example of an annotated page: http://au.php.net/manual/en/function.array-sum.php This is my concern about the Wiki method too. When discussing what is good for LyX one needs to factor in the available resources. A limited number of developers already committed to high priority projects, no dedicated Editor, and a small documentation team. Perhaps a limitation of the PHP manual's user-notes feature is that whole new pages are hard for people to add. So there's still a place for Wiki but it shouldn't be one of the primary resources, I don't think. The PHP people have also done a great job of providing translations of their manual, and also provide the documentation in lots of different formats, eg CHM for reading online with Windows, and online/offline HTML and PDF, eg see http://au.php.net/docs.php. There is a Linux documentation format standard over at freedesktop.org that we should comply with too. I think these ideas serve a much larger project with much greater resources. LyX is cross-platform itself. It is readable in DVI, Postscript and pdf. The conversion to html is straightforward and XML is the next LyX major goal. htlatex foo.tex - foo.html The problem with OS specific documentation is that it is only going to benefit about ~half of the users at most, and they already have several formats available. The left margin toc is perhaps slightly better/readable for chm than pdf but I don't know of a free .tex or .pdf converter to .chm. Problems with .chm or say kde are outside the scope of LyX and only benefit about half the users. LyX doesn't have a reource luxury. I don't think that we should expect people to use LyX as their documentation browser. Operating systems all provide good standard ways of accessing help: Installed LyX documentation should play nice with those so that there's one less thing for new users to learn. I think that the LyX manual should serve as a model example of a well-published document, with HTML and PDF versions, downloadable in various formats, etc. It should be the type of end-result document that a person setting out to write a book or a software manunal with LyX would aspire to produce, not an exposition of the LyX GUI. I certainly agree, showcase comes to mind. The exposition of the Lyx GUI could be done like the Latex Visual FAQ, the LyX Visual FAQ. One person produced this remarkable package! There should be a good self-updating HTML version of the LyX manual. Ideally a local search engine could be installed that would search both the HTML manual and the Wiki side-by-side with a single installation of lucene, xapian, swish-e, etc. As I understand it, this will work better with XML. Updating comes to mind also with the Wiki index project (searchindex). We should aspire to the PDF version of the manual being a last port of call: online searching, CHM, Yelp (under GNOME), etc should be able to provide nicer and more efficient ways to read and search. Although, given what LyX is, it's important to produce a good looking PDF to prove what LyX can do. It took me less than 3 minutes to convert those 4 LyX guides which come with LyX-Help into pdfs and combine them into 1 searchable file. How long to convert those 4 .lyx files and combine them into 1 .chm with the left margin toc or then without it? How about Yelp? We're meanwhile trying to use LyX for documenting a project I've worked on: the ASCEND modelling environment. So we're very interested in taking the right approach here. I'm sure a lot of other writers, especially of software documentation, must be as well. Cheers JP I would like to the LyX Wiki displayed like a book. Wolfram does a great job of indexing, here is an online, hyperlinked, searchable index: http://www.wolframscience.com/nksonline/page-852d-text General Note/Intro to the Index http://www.wolframscience.com/nksonline/toc.html the toc which links to the index http://www.wolframscience.com/nksonline/index/ I am not as experienced as you are with the nitty gritty. But I am a good judge of books and their indexes. (ices) Wolfram's A New Kind of Science is over 1200 pages long. And if you are exploring a topic like,
Re: please consolidate the documentation
Jean-Pierre Chretien wrote: Date: Wed, 19 Jul 2006 09:37:55 -0700 To: lyx-users@lists.lyx.org Subject: Re: please consolidate the documentation From: Stephen Harris <[EMAIL PROTECTED]> Ingo Klöcker wrote: Am Mittwoch, 19. Juli 2006 08:58 schrieb Martin A. Hansen: [...] In any case, I'm pretty sure we can discuss this to death. Some people prefer a several megabyte large HTML file and other people prefer the same information nicely split up into several HTML files per chapter or even section (with nice navigation buttons of course). While the first approach is only feasible for people with a fast internet connection the second approach is feasible for anyone. There used to be a splitted HTML version of the doc. I found this while googling for "lyx verbatim 1.4" :-) http://www.lyx.org/~jug/lyx/lyxdoc/Extended/node6.html It's lyx-1.1.6 apparently, 1.4 is the section number. The toc is here: http://www.lyx.org/~jug/lyx/lyxdoc However a local indexing is needed (btw, lyx.org does not seem to be indexed) as googling retrieves a lot of noise. Turning the doc into a wiki seems complicated, as only two levels are allowed, but maybe there are tools to do so ? The indexing problem is solved this way. Wolfram's indexes are very detailed and I like the hyperlink feature but I suppose that requires html. http://documents.wolfram.com/v4/MainBook/Index/ This webpage index shows the 'see also' feature. For instance "layouts" would probably have several 'see alsos' and also appear in several references ->each given a short code, which could be listed alphabetically with page numbers. I want it to be detailed enough to provide clues to inexperienced users. http://www.indexers.org.uk/site/index.htm swish-e is supposed to be capable of indexing a Wiki. Perhaps this categorizing scheme will be quite productive. Regards, Stephen If layouts were mentioned in several documents
Re: please consolidate the documentation
Jean-Pierre Chretien wrote: Date: Thu, 20 Jul 2006 03:05:50 -0700 To: Jean-Pierre Chretien <[EMAIL PROTECTED]> CC: lyx-users@lists.lyx.org Subject: Re: please consolidate the documentation From: Stephen Harris <[EMAIL PROTECTED]> [...] swish-e is supposed to be capable of indexing a Wiki. Perhaps this categorizing scheme will be quite productive. PmWiki includes it own indexing scheme: the search field in each page is able to retrieve match in wiki pages. swish-e (or similar, htdig e.g.) are useful for segmented > HTML publication indexing. I am under the impression that the indexing you speak of just accelerates PmWikis normal searchbox function which doesn't include the content of the pdf files on the Wiki? I'm thinking that the PmWiki indexing scheme will report text Wiki matches of say "layout" but not .pdf content? That is the reason behind tagging pages with categories? swish-e will index pdf files on the wiki and the wiki. I would like to see a complete file, visually, like a TOC. The purpose behind the Index was to benefit inexperienced users who did not already know the keyword needed for the search; making the Wiki more accessible for new users. Precompiled special searchindex files don't do that, they make it faster, but do not include new content-- meaning something not available to you if you already know the right keyword, using the normal search function. Indexing pdf files provides new content, keywords are listed from a new domain. I didn't get the idea that the Pmwiki index would include "see also"(s). Increasing internet exposure had no priority so perhaps you developed the index idea for the Wiki, independently of the categorization origin. Regards, Stephen
Re: please consolidate the documentation
John Pye wrote: Hi all, I'd like to say congratulations to all on the re-inauguration of the LyX documentation team ;-) ! The scattered documentation of LyX has frustrated me too. I have some thoughts and ideas to mention... First, I think that the shining example of the *delivery* of software documentation is the PHP manual, which is at http://www.php.net/manual/en/. SH: It seems good to me and other people hold it as an example. In its favour: anyone can annotate a page in the manual with their own tips and clarifications. This is great and it prevents quite the same degree of random organic growth that occurs when people feel that they should jot things into a wiki. I would imagine it makes things easier for editors too: the community tells you where information is missing or unclear. Here is an example of an annotated page: http://au.php.net/manual/en/function.array-sum.php This is my concern about the Wiki method too. When discussing what is good for LyX one needs to factor in the available resources. A limited number of developers already committed to high priority projects, no dedicated Editor, and a small documentation team. Perhaps a limitation of the PHP manual's user-notes feature is that whole new pages are hard for people to add. So there's still a place for Wiki but it shouldn't be one of the primary resources, I don't think. The PHP people have also done a great job of providing translations of their manual, and also provide the documentation in lots of different formats, eg CHM for reading online with Windows, and online/offline HTML and PDF, eg see http://au.php.net/docs.php. There is a Linux documentation format standard over at freedesktop.org that we should comply with too. I think these ideas serve a much larger project with much greater resources. LyX is cross-platform itself. It is readable in DVI, Postscript and pdf. The conversion to html is straightforward and XML is the next LyX major goal. "htlatex foo.tex" -> foo.html The problem with OS specific documentation is that it is only going to benefit about ~half of the users at most, and they already have several formats available. The left margin toc is perhaps slightly better/readable for chm than pdf but I don't know of a free .tex or .pdf converter to .chm. Problems with .chm or say kde are outside the scope of LyX and only benefit about half the users. LyX doesn't have a reource luxury. I don't think that we should expect people to use LyX as their documentation browser. Operating systems all provide good standard ways of accessing help: Installed LyX documentation should play nice with those so that there's one less thing for new users to learn. I think that the LyX manual should serve as a model example of a well-published document, with HTML and PDF versions, downloadable in various formats, etc. It should be the type of end-result document that a person setting out to write a book or a software manunal with LyX would aspire to produce, not an exposition of the LyX GUI. I certainly agree, showcase comes to mind. The exposition of the Lyx GUI could be done like the Latex Visual FAQ, the LyX Visual FAQ. One person produced this remarkable package! There should be a good self-updating HTML version of the LyX manual. Ideally a local search engine could be installed that would search both the HTML manual and the Wiki side-by-side with a single installation of lucene, xapian, swish-e, etc. As I understand it, this will work better with XML. Updating comes to mind also with the Wiki index project (searchindex). We should aspire to the PDF version of the manual being a last port of call: online searching, CHM, Yelp (under GNOME), etc should be able to provide nicer and more efficient ways to read and search. Although, given what LyX is, it's important to produce a good looking PDF to prove what LyX can do. It took me less than 3 minutes to convert those 4 LyX guides which come with LyX-Help into pdfs and combine them into 1 searchable file. How long to convert those 4 .lyx files and combine them into 1 .chm with the left margin toc or then without it? How about Yelp? We're meanwhile trying to use LyX for documenting a project I've worked on: the ASCEND modelling environment. So we're very interested in taking the right approach here. I'm sure a lot of other writers, especially of software documentation, must be as well. Cheers JP I would like to the LyX Wiki displayed like a book. Wolfram does a great job of indexing, here is an online, hyperlinked, searchable index: http://www.wolframscience.com/nksonline/page-852d-text General Note/Intro to the Index http://www.wolframscience.com/nksonline/toc.html the toc which links to the index http://www.wolframscience.com/nksonline/index/ I am not as experienced as you are with the nitty gritty. But I am a good judge of books and their indexes. (ices) Wolfram's "A New Kind of Science" is over 1200 pages long. And if you are exploring a topic
Re: please consolidate the documentation
Ingo Klöcker wrote: Am Mittwoch, 19. Juli 2006 08:58 schrieb Martin A. Hansen: So what is the typical use-case for the LyX Manual? That someone wants to read it from the first page to the last page? Or that someone wants to read about a specific subject, say including graphics? In my experience the latter is the way more common use-case. I've read the Introduction once and the Tutorial once. And now, every now and then, I open the other two documents because I want to look something up. Therefore it would be preferable if loading the part I'm interested in wouldn't take 10 seconds but only 1 second. The only way to achieve this is to split up the document. Of course, there should be a master document with a complete toc so that I can quickly navigate to the chapter I'm interested in. Ideally, for the user it wouldn't feel different from one large lyx file with the exception that loading would be magnitudes faster. In any case, I'm pretty sure we can discuss this to death. Some people prefer a several megabyte large HTML file and other people prefer the same information nicely split up into several HTML files per chapter or even section (with nice navigation buttons of course). While the first approach is only feasible for people with a fast internet connection the second approach is feasible for anyone. And as always there's the option to do both. Provide the LyX manual as one huge single file and additionally split up into several files. I'd put the multiple-files version into the release and put the URL of the single file version near the start of the multiple-files version. Regards, Ingo I wasn't so sure that consolidated Help guides were all that useful. But making one in .pdf format and one in .lyx format to satisfy those who wanted it wasn't all that hard, so why not. It's on the Wiki. There are people who don't enjoy discussing things and they tend to describe the people who do enjoy it as beating a good horse to death. Single .lyx help guides already exist and it is pretty easy to pdflatex a pdf version from Lyx and there are existing multiple .lyx/pdf guides it doesn't seem fruitful to debate preferences. Learning visually brings to mind the Visual FAQ which demonstrates how to do something on the page itself and links to the tug FAQ. http://www.tug.org/tex-archive/info/visualFAQ/ Having trouble finding the answer to a LaTeX question? The Visual LaTeX FAQ is an innovative new search interface that presents over a hundred typeset samples of frequently requested document formatting. Simply click on a hyperlinked piece of text and the Visual LaTeX FAQ will send your Web browser to the appropriate page in the UK TeX FAQ. SH: I think a LyX VisualFAQ is a possible Wiki documentation project. Ingo: Of course, there should be a master document with a complete toc so that I can quickly navigate to the chapter I'm interested in. SH: The problem with keyword searches is that you have to know the keyword. We could create a detailed cross-referenced index of the entire Wiki which would be similar to the ouput of several hundred keyword searches. This master index would point to the document(s) which contained the concept being researched or related ideas. One wouldn't have to wade through several documents to find the right one. The way it is now, layouts might produce 12 hits, but which one of the 12 should be prioritized in your reading? A detailed index incorporates a meta-toc. Such a document would also be useful for building the Visual LyX FAQ. It would inform the FAQ as to which document informs the reader in more detail about a particular process by a hyperlink to the doc and/or the Index. This treats the whole Wiki as a FAQ. The index would also point to duplicate entries needing editing or possible deletion in an effort to become systematically sectioned when dividing the whole into assigned parts for a group undertaking. People don't all learn the same way, Stephen
Re: please consolidate the documentation
Ingo Klöcker wrote: Am Mittwoch, 19. Juli 2006 08:58 schrieb Martin A. Hansen: So what is the typical use-case for the LyX Manual? That someone wants to read it from the first page to the last page? Or that someone wants to read about a specific subject, say including graphics? In my experience the latter is the way more common use-case. I've read the Introduction once and the Tutorial once. And now, every now and then, I open the other two documents because I want to look something up. Therefore it would be preferable if loading the part I'm interested in wouldn't take 10 seconds but only 1 second. The only way to achieve this is to split up the document. Of course, there should be a master document with a complete toc so that I can quickly navigate to the chapter I'm interested in. Ideally, for the user it wouldn't feel different from one large lyx file with the exception that loading would be magnitudes faster. In any case, I'm pretty sure we can discuss this to death. Some people prefer a several megabyte large HTML file and other people prefer the same information nicely split up into several HTML files per chapter or even section (with nice navigation buttons of course). While the first approach is only feasible for people with a fast internet connection the second approach is feasible for anyone. And as always there's the option to do both. Provide the LyX manual as one huge single file and additionally split up into several files. I'd put the multiple-files version into the release and put the URL of the single file version near the start of the multiple-files version. Regards, Ingo I wasn't so sure that consolidated Help guides were all that useful. But making one in .pdf format and one in .lyx format to satisfy those who wanted it wasn't all that hard, so why not. It's on the Wiki. There are people who don't enjoy discussing things and they tend to describe the people who do enjoy it as beating a good horse to death. Single .lyx help guides already exist and it is pretty easy to pdflatex a pdf version from Lyx and there are existing multiple .lyx/pdf guides it doesn't seem fruitful to debate preferences. Learning visually brings to mind the Visual FAQ which demonstrates how to do something on the page itself and links to the tug FAQ. http://www.tug.org/tex-archive/info/visualFAQ/ Having trouble finding the answer to a LaTeX question? The Visual LaTeX FAQ is an innovative new search interface that presents over a hundred typeset samples of frequently requested document formatting. Simply click on a hyperlinked piece of text and the Visual LaTeX FAQ will send your Web browser to the appropriate page in the UK TeX FAQ. SH: I think a LyX VisualFAQ is a possible Wiki documentation project. Ingo: Of course, there should be a master document with a complete toc so that I can quickly navigate to the chapter I'm interested in. SH: The problem with keyword searches is that you have to know the keyword. We could create a detailed cross-referenced index of the entire Wiki which would be similar to the ouput of several hundred keyword searches. This master index would point to the document(s) which contained the concept being researched or related ideas. One wouldn't have to wade through several documents to find the right one. The way it is now, layouts might produce 12 hits, but which one of the 12 should be prioritized in your reading? A detailed index incorporates a meta-toc. Such a document would also be useful for building the Visual LyX FAQ. It would inform the FAQ as to which document informs the reader in more detail about a particular process by a hyperlink to the doc and/or the Index. This treats the whole Wiki as a FAQ. The index would also point to duplicate entries needing editing or possible deletion in an effort to become systematically sectioned when dividing the whole into assigned parts for a group undertaking. People don't all learn the same way, Stephen
Re: please consolidate the documentation
Ingo Klöcker wrote: Am Mittwoch, 19. Juli 2006 08:58 schrieb Martin A. Hansen: So what is the typical use-case for the LyX Manual? That someone wants to read it from the first page to the last page? Or that someone wants to read about a specific subject, say including graphics? In my experience the latter is the way more common use-case. I've read the Introduction once and the Tutorial once. And now, every now and then, I open the other two documents because I want to look something up. Therefore it would be preferable if loading the part I'm interested in wouldn't take 10 seconds but only 1 second. The only way to achieve this is to split up the document. Of course, there should be a master document with a complete toc so that I can quickly navigate to the chapter I'm interested in. Ideally, for the user it wouldn't feel different from one large lyx file with the exception that loading would be magnitudes faster. In any case, I'm pretty sure we can discuss this to death. Some people prefer a several megabyte large HTML file and other people prefer the same information nicely split up into several HTML files per chapter or even section (with nice navigation buttons of course). While the first approach is only feasible for people with a fast internet connection the second approach is feasible for anyone. And as always there's the option to do both. Provide the LyX manual as one huge single file and additionally split up into several files. I'd put the multiple-files version into the release and put the URL of the single file version near the start of the multiple-files version. Regards, Ingo I wasn't so sure that consolidated Help guides were all that useful. But making one in .pdf format and one in .lyx format to satisfy those who wanted it wasn't all that hard, so why not. It's on the Wiki. There are people who don't enjoy discussing things and they tend to describe the people who do enjoy it as "beating a good horse to death". Single .lyx help guides already exist and it is pretty easy to pdflatex a pdf version from Lyx and there are existing multiple .lyx/pdf guides it doesn't seem fruitful to debate preferences. Learning visually brings to mind the Visual FAQ which demonstrates how to do something on the page itself and links to the tug FAQ. http://www.tug.org/tex-archive/info/visualFAQ/ "Having trouble finding the answer to a LaTeX question? The Visual LaTeX FAQ is an innovative new search interface that presents over a hundred typeset samples of frequently requested document formatting. Simply click on a hyperlinked piece of text and the Visual LaTeX FAQ will send your Web browser to the appropriate page in the UK TeX FAQ." SH: I think a LyX VisualFAQ is a possible Wiki documentation project. Ingo: Of course, there should be a master document with a complete toc so that I can quickly navigate to the chapter I'm interested in. SH: The problem with keyword searches is that you have to know the keyword. We could create a detailed cross-referenced index of the entire Wiki which would be similar to the ouput of several hundred keyword searches. This master index would point to the document(s) which contained the concept being researched or related ideas. One wouldn't have to wade through several documents to find the right one. The way it is now, "layouts" might produce 12 hits, but which one of the 12 should be prioritized in your reading? A detailed index incorporates a meta-toc. Such a document would also be useful for building the Visual LyX FAQ. It would inform the FAQ as to which document informs the reader in more detail about a particular process by a hyperlink to the doc and/or the Index. This treats the whole Wiki as a FAQ. The index would also point to duplicate entries needing editing or possible deletion in an effort to become systematically sectioned when dividing the whole into assigned parts for a group undertaking. People don't all learn the same way, Stephen
Re: Converting in rtf or openoffice for windows
Charles de Miramon wrote: Sebastian wrote: Dear Listusers, I'm writing an article for a journal and the redaction is only taking rtf Format. Is there a way to export my lyx document into rtf or OpenOffice for windows. Unfortunatly works the export script for openoffice only for linux, but I'm working on windows. Is there a workaround or something? With kind regards, Sebastian Do you have tex4ht installed on your computer. If you use MikTeX try http://facweb.knowlton.ohio-state.edu/pviton/support/tex4ht.html htaltex which comes with the tex4ht package converts to html. from the command line: htlatex something.tex makes something.html, Conversion quality varies and outputs need to be proofread. http://www.surfpack.com/software/html2rtf/ offers a Windows html2rtf freeware utility. If you install the tex4ht package you will need to run the updating of the databases found in Miktex Options, part of Miktex. I usually Reconfigure (under Tools or Edit) LyX afterwards. Regards, Stephen
Re: Converting in rtf or openoffice for windows
Charles de Miramon wrote: Sebastian wrote: Dear Listusers, I'm writing an article for a journal and the redaction is only taking rtf Format. Is there a way to export my lyx document into rtf or OpenOffice for windows. Unfortunatly works the export script for openoffice only for linux, but I'm working on windows. Is there a workaround or something? With kind regards, Sebastian Do you have tex4ht installed on your computer. If you use MikTeX try http://facweb.knowlton.ohio-state.edu/pviton/support/tex4ht.html htaltex which comes with the tex4ht package converts to html. from the command line: htlatex something.tex makes something.html, Conversion quality varies and outputs need to be proofread. http://www.surfpack.com/software/html2rtf/ offers a Windows html2rtf freeware utility. If you install the tex4ht package you will need to run the updating of the databases found in Miktex Options, part of Miktex. I usually Reconfigure (under Tools or Edit) LyX afterwards. Regards, Stephen
Re: Converting in rtf or openoffice for windows
Charles de Miramon wrote: > Sebastian wrote: > > >>Dear Listusers, >>I'm writing an article for a journal and the redaction is only taking rtf >>Format. Is there a way to export my lyx document into rtf or OpenOffice >>for windows. Unfortunatly works the export script for openoffice only for >>linux, but I'm working on windows. Is there a workaround or something? >> >>With kind regards, >>Sebastian > > > Do you have tex4ht installed on your computer. > > If you use MikTeX try > http://facweb.knowlton.ohio-state.edu/pviton/support/tex4ht.html > htaltex which comes with the tex4ht package converts to html. from the command line: "htlatex something.tex" makes something.html, Conversion quality varies and outputs need to be proofread. http://www.surfpack.com/software/html2rtf/ offers a Windows html2rtf freeware utility. If you install the tex4ht package you will need to run the updating of the databases found in Miktex Options, part of Miktex. I usually Reconfigure (under Tools or Edit) LyX afterwards. Regards, Stephen
Re: SVGs with alpha channel transparency
John Pye wrote: Your approach defeats the purpose of using SVG in the first place, and will result in much large PDF files that I am currently getting. I really want to work out how use my SVG-with-alpha directly in LyX, or at least some vector format that will look OK. I wonder if there's an SVG-to-EPS converter that doesn't something smart with regard to alpha channels? It would need to flatten the layers of the vector image in a vectorised way, rather than the bitmapped way that most renderers no double work. Perhaps I just need to give up on the alpha-channel idea... Cheers JP Stephen Harris wrote: John Pye wrote: Hi Uwe, This approach (save as PDF from Inkscape) did not give me alpha channel transparency in my PDF. For example: On the left is a PNG exported from Inkscape (or alternatively, generated using 'rsvg-convert'. On the right is the PDF exported by Inkscape. So I'm still stuck with no alpha channel; the only approach still is to use a PNG conversion filter, which means blurry figures. I'm hoping that rsvg-convert's PDF output might do a better job than Inkscape's, but haven't succeeded with that (the LyX builtin 'convert' convert seems to get in the way for some reason). Cheers JP This is a recommended method I found before: Alternatively, SVG to EPS or PDF 1. Open with inkscape. 2. Export to png (huge hi-resolution) 3. Open with the GIMP 4. Save as .eps 5. gsview (or linux command) convert to .ps 6. ps2pdf convert .ps to .pdf Regards, Stephen Adobe is a supporter of SVG and recommends Adobe Illustrator CS and they also have a viewer. Notoriously poor support for Linux. http://www.adobe.com/svg/viewer/install/main.html * Current support documentation (PDF: 743k) * Adobe® SVG Viewer for Windows® (PDF: 65k) * Adobe SVG Viewer for Macintosh (PDF: 70k) Regards, Stephen
Re: Windows XP: Aspell for Opera and Lyx conflict
David Finlayson wrote: Maybe some of you use Opera browser as well as Lyx on Windows XP? I can't seem to get Opera to find the custom Aspell 0.6 built for Lyx, and I can't get Lyx to work with Aspell 0.5 which Opera can use (installed in C:\Aspell in both cases). Finally, it doesn't seem like you can have both Aspell versions installed because Opera uses c:\Aspell no matter where an alternate version is placed. Grrr. Is it really true that I can only have spell checking in my email client or my word processor but not both at the same time? Joost has fixed it so Aspell can be installed where you want it. Probably available in the next LyX release. You can have two versions of Aspell installed for LyX, so I don't see why it wouldn't work for LyX and Opera. The traditional 0.5 should work with Opera or LyX1.3.7 -- and 0.6 should work with LyX1.4.1 -- they share the same parent folder, C:\Aspell but are installed in different folders after that with different dictionaries. They don't conflict for the two LyX versions. I don't have Opera, but a full path specified to the 0.53 Aspell should work. Regards, Stephen
Re: SVGs with alpha channel transparency
John Pye wrote: Your approach defeats the purpose of using SVG in the first place, and will result in much large PDF files that I am currently getting. I really want to work out how use my SVG-with-alpha directly in LyX, or at least some vector format that will look OK. I wonder if there's an SVG-to-EPS converter that doesn't something smart with regard to alpha channels? It would need to flatten the layers of the vector image in a vectorised way, rather than the bitmapped way that most renderers no double work. Perhaps I just need to give up on the alpha-channel idea... Cheers JP Stephen Harris wrote: John Pye wrote: Hi Uwe, This approach (save as PDF from Inkscape) did not give me alpha channel transparency in my PDF. For example: On the left is a PNG exported from Inkscape (or alternatively, generated using 'rsvg-convert'. On the right is the PDF exported by Inkscape. So I'm still stuck with no alpha channel; the only approach still is to use a PNG conversion filter, which means blurry figures. I'm hoping that rsvg-convert's PDF output might do a better job than Inkscape's, but haven't succeeded with that (the LyX builtin 'convert' convert seems to get in the way for some reason). Cheers JP This is a recommended method I found before: Alternatively, SVG to EPS or PDF 1. Open with inkscape. 2. Export to png (huge hi-resolution) 3. Open with the GIMP 4. Save as .eps 5. gsview (or linux command) convert to .ps 6. ps2pdf convert .ps to .pdf Regards, Stephen Adobe is a supporter of SVG and recommends Adobe Illustrator CS and they also have a viewer. Notoriously poor support for Linux. http://www.adobe.com/svg/viewer/install/main.html * Current support documentation (PDF: 743k) * Adobe® SVG Viewer for Windows® (PDF: 65k) * Adobe SVG Viewer for Macintosh (PDF: 70k) Regards, Stephen
Re: Windows XP: Aspell for Opera and Lyx conflict
David Finlayson wrote: Maybe some of you use Opera browser as well as Lyx on Windows XP? I can't seem to get Opera to find the custom Aspell 0.6 built for Lyx, and I can't get Lyx to work with Aspell 0.5 which Opera can use (installed in C:\Aspell in both cases). Finally, it doesn't seem like you can have both Aspell versions installed because Opera uses c:\Aspell no matter where an alternate version is placed. Grrr. Is it really true that I can only have spell checking in my email client or my word processor but not both at the same time? Joost has fixed it so Aspell can be installed where you want it. Probably available in the next LyX release. You can have two versions of Aspell installed for LyX, so I don't see why it wouldn't work for LyX and Opera. The traditional 0.5 should work with Opera or LyX1.3.7 -- and 0.6 should work with LyX1.4.1 -- they share the same parent folder, C:\Aspell but are installed in different folders after that with different dictionaries. They don't conflict for the two LyX versions. I don't have Opera, but a full path specified to the 0.53 Aspell should work. Regards, Stephen
Re: SVGs with alpha channel transparency
John Pye wrote: Your approach defeats the purpose of using SVG in the first place, and will result in much large PDF files that I am currently getting. I really want to work out how use my SVG-with-alpha directly in LyX, or at least some vector format that will look OK. I wonder if there's an SVG-to-EPS converter that doesn't something smart with regard to alpha channels? It would need to flatten the layers of the vector image in a vectorised way, rather than the bitmapped way that most renderers no double work. Perhaps I just need to give up on the alpha-channel idea... Cheers JP Stephen Harris wrote: John Pye wrote: Hi Uwe, This approach (save as PDF from Inkscape) did not give me alpha channel transparency in my PDF. For example: On the left is a PNG exported from Inkscape (or alternatively, generated using 'rsvg-convert'. On the right is the PDF exported by Inkscape. So I'm still stuck with no alpha channel; the only approach still is to use a PNG conversion filter, which means blurry figures. I'm hoping that rsvg-convert's PDF output might do a better job than Inkscape's, but haven't succeeded with that (the LyX builtin 'convert' convert seems to get in the way for some reason). Cheers JP This is a recommended method I found before: Alternatively, SVG to EPS or PDF 1. Open with inkscape. 2. Export to png (huge hi-resolution) 3. Open with the GIMP 4. Save as .eps 5. gsview (or linux command) convert to .ps 6. ps2pdf convert .ps to .pdf Regards, Stephen Adobe is a supporter of SVG and recommends Adobe Illustrator CS and they also have a viewer. Notoriously poor support for Linux. http://www.adobe.com/svg/viewer/install/main.html * Current support documentation (PDF: 743k) * Adobe® SVG Viewer for Windows® (PDF: 65k) * Adobe SVG Viewer for Macintosh (PDF: 70k) Regards, Stephen
Re: Windows XP: Aspell for Opera and Lyx conflict
David Finlayson wrote: Maybe some of you use Opera browser as well as Lyx on Windows XP? I can't seem to get Opera to find the custom Aspell 0.6 built for Lyx, and I can't get Lyx to work with Aspell 0.5 which Opera can use (installed in C:\Aspell in both cases). Finally, it doesn't seem like you can have both Aspell versions installed because Opera uses c:\Aspell no matter where an alternate version is placed. Grrr. Is it really true that I can only have spell checking in my email client or my word processor but not both at the same time? Joost has fixed it so Aspell can be installed where you want it. Probably available in the next LyX release. You can have two versions of Aspell installed for LyX, so I don't see why it wouldn't work for LyX and Opera. The traditional 0.5 should work with Opera or LyX1.3.7 -- and 0.6 should work with LyX1.4.1 -- they share the same parent folder, C:\Aspell but are installed in different folders after that with different dictionaries. They don't conflict for the two LyX versions. I don't have Opera, but a full path specified to the 0.53 Aspell should work. Regards, Stephen
Re: SVGs with alpha channel transparency
John Pye wrote: Hi Uwe, This approach (save as PDF from Inkscape) did not give me alpha channel transparency in my PDF. For example: On the left is a PNG exported from Inkscape (or alternatively, generated using 'rsvg-convert'. On the right is the PDF exported by Inkscape. So I'm still stuck with no alpha channel; the only approach still is to use a PNG conversion filter, which means blurry figures. I'm hoping that rsvg-convert's PDF output might do a better job than Inkscape's, but haven't succeeded with that (the LyX builtin 'convert' convert seems to get in the way for some reason). Cheers JP This is a recommended method I found before: Alternatively, SVG to EPS or PDF 1. Open with inkscape. 2. Export to png (huge hi-resolution) 3. Open with the GIMP 4. Save as .eps 5. gsview (or linux command) convert to .ps 6. ps2pdf convert .ps to .pdf Regards, Stephen
Re: SVGs with alpha channel transparency
John Pye wrote: Hi Uwe, This approach (save as PDF from Inkscape) did not give me alpha channel transparency in my PDF. For example: On the left is a PNG exported from Inkscape (or alternatively, generated using 'rsvg-convert'. On the right is the PDF exported by Inkscape. So I'm still stuck with no alpha channel; the only approach still is to use a PNG conversion filter, which means blurry figures. I'm hoping that rsvg-convert's PDF output might do a better job than Inkscape's, but haven't succeeded with that (the LyX builtin 'convert' convert seems to get in the way for some reason). Cheers JP This is a recommended method I found before: Alternatively, SVG to EPS or PDF 1. Open with inkscape. 2. Export to png (huge hi-resolution) 3. Open with the GIMP 4. Save as .eps 5. gsview (or linux command) convert to .ps 6. ps2pdf convert .ps to .pdf Regards, Stephen
Re: SVGs with alpha channel transparency
John Pye wrote: Hi Uwe, This approach (save as PDF from Inkscape) did not give me alpha channel transparency in my PDF. For example: On the left is a PNG exported from Inkscape (or alternatively, generated using 'rsvg-convert'. On the right is the PDF exported by Inkscape. So I'm still stuck with no alpha channel; the only approach still is to use a PNG conversion filter, which means blurry figures. I'm hoping that rsvg-convert's PDF output might do a better job than Inkscape's, but haven't succeeded with that (the LyX builtin 'convert' convert seems to get in the way for some reason). Cheers JP This is a recommended method I found before: Alternatively, SVG to EPS or PDF 1. Open with inkscape. 2. Export to png (huge hi-resolution) 3. Open with the GIMP 4. Save as .eps 5. gsview (or linux command) convert to .ps 6. ps2pdf convert .ps to .pdf Regards, Stephen
Re: Confused about Lyx's goals -- isn't this supposed to increase productivity?
Richard Heck wrote: Speaking just for myself...and, yes, I'm an academic, a philosopher (with mathematical interests)... I have found LyX to deliver precisely what it purports to offer: I concentrate more on my writing and less on formatting. It seems crazy in retrospect, but when I was using a traditional word processor (WordPerfect, in my case), I'd spend a ridiculously long time worrying about hyphenation, line length, and the like, and that despite the fact that it didn't make a bit of difference, since I was probably going to re-write the paragraph I was so worried about the next day. (I've spoken to other people and have found this to be a common experience.) I'd worry about formatting section headings, where page breaks occurred, etc, etc. Now I don't. I just write and let LaTeX do all the work formatting my document. (And, of course, when I'm writing logic, well, you can't beat LaTeX when it comes to typesetting formulae.) So most of the time, there is no ERT in my LyX documents at all, and the preamble contains nothing more than what's needed to get fancyhdr to do its thing. Could the formatting be tweaked? Sure. If you /want/ to worry about that kind of thing with LyX or LaTeX, you're free to do so, and I've done some of that tweaking myself from time to time: That's when you have to delve into LaTeX. But precisely because LyX isn't WYSIWYG, formatting issues don't stare you in the face while you're trying to write, and so you are free to ignore them. (I find that I can write almost as freely in LyX as I can when I'm just writing longhand.) Indeed, I find that one of the first things people have to do, when they first come to LyX, is simply to /stop worrying/ /about formatting/ and learn to focus on content. It's a common complaint among college teachers that students seem to spend more time worrying about the appearance of their papers than they do their content, and, in that same vein, I often find myself wanting to ask people who post formatting questions to this list how much it really matters whether the gap about section headings is this big or only that big and, for that matter, whether they really think they know more about typesetting than the people who produced the styles they're using. That's not to say there aren't legitimate issues that arise, and if you're self-publishing books, like Steve Litt, for example, or trying to get your thesis into the appropriate format, then you're going to have more such issues to handle. But a lot of these have been encountered by other people, and a lot of them have been solved by people who posted the resulting LaTeX packages on CTAN. And for the most common issues, very comprehensive packages (like titlesec, say) have been written to expose the internals in a comprehensible way. I strongly suspect, however, that some very large percentage of the time, people just need to /chill on the formatting/. The core to LyX's advantage, one inherited from LaTeX, is thus that form is separated from content. As you may know, that's kind of a mantra these days. In this respect, LaTeX incorporates a primitive version of the kind of /semantic/ markup that's supposed to power the semantic web. Because the markup is semantic, it's a relatively trivial matter to convert a LaTeX document to a spoken format for the blind or to reformat the document when it gets rejected by journal A and needs to be resubmitted to journal B. Yes, of course you can do a more semantic markup with Word or OO, but how many people actually do? Creating and debugging styles in traditional sorts of word processors is every bit as labor-intensive as doing it in LaTeX, and because traditional programs make spot-formatting so easy to do, people don't put in the effort to create or even to learn how to use styles. They just format line-by-line. LyX and LaTeX purposely discourage that kind of behavior, and that is a Good Thing. But to understand what a good thing it is, you have to unlearn some bad habits. It's true that bibliography formatting is a sore spot. If you can get away with using standard styles like apalike, then it's simple, but obviously not everyone can, and natbib, in particular, has some wonderful features that could be easier to use. (That said, LyX 1.4.x is a /big/ jump forward, and thanks to the developers for that.) Jurabib is even more flexible, and it would indeed be nice to see a GUI to configure it, as it can be pretty confusing, but I strongly suspect we will see that. But here again, I think a mental adjustment is in order. Journals do of course have their own styles, but I've never once had a journal send a paper back to me insisting that I put the references in form A or form B, and the journals that are really insistent all produce their own BibTeX styles, anyway. So for most people, natbib is going to be more than sufficient. What's true, however, is that most of the focus so far has been on scientific writing, and there are some issues connected with writing
Re: Confused about Lyx's goals -- isn't this supposed to increase productivity?
Richard Heck wrote: Speaking just for myself...and, yes, I'm an academic, a philosopher (with mathematical interests)... I have found LyX to deliver precisely what it purports to offer: I concentrate more on my writing and less on formatting. It seems crazy in retrospect, but when I was using a traditional word processor (WordPerfect, in my case), I'd spend a ridiculously long time worrying about hyphenation, line length, and the like, and that despite the fact that it didn't make a bit of difference, since I was probably going to re-write the paragraph I was so worried about the next day. (I've spoken to other people and have found this to be a common experience.) I'd worry about formatting section headings, where page breaks occurred, etc, etc. Now I don't. I just write and let LaTeX do all the work formatting my document. (And, of course, when I'm writing logic, well, you can't beat LaTeX when it comes to typesetting formulae.) So most of the time, there is no ERT in my LyX documents at all, and the preamble contains nothing more than what's needed to get fancyhdr to do its thing. Could the formatting be tweaked? Sure. If you /want/ to worry about that kind of thing with LyX or LaTeX, you're free to do so, and I've done some of that tweaking myself from time to time: That's when you have to delve into LaTeX. But precisely because LyX isn't WYSIWYG, formatting issues don't stare you in the face while you're trying to write, and so you are free to ignore them. (I find that I can write almost as freely in LyX as I can when I'm just writing longhand.) Indeed, I find that one of the first things people have to do, when they first come to LyX, is simply to /stop worrying/ /about formatting/ and learn to focus on content. It's a common complaint among college teachers that students seem to spend more time worrying about the appearance of their papers than they do their content, and, in that same vein, I often find myself wanting to ask people who post formatting questions to this list how much it really matters whether the gap about section headings is this big or only that big and, for that matter, whether they really think they know more about typesetting than the people who produced the styles they're using. That's not to say there aren't legitimate issues that arise, and if you're self-publishing books, like Steve Litt, for example, or trying to get your thesis into the appropriate format, then you're going to have more such issues to handle. But a lot of these have been encountered by other people, and a lot of them have been solved by people who posted the resulting LaTeX packages on CTAN. And for the most common issues, very comprehensive packages (like titlesec, say) have been written to expose the internals in a comprehensible way. I strongly suspect, however, that some very large percentage of the time, people just need to /chill on the formatting/. The core to LyX's advantage, one inherited from LaTeX, is thus that form is separated from content. As you may know, that's kind of a mantra these days. In this respect, LaTeX incorporates a primitive version of the kind of /semantic/ markup that's supposed to power the semantic web. Because the markup is semantic, it's a relatively trivial matter to convert a LaTeX document to a spoken format for the blind or to reformat the document when it gets rejected by journal A and needs to be resubmitted to journal B. Yes, of course you can do a more semantic markup with Word or OO, but how many people actually do? Creating and debugging styles in traditional sorts of word processors is every bit as labor-intensive as doing it in LaTeX, and because traditional programs make spot-formatting so easy to do, people don't put in the effort to create or even to learn how to use styles. They just format line-by-line. LyX and LaTeX purposely discourage that kind of behavior, and that is a Good Thing. But to understand what a good thing it is, you have to unlearn some bad habits. It's true that bibliography formatting is a sore spot. If you can get away with using standard styles like apalike, then it's simple, but obviously not everyone can, and natbib, in particular, has some wonderful features that could be easier to use. (That said, LyX 1.4.x is a /big/ jump forward, and thanks to the developers for that.) Jurabib is even more flexible, and it would indeed be nice to see a GUI to configure it, as it can be pretty confusing, but I strongly suspect we will see that. But here again, I think a mental adjustment is in order. Journals do of course have their own styles, but I've never once had a journal send a paper back to me insisting that I put the references in form A or form B, and the journals that are really insistent all produce their own BibTeX styles, anyway. So for most people, natbib is going to be more than sufficient. What's true, however, is that most of the focus so far has been on scientific writing, and there are some issues connected with writing
Re: Confused about Lyx's goals -- isn't this supposed to increase productivity?
Richard Heck wrote: Speaking just for myself...and, yes, I'm an academic, a philosopher (with mathematical interests)... I have found LyX to deliver precisely what it purports to offer: I concentrate more on my writing and less on formatting. It seems crazy in retrospect, but when I was using a traditional word processor (WordPerfect, in my case), I'd spend a ridiculously long time worrying about hyphenation, line length, and the like, and that despite the fact that it didn't make a bit of difference, since I was probably going to re-write the paragraph I was so worried about the next day. (I've spoken to other people and have found this to be a common experience.) I'd worry about formatting section headings, where page breaks occurred, etc, etc. Now I don't. I just write and let LaTeX do all the work formatting my document. (And, of course, when I'm writing logic, well, you can't beat LaTeX when it comes to typesetting formulae.) So most of the time, there is no ERT in my LyX documents at all, and the preamble contains nothing more than what's needed to get fancyhdr to do its thing. Could the formatting be tweaked? Sure. If you /want/ to worry about that kind of thing with LyX or LaTeX, you're free to do so, and I've done some of that tweaking myself from time to time: That's when you have to delve into LaTeX. But precisely because LyX isn't WYSIWYG, formatting issues don't stare you in the face while you're trying to write, and so you are free to ignore them. (I find that I can write almost as freely in LyX as I can when I'm just writing longhand.) Indeed, I find that one of the first things people have to do, when they first come to LyX, is simply to /stop worrying/ /about formatting/ and learn to focus on content. It's a common complaint among college teachers that students seem to spend more time worrying about the appearance of their papers than they do their content, and, in that same vein, I often find myself wanting to ask people who post formatting questions to this list how much it really matters whether the gap about section headings is this big or only that big and, for that matter, whether they really think they know more about typesetting than the people who produced the styles they're using. That's not to say there aren't legitimate issues that arise, and if you're self-publishing books, like Steve Litt, for example, or trying to get your thesis into the appropriate format, then you're going to have more such issues to handle. But a lot of these have been encountered by other people, and a lot of them have been solved by people who posted the resulting LaTeX packages on CTAN. And for the most common issues, very comprehensive packages (like titlesec, say) have been written to expose the internals in a comprehensible way. I strongly suspect, however, that some very large percentage of the time, people just need to /chill on the formatting/. The core to LyX's advantage, one inherited from LaTeX, is thus that form is separated from content. As you may know, that's kind of a mantra these days. In this respect, LaTeX incorporates a primitive version of the kind of /semantic/ markup that's supposed to power the "semantic web". Because the markup is semantic, it's a relatively trivial matter to convert a LaTeX document to a spoken format for the blind or to reformat the document when it gets rejected by journal A and needs to be resubmitted to journal B. Yes, of course you can do a more semantic markup with Word or OO, but how many people actually do? Creating and debugging styles in traditional sorts of word processors is every bit as labor-intensive as doing it in LaTeX, and because traditional programs make spot-formatting so easy to do, people don't put in the effort to create or even to learn how to use styles. They just format line-by-line. LyX and LaTeX purposely discourage that kind of behavior, and that is a Good Thing. But to understand what a good thing it is, you have to unlearn some bad habits. It's true that bibliography formatting is a sore spot. If you can get away with using standard styles like apalike, then it's simple, but obviously not everyone can, and natbib, in particular, has some wonderful features that could be easier to use. (That said, LyX 1.4.x is a /big/ jump forward, and thanks to the developers for that.) Jurabib is even more flexible, and it would indeed be nice to see a GUI to configure it, as it can be pretty confusing, but I strongly suspect we will see that. But here again, I think a mental adjustment is in order. Journals do of course have their own styles, but I've never once had a journal send a paper back to me insisting that I put the references in form A or form B, and the journals that are really insistent all produce their own BibTeX styles, anyway. So for most people, natbib is going to be more than sufficient. What's true, however, is that most of the focus so far has been on scientific writing, and there are some issues connected with writing
Re: Layout copyright; was: Re: Sharing layout files
Steve Litt wrote: On Friday 16 June 2006 11:50 am, David Neeley wrote: Finally, I do believe that if you wish to be covered, the wiki should have a copyright statement something like: Files submitted to the wiki for general download are covered by the XXX license in the name of their respective author, unless specified otherwise by the contributing authors. That sounds good. I would suggest something like the BSD license as the basic one, so there are no real limitations or questions about use--commercial or otherwise--but giving the contributor the option of choosing another one if he or she desires. That way, if the files can be copyrighted, they would be covered in all cases. That also sounds good, at least for most stuff, including what I emailed a couple days ago. If it were something I worked 60 hours on I might go GPL to prevent a Microsoft Kerberos type situation, but my layout files aren't that type of work. Thanks for the clarification and good idea. http://www.c4.net/Index.cfm?Method=NewsStories.NewsStoryNewsStory_ID=143 This article at the Register discusses one of the major hurtles confronting would be challengers to the Microsoft throne, fonts. It may seem like an insignificant part of the whole, but it is important enough that current U.S. law actually makes an exception for copyrighting the shape and design of fonts in the name of free press. This means that, for all intents and purposes, you could rename a font and redistribute it…in the States. Other countries are not so forgiving, and that's where trouble comes into paradise.
Re: Layout copyright; was: Re: Sharing layout files
Steve Litt wrote: On Friday 16 June 2006 11:50 am, David Neeley wrote: Finally, I do believe that if you wish to be covered, the wiki should have a copyright statement something like: Files submitted to the wiki for general download are covered by the XXX license in the name of their respective author, unless specified otherwise by the contributing authors. That sounds good. I would suggest something like the BSD license as the basic one, so there are no real limitations or questions about use--commercial or otherwise--but giving the contributor the option of choosing another one if he or she desires. That way, if the files can be copyrighted, they would be covered in all cases. That also sounds good, at least for most stuff, including what I emailed a couple days ago. If it were something I worked 60 hours on I might go GPL to prevent a Microsoft Kerberos type situation, but my layout files aren't that type of work. I've been reading about this some more. It turns out to be a very complex legal issue, especially regarding fonts, which do not have the same legal status as layout files. http://www-personal.umich.edu/~pfs/essay2.html Though I think your copyright rights, if they are weak, will extend to whoever tries to steal your work. If they can get away with stealing yours, then someone can steal from them too. Also obtaining a license for some fonts doesn't give you the same rights to use those fonts as if you had bought them.
Zref package expands reference system flexibility
The zref package Heiko Oberdiek 2006/05/25 v1.2
Abstract
Package zref tries to get rid of the restriction in LATEX's
reference system that only two properties are supported. The
package implements an extensible referencing system, where
properties are handled in a more flexible way. It offers an
interface for macro programmers for the access to the system
and some applications that uses the new reference scheme.
http://www.informatik.uni-freiburg.de/~oberdiek/tmp/zref.pdf
(temporary location until I find time for a CTAN upload)
Chapter 7 and 7.1 include installation details.
pdftk zref.pdf unpack_files output produces zref.dtx
which is unpacked with tex zref.dtx
pdftk is a free download available from AccessPDF
http://www.accesspdf.com/article.php/20041130153545577
There are several files produced by tex zref.dtx
which need to be copied to their appropriate directory on
your system. Most of the Oberdiek directories already
existed on my system with the execption of the source
path for /Oberdiek which will contain the zref.dtx file.
-
6.2.10 Compatibility with babel
[EMAIL PROTECTED]@babel
430 [EMAIL PROTECTED]@babel#1#2{%
431 \begingroup
432 \csname @[EMAIL PROTECTED]
433 \edef\x{#2}%
434 \expandafter\endgroup
435 [EMAIL PROTECTED]@babel\expandafter{\x}{#1}%
436 }
437 [EMAIL PROTECTED]@babel#1#2{%
438 #2{#1}%
439 }
---
SH: I figure this package will benefit someone, sometime.
Regards,
--
Stephen
Topic ontology recapitulates entropic philology.
Re: Layout copyright; was: Re: Sharing layout files
Steve Litt wrote: On Friday 16 June 2006 11:50 am, David Neeley wrote: Finally, I do believe that if you wish to be covered, the wiki should have a copyright statement something like: Files submitted to the wiki for general download are covered by the XXX license in the name of their respective author, unless specified otherwise by the contributing authors. That sounds good. I would suggest something like the BSD license as the basic one, so there are no real limitations or questions about use--commercial or otherwise--but giving the contributor the option of choosing another one if he or she desires. That way, if the files can be copyrighted, they would be covered in all cases. That also sounds good, at least for most stuff, including what I emailed a couple days ago. If it were something I worked 60 hours on I might go GPL to prevent a Microsoft Kerberos type situation, but my layout files aren't that type of work. Thanks for the clarification and good idea. http://www.c4.net/Index.cfm?Method=NewsStories.NewsStoryNewsStory_ID=143 This article at the Register discusses one of the major hurtles confronting would be challengers to the Microsoft throne, fonts. It may seem like an insignificant part of the whole, but it is important enough that current U.S. law actually makes an exception for copyrighting the shape and design of fonts in the name of free press. This means that, for all intents and purposes, you could rename a font and redistribute it…in the States. Other countries are not so forgiving, and that's where trouble comes into paradise.
Re: Layout copyright; was: Re: Sharing layout files
Steve Litt wrote: On Friday 16 June 2006 11:50 am, David Neeley wrote: Finally, I do believe that if you wish to be covered, the wiki should have a copyright statement something like: Files submitted to the wiki for general download are covered by the XXX license in the name of their respective author, unless specified otherwise by the contributing authors. That sounds good. I would suggest something like the BSD license as the basic one, so there are no real limitations or questions about use--commercial or otherwise--but giving the contributor the option of choosing another one if he or she desires. That way, if the files can be copyrighted, they would be covered in all cases. That also sounds good, at least for most stuff, including what I emailed a couple days ago. If it were something I worked 60 hours on I might go GPL to prevent a Microsoft Kerberos type situation, but my layout files aren't that type of work. I've been reading about this some more. It turns out to be a very complex legal issue, especially regarding fonts, which do not have the same legal status as layout files. http://www-personal.umich.edu/~pfs/essay2.html Though I think your copyright rights, if they are weak, will extend to whoever tries to steal your work. If they can get away with stealing yours, then someone can steal from them too. Also obtaining a license for some fonts doesn't give you the same rights to use those fonts as if you had bought them.
Zref package expands reference system flexibility
The zref package Heiko Oberdiek 2006/05/25 v1.2
Abstract
Package zref tries to get rid of the restriction in LATEX's
reference system that only two properties are supported. The
package implements an extensible referencing system, where
properties are handled in a more flexible way. It offers an
interface for macro programmers for the access to the system
and some applications that uses the new reference scheme.
http://www.informatik.uni-freiburg.de/~oberdiek/tmp/zref.pdf
(temporary location until I find time for a CTAN upload)
Chapter 7 and 7.1 include installation details.
pdftk zref.pdf unpack_files output produces zref.dtx
which is unpacked with tex zref.dtx
pdftk is a free download available from AccessPDF
http://www.accesspdf.com/article.php/20041130153545577
There are several files produced by tex zref.dtx
which need to be copied to their appropriate directory on
your system. Most of the Oberdiek directories already
existed on my system with the execption of the source
path for /Oberdiek which will contain the zref.dtx file.
-
6.2.10 Compatibility with babel
[EMAIL PROTECTED]@babel
430 [EMAIL PROTECTED]@babel#1#2{%
431 \begingroup
432 \csname @[EMAIL PROTECTED]
433 \edef\x{#2}%
434 \expandafter\endgroup
435 [EMAIL PROTECTED]@babel\expandafter{\x}{#1}%
436 }
437 [EMAIL PROTECTED]@babel#1#2{%
438 #2{#1}%
439 }
---
SH: I figure this package will benefit someone, sometime.
Regards,
--
Stephen
Topic ontology recapitulates entropic philology.
Re: Layout copyright; was: Re: Sharing layout files
Steve Litt wrote: On Friday 16 June 2006 11:50 am, David Neeley wrote: Finally, I do believe that if you wish to be covered, the wiki should have a copyright statement something like: "Files submitted to the wiki for general download are covered by the XXX license in the name of their respective author, unless specified otherwise by the contributing authors." That sounds good. I would suggest something like the BSD license as the basic one, so there are no real limitations or questions about use--commercial or otherwise--but giving the contributor the option of choosing another one if he or she desires. That way, if the files can be copyrighted, they would be covered in all cases. That also sounds good, at least for most stuff, including what I emailed a couple days ago. If it were something I worked 60 hours on I might go GPL to prevent a Microsoft Kerberos type situation, but my layout files aren't that type of work. Thanks for the clarification and good idea. http://www.c4.net/Index.cfm?Method=NewsStories.NewsStory_ID=143 "This article at the Register discusses one of the major hurtles confronting would be challengers to the Microsoft throne, fonts. It may seem like an insignificant part of the whole, but it is important enough that current U.S. law actually makes an exception for copyrighting the shape and design of fonts in the name of free press. This means that, for all intents and purposes, you could rename a font and redistribute it…in the States. Other countries are not so forgiving, and that's where trouble comes into paradise."
Re: Layout copyright; was: Re: Sharing layout files
Steve Litt wrote: On Friday 16 June 2006 11:50 am, David Neeley wrote: Finally, I do believe that if you wish to be covered, the wiki should have a copyright statement something like: "Files submitted to the wiki for general download are covered by the XXX license in the name of their respective author, unless specified otherwise by the contributing authors." That sounds good. I would suggest something like the BSD license as the basic one, so there are no real limitations or questions about use--commercial or otherwise--but giving the contributor the option of choosing another one if he or she desires. That way, if the files can be copyrighted, they would be covered in all cases. That also sounds good, at least for most stuff, including what I emailed a couple days ago. If it were something I worked 60 hours on I might go GPL to prevent a Microsoft Kerberos type situation, but my layout files aren't that type of work. I've been reading about this some more. It turns out to be a very complex legal issue, especially regarding fonts, which do not have the same legal status as layout files. http://www-personal.umich.edu/~pfs/essay2.html Though I think your copyright rights, if they are weak, will extend to whoever tries to steal your "work". If they can get away with stealing yours, then someone can steal from them too. Also obtaining a license for some fonts doesn't give you the same rights to use those fonts as if you had bought them.
Zref package expands reference system flexibility
The zref package Heiko Oberdiek 2006/05/25 v1.2
Abstract
"Package zref tries to get rid of the restriction in LATEX's
reference system that only two properties are supported. The
package implements an extensible referencing system, where
properties are handled in a more flexible way. It offers an
interface for macro programmers for the access to the system
and some applications that uses the new reference scheme."
"http://www.informatik.uni-freiburg.de/~oberdiek/tmp/zref.pdf
(temporary location until I find time for a CTAN upload)"
Chapter 7 and 7.1 include installation details.
"pdftk zref.pdf unpack_files output" produces zref.dtx
which is unpacked with "tex zref.dtx"
pdftk is a free download available from AccessPDF
http://www.accesspdf.com/article.php/20041130153545577
There are several files produced by "tex zref.dtx"
which need to be copied to their appropriate directory on
your system. Most of the "Oberdiek" directories already
existed on my system with the execption of the "source"
path for /Oberdiek which will contain the zref.dtx file.
-
6.2.10 Compatibility with babel
[EMAIL PROTECTED]@babel
430 [EMAIL PROTECTED]@babel#1#2{%
431 \begingroup
432 \csname @[EMAIL PROTECTED]
433 \edef\x{#2}%
434 \expandafter\endgroup
435 [EMAIL PROTECTED]@babel\expandafter{\x}{#1}%
436 }
437 [EMAIL PROTECTED]@babel#1#2{%
438 #2{#1}%
439 }
---
SH: I figure this package will benefit someone, sometime.
Regards,
--
Stephen
Topic ontology recapitulates entropic philology.
Re: OT: Eliminating all pixels around a figure
Paul Smith wrote: On 6/14/06, Stephen Harris [EMAIL PROTECTED] wrote: Thanks, David and Georg. In particular, I am trying to find a tool to work on Linux. Gimp is a Linux application, but maybe there is already a Linux equivalent of StripFile: http://www.nuetools.co.uk/stripfile.html I will ask for it on the Fedora mailing list. Stripfile succeeds mainly by removing embedded comments/text. http://files.linuxforum.com/man/jpegtran.1.php jpegtran also recognizes these switches that control what to do with extra markers, such as comment blocks: -copy none Copy no extra markers from source file. This setting suppresses all comments and other excess baggage present in the source file. -optimize Perform optimization of entropy encoding parameters. -trim Drop non-transformable edge blocks. http://mapivi.sourceforge.net/mapivi.shtml http://rpmfind.net/linux/RPM/suse/9.0/i386/suse/i586/ungifsicle-1.39-34.i586.html http://www.intuitive.com/coolweb/FAQ/giftrans-doc.html giftrans converts any GIF file into a GIF89a. Allows for setting the transparent or background color, changing colors, adding or removing comments. Also code to analyze GIF contents. SH: These all work on Linux but only MapIvi has a nice interface. embedded JPEG comments (single and multiple comments are supported): * display * add, edit, copy, join or remove Thanks, David and Stephen. Meanwhile, a gentleman has suggested me pngcrush, which I have tried with significant size reduction of png images, with no loss of quality. Please, have a look at: http://pmt.sourceforge.net/pngcrush/ It is command line oriented and also works on MS Windows. There seems to be a quite recent release also. Paul SH: After nosing around into Netpbm, I looked at ImageMagick: http://www.cit.gu.edu.au/~anthony/graphics/imagick6/formats/ Reading JPEG Images +profile '*' -strip JPEG images as saved by digital cameras, scanning software and other image processing software like photoshop will often add large profiles of program comments to JPEG images. Either of these options will remove those profiles from a image that was read in. Non-ImageMagick JPEG Processing As re-writing a JPEG image results in a degrading of image quality (unless lossless compression is used) the JPEG image library provides a number of special programs that can manipulate the image, without loss of quality. These command will also be generally a lot faster than IM equivalents, as they do not have to do as much processing of the image. Examples of these commands include... read comments: rdjpgcom image.jpg remove comments: wrjpgcom -replace -comment '' image.jpg new_image.jpg remove profiles: jpegtran -copy none image.jpg new_image.jpg - Here is an example of a shell command to convert all your of PNG files (named *.png) to JPEG files named *.jpg: for i in *.png; do pngtopnm $i | ppmtojpeg `basename $i .png`.jpg; done jpegtran Does some of the same transformations as Netpbm is famous for, but does them specifically on JPEG files and does them without loss of information. --- SH: One would imagine that pngcrush would be better specialized to do conversions than using a Netpbm command or some piped commands. Jpeg appears to have the best stripping options. I don't know if converting other image formats to jpeg for stripping is clever. Regards, -- Stephen Topic ontology recapitulates entropic philology.
Re: Subtitles
Rich Shepard wrote: On Wed, 14 Jun 2006, Steve Litt wrote: I know you didn't learn it in Kopka and Daly's Guide to LaTeX, because I read that book cover to cover and there were no more than a few sentences on the use of the \let TeX primative. Steve, Have you read Knuth's TeXbook? Rich The book is available for download at http://www.yunnan.tk/component/option,com_docman/task,cat_view/gid,34/Itemid,78/ -- Stephen Topic ontology recapitulates entropic philology.
Re: OT: Eliminating all pixels around a figure
Paul Smith wrote: On 6/14/06, Stephen Harris [EMAIL PROTECTED] wrote: Thanks, David and Georg. In particular, I am trying to find a tool to work on Linux. Gimp is a Linux application, but maybe there is already a Linux equivalent of StripFile: http://www.nuetools.co.uk/stripfile.html I will ask for it on the Fedora mailing list. Stripfile succeeds mainly by removing embedded comments/text. http://files.linuxforum.com/man/jpegtran.1.php jpegtran also recognizes these switches that control what to do with extra markers, such as comment blocks: -copy none Copy no extra markers from source file. This setting suppresses all comments and other excess baggage present in the source file. -optimize Perform optimization of entropy encoding parameters. -trim Drop non-transformable edge blocks. http://mapivi.sourceforge.net/mapivi.shtml http://rpmfind.net/linux/RPM/suse/9.0/i386/suse/i586/ungifsicle-1.39-34.i586.html http://www.intuitive.com/coolweb/FAQ/giftrans-doc.html giftrans converts any GIF file into a GIF89a. Allows for setting the transparent or background color, changing colors, adding or removing comments. Also code to analyze GIF contents. SH: These all work on Linux but only MapIvi has a nice interface. embedded JPEG comments (single and multiple comments are supported): * display * add, edit, copy, join or remove Thanks, David and Stephen. Meanwhile, a gentleman has suggested me pngcrush, which I have tried with significant size reduction of png images, with no loss of quality. Please, have a look at: http://pmt.sourceforge.net/pngcrush/ It is command line oriented and also works on MS Windows. There seems to be a quite recent release also. Paul SH: After nosing around into Netpbm, I looked at ImageMagick: http://www.cit.gu.edu.au/~anthony/graphics/imagick6/formats/ Reading JPEG Images +profile '*' -strip JPEG images as saved by digital cameras, scanning software and other image processing software like photoshop will often add large profiles of program comments to JPEG images. Either of these options will remove those profiles from a image that was read in. Non-ImageMagick JPEG Processing As re-writing a JPEG image results in a degrading of image quality (unless lossless compression is used) the JPEG image library provides a number of special programs that can manipulate the image, without loss of quality. These command will also be generally a lot faster than IM equivalents, as they do not have to do as much processing of the image. Examples of these commands include... read comments: rdjpgcom image.jpg remove comments: wrjpgcom -replace -comment '' image.jpg new_image.jpg remove profiles: jpegtran -copy none image.jpg new_image.jpg - Here is an example of a shell command to convert all your of PNG files (named *.png) to JPEG files named *.jpg: for i in *.png; do pngtopnm $i | ppmtojpeg `basename $i .png`.jpg; done jpegtran Does some of the same transformations as Netpbm is famous for, but does them specifically on JPEG files and does them without loss of information. --- SH: One would imagine that pngcrush would be better specialized to do conversions than using a Netpbm command or some piped commands. Jpeg appears to have the best stripping options. I don't know if converting other image formats to jpeg for stripping is clever. Regards, -- Stephen Topic ontology recapitulates entropic philology.
Re: Subtitles
Rich Shepard wrote: On Wed, 14 Jun 2006, Steve Litt wrote: I know you didn't learn it in Kopka and Daly's Guide to LaTeX, because I read that book cover to cover and there were no more than a few sentences on the use of the \let TeX primative. Steve, Have you read Knuth's TeXbook? Rich The book is available for download at http://www.yunnan.tk/component/option,com_docman/task,cat_view/gid,34/Itemid,78/ -- Stephen Topic ontology recapitulates entropic philology.
Re: OT: Eliminating all pixels around a figure
Paul Smith wrote: On 6/14/06, Stephen Harris <[EMAIL PROTECTED]> wrote: > Thanks, David and Georg. In particular, I am trying to find a tool to > work on Linux. Gimp is a Linux application, but maybe there is already > a Linux equivalent of StripFile: > > http://www.nuetools.co.uk/stripfile.html > > I will ask for it on the Fedora mailing list. Stripfile succeeds mainly by removing embedded comments/text. http://files.linuxforum.com/man/jpegtran.1.php "jpegtran also recognizes these switches that control what to do with "extra" markers, such as comment blocks: -copy none Copy no extra markers from source file. This setting suppresses all comments and other excess baggage present in the source file. -optimize Perform optimization of entropy encoding parameters. -trim Drop non-transformable edge blocks." http://mapivi.sourceforge.net/mapivi.shtml http://rpmfind.net/linux/RPM/suse/9.0/i386/suse/i586/ungifsicle-1.39-34.i586.html http://www.intuitive.com/coolweb/FAQ/giftrans-doc.html giftrans converts any GIF file into a GIF89a. Allows for setting the transparent or background color, changing colors, adding or removing comments. Also code to analyze GIF contents. SH: These all work on Linux but only MapIvi has a nice interface. embedded JPEG comments (single and multiple comments are supported): * display * add, edit, copy, join or remove Thanks, David and Stephen. Meanwhile, a gentleman has suggested me pngcrush, which I have tried with significant size reduction of png images, with no loss of quality. Please, have a look at: http://pmt.sourceforge.net/pngcrush/ It is command line oriented and also works on MS Windows. There seems to be a quite recent release also. Paul SH: After nosing around into Netpbm, I looked at ImageMagick: http://www.cit.gu.edu.au/~anthony/graphics/imagick6/formats/ Reading JPEG Images +profile '*' -strip "JPEG images as saved by digital cameras, scanning software and other image processing software like "photoshop" will often add large profiles of "program comments" to JPEG images. Either of these options will remove those profiles from a image that was read in. Non-ImageMagick JPEG Processing As re-writing a JPEG image results in a degrading of image quality (unless lossless compression is used) the JPEG image library provides a number of special programs that can manipulate the image, without loss of quality. These command will also be generally a lot faster than IM equivalents, as they do not have to do as much processing of the image. Examples of these commands include... read comments: rdjpgcom image.jpg remove comments: wrjpgcom -replace -comment '' image.jpg > new_image.jpg remove profiles: jpegtran -copy none image.jpg > new_image.jpg - Here is an example of a shell command to convert all your of PNG files (named *.png) to JPEG files named *.jpg: for i in *.png; do pngtopnm $i | ppmtojpeg >`basename $i .png`.jpg; done jpegtran Does some of the same transformations as Netpbm is famous for, but does them specifically on JPEG files and does them without loss of information." --- SH: One would imagine that pngcrush would be better specialized to do conversions than using a Netpbm command or some piped commands. Jpeg appears to have the best stripping options. I don't know if converting other image formats to jpeg for stripping is clever. Regards, -- Stephen Topic ontology recapitulates entropic philology.
Re: Subtitles
Rich Shepard wrote: On Wed, 14 Jun 2006, Steve Litt wrote: I know you didn't learn it in Kopka and Daly's "Guide to LaTeX", because I read that book cover to cover and there were no more than a few sentences on the use of the \let TeX primative. Steve, Have you read Knuth's "TeXbook?" Rich The book is available for download at http://www.yunnan.tk/component/option,com_docman/task,cat_view/gid,34/Itemid,78/ -- Stephen Topic ontology recapitulates entropic philology.
Re: OT: Eliminating all pixels around a figure
Paul Smith wrote: Thanks, David and Georg. In particular, I am trying to find a tool to work on Linux. Gimp is a Linux application, but maybe there is already a Linux equivalent of StripFile: http://www.nuetools.co.uk/stripfile.html I will ask for it on the Fedora mailing list. Paul Stripfile succeeds mainly by removing embedded comments/text. http://files.linuxforum.com/man/jpegtran.1.php jpegtran also recognizes these switches that control what to do with extra markers, such as comment blocks: -copy none Copy no extra markers from source file. This setting suppresses all comments and other excess baggage present in the source file. -optimize Perform optimization of entropy encoding parameters. -trim Drop non-transformable edge blocks. http://mapivi.sourceforge.net/mapivi.shtml http://rpmfind.net/linux/RPM/suse/9.0/i386/suse/i586/ungifsicle-1.39-34.i586.html http://www.intuitive.com/coolweb/FAQ/giftrans-doc.html giftrans converts any GIF file into a GIF89a. Allows for setting the transparent or background color, changing colors, adding or removing comments. Also code to analyze GIF contents. SH: These all work on Linux but only MapIvi has a nice interface. embedded JPEG comments (single and multiple comments are supported): * display * add, edit, copy, join or remove - -- Stephen Topic ontology recapitulates entropic philology.
