Re: [NTG-context] ConTeXt on Debian: The wiki entry

Frank � wrote:

Hans Hagen wrote:

...

concerning fmtutil: there was a time that texexec could call fmtutil, but the lack of engine support (as taco explained, it was a trade off for simplifying the fmt suffix but part of the bargain was nog kept) as well as all kind of messy 'aliasing' going on in tex distributions (leading to dropped patterns and fonts)

Uups, what kind of aliasing? Can you point me to a place where this is discussed?

the problem is that it is not really discussed we accidentally stumbled into this when at a tug conference workshop attendents could not hyphenate; the problem was that pattern files were renamed, but aliased in an 'alias' file in one of the texmf roots; when looking at this file, more funny aliasing was taking place and i found out that quite some font problems were resulting from this, i.e. if one refers to font 'abc' which is aliased on one system but not on another ... ; normally such things are (off list) discussed with karl who then sort things out in tex live; when, at user group meetings, i had talks about 'contexts way of dealing with patterns and pattern files' and mentioned this alias mess, it was interesting to see tex experts launching up their laptops and scratching their heads over this unknown obscure aliasing feature ; in the end we found out that it was also the cause of some 'hyphen.tex' not being the real 'hyphen.tex' problem; anyhow, by now, no alias file should be present in any tex root any more; it was a bad idea anyway

...

made us decide to drop that; another reason is that distrubutions like texlive more or less assume a'wipe your system clean and install new' policy which is not possible if you have aditional trees, run older binaries with newer trees, etc,

I know that TeXlive has such an approach, but as I understood it this only extends to the TeXlive system itself: TEXMFLOCAL, TEXMFHOME and any other user-added tree should continue to work.

Pool files are a problem, but if ConTeXt has found a way to use for example different versions of pdftex and let each one find its correct pool file, I think this feature should be implemented in TeXlive, too.

pool files normally are in web2c paths; future versions of pdftex and mpost have the pool file embedded so this problem will (hopefully) disappear

...

which is why texmfstart came around: relocating script paths and enc/map paths was done in not downward compaible ways (which in turn is the reason why context ships with all kind of tools to clean up and reorganize trees etc).

Hm, it seems I really need to actually dig into what texmfstart and other ConTeXt scripts do before I can continue. I thought everybody was happy with current TDS, and also that it didn't leave important things unspecified.

