Application: TeXstudio
Category: Office
Description: From the publisher's website:
TeXstudio is an integrated environment for writing LaTeX documents. Our goal is to make writing LaTeX as easy and comfortable as possible. Therefore TeXstudio has numerous features like syntax-highlighting, integrated viewer, reference checking and various assistants. For more details see the features.
TeXstudio is open source and is available for all major operating systems.
Download TeXstudio Portable 2.11.2 Dev Test 2 (29.1MB download / 120MB installed)
(MD5: f36e51c63977f9265c1dae8caf9d5ef1)
Note: All releases rely on the following programs:
- MiKTeX for background TeX processing
- Ghostscript Portable
- Asymptote (optional, but recommended)
- GSview (optional, but recommended)
- Strawberry Perl (optional, for latexmk)
User Note: For users that will rely on the built-in Asymptote PDF and Asymptote DVI Toolchains, you will have to run the chain twice or run the components separately in order for a document to be created properly. The reason behind this is currently unknown and may be an artifact of the program itself. It is also highly recommended that Data\texstudio\texstudio.ini be replaced with the most recent version found in App\DefaultData\texstudio\texstudio.ini because of recent structural updates to the file.
Release Notes:
See all release notes at the SourceForge project page.
Updated to 2.6.0 Dev Test 1.
Updated to 2.6.2 Dev Test 1
In the first run it shows up. When I run again, does not shows at all. Not even the splash screen.
I thought that was because added a dictionary for spanish. Reinstalled but the experience repeated.
I have no way of being sure what happen, because I did not tried yet to configure.
Using Windows 7 starter, SP1.
I tried using a clean install version of the app but no problems arose. Can you link me to the dictionary that you added? I would like to see if that broke it.
Edit: Do you have MiKTeX Portable and Ghostscript Portable as well? TeXstudio relies on those for complete use, so see if their concurrent installation will help.
I encountered the same problem as well. The disappearance of the main windows happens when changes (such as unmaximizing windows) are made to texstudio.ini and copied to the Data directory on closing. It could very well related to a bug of Texstudio itself. To recover the main window, one has to copy the default .ini to the Data or the App/TexStudio directory.
There is a separate issue with the profile move of MikTex portable. Without MikTex portable running, compilation from TexStudio does not work due to an error of "pdflatex.exe: The memory dump file could not be found. pdflatex.exe: Data: pdflatex.fmt". Could you make the Texstudio launcher to start MikTex Portable automatically if it is not yet running?
I'll see what I can do about MiKTeX; I'll be the first to admit that I know very little about NSIS scripting, so I'll poke around for a solution. As far as I know, MiKTeX doesn't actually have to be running, but I think the way the settings are stored in the portable version makes it necessary by proxy.
True, perhaps the scripts for moving configs in MikTexPortable could do the trick here.
btw, the registry entries of Qt are left but can be removed by adding it to TeXstudioPlusPortable.ini.
Darksabre,
I wish to recall that MikTeX can be installed on the harddrive, and Portable MikTeX shall be able to run without interference with the installed version. Thats happened with LyX and the previous MikTeX installation I used.
MikTeX and its auxiliary programs could be invoked at the moment the compilation is needed. After all, they are CLI programs.
TeXstudio is an example. It runs well.
An useful feature of your implementation is the inclusion of Asymptote and Ghostgum. I have not used yet Asymptote, because I found it dificult to use. Ghostgum is similar. Is dificult to invoque too, because being a portable application is not recorded with the application's path (%PATH%) and can't be called without the mechanisms that facilitate the portableapps platform.
You could easily add Sumatra too, as an external viewer for pdf. I use it in that way with PortableFirefox.
I received a mail from sourcefourge, informing that TeXstudioPlusPortable_2.6.2_Dev_Test_2_English.paf.exe was available. I downloaded an installed over the previous TeXstudio Plus Portable.
The problem of not showing the interface, persists. For a moment, I thought that is something related with the way I use the application.
I have a mirror copy of my usb contents on disk. The usb contents is copied to C:\USB16\. When working in my machine I ran the applicaton with the PortableApps platform from that directory. Later, I synchronize C:\USB16\ with the pen drive when I need to use it in a different machine and also for backup purposes. I allways backup at least once in a month to an external hard disk. That way I can recover at least, the data and the program that works with it.
When the application work from the hard drive, the path is increased by the name of the directory containing the USB files. I have observed that sometimes that causes problems, particularly when a database is involved, because the path is recorded inside the database and don't change when the usb is used with another drive letter.
For this reason, I used 7z to compress the data directory of TeXstudioPlusPortable and the last temporary directory that was left on
C:\Users\usuario\AppData\Local\Temp.
I left the compressed file as public shared on
https://docs.google.com/file/d/0B4L8h2bs1p1BM3RxeEYzdFhUM1E/edit?usp=sha...
To see the contents of the files that were modified by TeXstudio Plus Portable.
I have ghostscript portable; I have MikTeX, but installed by PortableLyx.
The dictionary in use is: es_NI (spanish for Nicaragua), that I have in use with TeXstudio. I copied es_NI.aff, es_NI.dic, hyph_es_NI, th_es_NI_v2.dat, all dictionaries from OpenOffice/LibreOffice.
The link is: http://extensions.libreoffice.org/extension-center/spanish-dictionaries/...
I have this dictionaries in use with LibreOffice, too.
MiKTeX Portable has been updated to address the external usability issues brought up on this page and on the MiKTeX page.
Updated to 2.6.2 Dev Test 4. See release notes for details.
(1)gsview executable is gsview32.exe:
Tools\Commands\view-ps=\"App/Ghostgum/gsview/gvwgs32.exe\" %.ps
perhaps should be replaced with
Tools\Commands\view-ps=\"App/Ghostgum/gsview/gsview32.exe\" %.ps
(2)external pdf reader assumes PortableApps directory is in root:
Tools\Commands\view-pdf-external=\"/PortableApps/FoxitReaderPortable/FoxitReaderPortable.exe\" %.pdf
perhaps should be replaced with
Tools\Commands\view-pdf-external=\"../FoxitReaderPortable/FoxitReaderPortable.exe\" %.pdf
I'm actually in the process of testing out Dev Test 5 which would add the external PDF readers and browsers via PATH. If TeXstudio works the same way as TeXmaker in any way, then the configuration files will be much simpler.
Updated to 2.6.2 Dev Test 5. See release notes for details. (This is an almost complete overhaul of the way configuration files and external programs are handled. It also allows for either version of MiKTeX portable or a local version to be used.)
the link to DT5 points to CopyPath; looked in your directory under TexStudio DT's & only found DT4 & earlier; did I miss something?
It didn't upload properly for some reason. I'm going to fix that now.
Update: SourceForge is giving me all sorts of problems right now. It seems to refuse to mirror the Dev Test 5 no matter how it is uploaded. Sorry for the delay.
Update 2: So apparently it was an actual problem at SourceForge that has now been fixed. Have at it.
laudatory to include portable browser versions [1] but I missed where TeXStudio can be configured for the choice of browser to display its Help; absent same, the system default browser will be automatically used for the Help display unless, say, Expresso is running w/ html extensions linked to the portable browser of choice, in which case the path addition for browsers is still unnecessary;
Note(s):
[1]plug, rant: esp. nice to include Opera, my long time fave; it's a pity they're rebuilding it w/ chromium, because the latter--at least its Chrome variant--chews up mega resources with new tabs; (Firefox is unbeatable in extensions [Zotero, privacy/security extensions] but still slow for my taste & setup of its sync'ing is unfathomable);
I have no clue where the browser is set within TeXstudio, but I saw the option in the configuration file, so I figured that forward thinking is the best thinking.
(1)nice planning for the unexpected/undocumented;
(2)re "...overhaul of the way configuration files...are handled.":
I like the env. var. approach; have beeen using it myself for some time, as my LyX comments may have indicated;
the only drawback I have seen is the user may alter some program calls in dialog boxes using absolute path names for the prog locations on the usb at the current time; in that case, the FileWrites are still needed on update; the env. var. approach remains robust & dynamic IF
(a)either the FileWrites are retained for insurance against such user behavior--not completely the case in DT5, I think, for Data\texstudio\texstudio.ini--
(b)or the user is apprised--and heeds warnings--not to indulge in it.
In DT5 the (2)(b) issue ("user... heeds warnings"--yeah, sure) is very much mititgated since the file names for executables from the path revisions appearing in the dialog boxes (like latex, dvips, asy, etc) are very simple, so if the user mods them, she knows she's throwing sand in the gears. So no mods to DT5 for FileWrites (insurance of (1)) looks required or even necessarily desirable here.
(3)as a matter of principle, the must-see items on the path, like MikTeX binaries, should come first, so that they get precedence in the case of unanticipated name collisions; for that reason, my suggestion would be to move the MikTeX binaries potential locations (MikTeXPortable\App...;CommonFiles\...)to the beginning of the TEX env. var. in the launcher. As is, no mod looks required (execs well as is), this is just a safety measure.
I know, there are no programs internal to TeXstudio (or any of the other TeX programs I'm packaging for that matter) that would interfere with MiKTeX binaries. I also believe that's intentional on the parts of the original devs who made it to work with a backend, not as a standalone product. The order can be changed, but that would occur if there is another critical update and not before. As for the settings, that's also something I'm going to relegate to a later update as non-essential, because I do mention it in the README (if I can remember my documentation correctly). In any case, if someone messes it up royally, they can reinstall the package and be A-OK until there's an easier method.
Updated to 2.6.2 Dev Test 6. See release notes for details.
Updated to 2.6.4 Dev Test 1. See release notes for details.
For me the internal viewer doesnt work. I installed Texstudio (2.6.4 Dev Test1), MikTex and Ghostscript (latest versions, and GSView (5 DevTest1) on Win 7. Anything else you need to know?
Other than that one big THANK YOU for you!
"What about Love?" - "Overrated. Biochemically no different than eating large quantities of chocolate." - Al Pacino in The Devils Advocate
Do any particular errors show up when you try to open the viewer? it seems like you have everything installed that you need to, so I'm not sure how to test this quite yet.
upon fresh install out-of-the-box & the loading of a TeX file, the internal viewer comes up in a separate window but the left edge of that window is located to the far right of the screen, making the viewer barely visible; can center it w/ mouse or embed it by clicking on one of the toolbar icons to get a split screen effect; at least that's the way it's working for me;
I was wondering why I had 2 icons in my toolbar but only one window...Now its there.
"What about Love?" - "Overrated. Biochemically no different than eating large quantities of chocolate." - Al Pacino in The Devils Advocate
I'm not sure where in the settings that is set (all other settings not having to do with paths were direct from the USB version) but I'm glad you figured out the problem.
(1)off-hand I think the following may be typo propagations (that may also occur in other TeX apps--haven't checked):
shouldn't
";%PAL:PortableAppsDir:ForwardSlash%/Asymptote"
be
";%PAL:PortableAppsDir:ForwardSlash%/AsymptotePortable"
?
And,
shouldn't
";%PAL:PortableAppsBaseDir:ForwardSlash%/CommonFiles/StrawberryPerl"
be
";%PAL:PortableAppsBaseDir:ForwardSlash%/CommonFiles/StrawberryPerl/perl/bin"
?
(2)The occurrences of %PAL:PortableAppsBaseDir:ForwardSlash% in defining env. vars. (that are in turn used to defne the path) looks like a typo; shouldn't it be %PAL:PortableAppsDir:ForwardSlash% w/o the 'Base' portion?
I just can't read sometimes... I'll take a look at this and the other TeX apps and see how badly I screwed these up. Look for updates in the near future.
even after the path mod of (1) in the prior comment, shouldn't 'asy' be changed to 'AsymptotePortable' in DefaultData\texstudio\texstudio.ini lines like the following:
"Tools\Commands\asy-dvi-chain=txs:///latex | txs:///asy | txs:///latex | txs:///view-dvi"
and
"Tools\Commands\asy-pdf-chain=txs:///pdflatex | txs:///asy | txs:///pdflatex | txs:///vi"
?
I can gladly say those don't get changed. The "txs:///" prefix denotes that it uses the setting that equates to that file type (from what I've read elsewhere) so it shouldn't have to be changed. If I'm wrong, then I'll fix it though.
'txs:///': learn something everyday
Updated to 2.6.4 Dev Test 2. See release notes for details.
Updated to 2.6.6 Dev Test 1. See release notes for details.
exec'd out-of-the-box TexStudioPlusPortable using CommonFiles plugin for MikTeX on a small test ".tex" file; default Build&View (pdflatex, internal pdf viewer) exec'd; close TSPortable; now there is a 0 kb file named "Music" in the TexStudioPlusPortable directory.
fyi, in prior versions of miktex (think it was the MiktexPortable one, not the CF plugin; but can't swear by it one way or the other) I had seen something similar in the MiktexPortable dir (or the CommonFiles\Miktex dir, whichever).
It's a weird thing that happens with some of the applications I create using the Launcher Generator. I have no clue why it's there, but it appears to be without size so I kind of ignore it. Never felt it was important enough to ask on the Development forum about.
it looks like Texmaker is not the only software with some quirks; the "Music" file does not 'officially' affect portability, I guess, since it's in the main Appname folder but it does make any user who sees it--it's hard to miss if exec is from Win Explorer--wonder what she may be doing wrong or what else might be messed up. No, not a biggie for Devs, just a big 'Huh?' for users.
hence the DVI>PS>PDF Build chain does not work either; both simply stall with no start of the latex; in the Options>Configure...>Commands, I replaced
the current setting in the dialog box for the "Latex" command with this:
latex -interaction=nonstopmode %.tex
All subsequently worked well. In the DefaultData\texstudio\texstudio.ini file this means using the following (from an installed version of TS)
Tools\Commands\latex="latex -interaction=nonstopmode %.tex"
instead of the current
Tools\Commands\latex="\"latex.exe\" -src interaction=nonstopmode %.tex"
I don't think I ever touched that particular command, but that's an easy fix to accomplish. I wonder why it had the original one...
The rest of the Tools\Commands\ are the same way with the escaped double quotes. I didn't notice a problem with either pdflatex or xelatex before. I'll check an untouched config file from the most recent version to see if this needs to be changed for all of them.
but I going to test the GsviewPortable call, so needed the postscript but couldn't produce it; oddly the TS latexmk command , which calls latex directly but which does Not go thru the TS latex command, did work
I am looking at the Options>Configure Texstudio...>Commands diaglog box and at the manual; Note that the treatment of quotes ('"') is different from in the ".ini" file; in the .ini file, a '"' of the dialog box box gets escaped to appear as '\"'.
These observations are from the Dialog Box from a fresh install of TS version 2.66 & the manual's (partial) picture of the Dialog Box (not all commands are shown):
manual's picture for "Latex" command in Dialog Box:
latex -src -interaction=nonstopmode %.tex
installed "Latex" command in Dialog Box (my suggested 'fix'):
latex -interaction=nonstopmode %.tex
The double quotes ('"') are missing in each, but the '-src' that is missing from the installed version is in the manual's picture of the Dialog Box.
For all other commands, the double quote ('"') around the leading executable name in the command definition of the Dialog Box never shows in the picture from the manual or in the installed version for any command that is in the system path, which includes the Miktex binaries and the Asymptote ones;
the double quotes should be a red herring but who knows?
Asymptote's
I used the following in the Dialog Box the and it worked:
latex -src -interaction=nonstopmode %.tex
only diff between this and the out-of-the-box (OOTB) version of TSPortable is that the OOTB version surrounds the 'latex' part with double quotes ('"');
go figure!
I'll try the -src addition. Maybe that's causing issues on my end.
And the typos strike once again. It turns out that the out-of-box command is actually "\"latex.exe\" -src interaction=nonstopmode %.tex" which is missing the dash in front of "interaction". That's what's causing the issue, not the double quotes, which were, in fact, a red herring. Thank goodness it's an easy fix, and one that I must have somehow screwed up along the way.
a missing '-'; wow; such a small error, so much grief
I think I'll blame the "Typo Gremlin" from now on... it seems appropriate. At least I caught it early this time.
When I tested on my portable version from my flash drive, I ran it both with the change and without the change. latex.exe ran both times but it froze completely on each run and had to be manually terminated. I then installed the portable version into a separate folder on my flash drive and tried it both ways and again froze completely. I think something might be up with my flash drive so I installed all of the components freshly in a folder on my computer and ran them as well in both configurations... and it froze on both as well. I have no idea why it's not working.
Just for comparison, I ran an installed version on my computer both ways and it worked in both.
So... I'm not certain if that fix will work, let alone why it won't work in any of my tests. I'll look into it further before releasing the fix.
I got this only without the suggested fix; now your experiences are baffling; was pdflatex (default out-of-the-box Build) working OK in the situations where it froze both ways?
I usually use XeLaTeX and PDFLaTeX when I'm working with my documents, hence I never saw any of the issues with stock LaTeX.
context:
am reporting an oddity for TSPortable confirmed on
sterile XP-SP3 VM (Admin) and on
quasi-clean [1] Win 7 Pro (Admin);
in TSPortable I set the the Options>Configure Texstudio...>Build>Build&View to "Asymptote PDF Chain", loaded "latexusage.tex", & clicked the double-arrow on the Toolbar.
the Fail:
A pdf was produced but it had No figures; the dir containing the ".tex" file is exactly what would be produced by exec'ing only the PDFLatex Build Chain; it had the 3 ".asy" files but none of their ".tex" counterparts, e.g.
Fail NOT due to default Build&View actually in effect:
This Fail was Not because, say, the Build&View selection did not "take" & the default PDFLatex Build Chain was used; the Fail was retested by selecting the "Asymptote PDF Chain" for Build&View, closing TSPortable, re-opening & checking the Build&View to confirm tht "Asymptote PDF Chain" was selected; it was; the double-arrow was again clicked to re-test, again leading to the same Fail.
the Success: next I cleaned the .tex file's dir of all but that file itself, went back to TSPortable (never closed) & exec'd in sequence from the Tools>Commands menu the following commands, which ARE the commands of the "Asymptote PDF" Build Chain: PDFLatex, Asymptote, PDFLatex, View PDF.
Final output was complete and correct in all particulars, with all intermediate ".tex" files and ".pdf"'s corresponding to each of the 3 figures appearing in the ".tex" file directory.
on Installed TS:
to check the "Asymptote PDF" Build Chain itself: performed same procedure identically for using the "Asymptote PDF Chain" on installed, otherwise-unmodified TS 2.6.6; complete success of the chain; the installed TS was on a 3rd "filthy" box, Win 7 Home (Admin), with everything installed (TS, Miktex, & Asymptote, in part., + everything else under the sun);
No obvious texstudio.ini errors:
I found no obvious errors in texstudio.ini by the way. In part., I copied the followng "Tools\Commands\..." specs. from the installed texstudio.ini into TSPortable's in Data\texstudio\texstudio.ini: Tools\Commands\asy-pdf-chain, Tools\Commands\asy, & Tools\Commands\pdflatex, where 'AsymptotePortable' was substituted for 'asy' on the RHS of the '=' in the Tools\Commands\asy spec., of course. I got the same TSPortable Fail for the "Asymptote PDF" Build Chain.
Are you seeing this oddity?
Note(s):
[1]"quasi-clean": no installations for the software under immediate investigation or its direct, known dependencies, though there may be (in fact, there are) plenty of other installations; in this case, "quasi-clean" means no installations of any of TexStudio, MikTeX, or Asymptote; only Portable (.paf) versions of the software & its direct, known dependencies are used.
On first run of the portable version after changing it over to Asymptote PDF toolchain, it ran pdflatex.exe three times in succession according to the log. I ran it again and it outputted exactly what it should have. It also worked when I ran the components individually. This pattern happens every time the folder is cleared of intermediate files, so I'm not sure why it just runs pdflatex.exe three times without even a call to txs:///asy. I have also tried an edited version of the same toolchain using xelatex.exe instead (since that is my preferred compiler) and it behaved identically. The changes were done by checking "Show Advanced Options" and editing the appropriate toolchain. Once again, the individual parts of the run behave just fine.
Strangely enough it didn't work at all when I used an installed version, but Asymptote behaves strangely when running from Program Files (x86) so I don't take it as an omen.
I also just tried the Asymptote DVI toolchain and it worked first time with all auxiliary files cleared out. This might be a peculiarity in TeXstudio, which is rather annoying...
exec on sterile XP...: from a clean dir (only ".tex" file in it) need 2 execs of "Asymptote PDF" Build Chain from TSPortable; then it works fine
as noted in my post, "Asymptote PDF" Build Chain works beautifully here at 1st go--no need of 2 execs--on the "installed-everything" box (Win 7: TS+Asy.+Miktex+much other stuff installed;
very odd situation; I have no explanations; guess it must be just racked up to a TS quirk, as you noted;
might be worth adding a note to user
Seeing as how it worked on the second shot, I tried "doubling the chain". That is, I copy-pasted the commands in the toolchain twice to see if letting pdflatex.exe run through the first time around then it'd be fine. Turns out I was wrong,
but I did notice something that could be screwing things up but I'm not sure how to fix it. From things I've read online, the commandline switch "-interaction=nonstopmode" may have something to do why the toolchain reacts improperly. This is by far not a definite reason, but it very well could be messing things up.Yeah, removing that option did nothing. Forget I mentioned it.adjusted AsymptotePortable launcher's settings to set HideCommanLineWindow=true instead of the out-of-the-box setting of '...=false', since that setting gave clean Asymptote command for TexMaker & it is a very close relative of TexStudio; no change; same TexStudioPortable results on the "AsymptotePortable PDF" Build Chain; "quirk" may be the only explanation, esp. since installed TS "AsymptotePortable PDF" Build Chain worked fine w/o need of double exec.; assuming so, a heads-up to user may be in order; I'm not pursuing this one to the end of the earth; it's just too flaky & the 'fix' of exec'ing twice is too simple
discovered this one in a "what the heck, give 'er a whirl" test; this result is contrary to your previously-reported experience, I think; context is sterile XP-SP3 VM (Admin). A note to User may be appropriate.
Seems like TeXstudio doesn't like to play nice with Asymptote for anything, eh? I'll tack it on underneath the other warning.
am getting from Regshot modifications of the key
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine\Extension-List\{00000000-0000-0000-0000-000000000000}\StartTimeLo
also of similar keys ...\StartTimeHi, ...\EndTimeLo, & ...\EndTimeHi;
google has been a bust so far; any ideas about what these mean?
context:
sterile XP Professional-SP3 VM under Admin account; AV On; Indexing Off; all exec's from Win Explorer;
Procedure:
out-of-the-box-installs of AsymptotePortable, GsviewPortable, TexStudioPortable;
1st Regshot;
loaded ".tex" file ("latexusage.tex" from AOPS) in TSPortable;
exec'd different Asymptote Build Chains, wiping ".tex" file's dir clean of all but ".tex" file itself and then emptied Recycle Bin after each build;
closed file;
loaded new non-Asymptote, ".tex" file;
exec'd default Build Chain (PDFLtex+View PDF);
wiped this .tex file's slate clean as had w/ first;
exec'd from Tools>Commands in sequence Latexmk; DVI>PS; View PS; PS>PDF; View PDF;
closed 2nd ".tex" file;
closed TSPortable;
2nd Regshot;
I say ignore them. A quick search revealed that other programs leave those "group policy"-entries behind as well and it doesnt matter. The registry branch in question ( HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\ ) can be ignored completely I think as several programs can use it simultaneously and therefore it would be too much of a hassle / impossible to deal with.
"What about Love?" - "Overrated. Biochemically no different than eating large quantities of chocolate." - Al Pacino in The Devils Advocate
Suggestion: replace
Tools\Commands\dvipdf=\"dvipdf\" %.dvi
in DefaultData\texstudio\texstudio.ini
with
Tools\Dvipdf=dvipdfm %.dvi
There is no dvipdf in MikTeX\miktex\bin but there is dvipdfm. Replacement suggestion found on StackExchange (did not keep track of URL; sorry about that), where it was noted that more recent changes in MikTeX necessitated TS change for the DVIPDF command. Suggestion confirmed from new install of TS 2.6.6's %AppData%\Texstudio\texstudio.ini
Nice and simple fix to that, thank goodness. Only problem with these changes to the preference file are that they're only caught on new installs. Also, random question since you've tested it: does it still work with \"dvipdfm\" or just with the command as written. Doesn't make much of a difference but I'm a bit of a traditionalist with these commands as in I prefer the smallest change necessary for a correct conversion.
context: MikTeX fully updated, sterile XP-SP3 VM; DVI->PDF Chain for Build
do get, however, this in the TSPortable Messages window:
** WARNING ** Couldn't open font map file "kanjix.map". equations.dvi -> equations.pdf....
followed by a cascaded ton of other warnings; final pdf output looks good, tho'--when using dvipdfm
I was actually referring to the quotes and not the dvipdf -> dvipdfm. I figured that if the new command is preferred there's a reason.
the quotes look like they could throw off the parser; probably a red herring; in any instance, tested with No quotes; also Installed TS 2.6.6 has No quotes.
In TSPortable vs. TSInstalled testing I noted a behavioral difference on the Latexmk command; in TSportable, per the log and the ".tex" file dir,
latex is called to produce dvi output; on TSInstalled (new install of 2.6.6 on Win 7), latexmk (again per the log with ".tex" file confirmation) calls pdflatex to produce pdf output.
In DefaultData\texstudio\texstudio.ini of TSPortable, there is this line:
Tools\Commands\latexmk="latexmk -dvi -silent -latex=\"latex -src %%O %%S\" %"
In Installed TS in %AppData%\Texstudio\texstudio.ini, there is, by contrast, this line:
Tools\Latexmk="latexmk -e \"$pdflatex=q/pdflatex -synctex=1 -interaction=nonstopmode/\" -pdf %.tex"
My personal preference would be for the pdf (InstalledTS version) rather than for the DVI (of current TSPortable), esp. since a non-default YAP config. is needed to properly display the DVI.
I prefer updated versions of commands as well so that'll be "fixed" as well in the next release. I do notice a weird little thing in your newer command, however. The original is under Tools\Commands\latexmk while the new one is Tools\latexmk. Is that intentional or just a mistype?
Also, thank you for testing literally every command. I'm not sure many other testers would go out of their way to do that.
go figure;
Both & w/ different specs.:
Tools\Latexmk="latexmk -e \"$pdflatex=q/pdflatex -synctex=1 -interaction=nonstopmode/\" -pdf %.tex"
Tools\Commands\latexmk="latexmk -pdf -silent -pdflatex=\"pdflatex -synctex=1 %%O %%S\" %"
TSPortable's ".ini" does not have the "Tools\Latexmk" version.
Not sure what to make of this %AppData% business with 2 specs, one with 'Command' and without. In both Installed-TS-%AppData% versions, tho', it's pdflatex, not plain latex, that's apparently doing the compiling with pdf output being produced--or that's how I interpret the 2 specs; might easily be wrong tho'; haven't consulted the latexmk command line doc.
That's so incredibly strange... It feels like a typo, to be honest, but you say having both in there works properly, right?
??? beats me;
here's the complete texstudio.ini file in %AppData% after (1)uninstall of TS with "full-clean-out" options set, doubly assuring that the dir %Appdata%\texstudio is fully wiped out ;(2)install of TS 2.6.6 using "texstudio266_win32.exe"; (3) open of Installed TS followed by immediate close of TS to get it write the ".ini" file (context: Win 7 Home, Admin acct.; "everything" installed; in part., MikTeX-32bit; Asymptote; Ghostscript; Gsview; etc.); you'll notice that other commands have both the Tools\command_name and Tools\Command\command_name variants:
I see others that fall under just Tools\ in the current version, but they're hard to track down since the whole INI file seems to be in no particular order. Those new commands, however, are not in there, so I'll add them as they appear above. Still a bit odd...
Scratch that, the regular one says texmaker on the top as well. That was foolish of me.
For the larger comments, can you put them between <pre> and </pre>? It makes them a little easier to read.
for the tip
Original faulty update to 2.6.6 Dev Test 3.
had to kill TS.exe from TaskManager; briefly the DT & TS splash screens show simultaneously, then nothing on the screen; yes, I waited; context: sterile XP_SP3 VM, Admin
I'm going to check what's going on and then rebuild the texstudio.ini file again. I have a feeling I copy and pasted incorrectly or didn't change the right options.
Update: Having rewritten this configuration file multiple times, I cannot get it to launch on first try anymore. Even placing a blank ini file in its place does not get read or written by the program as it just hangs. There is an odd circumstance, however, that if App\TeXstudio\texstudio.exe is run while the other instance is hanging, the application will start as intended. I will look further into it, but for now I'm rolling back the release above to Dev Test 2 for functionality purposes.
Not sure going back the DT2 will help as this problem didn't really go away in previous DTs, at least for me. As reported earlier, it can be reproduced by un-maximizing the main window from full screen to normal size and then quit. I can recover by replacing the texstudio.ini in \Data\texstudio\ with the default from \App\DefaultData\texstudio\. Simply deleting the file does not work as its existence is not checked (or copied in case of absence) by the launcher at the start.
Of course the disappeared texstudio.exe and launcher should be terminated before doing it.
(1)"can be reproduced by un-maximizing the main window...and then quit"
(2)"can recover by replacing the texstudio.ini..."
Both (1) & (2) confirmed here on **DT2** in sterile XP(SP3) & in quasi-clean [1] Win7 Pro; hadn't noticed that before; nice catch;
no such issue for Installed TS 2.6.6 (Win 7)
very odd behavior;
Note(s):
[1]"quasi-clean": no installations on the box of the app under investigation or of its immediate dependencies (in this case: Miktex, Asymptote, Gsview);
In the launcher's ".ini" I set HideCommandLineWindow=false instead of the current DT2 setting of ...=true; this seemed to fix the unmaximize-quit-reexecute-can't-see-it issue;
have confirmed this fix on sterile XP(SP3) and on quasi-clean Win 7 Pro;
Fix confirmed on win 7, not very clean but without local tex installs.
thanks
In DefaultData\texstudio\texstudio.ini
Replace
Tools\Commands\latexmk="latexmk -dvi -silent -latex=\"latex -src %%O %%S\" %"
with
Tools\Commands\latexmk="latexmk -pdf -silent -pdflatex=\"pdflatex -synctex=1 %%O %%S\" %"
and
Replace
Tools\Commands\dvipdf=\"dvipdf\" %.dvi
with
Tools\Commands\dvipdf=dvipdfm %.dvi
In the launcher's ".ini" file
Replace
HideCommandLineWindow=true
with
HideCommandLineWindow=false
one qualifier: with the DVI->PDF Build Chain I get tons of Warning messages but also get proper pdf output (huh??); have tried using 'dvipdfmx' in the suggested replacements of the above post rather than 'dvipdfm' but that substitution produces identical results on the DVI-PDF chain; the DVI->PS->PDF Build Chain works without producing Warning messages while also producing beautiful output using the suggested replacement as is, i.e., with 'dvipdfm'; all exercises of the Tools>Commands worked as expected;
I'll go back and put those changes in and release it as the correct Dev Test 3 as soon as I can. I had thought the unmaximize and close error was related to how MiKTeX had been implemented back then, so I assumed it was fixed afterward. It's strange that "showing" the commandline window does anything in this case but I trust both of your testing on this. Thank you again, and look for a proper Dev Test 3 later today.
Thank you for bringing us the tex related apps, also thank d4winds for his insights and careful tests.
Updated to 2.6.6 Dev Test 3. See release notes for details.
These Portability Tests are of the "does it work at all?" variety;
execs of TexstudioPortable DT3 were from Win Explorer from each of:
C:\USB\PortableAppsEnv\PortableApps\TeXstudioPlusPortable
Q:\PortableAppsEnv\PortableApps\TeXstudioPlusPortable
P:\PortableApps\TeXstudioPlusPortable
X:\TeXstudioPlusPortable
each test was for basic portability functionality by successively
wiping the sample ".tex" file dir clean of everything but the ".tex" file itself;
opening TSPortable & then opening the ".tex" file within TSPortable;
using default Build (PDFLatex+View PDF) by double-clicking on the double arrow to build, view, & examine the pdf output;
closing ".tex" file and then closing TSPortable.
All output pdfs were excellent.
Fundamental Portability functionality tests have all been passed.
context:
sterile XP(SP3) VM, Admin;
All tests were performed without error or incident with flawless output; see Qualifications at bottom fr commentary, if any;
(1)Tested Commands of 'Tools>Commands':
"wipe slate clean" means:
to empty the dir containing the ".tex" file under test of everything except the ".tex" file itself;
Note on Yap: In the first exec. of View DVI, Yap displays errors; following advice found on StackExchange, while Yap was open
set 'View>Options>Display>DVI settings>Default render method' to 'Dvips'; subsequent Yap displays were flawless.
These commands were exec'd in sequence:
Latex
View DVI
DVI->PS
View PS
PS->PDF
View PDF
"wipe slate clean";
next commands tested:
Latexmk
View PDF
"wipe slate clean";
(2)Test Build Chains, i.e., specifications for 'Options>Configure Texstudio...>Build>Buidl&View':
"wipe slate clean" performed before testing each Build Chain;
Chains tested:
Compile&View (default)
PS Chain
PDF Chain
DVI Chain
DVI->PDF Chain (*)
DVI->PS->PDF Chain
closed current ".tex" file, opened new Asymptote ".tex" file, viz., "latexusage.tex" from AOPS site;
tested these Aymptote Build Chains:
Asymptote DVI Chain (**)
"wipe slate clean";
Asymptote PDF Chain (**)
Qualifications:
(*) generated cascade of Warnings in Texstudio Messages window; output flawless, however
(**) must exec twice; output flawless if that is done;
Detailed Regshot below;
context:
sterile XP(SP3), Admin;
AV is On (AV=WebRoot--note WRData entries in HKLM);
'User-GUID' replaces the long-winded UID in HKU entries;
all execs from Win Explorer;
TSPortable dir is on the virtual 'P' drive under the 'P:\PortableApps' dir, where the 'P' drive is equivalent (via the subst command) to 'C:\USB\PortableAppsEnv';
'Asymptote_LaTeX_Sample.tex' was the .tex file, it is the same as 'latexusage.tex' from the AOPS site;
TSPortable DT3 out-of-the-box was tested; it utilizes
AsymptotePortable
GsviewPortable
CommonFiles\Miktex
Procedure:
1st Regshot; load .tex file; exec'd the Asymptote PDF Chain; closed TSPortable; 2nd Regshot
in support of the assertion titling this post, please note the 3 prior posts
I leave to do a project and I come back to see it tested into the dust once again. Thank you d4winds yet again for your dedication to TeX testing. I'm glad it all came out clean this time around.
Pages