[tex-live] map file / new path settings

[Thomas Esser]

> compatibility, but the problem here is "ho wis someone supposed to know 
> that already a year ago there was a change in tds", actually, if that is 

You can always only reach a small fraction of all TeX users. That's why
I suggest to make these changes now and not in a year.

> >The map file stuff is not the only point, we also no longer search
> >texmf/pdftex or texmf/etex for tex input stuff. We have done this to be
> 
> that's ok since there is nothing in there and context (and probably also 
> latex) does not use the etex src files; actually, my local texmf.cnf files 
> often drop even more funny paths -)

Well, but that is just your point of view. I can well imagine that
some people have installed additional macro packages for pdftex into
texmf/pdftex in their local tree.

You want to ignore their problems, but not yours!? Basically, it is the
same kind of problem and I'd like to handle them in the same way.

> my main concern is fonts, and not tex files or graphics; fonts often end up 
> in a local tree, but document sources in a user specific path; since tex 

I think that it helps to tell people *one* place where to put map files,
not two or three. Same for enc files etc. We are on the right way to
make things easier. But, only if we simplify the search paths.

> sure, but we can only do that when we have a mechanism for announcing that 
> in place, e.g. a place on a web page (of user groups) explaining that the 
> *next* tex live will drop this or that compatibility so that one has one 
> year to prepare; actually, on the cover there should be a reference 
> pointing to a file.

If we had that possibility to inform most TeX users, I'd agree. But,
we don't really have it and that's why I prefer to make the change now.
Maybe, it would help to put a warning message into the updmap program.
People are supposed to run it to "register" their map files. It could
generate a prominent warning about a search path change if it cannot
find a listed map file.

> one year should then be enough to let users adapt scripts etc etc

All these changes have little impact on user's work. They don't need a
year to rearrange their files or adjust their scripts. It took me about
two evenings to make the transition for TeX Live (scripts, drivers and
texmf tree). And, some of this time was merely a general removal of
duplicates and cleanup before I started the real work.

> in spite of tex running out of the box, i find myself too often explaining 
> (even to experienced users) why a file (format or whatever) is not found 

Well, I think that we have solved a great ammount of that by making a new
kpse_pdftex_config_format, so finding pdftex.cfg now works independent
of TEXINPUTS.$progname and the right setting of progname.

See, by putting the files to the right place and by using the right search
paths, things become more simple.

> regards to "it used to work but ..." (happened before when some tfm/pfb 
> names changed and afm files became gzipped and unreadable).

gzipped afm files are off-topic here.

> maybe we should consider (in pdftex) an option: \pdfmapfilepath {some 
> syntax that works ok with the $NAMES}, but then, how to feed that back into 
> kpse ...
> 
> (given this thread, i'm seriously considering to drop map files and define 
> map entries dynamically, since this is what pdftex can do nowadays, but i 
> have to find time to play with that in more detail)

Well, you might well do your own thing about map file entries at pdftex
macro level, but for me, this is no solution. I always suggest that my
users (be it teTeX or TeX Live) make their ps fonts known to updmap. That
way, they can use the fonts with pdftex, dvips, xdvi, dvipdfm etc etc. All
that you can offer is a pdftex-only solution. Any you suffer from the
problem that your macros don't know which names the font files have on
the target system.

Thomas