Application: Texmaker
Category: Office
Description: From the publisher's website:
Texmaker is a free, modern and cross-platform LaTeX editor for linux, macosx and windows systems that integrates many tools needed to develop documents with LaTeX, in just one application.
Texmaker includes unicode support, spell checking, auto-completion, code folding and a built-in pdf viewer with synctex support and continuous view mode.
Texmaker is easy to use and to configure.
Texmaker is released under the GPL license .
Features
Unicode editor
Texmaker is fully unicode and supports a large variety of encodings.
Spell checker
Texmaker includes spell checking while typing.
Code folding
All \part, \chapter, \section,.., \begin{foo} \end{foo} blocks can be collapsed.
Code completion
The main LaTeX commands can be quickly inserted while typing.
Fast navigation
Texmaker includes a "structure view" which is automatically updated while typing.
"Master" mode
Texmaker allows you to work easily onto documents separated in several files with the "master mode".
Integrated Pdf viewer
Texmaker includes a built-in pdf viewer with continuous scrolling and synctex support.
Easy compilation
"One-click" compilation with the predefined "Quick build" commands.
Mathematical symbols
370 mathematical symbols can be inserted in just one click.
Wizards
Texmaker includes wizards to generate the most standard LateX code ('Quick document', 'Quick letter', tabular, tabbing and array environments.
LaTeX documentation
An extensive LaTeX documentation is furnished with Texmaker.
Error Handling
Texmaker automatically locates errors and warnings detected in the log file after a compilation and you can reach the corresponding lines in the document in one-click.
Rectangular block selection
Easy rectangular selection with the mouse+Alt key. Users can easily cut/copy/paste columns of a table.
Find in folders
With Texmaker you can search for text in all the latex documents included in a folder (and the subfolders). If you click on a line, Texmaker will open the corresponding document at the right line.
Rotation mode for the pdf viewer
Export to html and odt via TeX4ht
Regular expressions support
Full asymptote support
(syntax higlighting - commands )
Unlimited number of snippets
With Texmaker, users can define an unlimited number of snippets with keyboard triggers
Ready for the future (Qt5)
Texmaker is already available for the new major version of the Qt toolkit.
See the user manual for other features.
Download Texmaker Plus Portable 4.5 Dev Test 2 (39.1MB download / 137.5MB installed (160MB with optional components))
(MD5: b03962862912ab56c83998f06467e941)
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)
Note: Windows XP users may encounter hanging when running Asymptote from within Texmaker. The only current solution is to close the commandline window after all of the necessary files are outputted. You can reference the conversations below for more information.
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 BlueSky
Follow us on Facebook
Follow us on LinkedIn
Follow us on Mastodon
Follow us on Twitter
PA complains that '...Launcher\TexMakerPlusPortable.ini could not be found'; need to rename current Launcher\TexMakerPortable.ini.
gswin32c.exe, gsview32.exe, & asy.exe are not getting picked up by TexmakerPlusPortable from their respective portable dirs (CommonFiles\Ghostscript or App\Ghostgum\gsview or App\Asymptote); thes dirs (CommonFiles\Ghostscript\bin, etc.) containing them need to be on the path via launcher. wrt gsview, see also my comment of 09/30/2013 titled 'gsview' on LyXPortable at https://portableapps.com/node/38209, where it was found that being on path was necessary for gsview32.exe to function but by no means sufficient (am not familiar with portabilizing Asymptote).
Fixed in update
Updated to 4.0.4 Dev Test 2. See release notes for details.
MikTeX is not detected if there is not an installed version since it is not on the path; for the same reason, if there is an installed MIkTeX it will get picked up rather than the MikTeXPortable that the user has presumably added packages to or updated. The MikTeXPortable binaries must come first on the path, so that they get precedence. A suggestion is to replace the current path specification in Launcher\TexPortablePlus.ini with the following:
PATH=%PAL:PortableAppsDir%\MikTeXPortable\App\MikTeX\miktex\bin;%PAL:AppDir%\Asymptote;%PAL:AppDir%\Ghostgum\gsview;%PAL:PortableAppsBaseDir%\CommonFiles\Ghostscript;%PATH%
previously had an erroneous post in here; No, the prior post about the path was correct; after making the path mod TMPortable Dev2 is giving core functionality of the edit/build/view_pdf cycle.
It's odd to me that it needs it in the path, as the texmaker configuration file (configs\texmaker.ini) uses all paths that point to (what I thought were) the correct locations for MiKTeX Portable standalone. Since your testing has shown a need for the PATH to be updated, then I'll add it to the launcher accordingly. Thanks again.Edit: Nevermind what I said above. I was thinking of TeXstudio with the PATH variable. The right updates will be made in the next Dev Test.
so path spec becomes:
PATH=%PAL:PortableAppsDir%\MikTeXPortable\App\MikTeX\miktex\bin;%PAL:AppDir%\Asymptote;%PAL:AppDir%\Ghostgum\gsview;%PAL:PortableAppsBaseDir%\CommonFiles\Ghostscript\bin;%PATH%
You caught me with this comment just before I released an update with the other path. Keep a look out for the correct path soon.
Updated to 4.0.4 Dev Test 3. See release notes for details.
DT3's Launcher\....ini says:
'PATH=PATH=...', should be simply 'PATH=...'; TM can't build a LaTeX file.
I'm just going to replace the Dev Test 3 that's there. No sense in creating Dev Test 4 for that...
I had a good laugh; thanks for the humor
'DirectoryMoveOK=yes' looks warranted IF MikTeXPortable does a concurrent move to maintain the relative relationship; is that "IF" why you have it set to "warn"; all PA apps which may utilize parts/all of others face the similar issue: the dir may be movable but only on the proviso that the ones it uses move in parallel; not sure what PA conventions are for that, if any
I'm going to assume that people are moving the directories in sync with each other for now because seeing "The directory has changed" every time you plug it into a computer that assigns a new disk letter is quite annoying. In a perfect world, I'd just use the MiKTeX Plugin and have that be a requirement, like Ghostscript or Java.
sounds good to me; very good
prior positive assertions on core functionality hereby retracted; performed new, completely clean test with no potential interference from installations and no fossils in the TeX file directory from old builds that TM could display as though it had created them.
Context: New install of TMPortable_DT3 on an XP VM with No installed MikTeX, ghostscript, gsview, or Asymptote; cleaned the directory containing a test TeX file of everything but the TeX file itself; exec'd TMPortable_DT3 (from PA menu), loaded the TeX file, & pressed the 'Quick Build' button w.i. TM; received the message from TM that it "Could not start the command." [1] The code looks right; the results obviously do not.
correct-looking appearances notwithstanding, something is awry in the TM config file (texmaker.ini) from DefaultData. I suspect that the TM syntax conventions being used for the Tools in that ini file are the culprit & that syntactic simplicity may bring more proper behavior.
Note(s):
[1]FYI from an installed TM on another (Win7) box using the same TeX file, same clean-out of the other files in its directory, & same Quick Build, TM performed flawlessly.
the following lines were used in DefaultData\configs\texmaker.ini in lieu of the lines begging with 'Tools\...' currently there:
Tools\ExtraPath=
Tools\OutputDir=false
Tools\Quick%20Mode=3
Tools\Latex="latex.exe -interaction=nonstopmode %.tex"
Tools\Dvi=yap.exe %.dvi
Tools\Dvips="dvips.exe -Pdownload35 -o %.ps %.dvi"
Tools\Ps=gsview32.exe %.ps
Tools\Ps2pdf="ps2pdf.exe %.ps"
Tools\Makeindex="makeindex.exe %.idx"
Tools\Bibtex="bibtex.exe %"
Tools\Pdflatex="pdflatex.exe -synctex=1 -interaction=nonstopmode %.tex"
Tools\Xelatex="xelatex.exe -synctex=1 -interaction=nonstopmode %.tex"
Tools\Pdf=
Tools\Dvipdf=dvipdfm.exe %.dvi
Tools\Metapost="mpost.exe --interaction nonstopmode "
Tools\Ghostscript=gswin32c.exe
Tools\Asymptote=asy.exe %.asy
Tools\Latexmk="latexmk.exe -e \"$pdflatex=q/pdflatex -synctex=1 -interaction=nonstopmode/\" -pdf %.tex"
Tools\Sweave=R.exe CMD Sweave %.Rnw
Tools\Texdoc=texdoc
Tools\HtOptions="\"\" \"\" \"\" -interaction=nonstopmode"
Tools\Htlatex=htlatex.exe
Tools\Userquick="latex.exe -interaction=nonstopmode %.tex|bibtex.exe %.aux|latex -interaction=nonstopmode %.tex|latex.exe -interaction=nonstopmode %.tex|xdvi %.dvi"
Tools\QuickAsy=asy.exe -f pdf -noView %.asy
Tools\LP=
Tools\Run=0
Tools\View=2
Tools\IntegratedPdfViewer=true
Tools\PdfInternalViewEmbed=true
Tools\SingleViewerInstance=false
w/ these mods, core functionality is now in place (same environment, test file & test file directory contents as above); will check out further (gsview, etc)
looks good, not perfect for items tested; principal qualification is that the tests have not been checked on the Portable version when there is also an installed TM and/or MikTex to potentially muddy things.
--Summary--
QuickBuilds (2) using Asymptote not tested; Latexmk command is not working, a copy from a known, tested installed version failed also; everything tested except Latexmk worked as it would from installed version; in particular, of course, pdfLatex build & pdf view (TM's default QuickBuild) worked smoothly as did dvips bild + postscript view from gsview.
-Environment--
(a)no installed MikTex, ghoscript, gsview, TeXMaker; OS=XP/SP3
(b)with each test of a QuickBuild method, the directory containing the test TeX file was first emptied of everything else
--Details on Results---
QuickBuild Tests for TeXMakerPortable using my mods to the 'Tools\...' lines of 'DefaultData\configs\texmaker.ini:
PDFLatex+view PDF (default out-of-the-box QuickBuild):
check
Latex+dvips+view PS:
check
Latex+view dvi:
as installed for TM&Miktex:
dvi& yap executes but yap reports "Some Postscript specials could not be rendered."
all OK after a changing the default YAP rendering method to dvips (from Pk) thru yap's menu View>Options>Display>...This behavior is identical to installed versions. ie., the test is passed.
Latex+dvipdfm+view PDF:
check
Latex+dvips+ps2pdf+view PDF:
check
Latexmk+view PDF:
context: out-of-the-box:
result:"Could not start the command."
context: changed the Latexmk command from the TM menu in Options>Configure Texmaker>Commands
to one from a tested latexmk command [1] on an installed TM on another box
result:"Could not start the command."
XeLatex+View PDF:
check
Quick Build Options Not Tested (no .asy file for testing; do not use Asymptote):
Latex+Asymptote+Latex++dvips+view PS
PdfLaTeX+Asymptote+PdfLaTeX+View Pdf
Note(s):
[1]the tested Latexmk command from an installed TM on another box:
latexmk -e "$pdflatex=q/pdflatex -synctex=1 -interaction=nonstopmode/" -pdf %.tex
--did not work on portable version; does work on installed version; ???
Basically, it looks like that I have to remove the pathing in the configuration file because for some reason it isn't picked up properly because technically the pathing is taken care of by the PATH extensions... When a configuration file stops being a real configuration file, that gets quite annoying. Thank you for testing in a non-MiKTeX environment. I don't really have that ability right now so it is appreciated. I'll look over your comments and change what needs to be in the next release.
Edit: The changes that I made to the INI file seem to have allowed for latexmk to work properly, or least it seemed that way in a very simple test of mine. The next version also includes the MiKTeX portable plugin version in the PATH so it will ease the transition down the line.
still does not work in the test environment: no installed MikTex, TM, gsvew, etc. I get the same message, viz., "Could not start...".
That's odd. I'll see what I can do to test that in a more sterile environment. The major issues of pathing have been taken care of, which I think was much more pressing.
Update: I found a good way of spot testing without having to setup a clean environment. Since this program makes such heavy use of PATH, if you remove the final ";%PATH%" from the Environment, then it can only work with the portable version. This will save me some time in the future...
I went for a sterile environment (I understand you do not have) so that TM,eg, could not go to the registry for legitimate paths.
something is wrong in the configs\texmaker.ini concerning the geometry and/or fonts in the pdf viewer; the portable version's font rendering looks close to sans serif font from a tex file producing roman (tex default)& the letters/symbols are stretched outward in the left-right axis; visual appearance w/i Adobe's acrobat of the exact same pdf on the same box is far superior to portable TM version but it is also identical to the installed TM's (different box) pdf viewer's rendering.
Updated to 4.0.4 Dev Test 4. See release notes for details.
this line in DefaultData\configs\texmaker.ini will creates issues w/ all the deletes of FileWrites you did:
Spell\Dic=APPROOT/texmaker/en_US.dic
I've exec'd TMPortable in the sterile environ. & by now the line is mangled.
I'm pretty sure that APPROOT still does forward slashes, but I'll look for a reason.
Edit: Well... APPROOT does forward slashes, but the second FileWrite sure doesn't... Stupid on my part. I will just be replacing the current Dev Test because that's a typo more than anything.
look at FileWrite2, eg
It's kind of funny to look at the configuration files when it escapes all of the letters... at least in retrospect. It should be fixed now in the real Dev Test 4.
the spelling dictionary is looking correct now; I tested w/ a coupld of invocations of TMPortable from different drive-dir combos.
latexmk is a Perl script (Duh!);
that's why the installed TM execs it fine--it has Perl installed & that's why TMPortable does not exec it in the sterile environment since Perl is not installed there;
as I recall (could have faulty memory here), you reported getting TMPortable to exec latexmk; if so, was Perl installed?
The full MiKTeX installation package might have it in there, or else another program I use installed it. I know that I didn't install Perl by myself. At least it makes sense why it kept failing.
dumb remark; latexmk has the .exe extension; shouldn't need the Perl interpreter; should already compiled into a Win executable (double Duh!)
no issue in TMPortable per se with latexmk;
but, if one desires to use latexmk from TM or otherwise, then the Perl binaries from an installed Perl or from, say, the StrawberryPerl portable version need to be on the path for latexmk.exe
in the sterile environment, I installed Perl (ActiveState distrib., full defaults in the install), where the installer for Perl puts the Perl\bin & Perl\site\bin directories on the system path. I invoked an unmodified TexmakerPortable DT4, set QuickBuild to the Latexmk option, loaded the test tex file (afte having cleared its dir of everything else first), pushed the button for the QuicBuild, & voila: all was well TM land.
user desiring to portably use latexmk must modify the TMPortable launcher to set the path accordingly (include Perl\bin & Perl\site\bin). Details on confirmation of this follow:
--Details--
This was confirmed by running TMPortable with 2 alternate to the DT4 version in the path spec of the launcher (the sterile environment has the system path of 'C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\system32\WindowsPowerShell\v1.0', abbreviated to 'C:\Windows....' below; the Perl is located in the dir C:\Perl):
;1st alternate: path=TM path additions+only std system path w/o Perl bins:
[Environment]
PATH=%PAL:PortableAppsDir:ForwardSlash%/MikTeXPortable/App/MikTeX/miktex/bin;.....Ghostscript/bin;C:\WINDOWS\system32....
;2nd alternate: path=TM path additions+std system path+Perl bins:
[Environment]
PATH=%PAL:PortableAppsDir:ForwardSlash%/MikTeXPortable/App/MikTeX/miktex/bin;.....Ghostscript/bin;C:\WINDOWS\system32....
;C:\Perl\site\bin;C:\Perl\bin;
w/ 1st version (no Perl bins on path), TM reports "Could not start..."
w/ 2nd version (Perl bins are on the path), voila! all works well.
I found a couple of old versions of Perl portable so I think they could be added to PATH if users want the functionality, for now.
the display by the TMPortable internal pdf viewer of the **same** pdf is, as previously reported, visually different from the displays by both the installed Adobe Acrobat on the same sterile XP VM & by the installed TM on a different Win 7 box; further those last 2 non-TMPortable displays are identical. Even the font in the TMPortable internal pdf viewer rendering looks significantly different.
I can't really figure out what could be causing your disparity in fonts, but unless we hear from another user, I can assume it's an isolated case (for whatever reason).
is identical on the XP sterile box to that for Adobe Acrobat & to the Win7 "polluted" box (all kinds of installations) for TM's viewer; just TMPortable's viewer is looking different (not even a roman font)
I'll look into it when I get a chance. Thanks again for testing.
this is the mod I have made to the launcher Environment section to include the Perl binaries from a complete installation (just a copy of only the directory Perl\bin will not work, since perl libs in other dirs are needed; yes, that assertion was tested); the same mod would be necessary to use latexmk from any of the other TeX apps: TeXWorks, TeXStudio, LyX; the env.var. Perl_bin can be left empty; FYI, latexmk is very handy since invokes & re-invokes latex, bibtex, etc. until everything is resolved; otherwise multiple execs (of, say, pdflatex) by user are needed for creating indexes, TOCs, lists, etc.
[Environment]
;original:
;PATH=%PAL:PortableAppsDir:ForwardSlash%/MikTeXPortable/App/MikTeX/miktex/bin;%PAL:PortableAppsDir:ForwardSlash%/CommonFiles/MiKTeXPortable/App/MikTeX/miktex/bin;%PAL:AppDir:ForwardSlash%/Asymptote;%PAL:AppDir:ForwardSlash%/Ghostgum/gsview;%PAL:PortableAppsBaseDir:ForwardSlash%/CommonFiles/Ghostscript/bin;%PATH%
;d4winds mods:
Perl_bin=C:\Perl\bin
TeX=%PAL:PortableAppsDir:ForwardSlash%/MikTeXPortable/App/MikTeX/miktex/bin;%PAL:PortableAppsDir:ForwardSlash%/CommonFiles/MiKTeXPortable/App/MikTeX/miktex/bin;%PAL:AppDir:ForwardSlash%/Asymptote;%PAL:AppDir:ForwardSlash%/Ghostgum/gsview;%PAL:PortableAppsBaseDir:ForwardSlash%/CommonFiles/Ghostscript/bin
: Remarks:
; (a)OK to leave RHS of 'Perl_bin=...' empty
; (b)RHS, if not empty, must point to the dir containing perl.exe
; in a complete installation of Perl; e.g.,use installs from
; the portable (,zip) version of Strawberry Perl at
; http://www.perl.org/get.html#win32;
; Reason: used by latexmk; latexmk will not execute without it
PATH=%TeX%;%Perl_bin%;%path%
I'd say that this could be helpful for anyone looking to do it themselves. Until there's an up-to-date Perl Portable (though there are the couple of outdated dev tests sitting in the forums), I'm going to keep that out. After Asymptote and gsview, I might tackle it if I have the time.
strawberry-perl-portable looks very good; there was a formal perl project to come up with a portable version & strawberry-perl-portable was the result; there is much portability support on the perl end, though almost none formally forthcoming from PA.c of which I'm aware;
at 1st blush: from one of the forums, PerlPortable, though having custom code, did nothing except call a poorly modified version of the strawberry-distributed batch file (& it created some extraneous dirs in Data that it did absolutely nothing with); unless I've missed something, the paf version of strawberry-perl-portable would have nothing to do except to launch the batch file as is. Maybe that's why there is no PA.c version; maybe it's just too simple & the only value-added from the paf is to create a .exe that the PA.c menus would deign to execute.
Of course, more likely, I have missed quite a bit, as did the old forum poster/paf developer; offhand, the issue that I have unresolved is that of package maintenance w/i perl & the the PA update process; if there's a biggie, that may be it; but, frankly I'm far too ignorant of perl, its ppm, cpan, etc. to hazard intelligent guesses about the package maintenance, etc.; for me, perl has always been a back-end thing to execute someone else's perl scripts w/ no thought involved;
FYI, the strawberry-perl version is bloated about 220MB (installed) by its 'c' subdir, which duplicates the mingw compiler/lib/include suite; its functionality for perl could probably be dup'd by simple path mod to enable access to the PA mingw binaries.
for latexmk per se, I found by test that one needs the subdirs perl\bin & perl\lib from the strawberry-portable distribution (80MB installed) & that their location is irrelevant (I tested by placing them in a Perl dir on the desktop) so long as the perl\bin subdir (no need of perl\site\bin, which ships empty)is on the path.
That analysis of the Perl stuff could come in handy later, especially if I rig up a portable version of Strawberry (since that seems to be the most portable off the bat). Like LyX, I'd probably use the OptionalComponents feature to let people include the mingw stuff if they want to but keep the base stuff for use with other apps, like latexmk (which is the primary reason I'd even do that in the first place).
sounds like a good idea;
another idea: include bin & lib subdirs from strawberry's 'perl' dir--possibly optionally--in a new sub dir of MikTeXPortable\App, going under MikTeXPortable\App\Perl; then add the line
"path=MikTeXPortable\App\Perl\bin;%path%"
just **before** the ususal path line in the Tex apps--LyX, TeXWorks, TeXStudioPlus, & TeXMaker.
that way, the TeX-only crowd with no Perl interest per se (98% of the users, I would conjecture) have the functionality available for latexmk; latexmk is, as I previously noted, extremely handy for pure TeX/LyX; it is also very handy for Asymptote. Further, w/o such an inclusion, if one innocently execs latexmk from any of the TeX apps on a box with no Perl (as I did after setting up the sterile XP VM environment), one gets the cryptic "Could not start the command" with absolutely no clue as to what went wrong--a **very** poor user experience, esp. since these TeX apps, finding latexmk in the MikTeX binaries, assume the functionality is there & positively invite its usage.
I kind of want to steer clear of making more things as add-ons or bundle-ins in the future just because there might be more things that use Perl in the future (the same reason I broke apart the original proTeXt package into two parts).
Summary: believe TM code for usb is itself faulty; this is a show-stopper; external pdf viewer may be a fix.
have checked again how the pdf looks usng SumatrapdfPortable on the same sterile-environment XP VM; it looks identical to the way it looks under Adobe--and as it should look; but the TM pdf viewer still renders differently: its characters seem more spread out w/ some of the math squished; indeed all of the math looks rendered in a Courier-like font, not the AMS Roman; further, the first word (always, sometimes one or two more)in a enumerated list is rendered in boldface, even though the TeX file producing the pdf has no such boldface specifications & even though other pdf viewers using the same pdf file do not show such.
Unfortunately, this is a show-stopper for real-world use. One simply cannot constantly (& correctly) modify TeX expecting one thing & getting another. Perhaps the only way TM can be used portably is by using an external pdf viewer like Sumatrapdf.
This may be a TM bug. I get the same improper rendering on the same sterile XP VM by downloading the latest texmakerwinusb32.zip (version 4.04) from the the TM site, throwing MikTex into the path & exec'ing TM from the command line. I suspect that their pdf viewer code for the usb version is faulty because I get the same bad rendering using the identical texmakerwinusb32 code & command line on a different Win7 (!)box. FYI, that box is polluted with installations but does not have TM installed. (All Win7 boxes mentioned are 64 bit; TM site gives only 32bit, claimed therein it "works for 64bit.") It is physically separate from the Win7 box mentioned in other comments that does have TM installed. My best guess is that the TM installation process adds some helper dlls to the system directory (when installed by an admin account for 'All Users' anyway, which it was for the other Win7 box that does have TM installed & which renders properly for both the installed TM the TMPortable versions).
In any case, the towel has been thrown in. One simply can't expect to use it unmodified on an ordinary XP (or even Win7!) box. Again, an external viewer may be a fix for at least usability.
found the problem;
the VM and the Win7 w/ no installed TM are on the same physical box being accessed remotely thru net/Remote Desktop; that box has an over-sized desktop monitor; the laptop for remote access has a normal-sized one (normal for a desktop, that is; acrtually a bit large for most laptopss, by the width of separate numeric keypad) ; hence the spreading out by the TM internal pdf viewer; this does not account for the boldface appearance of leading words in an enumerated list but could account for the Courier-like & squished-down appearance of the Roman font for text & AMS math;
in any case, TMusb was exec'd with path restricted to **only** MikTeXPortable binaries on the remote laptop, also the Win 7 with installed TM (but the path restriction should correct for any system dir type issues); all went well with the viewer no issues;
to confirm performed the same test--same path restriction, same batch file--from yet another Win7 laptop (normal-sized screen for a desktop again, a bit largish for most laptops); again, an undistorted image;
odd, that TeXStudio & TeXWorks internal pdf viewers & all standard pdf viewers like Acrobat & Sumatrapdf are not "fooled" by the over-sized underlying screen geometry but render an undistorted view, but TM's (at least its usb version) is fooled; perhaps it is interaction of TM&RDP that is fooled; don't know, since don't have physical access to the box, only remote.
The remote connection sounds like a reasonable reason for having the issues (combined with the display differences). I'm not certain why the issue is there, though, but maybe a locally installed version for comparison would help. I would do so, but I'm not at my normal computer (for a little while at least), so I can't test that straight away.
have not had & will not have for a while the opportunity to test with non-remote access in comparable sterile-XP-big-screen situation; might be able to pseudo-test next week: non-remote access, big screen, but 'polluted' Win7 (many installations) though can, of course, use path truncated to TeX-stuff (ergo the 'pseudo' moniker); the testing interp. would be muddied by TM possibly using, even if not installing itself, registry values put in from other apps (the big advtanage of sterility). That type of pseudo-test next week may the best I'll be able to come up with; cannot really subject TMPortable to much else in the way of testing until I have some comfort level beyond reasonable-sounding conjecture on the display issue since it's such a show-stopper; looks like it's a red herring, but gotta have some direct evidence first (even with some muddying per above).
had occasion to use web browser on the remote box recently (almost never do); discovered that in the display of some pages the letter 'f' was appearing boldfaced in the browser, though obviously not intended to seem so; so the inexplicable appearance of boldface in TM is a remote access rendering issue;
the hardware screen on remote box vs receiving box may account for the flatness, etc.; still need a direct test on that one
Glad that's making headway, as I still haven't seen the same display errors you have.
Updated to 4.0.4 Dev Test 5. See release notes for details.
Well, I finally got around to making Strawberry Perl into an updated portable app. You can find it here in both 32- and 64-bit flavors. Even though I did this mainly for TeX, I hope others use it too. Give it a shot and see if it works with latexmk.
Updated to 4.0.4 Dev Test 6. See release notes for details.
Updated to 4.1.0 Dev Test 1. See release notes for details.
in the def. of the TEX env. var. used to defined the path
%PAL:PortableAppsDir:ForwardSlash%/CommonFiles/MiKTeX/bin
should be
%PAL:PortableAppsDir:ForwardSlash%/CommonFiles/MiKTeX/miktex/bin
I thought I took care of all of those... I'll try to fix this as soon as I can.
Updated to 4.1.0 Dev Test 2. See release notes for details.
per regshot, the following registry key is added:
HKU\...Software\QtProject\OrganizationDefaults\Qt\filedialog
Do you mean HKCU\Software\QtProject\OrganizationDefaults\Qt\filedialog? I'll take a look regardless, but HKU seems odd.
This is fixed in the newest update. I don't see what it controls, so for now, it's just "thrown out" like the other registry items.
context sterile XP-SP3 VM; out-of-the-box install of TM; ComonFiles plugin version of Miktex fully updated [1].
(1) good news
Quick Build was configured as follows & exec'd flawlessly:
pdflatex + View pdf
latex+dvips+ps2pdf+View pdf
latexmk+View pdf
The "View ps" command was also exec'd following the 3rd of these & exec'd flawlessly calling GSViewPortable.
(2) bad news:
However, when QB was set to the following & test doc is latexusage.tex from AOPS (has 3 Asympytote figures; see AsymptotePortable posts--you remember it; how could you forget?)
pdflatex+Asymptote+pdflatex+View pdf
w/ Asmptote command within TM out-of-the-box, 3 DT screens for AsymptotePortable are seen in succession (as expected) & 3 command line windows, 1 for each. However, each of the CLI windoww hangs & must be closed manually (by clicking on the 'x' in the upper right-hand corner); final pdf output has all figures with proper labels. How with hanging ??? One would have expected incomplete asy.exe execution improper or no pdf ouptut. pdf output is OK [2] subject qualifications about visual output of TM & current test environ.
No such hanging occurs in the 3-line batch file from AOPS.
Note(s):
[1]TM was 1st exec'd to get Miktex to install packages (on-the-fly=Yes); then it was updated using the taskbar-icon, then Refresh FNDB & rebuild of formats was performed (using Miktex Options from the taskbar-icon), then the taskbar-icon was exited.
I'll look into the hanging, but as near as I can tell, that is supposed to be closing as normal. Can I ask how long it seems to be hanging each time?
counted slowly to 30 on each window; gave up & closed manually; so, >=30sec on each of the 3 CLI windows.
By contrast the 3-line batch file, including pre- and post-AsympotePortable calls to pdlatex, execs in 2-3 secs.
Good news on the first test. On the second test, however, I tried it with all fresh installs (including a completely working Asymptote Portable) and I only experienced hanging while pdflatex.exe was being called by Asymptote.
exec sequence in 3-line batch file & in TM's config. is (1) pdlatex, (2) AsymptotePortable, (3) pdlatex. here (1) execs. leaving the 3 ".asy" files (latexusage-1.asy,...), one for each figure; then comes (2) with the 3 AsymptotePortable DT screens/CLI windows; on each of those CLI windows it hangs; I manually close each, and then--and only then--".tex" files are produced for each figure in turn with each such closure; finally (3) execs with No manual intervention necessary or used & all is complete
I still followed that exactly and it still automatically closed the commandline windows. Is there anything out of the ordinary in the windows while they're hanging? Or is it the same thing as if you started Asymptote Portable manually?
Updated to 4.1.0 Dev Test 3. See release notes for details.
following DT3 download link one gets a reference to DT4
There's actually two weirdly separate things at work there. For some reason, Texmaker 4.0.4 Dev Test 4 is considered the "newest" download on my SourceForge page, hence the link you see when you follow the download. Teh second problem is that, even though it was uploaded, the file cannot be downloaded since it hasn't been mirrored at all. I'll try to fix this with a reupload.
Update: It should be fixed now. I reuploaded the file. It may take a little while to mirror, but it is downloadable from my local mirror at least.
in the AsymptotePortable launcher, one uses
HideCommandLineWindow=true
instead of the current
HideCommandLineWindow=false
However, for raw, standalone invocation of AsymptotePortable with the above substitution one never gets the expected CLI: the splash screen displays, then the process stays around silently, needing to be killed off via TaskManager.
Clearly, with "HideCommandLineWindow=false" in the AsymptotePortable launcher's ".ini" file, user input is being expected from an interactive, gui environment--at least from the TM one.
On the other hand, since the 3-line batch file from AOPS works just fine using AsymptotePortable "HideCommandLineWindow=false", user input is Not being expected from batch;
So, if "HideCommandLineWindow=false" is to be AsymptotePortable launcher's ".ini" file to preserve expected stand-alone behavior, then somehow an EOF sentinel must be sent by TM.
Note(s):
[1] context:
sterile XP-SP3 VM; TM invoked from Win Explorer;
the TM Quick Build is set to the option "pdlatex+AsymptotePortable+pdlatex";
the test document for TM is latexusage.tex
For Texmaker invocation, Asymptote won't be looking for user input. You can try typing something in the commandline window and push Enter to see this. When asy.exe (the actual Asymptote executable) is called, it looks to see if it has any options after it. If the options are processing commands, it automatically runs them and then closes. If the options are not processing commands (like options to import plain.asy by default) or if there are no options, it goes into interactive mode. As before, I tested your steps and the command windows closed just fine. I made sure it was invoking the right asy.exe and everything.
tried that (entering Enter) before ever posting about the Hang; just tried w/i the CLI window each of ctrl+Z (Win) & ctrl+D (Linux variant, just in case of a cygwin dll mess-up) variations of an EOF sentinel ; neither works; one must close each of the CLI windows opened by TM's call to AsymptotePortable;
context:
"HideCommandLineWindow=false" in the AsymptotePortable launcher;
Quick Build for TM=pdlatex+Asymptote+pdflatex;
sterile XP, etc.
The typing was actually supposed to fail because in that state, Asymptote doesn't allow for user input. I don't know why it ends up hanging for you. Can you look in Task Manager (or an equivalent) to see what other processes are running during that time? Unfortunately, I can't access an XP machine, virtual or otherwise, so I don't know if that is a weird XP thing or if it's hanging for other reasons.
processes:
2 instances of asy.exe;
1 instance of each of AsymptotePortable & TexmakerPlusPortable
1 instance of pdflatex
files produced:
.asy files (3, 1 for each figure), produced by pdflatex
1 .tex file for the 1st figure, produced by asy.exe
1 .pdf file that is legitmate (not corrupted or in flux state) albeit that Adobe's Acrobat can read; the .pdf is for the 1st figure; it is unlabeled;
0 .tex files or .pdf files for other figures;
All of those look exactly right. Can you try running the pieces individually? It's possible that running it as quick build is messing things up, as weird as it sounds. While you do, I'll assign quick build those settings and run it myself. I've been doing them individually on previous tests.
Used the built in PDFlatex+Asymptote+PDFlatex+View PDF option and it still ran well without hangs.
used commands (1)PDFLaTeX;(2)Asymptote;(3)PDFLaTeX;
exec during (2) on XP identical to prior ones: 3 successive CLI windows, each of which must be closed manually; final output .pdf is OK, subject to the usual TM-remote-screen flatnesss, Courier-like issues.
For now, I'll note it above for users of XP.
ran OK on a polluted (gobs of apps) but free-of-installed-Asymptote-and-Miktex-and-TM Win 7 box (ie. none of the apps under immediate investigation is installed);
somehow "weird XP thing" doesn't help explain it;
fyi, my test environment:
I use a (very polluted) Win 7 Home Premium laptop to connect remotely to a Win 7 Professional desktop that has installed the Windows Virtual Machines software, in part., the XP VM; all OS's are up-to-date
I only suspect XP because it's far enough out of date where weird things can happen. Albeit Texmaker explicitly mentions XP support and Asymptote mentions it in passing, so there shouldn't be any issues. I'll do my best to find or make some XP VM since there might be these notable issues.
XP has a decade of experience with millions of eyeballs looking for every conceivable thing ; Win 7 does not; that said, I use Win 7 daily and not XP (it's just for testing & for some irreplaceable 16-bit bit apps) because of UAC/security; I think of it as basically the same thing as the Vista I thankfully by-passed but with a 2nd shot at drivers by manufacturers; in any instance, at least until Aprl '14 XP will be around & will probably be around for 5 more years many places until the boxes crater.
ran separately the commands PDFLaTeX; Asymptote; PDFLaTeX from TexStudioPlusPortable's Tools>Commands menu using out-of-the-box AsymptotePortable & TexStudioPlusPortable; exec was on sterile XP, etc.
results were smooth, no hangs, by contrast to TexmakerPortable on XP;
get hangs on AsymptotePortable previously described when called by TMPortable on XP box [1] and with TMPortable & AsymptotePortable set as shipped; in part., AsymptotePortable launcher has "HideCommandLineWindow=false";
No hangs in any of these circumstances:
(a)XP; run from TMPortable with AsymptotePortable launcher reset to "HideCommandLineWindow=true", rather than out-of--box version "HideCommandLineWindow=false", otherwise identical AsymptotePortable; TMPortable out-of-the-box;
(b)XP; run from batch file rather than TMPortable; AsymptotePortable out-of-the-box
(c)XP; run from TexStudioPlusPortable out-of-the-box; AsymptotePortable out-of-the-box
(d)Win 7 installation-clean w.r.t. apps under investigation [2]; TMPortable out-of-the-box; AsymptotePortable out-of-the-box; MiktexPortable is used, fully up-dated for Asymptote [3]
(e)Win 7 filthy (all manner of things installed); everything under investigation Is installed: TM (version 4.1.0) is installed, MikTeX is installed, Asymptote (version 2.24) is installed; Asymptote exec'd from installed TM using QuickBuild option
Note(s):
[1]
(i)XP refers to the same sterile XP-SP3 VM in all instances; e.g., the system path (from "echo %path%" from the CLI) is below:
C:\WINDOWS\system32
;C:\WINDOWS
;C:\WINDOWS\System32\Wbem
;C:\WINDOWS\system32\WindowsPowerShell\v1.0
(ii)in all cases this versioning applies whether XP or Win 7:
AsymptotePortable is 2.24 Dev Test 5;
TexmakerPlusPortable is 4.1.0 Dev Test 3
[2]no installed Asymptote, Miktex, or Texmaker on this particular Win 7 box;
[3]up-to-date:
(i)in all instances, Miktex has been "prepped" by updating, running AOPS 3-line batch to ensure Asymptote-required Miktex packages are installed on the fly, update MIktex again, Refresh FNDB, recreate Miktex formats. (ii)All OS's are fully up-to-date
As usual, I can't find any peculiarities in your testing methods, but unfortunately, it seems to be confined to XP still (assuming stock settings). I added the warning above and I also have saved your test results above in a separate file for when I can see if there are any noticeable patterns outside the obvious (which I can't think of a way to disable the commandline via launcher invocation). Hopefully this has a decent resolution, but, if not, there is the temporary fix of switching the Asymptote settings.
A random thought comes to mind: would setting the command window visibility to "true" for Texmaker have any difference? I think it's just the lack of sleep talking at this point but it's worth testing. I'll try it myself in the morning, but if you can test as well, that's be great.
Conclusions:
(I)TMPortable setting of command line visibility is irrelevant; only AsympotePortable setting matters;
(II)only if AsympotePortable setting of command line visibility is 'false', ie, only if "HideCommandLineWinow=true", does one get normal, No-Hang behavior for AsymptotePortable called from TMPortable on XP;
(III)one gets No-Hangs for out-of-the-box AsymptotePortable under XP called under all other circumstances: from TexStudioPlusPortable on XP, from AOPS 3-line batch file on XP;
(IV)on Win 7, No Hangs of AsymptotePortable from portable TM/Texstudio, or from batch
Results are on sterile XP:
(1)TMPortable command line visibility is as as-shipped:
of my comment "Summary...", if the CLI **visibility** is set to 'false' for AsymptotePortable, ie if "HideCommandLineWinow=true" is used in the AsymptotePortable launcher, contrary to out-of-the-box setting, then all works well--No Hangs--for "Asymptote" command from within out-of-the-box TMPortable **on XP**.
(a)as noted in
(b)but, setting the command window visibility to 'true' Is the out-of-the-box setting for AsymptotePortable since it has "HideCommandLineWinow=false"; with that for AsymptotePortable setting one always gets Hangs on XP when called from TMPortable.
(2)TMPortable command line visibility is explicitly = 'false'
ie, TMPortable launcher has HideCommandLineWindow=true, where out-of-the-box there is No setting (true or false) for HideCommandLineWindow;
(a)AsymptotePortable setting of HideCommandLineWindow is out-of-the-box, ie, "HideCommandLineWindow=false": get Hangs as ususal for this setting of HideCommandLineWindow.
(b)with AsymptotePortable launcher reconfigured to have "HideCommandLineWindow=true", results are No Hangs, as usual.
add to the Hangs (Not No-Hangs, but Hangs):
on XP with Installed TM calling AsymptotePortable
(1)Hangs of AsymptotePortable are a TM issue on XP, not a TMPortable issue; (2)Hangs are a TM issue on XP only if AsymptotePortable is configured as-is out-of-the-box; if, instead, the launcher's ".ini" file for AsymptotePortable is modified to set "HideCommandLineWindow=true" when TM execs, there are no Hangs.
(3)No Win 7 Hang issues
TMPortable looks functional enough for a Regshot. (Still need hard visual confirmation of no viewer issues for TM.)
I'm weirdly happy that this is something inherent to Texmaker and not something I managed to screw up on portablization. It doesn't make the issue any less confusing, but it sure puts a little less stress on the situation. Thanks again for testing, especially in the XP stuff where I can't.
would like to see other TM-XP-AsymptotePortable results to see if there is an explanation;
suffice it say there are some oddities in TM code, compilation, or linking; these oddities by themselves obviously do not per se indicate a no-use condition for TM, but do raise a gentle Caveat Emptor flag (if one can argue that any user becomes a 'buyer' of free software by virtue of the time investment--I certainly feel like I have made quite a purchase).
had opportunity this weekend to see TMPortable output directly on oversized monitor; looks good; all OK; the Courier-like aspect of the font rendering is gone, etc.
Pages