Texmaker Portable 4.5 Dev Test 2

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).

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.

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.

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 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.

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%

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.

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

per regshot, the following registry key is added:
HKU\...Software\QtProject\OrganizationDefaults\Qt\filedialog

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.

following DT3 download link one gets a reference to DT4

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