[tex-live] map file / new path settings
pragma at wxs.nl
Sat Jan 24 16:58:19 CET 2004
At 20:42 23/01/2004, Thomas Esser wrote:
>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.
no, it's more that i (wildly) guess that users put their tex file in a
local place or tree, while tex related font files are placed in the tree by
programs; so i expect less problems with tex files than with the lesser
known files (that are magically produced by utilities and so)
> > 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.
get me right, i agree with you on making things simple; i only want to make
sure that for some time old things keep working; most users kno wwhat to do
when they get a message that a tex file is not found (tex simply waits) but
everything related to fonts is more depressing and obscure (e.g. you find
out too late that an encoding vector or map file has changed and that the
wrong one was used, or a file cannot be found (it takes a while to know if
the vf or tfm file is the troublemaker) or ...
so, it's the *font* aspect that troubles me, since that's for most users
the most difficult and obscure part of tex
>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.
how difficult would it be to write all error messages to jobname.error.log
(messages concerning missing glyphs, etc)
> > 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.
but how many fonts do you have in your tree system that are not part of tetex?
> > 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.
sure, and when pdftex does no longer aborts when no cfg file is found that
will not bring troubles for (context) users since the config file is kind
> > 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.
i used them as an illustration of a change in the distribiution that broke
things; it also demonstrates that (and i fall into that trap more often
than i want) something that works here not need to work there (in that
respect it is already a miricle that te/fp/*tex work the way they do)
>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
which has the danger of getting conflicts in the file since the current
naming scheme permits the same name for fonts (esp slanted and caps) which
in fact may differ and have different metrics (ok, i know that this is off
topic, but it's one reason for problematic pdf/ps files being around)
>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
hm, i wonder why people always think that i'm only aware of pdftex; i use
dvips in mp related trickery; and, dvipdfmx is quite well supported as
well; i would not be surprised if Chof will also support the pdftex map
control features (just as dvipdfmx supports all other pdftex features,
which means that context files work equally well with both systems, and for
cjk even better with dvipdfmx -)
>problem that your macros don't know which names the font files have on
>the target system.
indeed a problem
so, to repeat myself: i have no problem with improvements in the tree, but
i do have problems with sudden changes in some areas; anyhow, i'll just
redirect questions that will arise to this list -)
More information about the tex-live