Frank � wrote:
> Hans Hagen <[EMAIL PROTECTED]> 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
-----------------------------------------------------------------
_______________________________________________
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context
