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?
> 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.
> 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.
> 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.
> 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.
>> 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
- 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.
> 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.
> 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.
> 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.
>> 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...
I'll see that I or Norbert Preining look into this and come back with a
more constructive proposal.
Regards, Frank
--
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)
_______________________________________________
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context