texmfstart somefile will launch somefile, i.e. it is the script launcher; by using texmfstart, one can be sure that the right one is found (it also passes some info to underlying progs/scripts so that redundant kpsewhich calls don't take place; it's teh context way of dealing with non-downward compatible texlives; (it has an embedded kpsewhich written in ruby but this is disabled by default; it can also act as kpse servlet [serving multiple independent trees]; yet another feature is that it can be uses as: texmfstart --tree=sometree somescript ..... which us handy when running from cgi scripts (for that purpose it can initialize independent trees based on simple cross platform env var definiton files) well, it can do a bit more, like launching documentation and so (context ships with more tools: textools, tmftools, ctxtools, etc and when seldomly used, starting them with "texmfstart ctxtools" instead of stubs makes sense; the tex bin trees ship with potentially name-conflicting stuff, like 'access' and by launching scripts this way there is less danger of clashing names)

...

Concerning updmap, as Taco explains in another mail, context does not use updmap output; this has a long history:

- context had runtime map loading before updmap was around - we never used the 'huge map files' because it was real slow (this was fixed at some point, hash instead of linear search) - merging map entries in to one big file is dangerous (there can be multiple instances of fonts, same name, different metrics, same longname, different font etc) - we want clean and easy ways to add support for commercial fonts (which is the majority) - pdftex and dvipdfmx were adapted to do run time loading

so, there is no need to spend time on updmap for context.

But maybe other formats could profit from ConTeXt's way to do it, too: These arguments seem to apply to LaTeX and whatever else, too.

sure, one can use \pdfmapfile{somename} in any package we can even do without map files for pdftex, just use \pdfmapline

...

I have no idea what texconfig does but i don't think context needs it (i may be wrong).

I never need it... It's just a textmode-menu interface to things like editing language.dat (hyphenation patterns for latex and relatives), calling updmap, changing dvips defaults, etc.

ah, i see

...

...

I'm not sure what you mean. The default TEXMF path for teTeX (and I think also for TeXlive) is

TEXMF = {!!$TEXMFCONFIG,!!$TEXMFVAR,$TEXMFHOME,!!$TEXMFSYSCONFIG,!!$TEXMFSYSVAR,!!$TEXMFMAIN,!!$TEXMFLOCAL,!!$TEXMFDIST}

the problem with texmf is that there can be many variants, and there have been in the past; here i now have:

TEXMF={!!$TEXMFPROJECT,!!$TEXMFFONTS,!!$TEXMFLOCAL,!!$TEXMFEXTRA,!!$TEXMFMAIN}

texmfproject : a tree for project related files, these will not be wiped out with an update texmffonts : a safe place for commercial fonts, also not being wiped out (may have older tds structures) texflocal : the place for updates and specific user settings texmfextras : introduced a few years ago in texlive for non free stuff (first dvd productions) texmfmain : on my system a mere copy of the latest tex live, just the whole lot

So you don't use TEXMFVAR and user-specific trees? Anyway, I still fail to see how that's a problem for context updates. The natural approach seems to be

no var indeed; but indeed it should make no difference

- check whether context already exists anywhere except texmfmain (where the update can't go because of the wiping out)

- if yes, check whether the directory is writable

- if one answer was no, ask the user where to put it.

i could add that feature to ctxtools --update

...

interesting is that a request for texmfproject and texmffonts on the tex live list was rejected by tetex folks because they didn't want extra paths, but see what extra paths tetex adds -)

The extra paths that teTeX (and TeXlive too) add are paths with a particular role for each. From what you told me so far, I don't see what the difference between TEXMFPROJECT, TEXMFFONTS, TEXMFEXTRA and TEXMFLOCAL is, and why it is a problem for ConTeXt updates that individual admins might add trees.

they serve different purposes just like the tetex sys ones do ; for sure admins can add trees, but it would be handy if the fonts and project vars would be in the texmf list -)

...

concerning tex live: i must admit that i only copy the tree and use a much simplified texmf.cnf file which as a side effect makes tex run faster

That's an interesting point, in particular for us Debian people: We have split up texmf.cnf in individual parts (for reasons that don't matter here), and we might be able to provide a minimal texmf.cnf like yours if texlive-latex is not installed, but texlive-context is.

hm, interesting; lean and mean texmf.cnf files can speed up things a lot when playing with luatex (where i intend to replace kpse completely with a lua based variant) it is possible to have format specific file databases; this runs much faster; this whole ls-r stuff is pretty outdated

...

sure, but the fact that the 'real' names change every now and then makes it hard for users to cary a history around without renaming; also, one of the ideas behind tds and web2c was that platforms could share trees, which is what i like: i have one set of trees for running all platforms (so, texmf-local it is here)

That's not so much of a problem in Debian, because the package managment system will respect your changes and always keep texmf-local if you like. But generally I agree that this is suboptimal.

ok

...

...

AFAIK only the search path for texmf.cnf is hard-coded, and that can't be avoided. On the other hand, no one ever approached me and requested a relocation: What would you want, and in which cases?

i think that there are a few more paths in there (you sometimes see them in var expansions, but normally they don't hurt) ; life would be easier if texmfcnf was always taken from an env var; actually, i set all important env vars anyway, if only because it isolates tex distrubutions (after all we're talking about a only a few vars than determins all);

I trust you to do it right, but we've had a couple of bogus bugreports from people who set env vars wrongly, or completely forgot they ever had...

sure, but (i'm not sure if this is still true) running tex live alongside a tetex was always kind of problematic due to path settings and this autoparent mess then deriving locations of texmf.cnf from it luckilly the number of vars that one needs to set to get a nicely isolated tree is not that large (texmf, texmfcnf, texformats, and a few more)

I'll see that I or Norbert Preining look into this and come back with a more constructive proposal.

ok, thanks, Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------