<< MiKTeX 2.5 and Windows Vista | copystart.exe removed from MiKTeX 2.6 >>

MiKTeX 2.6: automation interfaces

Thursday, 22 February 2007 10:34 by CSchenk

MiKTeX 2.6 will offer COM interfaces that make it possible to automate MiKTeX-specific tasks.

For example, here is a Perl script that installs a package:

use Win32::OLE;
my $packageManager = Win32::OLE->new('MiKTeX.PackageManager')
or die "MiKTeX is not properly installed.\n";
$installer = $packageManager->CreateInstaller();
$installer->Add ("$ARGV[0]", 1);
$installer->InstallRemove;

The MiKTeX interfaces are in its initial stages. Interested users and 3rd party developers are welcome to make suggestions for COM objects/methods.

Be the first to rate this post

Currently 0/5 Stars.
1
2
3
4
5

Tags:		miktex 2.6, com, perl
Categories:		MiKTeX Development
Actions:		E-mail \| Permalink \| Comments (16) \| Comment RSS

MiKTeX 2.5 development has startedMiKTeX 2.8 statusMiKTeX Tools 2.8 Beta 2

Comments

February 26. 2007 14:04

why choose COM ? it's not portable!

luoyi

February 26. 2007 22:28

Huh? COM is supported on all Windows platforms.

CSchenk

March 1. 2007 16:36

cool

stfine

March 2. 2007 17:14

Great! What I would like is a COM interface for file searching (sty, map, fonts, binaries, etc), somewhat like kpathsea.
Regarding luoyi's comment, he might be thinking of something like XPCOM, a COM-lookalike used in Mozilla/Firefox. However, I believe interfacing with Windows scripting (COM-based scripts or PowerShell) is more useful for MikTeX than interfacing with Firefox.

Lionel Fourquaux

March 6. 2007 21:08

Yes, in order to cope with UAC it was necessary to implement a COM interface for the package manager. I haven't found a better solution. It must be possibly to run TeX and friends as a restricted/standard user. When a missing package has to be installed in "C:\Program Files\MiKTeX 2.6", then the UAC elevation prompt pops up (on the secure desktop). This cannot be handled with manifests.

CSchenk

March 6. 2007 21:48

Well, I prefer the COM implementation anyway, but from the technical point of view, I don't see why this couldn't be handled using manifests: MikTeX could use a dedicated executable with a manifest that forces a UAC prompt and which installs a list of packages passed as arguments. The drawback is that it would be very hard to avoid multiple prompts, since getting a complete list of required packages would require parsing the input files. Is this problem (how to avoid multiple prompts) the reason why you say it cannot be handled with manifests?

Lionel Fourquaux

March 6. 2007 21:50

By the way, is this change related to Vista compatibility? More precisely, do you trigger UAC prompts using a COM out-of-process object rather than using dedicated commands with manifests? (I would have thought the latter would be easier to implement in MikTeX, but the COM solution is more flexible).

Lionel Fourquaux

March 7. 2007 07:47

Yes, the "only one UAC prompt per run" requirement is the main justification for a COM interface.

CSchenk

March 7. 2007 17:18

Thank you for the clarification.

Lionel Fourquaux

April 2. 2007 09:40

I guess we can use MikTex to do report.

For example, I could read data from a database, create a complete .tex file based on the data that I read out. Then compile .tex into dvi and possibly ps and pdf. I think it would be great.

Consider how flexible this can be

Van Be Hai Nguyen

April 17. 2007 08:02

I just had a look at it. I think it's very conveniant to have something like this, because, for example, after a fresh install of MiKTeX I now can run a small (VB) program that installs all the 20+ non-standard packages I frequently use.

I have a suggestion for an addition to the PackageInfo type. Something like a boolean "IsInstalled" would be nice. Yes, I know, it can be extracted from "timeInstalled" - if 1970 then it's not installed - but still...

And, of course, the comment of Van Be Hai Nguyen offers a tempting perspective

takrl

April 22. 2007 06:09

I think that adding automation interfaces is certainly a great idea. In fact seveal years ago I wrote an event-driven COM-based dvi-->PostScript driver (I called it DVIPSCOM). The basic idea is that the DVI-parsing loop is in the COM object but the output is **entirely** under the control of the client backend, which responds to the events fired from COM. In essence, the COM object exposes the values of the DVI file registers h, v, w, x, y, z and fires about 20 different events as it encounters various DVI opcodes --- such as specials, font definitions etc. This model offers enormous flexibility because you can put **ANY** \special in the LaTeX code and have your backend respond as you need.

I chose to use Perl as the backend because of ease of development. I changed the Perl backend to output SVG. I guess you could output whatever you like because the output is completely under the control of the client code as the COM component is just parsing the DVI and telling you what it sees.

Unlike Christian I am not a professional programmer, at all, just an amateur hacker, so the code is not pretty etc. I have not released this but if you'd like the source code Christian I'd be happy to send it to you.

Kind regards

Graham

Graham Douglas

August 30. 2007 13:55

After several attempts to try MiKTeX 2.6 working with Itrans 5.3 package, I have come up with a successful handshake of the MiKTeX 2.6 and Itrans 5.3 package. I had to spend some time to work on this since I was very much pleased with the automated interface of MiKTeX. I have uploaded the handshake on my URL. Anyone interested can check the Readme pdf file and also download the zip file and try on their XP. Since I do not have enough space on my URL, I will be removing the files from the web site after a month. I dont mind if anyone uploads these file on their large size URL after informing me about it.

pinakpani (Ashok Basargekar)

September 21. 2007 10:27

# re: MiKTeX 2.6: automation interfaces
Friday, March 02, 2007 5:14 AM by Lionel Fourquaux
Great! What I would like is a COM interface for file searching (sty, map, fonts, binaries, etc), somewhat like kpathsea.
Regarding luoyi's comment, he might be thinking of something like XPCOM, a COM-lookalike used in Mozilla/Firefox. However, I believe interfacing with Windows scripting (COM-based scripts or PowerShell) is more useful for MikTeX than interfacing with Firefox.

max

September 21. 2007 11:23

Great! What I would like is a COM interface for file searching (sty, map, fonts, binaries, etc), somewhat like kpathsea.

max

July 13. 2009 21:36