[tex-live] Proposal for collection reorganization

[Hans Hagen]

Norbert Preining wrote:
> Hi Robin, hi all!
>
> On Son, 04 Jun 2006, Robin Fairbairns wrote:
>   
>>>>   pdf-trans -- Transformations of TeX boxes for pdfTeX.
>>>>         
>>> this one is not related to LaTeX, should be left standalone.
>>>       
>> as anyone who cared to read the catalogue entry would have known.
>>     
>
> Ok.
>
>   
>> when did thumbpdf stop being a standalone script (called by a shell
>> wrapper).
>>     
>
> In fact I have reverted this change in Debian. Currently in TL it is a
> link to texexec, which executes the .pl in TEXMFDIST. I moved for the
> Debian packages the .pl script into /usr/bin instead of the link. I
> would say this makes more sense.
>   

thumbpdf is not related to context or texexec so i think that there is 
an error there:

texexec = self resolving stub to calling parent => texexec.pl

pdfthumb => link to texexec => self resolving stub to calling parent => 
pdfthumb.pl

anyhow, the context texexec.pl script has been replaced by a ruby variant

the recommended way to cal context related scripts (for unix) is as 
follows but there are alternatives possible (up to the packager)

- copy texmfstart.rb (from scripts/context/ruby) to a 
someplace/bin/texmfstart

- create stubs in bin, either manually, or by using:

texmfstart --make all

such a stub looks like:

#!/bin/sh
texmfstart texexec.rb $@

so, texmfstart is the launching program. I've introduced this approach 
for several reasons:

- this way i'm independent of changes in tds (i only need to adapt 
texmfstart) in the sense that i can provide backaward compatibility 
(i've been bitten in the tail too often)
- it does some caching of paths (passing kpse lookups to child calls) 
when scripts call other ones which speeds up processing
- by using 'texmfstart somescript' directly one does not need stubs 
which avoids conflicts with names
- it can be used (in web server apps) to  initialize multiple tex trees 
(needed when one runs old and new trees in parallel)
- it can act as a kpse server (by using a built in kpse functionality) 
which in more complex workflows is faster
- it can locate and launch documentation and/or assiciated programs
- it can be used to launch application that need full paths to resource 
files in the texmf tree
- some more

the collection of scripts that come with context is rather large and not 
all of them need to be stubbed; the prefered list is:

texexec (former perl script, now ruby script with integrated texutil; 
manages tex runs and creates formats)
texutil   (former perl script, now ruby script, stripped down 
functionality, will become obsolete
texfont  (perl script, will be ruby script some day, creates tex font 
metric files)
pstopdf (former perl script, now ruby script, assumes gs and optionally 
imagemagick and inkscape to be present)
mptopdf (perl script, will become integrated in mpstools)
makempy (perl script, will become integrated in mpstools)
ctxtools (ruby script)
pdftools (ruby scrip)
xmltools(ruby script)
textools (ruby script)
mpstools(ruby script)
tmftools (ruby script)
exatools (ruby script)
runtools (ruby script)
rlxtools (ruby script)

existing aliases in the alias file (when present) related to context 
need to be  removed (should not have been present in the  first place)

in order  to work well with xetex, aleph and pdftex, contex assumes that 
the TEXFONTMAPS path is set to: (i get reports that this is not the case 
in linux distributions)

TEXFONTMAPS   = .;$TEXMF/fonts/map/{$progname,pdftex,dvips,}//

So far,

Hans