[tex-live] map file / new path settings

[Hans Hagen]

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 
of redundant

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

Hans