Application: LyX
Category: Office
Description: From the publisher's website:
LyX is a document processor that encourages an approach to writing based on the structure of your documents (WYSIWYM) and not simply their appearance (WYSIWYG).
LyX combines the power and flexibility of TeX/LaTeX with the ease of use of a graphical interface. This results in world-class support for creation of mathematical content (via a fully integrated equation editor) and structured documents like academic articles, theses, and books. In addition, staples of scientific authoring such as reference list and index creation come standard. But you can also use LyX to create a letter or a novel or a theatre play or film script. A broad array of ready, well-designed document layouts are built in.
LyX is for people who want their writing to look great, right out of the box. No more endless tinkering with formatting details, “finger painting” font attributes or futzing around with page boundaries. You just write. On screen, LyX looks like any word processor; its printed output — or richly cross-referenced PDF, just as readily produced — looks like nothing else.
LyX is released under a Free Software/Open Source license, runs on Linux/Unix, Windows, and Mac OS X, and is available in several languages.
Download LyX Portable 2.2.2 Dev Test 2 (87.6MB download / 265MB installed (557MB with optional components))
(MD5: d10da176b3fdbc10a2fe1355fdc9c60d)
Note: All releases rely on the following programs:
- MiKTeX for background TeX processing
- Ghostscript Portable
- GSview (optional, but recommended)
- Strawberry Perl (optional, for latexmk)
Optional: LyX Portable allows for users to add other local and portable applications for use inside LyX. For example, if you wanted to specify that SumatraPDF or Foxit Reader is the default PDF reader for previews a user can either go into preferences and specify a path there or they can add them manually under EXTRAS in launcher.ini:
[Environment] EXTRAS=%PAL:PortableAppsDir:ForwardSlash%\SumatraPDFPortable
Thanks to d4winds for this suggestion.
Release Notes:
See all release notes at the SourceForge project page
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
1st of all, Thank you! This is long, long overdue for PA.com. Here are some observations. First,the Launcher\LyXPortable.ini:
[RegistryValueWrite]: ut_files should be ui_files (typo). I am not sure why there would be any need of a registry section at all other than to backup the current one as a precaution, since an installed LyX functions quite well with its registry entries deleted. In that case, one has
[RegistryKeys]
-=HKCU\Software\LyX
Perhaps I'm missing something.
[DirectoriesMove]: I have found that using
CommandLineArguments=-userdir "%PAL:DataDir%\profile" in the [Launch] section works very well, is fully supported by LyX (http://wiki.lyx.org/Windows/PortableInstallation), and avoids potential, though unlikely corruption of installed AppData in case of crash.
[Launch]: DirectoryMoveOK=yes is needed, else PA scolds.
Now for the structure of the Data directory and for the file Data\profile\preferences.
The following entries should be deleted, since otherwise the LyX-provided default versions--which are quite enlightening--are not immediately accessible as the user expects, since the associated Data\profile\ directories are empty.
\example_path "DATADIR/examples"
\template_path "DATADIR/templates"
The entry
\backupdir_path "DATADIR/backup
should also be deleted IMHO since the default action by LyX is to store the auto-backup to a LyX file (ends with ".lyx~") in the same directory as the original LyX file, which is where the user expects to find from the Users Guide in case it is needed for recovery. Tastes and preferences may vary.
Again, thanks.
The registry value that I write was more of a safeguard than anything. Since your testing seems to have shown it is not necessary, I'll just remove the save then.
As for DirectoriesMove, I forgot to add that in, and the commandline arguments make my life a little bit easier (I'll admit I didn't look into it fully before making portable).
The paths that were in there I assumed would be necessary, but that also came from me relying on moving the profile manually, so getting rid of the empty defaults makes sense.
Thank you again for your input, and expect to see a Dev Test 2 arrive soon.
Updated to 2.0.6 Dev Test 2. See release notes for details.
Thanks for the quick response.
Cleanup items: Delete from App\DefaultData the dirs examples, backup, templates, & workingdir;
Enhancement & Reason for it: In Launcher\LyxPortable.init add a section
[Environment]
LyX_Helpers=
path=%LyX_Helpers%;%path%
The user now specifies the helper apps she has on the RHS of the = sign in for LyX_Helpers above (or leaves it as is, ie, empty) to assure portably that LyX will find its helpers in its path when they are required to be there. Eg, to use Sumatrapdf as the pdf viewer and to assure importing of Excel files (not just csv's) and to use Evince as, say, the postscript viewer (no nag screen like gsview), one may use
LyX_Helpers=%PAL:PortableAppsDir%\SumatrapdPortable;%PAL:PortableAppsDir%\GnumericPortable\App\Gnumeric\bin;%PAL:PortableAppsDir%\EvincePortable
One can then, eg, use SumatraPDFPortable in the the LyX menu Tools>Preferences>File Handling>File Formats>PDF (pdflatex)>Viewers.
very big file due in large part to the dirs dicts and thes in App\LyX\Resources; is there any way to cut down the size using online installs for a specified language of the dictionary and thesaurus?
Thanks again for the quick feedback. I forgot about the default folders I had set, so thanks for that catch.
As for the enhancement, I understand the need for that, and I agree that this is a good idea to include. The only catch is that I need to make a special note that this will be wiped between updates, and they will have to make a backup of their setting between installs.
As for the size, I included the full package for the time being. Trust me, I know it's unwieldy, so I will be looking for viable ways of reducing the size in the mean time.
Updated to 2.0.6 Dev Test 3. See release notes for details.
observations/thoughts:
LyX_Helpers: This environment variable in the launcher is not only unwieldy on updates but, on a closer look, may be unnecessary as well. To have, say, SumatrapdfPortable available in the path for LyX, one simply appends to the end of the PATH Prefix box in Lyx's Tools>Preferences>Paths the string (sans quotes) "X:\dir1\dir2\PortableApps\SumatrapdfPortable" and clicks Apply, then Save as usual, where, say, "X:\dir1\dir2\PortableApps" is the drive-dir containing the PA files. Your FileWrites in the launcher will automatically update this LyX path prefix upon drive-dir change and the user will have no need of storing separately the LyX_Helpers (so they're not wiped out by an update to LyXPortable, as you noted) IF: (1) the undocumented variable PAL:LastPortableAppsDirectory in Data\settings\LyXPortableSettings.ini is available to the launcher as an environment variable and IF (2)you add an additional FileWrite to the preferences file to replace %PAL:LastPortableAppsDirectory% with %PAL:PortableAppsDir%. If (1) and (2) are both true, the user has all the benefits of the LyX_Helpers variable with none of the drawbacks.
Size: wrt the new installer allowing for additional languages in the install: Touche! However, the installed size, even for the default language of English, is still high by about 34MB. The culprit seems to the directory App\LyX\Resources\backup, which currently has in it some thesauri (German and Australian English) which would not seem necessary, though I may have missed something.
The LyX_Helpers environment variable adds no extra size to the program, so I will keep it there for power users who want more immediate control over their paths.
All paths in settings should be taken care of properly by the FileWriteNs that I already have in there (though I forgot to take care of PartialPackageDir in "session"), so dealing with LastPortableAppsDirectory as a variable is unneeded.
As for the extra 34MB, I didn't even notice the backup folder had stuff in it. The next release has them removed (since the thesauri in question are already in the correct place in the optional components from what I can tell.
In my example your FileWrites do take care of updating the preferences file generated by DefaultData on initial load for PACROOT but will not take of similar changes on subsequent use. The drive letter, however, will always be portably handled.
E.g., DefaultData\profile preferences has "PACROOT/LyXPortable/App/LyX/bin;....;PACROOT/MiKTeXPortable/App/miktex/bin/....". The user initially installs the PA platform to so that the LyXPortable directory is in the dir Y:\mydir\PortableApps. On first use the line in Data\profile\preferences correctly becomes "Y:/mydir/PortableApps/LyXPortable/App/LyX/bin;....;Y:/mydir/PortableApps/MiKTeXPortable/App/miktex/bin/....". Now the user moves the usb and rearranges very modestly so that the LyXPortable and MikTeXPortable directories are now a sister sub-dirs of X:\dir1\dir2\PortableApps. LyXPortable.exe is executed & preferences Data\profile\preferences now has the line "X:/dir1/dir2/PortableApps/LyXPortable/App/LyX/bin;....;X:/mydir/PortableApps/MiKTeXPortable/App/miktex/bin/....". LyX executes but cannot find MikTeX, since there is no X:\mydir\PortableApps\MiKTeXPortable dir although there is a directory X:\dir1\dir2\PortableApps\MiKTeXPortable.
I have the following:
The first one takes care of everything except the drive letter and the second replaces the drive letter.
Edit: Forget I said anything. FileWrite4 will only take care of LyX specifically which is what you were saying. The easiest fix that I can find is to add:
...which will subsequently be in Dev Test 5. Thanks again.
I cannot test now, will tomorrow ; am on the road with an internet connection that churns & churns just to load this page
Updated to 2.0.6 Dev Test 4. See release notes for details.
Updated to 2.0.6 Dev Test 5. See release notes for details.
Thank you for the quick response.
(1)DefaultData
Replace "PACROOT/MiKTeXPortable/App/miktex/bin/" with "PACROOT/MiKTeXPortable/App/MikTeX/miktex/bin/" in DefaultData\profile\preferences. I missed this one previously by foolishly testing on a box with an installed MikTeX (Duh!).
(2)FileWrites:
A replacement of %LastPortableAppsBaseDir:ForwardSlash% with %PortableAppsBaseDir:ForwardSlash% is helpful but not sufficient; a replacement of %PAL:LastPortableAppsDirectory:ForwardSlash% with %PAL:PortableAppsDir:Forwardslash% must be done as well and should be done prior to the change on PortableAppsBaseDir but following the one on PackagePartialDir. Otherwise, despite the change of (1), LyX will not be able to find MikTeX in a joint move of LyXPortable and MikTeXPortable from, e.g., D:\ to D:\PortableApps. I tested that move and a joint move from D:\ to Q:\TestEnv\PortableApps and all looked OK using the FileWrites below, which are mods to yours using the preceding observatons (as well as avoiding all drive letter replacements until combos involvng them have first been done):
[FileWrite1]
Type=Replace
File=%PAL:DataDir%\profile\preferences
Find=PACROOT
Replace=%PAL:PortableAppsDir:ForwardSlash%
[FileWrite2]
Type=Replace
File=%PAL:DataDir%\profile\session
Find=%PAL:LastDrive%%PAL:LastPackagePartialDir:ForwardSlash%
Replace=%PAL:Drive%%PAL:PackagePartialDir:ForwardSlash%
[FileWrite3]
Type=Replace
File=%PAL:DataDir%\profile\preferences
Find=%PAL:LastDrive%%PAL:LastPackagePartialDir:ForwardSlash%
Replace=%PAL:Drive%%PAL:PackagePartialDir:ForwardSlash%
[FileWrite4]
Type=Replace
File=%PAL:DataDir%\profile\preferences
Find=%PAL:LastPortableAppsDirectory:ForwardSlash%
Replace=%PAL:PortableAppsDir:Forwardslash%
[FileWrite5]
Type=Replace
File=%PAL:DataDir%\profile\preferences
Find=%LastPortableAppsBaseDir:ForwardSlash%
Replace=%PortableAppsBaseDir:ForwardSlash%
[FileWrite6]
Type=Replace
File=%PAL:DataDir%\profile\preferences
Find=%PAL:LastDrive%
Replace=%PAL:Drive%
[FileWrite7]
Type=Replace
File=%PAL:DataDir%\profile\session
Find=%PAL:LastDrive%
Replace=%PAL:Drive%
1) I made the same mistake, so that initial configuration is set correctly now.
2) Your testing seems to be much more thorough than mine, to say the least. I don't often move my apps around from folder to folder, so it rarely comes up in testing (which I should probably deal with more often...). The reordering makes sense, and is going to be in the next update.
Updated to 2.0.6 Dev Test 6. See release notes for details.
Thanks again for the quick response. I tried it out & it looks good. Also tested with RegShot & it looked clean.
Your inclusion of gsview (App\Ghostgum directory) seems like a good idea. Alas, even though Ghostscript\bin is on the path, gsview does not locate the ghostscript dll & complains about it if there is no installed version or it gets hopelessly confused & verbose if there is an installed 64-bit version of ghostscript. So it needs an ini file, which by default is stored in %userprofile%. To rectify, I tested the following mods on an XP box (SP3) with no gsview or LyX installed and on a Win7 box with an installed 64-bit gsview & ghostscript. All went smoothly.
(1)Add to the Launcher\LyXPortable.ini the following lines to the end of the current FileWrites section:
[FileWrite8]
Type=Replace
File=%PAL:DataDir%\gsview32.ini
Find=PACROOT
Replace=%PAL:PortableAppsDir%
[FileWrite9]
Type=Replace
File=%PAL:DataDir%\gsview32.ini
Find=%PAL:LastPortableAppsDirectory%
Replace=%PAL:PortableAppsDir%
[FilesMove]
gsview32.ini=%USERPROFILE%
(2)Add the file gsview32.ini (see below) to the directory App\DefaultData.
(3)To make LyXPortable use gsview out-of-the-box for postscript viewing, add the following line to the preferences file in the DefaultData\profile directory after the line beginning with '\format "text2".....':
\format "ps" "ps" "Postscript" "t" "gsview32 $$o" "" "document,vector,menu=export"
The first few lines for the gsview32.ini file in the directory "App\DefaultData" that I used are below:
[GSview-5.0]
Configured=1
GSversion=910
Version=5.0
GhostscriptDLL=PACROOT\CommonFiles\Ghostscript\bin\gsdll32.dll
GhostscriptEXE=PACROOT\CommonFiles\Ghostscript\bin\gswin32c.exe
GhostscriptInclude=PACROOT\CommonFiles\Ghostscript\lib
GhostscriptOther=
[Options]
Language=en
.............
To get the ini, I did the following: deleted it from %userprofile%, executed gsview32.exe from the App\Ghostgum directory, copied the ini from %userprofile% to App\DefaultData, & edited the latter in the [GSview-5.0] section as appropriate, esp. for the GhostscriptDLL and GhostscriptInclude lines.
the same modifications may be necessary for your inclusion of gsview in TexStudioPlus; they also look like a start on a possible GsViewPortable paf.
Making a portable version of GSview seems like a good idea right around now because I have 2 or 3 applications that all use GSview and as of right now they're just bundled together. If anything, it'll probably be a CommonFiles plugin like Ghostscript itself, so stay tuned. For now, I'll look at your workarounds.
Edit: For the time being, all of the bundled versions are going to get similar updates to their launchers.
gsview should NOT Bea common files plugin, as it is not a library used by other apps, but rather an app itself, with its own GUI, etc.
I've only used gsview in the context of other apps, so I thought it could be a plugin. But since it needs .ini path fixing when used with other apps, I'm keeping it bundled for now if only to make my life easier. I tried moving config files externally before with MiKTeX and it was not fun.
Updated to 2.0.6 Dev Test 7. See release notes for details.
installer enhancement:
for the installer, let the user exercise some selectivity on the additional thesauri & dictionaries; as it stands a non-English speaker (rather, a non-English-only speaker) pays a pretty hefty 150+MB penalty in unused language files just to get spellcheck going in her desired tongue.
launcher:
will test with RegShot later; the pre-gsview-mods RegShot looked clean, as previously noted in another comment; current execution is smooth, works as expected; nice!
Unfortunately, the installer only allows for one optional components section (as far as I'm aware) so I would need to probably do a lot of fancy coding footwork in NSIS in order to make each language its own selection. At this point, the only way is to just have people remove what dictionaries and thesauri that they deem unnecessary by hand.
the catch: the manual deletion would become necessary for the non-English-only speaker with each update
possible solution: install all dicts (the 'dicts' subdir of App\LyX\Resources) & thesauri (the 'thes' subdir) in the Data directory & use a DirectoryMove to their run-time respective locations in App\....just an idea; your thoughts?
nobody, including English-only speakers, ever gets an updated dictionary or thesaurus for LyX with an updated LyXPortable; not good; oh, well; maybe best to leave as is
These are the lines I have inserted into the launcher immediately prior to the 'path=...' line:
;Optional, uncomment lines below per your PA files and needs:
; LyX_Helpers=%LyX_Helpers%;%PAL:PortableAppsDir%\SumatraPDFPortable
; LyX_Helpers=%LyX_Helpers%;%PAL:PortableAppsDir%\FoxitReaderPortable
; LyX_Helpers=%LyX_Helpers%;%PAL:PortableAppsDir%\GnumericPortable\App\Gnumeric\bin
; LyX_Helpers=%LyX_Helpers%;%PAL:PortableAppsDir%\EvincePortable
; LyX_Helpers=%LyX_Helpers%;%PAL:PortableAppsDir%\R-Portable\App\R-Portable\bin\i386
;
; Notes on the LyX_Helpers lines:
; The path for LyX is portably set within the PortableApps context so that
; SumatraPDFPortable can be used as pdf viewer (see Lyx Help>Customization)
; FoxitReaderPortable can be used as pdf viewer (see Lyx Help>Customization)
; Excel spreadsheets (not just csvs) can be imported (unnec. for csvs only);
; EvincePortable can be used as postscript viewer or as pdf viewer
; R can be integrated with LyX using sweave or knitr
None of these lines is strictly necessary. E.g., for Excel table import when PA files are in the drive-dir 'D:\PortableApps', one simply adds (w/o the quotes) "D:\PortableApps\GnumericPortable\App\Gnumeric\bin" to the LyX path prefix from the Tools>Preferences>Paths menu of LyX (then one does a LyX Reconfigure and restart just as with an installed version). LyXPortable automatically takes care of the rest upon change of drive/directory.
I'll put a truncated version of this in a section labeled "Optional" in the main post so that people are aware of their options when dealing with external programs.
she'spic'n'span; details follow
Details
(1)For the Regshot & test (2) of this post, I used an XP (SP3) virtual machine with no installed gsview, ghostscript, miktex, or LyX. Adobe's AcrobatReader was the installed pdf viewer. For the Regshot, the pre- & post shots were taken vis a vis the following action: exec LyxPortable by double clicking it in Windows Explorer (not from the PA menu), open a small LyX file, perform a minor edit w/i LyX, save the edits w/i LyX, export the TeX from LyX, view the pdf and postscript outputs, close LyX. Both LyXPortable and MiKTeXPortable were completely fresh installs from the pafs with no execution of MiKTeXportable prior to that of LyXPortable. Execution was from an admin account. Windows XP was completely up to date but Windows Update and other standard system services, such as indexing, had not been turned off, nor was the installed AV from WebRoot. Summary of the results:
(a)The execution from the admin account and/or the non-suspension of background System-level services resulted in 5 minor HKLM registry mods found: 1 by Win for the Cryptography Seed , 1 by Win for SystemIndex\NotificationLogCheckPoint, & 3 by the AV under HKLM\SOFTWARE\WRData for its update status, etc.
(b)All other adds, deletes, modifies to the registry were to HKU. These were inconsequential & all were necessitated by the mere fact of having exec'd Acrobat & WinExplorer: for Acrobat Reader's RememberedViews, WinExplorer's and/or the shell's common dialogs/Bags MRUs or Cache. No HKCU registry mods were found.
(b)Apart from the expected, purely LyX-related file mods (LyX file that was edited, the LyX backup from auto-saves, tex/pdf/ps/latex-support outputs, & LyX profile in the Data directory)and the inescaple Win file mods directly induced from the LyX activity (Windows Prefetch, Win logs, NTUSER.DAT), there were merely file mods from the Win background (SystemIndex-related), the AV (All Users\Application Data\WRData), and Acrobat(ReaderMessages, SharedDataEvents).
(2)Following the Regshot test, a copy of the (post-Regshot-execution) LyXPortable and MikTeXPortable dirs was made to a subdir of XP's SharedDocuments folder. No mods were made at all. LyXPortable exec'd flawlessly (from the same admin account, again exec'd from WinExplorer & w/ same action set). Ditto for execution from the PA menu.
(3)The post-execution, XP-based, SharedFolders versions of LyXPortable & MikTeXPortable were then copied w/o mod to a USB (under the drive-dir of 'D:\PortableApps')that was then attached to a separate Win 7 box, where smooth execution was again obtained from a non-admin Win 7 Guest account.
Thank you for the very in-depth testing you've been doing on my TeX apps. I hope that eventually at least one of them will be available officially.
LyXPortable looks ready to be listed on the "Ready to Be Released" page to me.
In LyX, the PATH is effectively controlled via the preferences file under \path_prefix. Would it be worthwhile (in the next major release, not creating a Dev Test just for this) to use the PATH corrections seen in Texmaker and TeXstudio? Or would this defeat the purpose of using the configuration file. Personally, it seems like either way works just as well but I would like to hear an opinion outside of my own.
the Asymptote part would have to be deleted since it's not being distributed with LyX [1]; a simple statement in the Environment section of the Launcher such as
path=***path-additions***;%path%
would do the trick;
I think that as general principle standard stuff expected to be available out-of-the-box should be less visible to the user, preferably not even appearing in a dialog box for customizations; but, LyX itself already extensively modifies the path_prefix that is visible to the user in the Tools>Preferences>Paths dialog [2], so visibility there is no great gain from the environment variable approach on that score.
The biggest gain from the env.var. approach is easier [3], more robust maintenance with less potential for unexpected breakdowns from mods by LyX to the distribution down the road.
Note(s):
[1]it could be, I suppose, since any LaTeX can be incorporated into LyX directly (using ctrl+L); but a customized invocation of latex (for compile latex, exec asymptote, recompile latex) would be required & it would have to be incorporated into LyX (additional mods to the distributed preferences file in DefaultData\profile); it's a non-trivial task to research, implement, & test but could be worthwhile down the road.
[2]LyX incorporates into that path_prefix dialog items in the standard LyX Win distribution itself like Python & Imagemagick as well as a host of items its config scripts may have found installed on your system that LyX may find directly useful (like Inkscape for SVG edits).
[3]FYI, I have been using a homemade, PA-style portable LyX for a few months now & created it using the env.var. approach with the path env. var.: simple, effective & leverages the OS.
Personally, it sounds like a tossup as to whether or not PATH in the launcher is worth it then. I'll probably go about testing that at some point to see which feels more robust. LyX Portable has gone through enough Dev Tests for a little while. On that type of side note, though, I'm going to look into Asymptote and GSview as standalone applications so that they can finally be taken out of the packages they're bundled with currently.
tossup: true, tho' the environment variable mod in the launcher has much to commend it (see my Note [3]);
gsview: portable version looks promising based on the LyX work
asymptote: may not be as straight-forward;
On export to HTML or to LyX's 'HTML(Word)' format (the latter format being used to assist with export to MS Word), one gets the error message from Windows [1] to the effect that Windows does not know what to use to open the file 'elyxer.py'. Of course, it shouldn't, since that's a script, not an executable. The obvious remedy of inserting the string python (or python.exe) at the beginning of the converter definition in pereferences (but following the leading '"', of course) does not work; apparently, from examination of the installed version, the fpn for 'elyxer.py' is needed.
The remedy is in the construction of the converters within the preferences file under LyXPortable...DefaultData...The suggested revision below was deduced from an installed LyX (2.06) using the Resources\lyxrc.dist file & has been tested in a sterile XP(SP3) VM environment:
In App\DefaultData\profile\preferences, I suggest
Replacing
\converter "lyx" "html" "elyxer.py --directory $$r $$i $$o" ""
\converter "lyx" "wordhtml" "elyxer.py --html --directory $$r $$i $$o" ""
With
\converter "lyx" "html" "python -tt \"PACROOT/LyXPortable/App/LyX/Python/Lib/elyxer.py\" --directory $$r $$i $$o" ""
\converter "lyx" "wordhtml" "python -tt \"PACROOT/LyXPortable/App/LyX/Python/Lib/elyxer.py\" --html --directory $$r $$i $$o" ""
Note(s):
[1]Execution context for Win error: sterile XP (SP3) version of Windows; in particular, no associations for '.py' or '.pyc' files with an installed [or uninstalled] python; also, the only python on the system is the one in the LyXPortable\App\LyX\Python directory referenced by the LyXPortable path spec.; standard LyXPortable path; in fact, LyXPortable is a fresh install straight out-of-the-box with no mods to anything whatsoever.
Didn't even know that this existed as a feature, I'll be honest. But that quick fix makes sense as to why Python is included in the first place. I'll make sure to add that (or just add the included Python to PATH) to the next major release. Though as the little stuff piles up, it may be high tide to release a new one; I'll see. Thanks again.
re "or just add the included Python to PATH)":
Python is automatically included in LyX along with the path mods for access to its binaries (ditto for ImageMagick); there is no path mod to be made to DT7 for this error; any path mods for enabling **other** areas of LyX functionality are in my LyX_Helpers post.
the fix for the reported error is exclusively to the file DefaultData\profile\preferences, which is faulty as currently shipped;
Updated to 2.0.6 Dev Test 8. See release notes for details.
execution with out-of-the-box DT8, with no GSView, etc. installed, & from w/i a sterile XP_SP3 VM.
w/ DefaultData as shipped and w/ %userprofile%\gsview32.ini, if any from a prior execution, deleted, upon requesting a postscript view by LyX (ctrl+T in LyX), gsview reports that there is no Ghostscript on the computer. It also, creates a faulty gsview32.ini in %userprofile%. That ini has been constructed by gsview32 assuming improperly--despite the Ghostscript binaries on the path--that the Ghostscript binaries are in subdirs of GSViewPortable. No gsview32.ini should be exist post-execution at all, of course.
IMHO, the fix for this behavior is twofold:
(a)In DefaultData\profile\preferences, replace
\format "ps" "ps" "Postscript" "t" "gsview32 $$o" "" "document,vector,menu=export"
with
\format "ps" "ps" "Postscript" "t" "GsViewPortable $$o" "" "document,vector,menu=export"
(b)and delete (sans quotes) ";PACROOT/GSviewPortable/App/gsview" from the path_prefix in DefaultData\profile\preferences.
The second action prevents accidentally invoking gsview32, since such an invocation will necessarily be both non-portable & (if there is no gsview32.ini in %userprofile%) & erroneous.
Other TeX apps which rely, even optionally, on using gsview32.exe rather than gsviewPortable.exe will run afoul of the same non-portable & erroneous call issue as did LyX.
Not sure how I screwed that one up so thoroughly. I could have sworn I replaced everything correctly. Looks like I missed those pretty badly. I did intend on calling the correct portable version, but LyX must have been the one that got away. I'll change that when I can... though I almost want to wait for a LyX update at this point; that number behind the DT is getting a little big...
LyX is configurable for using latexmk as well as TeXStudio, etc.; would suggest adding to the TEX env. var. def. in Launcher\LyxPortable.ini
%PAL:PortableAppsBaseDir:ForwardSlash%/CommonFiles/StrawberryPerl/perl/bin
I'll add support for that too, while I'm at it.
Additionally, I'm going to move everything from the configuration file to the launcher... I'd rather have it up to date all the time instead of when people do a clean install. I don't know if I need the path correction in preferences with that difference, though.
Updated to 2.0.6 Dev Test 9. See release notes for details.
postscript viewing tested in sterile XP-SP3 VM; it works
see my post of October 14, 2013 - 12:09pm "LyXPortable does not convert to HTML--error from Windows" for how DefaultData\profile\preferences should be configured, in part. in the converters section; the basic issue is that 'elyxer.py' (sans quotes) in that spec. will not suffice; one must use the full path name of elyxer.py &, of course, scrupulously observe the syntax conventions w.r.t. quotes, etc.
suggested replacement in "DefaultData\profile\preferences", use the following 2 lines in lieu of the current 2 lines beginning with '\converter...':
\converter "lyx" "html" "python -tt \"APPDIR\LyX\Python\Lib\elyxer.py\" --directory $$r $$i $$o" ""
\converter "lyx" "wordhtml" "python -tt \"APPDIR\LyX\Python\Lib\elyxer.py\" --html --directory $$r $$i $$o" ""
modify current launcher to have FileWrites on Data\profile\preferences to
replace APPDIR with current app dir & to
(b)replace last app dir w/ current app dir
I looked into it and Python/lib is included in PATH (under TEX) so the call should not be failing the way it is. I'll look more into it to be sure... Also, it has to be forward slashes, from what I see, or it will just escape the proceeding letter.
Welp, I found my problem. Like a few other errors, I can't seem to read my own environment variables. I forgot to add "LyX" to the appropriate paths. I'll get the fix out as soon as I can.
please re-read my post; the full path name of elyxer.py (but plain 'python' is fine since it's an executable in the path) must be in the \converter lines within the preference file. Note the punctuation of the replacement '\converter lines' in my post; it was taken from my Win 7 installed version of LyX, from the "App\LyX\Resources\lyxrc.dist" file. (That file is, in effect, the default version of the preference file.)
I did fix the converter lines but at the same time, I realized that it shouldn't be calling anything properly anyway because a couple of the paths were missing correct parts. Either way, it's been tested to work completely now and should be set to go as soon as I can upload.
Updated to 2.0.6 Dev Test 10. See release notes for details.
";%PAL:PortableAppsDir:ForwardSlash%/Asymptote"
should be
";%PAL:PortableAppsDir:ForwardSlash%/AsymptotePortable/App/asy"
(sans quotes) shouldn't it?
I sure hope not... LyX should be calling "AymptotePortable.exe" and not "asy.exe" unless I really screwed that option up too. Asymptote by itself leaves traces behind so I don't want LyX to use it, just the portable version. Now I'll look through to see if I actually put the right thing in the preferences...
Oh good, it's not even referenced anywhere by default. That makes me feel a little better that it isn't being misused.
";%PAL:PortableAppsDir:ForwardSlash%/AsymptotePortable"
?
Yes, yes it should. Pretend the current dev test 10 was a mistake and I'll update this in a minute saying it uploaded...
sterile XP-SP3 VM environment:
tests on
viewing postscript with GsView,
generating HTML, HTML(Word), LyXHTML formats,
generating/reading pdf (of course)
all worked very well; will test further & apprise if see any issues;
good show;
It was absolutely perfect the first time around, no doubt about it. But redownload just in case there might have been something wrong... nope, no path problems here.
performed same functionality tests (GSView, HTML exports, etc);
all exec'd well without issues;
path looks good;
all is well
Good to hear that everything is finally working properly. Once 2.0.7 comes out, I can start the Dev Test renumbering and I won't feel as weird with a "Dev Test 10" in my repertoire.
version 2.07 has been released
I'll be updating it as soon as I can. I have the time but my connection is less than stellar.
Updated to 2.0.7 Dev Test 1. See release notes for details.
thanks
2.1.0 binaries are up at ftp://ftp.lyx.org/pub/lyx/bin/2.1.0/, although yet to be announced officially. Would be great to have your paf updated. Thanks.
Thank you for the update. I've been very busy with end-of-semester work and a Master's project, so my update time will probably lag on this (and everything else I package).
Understood. Good luck.
Wow!!!
This is great!
When the final version is expected?
I'm not sure what you mean by a "final version", to be honest. If you mean when this is released officially, then I have no idea since that's up to John, ultimately. If you mean the last version of LyX Portable, then either when LyX stops development or I pass the torch to someone else. (Okay, so I'm being a bit of a smart-alec with that last part).
from "http://www.lyx.org/News#item1", dated April 25, 2014:
"We are pleased to announce the release of LyX 2.1.0."
This is a major upgrade. See the above-referenced news item and links therein for new enhancements available in 2.1.
The binary for the Windows installer (non-Bundle version, i.e., verion not including MikTeX) is located in the ftp directory
ftp://ftp.lyx.org/pub/lyx/bin/2.1.0/
and the file is:
ftp://ftp.lyx.org/pub/lyx/bin/2.1.0/LyX-2.1.0-Installer-2.exe
Updated to 2.1.0 Dev Test 1 (finally). See release notes for details. Note that this release is over 100 MB bigger than the previous release with optional components.
this thank you is long over-due, but better late than never.
LyX is a great addition to Portable Apps. It adds capabilities for long and structured documents and technical documents that Microsoft Office doesn't have and is obtainable only with expensive software.
I'd like to install it, so I'd like to make sure I have the sequence correct.
Install in the following order:
1. MiKTeX for background TeX processing
2. Ghostscript Portable
3. GSview (optional, but recommended)
4. Strawberry Perl (optional, for latexmk)
5. Foxit Reader for PDF
6. Then install LyX portable
Will that provide a working installation. Also, is there an initial configuration needed for Windows 7 Pro?
Thanks again.
Jojo
GhostscriptPortable is in installed in the CommonFiles sub-directory of the PortableApps directory if you havei installed the PA platform, so another installation is not nec.
GSView and GhostscriptPortable are needed only if you prefer to view the Postscript output. If you always view the pdf output, then they are not nec.
Most Windows installations have Adobe Acrobat installed as a pdf viewer, so Foxit may not be strictly nec. Alternatives to Acrobat (and to Foxit) are SumatraPdf and Evince, for both of which portable versions may be found on the PA "Get Apps" page in addition to version for Foxit. A distinct disadvantaqe of using pre-installed Adobe Acrobat is that with each re-execution from LyX of the pdf generation Adobe opens up yet another window. This can get annoying. You mayt wish to check your pdf viewer's documentation--e.g., Foxit--to see how to set it so that it will re-use the same window when the pdf changes. Command-line parameters to the pdf viewer for such re-use (and other paramterizations) can be set within LyX->Tools->Preferences->File Handling. See the LyX Customization Help manual.
Updated to 2.1.1 Dev Test 1. See release notes for details.
"Error converting to loadable format" when display graphics in LyX on figures in PDF, emf, jpg etc. Only works with native format ppm and png. Seems converter issue, the "cache" directory in "profile" is empty.
Works for local install with default userdir in .....\AppData\Roaming\LyX2.1.
I am lost after fiddling without success with path and Launcher.ini settings. Did it work for you? Help much appreciated, perhaps from d4winds also.
I'll have to do a comparison of the local installation folder to the user directory in the portable version to see if there's a difference. Thank you for telling me there's a problem though. I apologize in advance that this may not be fixed for a little while.
Looking forward, hopefully not too long the wait.
btw, when starting a new userdir for the first time with local install , the process is rather long due to the checking of tex setup and others. In contrast the process of setting up a new profile in paf (at %PAL:DataDir%\profile) is much quicker. Can't see why the paf launcher should make any difference, but looks like something has gone amiss in the initialisation of userdir.
the Win installer (to Program Files (x86), e.g.) automatically invokes the LyX Reconfigure before loading LyX. The paf installer does not. Reconfigure thoroughly checks your TeX distribution for required binaries and packages; it also checks installed applications on you OS for potential helper apps. Reconfigure can take quite a while.
I saw the same apparent bug in PA version. pdf graphics would display "Error converting to loadable format" within LyX but if they were converted to postscript, the ps versions would load fine (postscript is the LaTeX native). I ran WinMerge to compare PA vs. installed [1] and was coming up empty in terms of differences. To guarantee no differences, I ran Reconfigure on both PA and installed. Still came up empty. But, lo and behold! Now, the PA version was properly displaying with no errors or messages the **pdf** versions of the graphics. Try Reconfigure out and let us us know the result. I sure hope it works because, as I said, I've been coming up empty on differences.
Note(s):
[1]LyXPortable\App\Lyx vs. C:\Program Files (x86)\LyX 2.1 for binaries and LyXPortable\Data\profile vs. %AppData%\LyX2.1 for lyxrc.defaults. Both PA and installed versions used the same PA\CommonFiles\MikTex.
"We strongly encourage all LyX users to upgrade to this version."
Hi d4winds:
I've seen LyX 2.14 downloads and have, in fact downloaded it. If I want to install LyX portable the files description says we need to have Mikex, Ghostscript and Ghostview, and Strawberry Perl (optional). So my question is what sequence to install these packages and which location to use to get a working portable Lyx?
In other words, my guess is that you install Miktex, Ghostscript and Ghostview to common and Lyx to its own portable app folder. Do I have this right, and if not, any advice as to how to install would be appreciated.
Thanks
Jojo
My windows 10 say this package is a virus.
Can it be updated?
Is there any update on this?
Something fully portable?
Thank You.
Anyone?
As I mentioned on one of my other projects, because of a lot of things that have happened in the past couple of years, I have been unable to devote any time or effort to maintaining my previous collection of Portable Apps. I have been encouraging people to pick up their favorite projects and package them themselves since there is not a very high chance that I will be able to return to packaging the way I was. Thank you for understanding.
I wish someone could takeover this.
A portable working version of LyX (And all required packages) would be amazing.
Pages