[tex-live] map file / new path settings

Hans Hagen pragma at wxs.nl
Fri Jan 23 18:45:37 CET 2004

At 18:07 23/01/2004, Thomas Esser wrote:

>We have waited a year to follow the TDS standard. At some point we have to
>drop backward compatibility, else the search paths are getting more and
>more complicated. The search paths have already been complicated and we
>have rearranged things -- if we want to be "old texmf tree" compatible,
>the search paths have to be set up even more complicated than they have
>ever been before.

i agree with the statement that we should not be rigid in backward 
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 
the case, why wasn't pdftex adapted to it before tex live went to iso-image

(some time ago the dutch hyphenation filename changed, and i as well 
asother dutch language support people ended up answering questions why 
things didn't work any more; in general, the problem is: how do we reach 
those who need to know what to change)

>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 -)

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 
already has a bad reputation of installing fonts and get 'm working, such a 
change could ruin the reputation even more

>able to simplify the search paths. I don't see the point in keeping the
>search paths compatible. If we do this, people will not rearrange the
>files in their local tree and they will be hit next year.

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.

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

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 
and how the tree is organized (not neccessarily related to context); i fear 
that (since quite some context users use commercial fonts or fonts that 
come with the system) i'll have to answer all kind fo questions with 
regards to "it used to work but ..." (happened before when some tfm/pfb 
names changed and afm files became gzipped and unreadable).

>My opinion is to meke a clear cut now and to write some notes about the
>changes into the documentation. We should even drop texmf/fontname from
>TEXFONTMAPS and just go with
>   TEXFONTMAPS = .;$TEXMF/fonts/map//

i never understood the purpose of texmf/fontname so i have no problems with 
dropping that -)

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)


More information about the tex-live mailing list