[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)
Hans
More information about the tex-live
mailing list