[tex-live] TL2004: Technical problems and testing

[Hans Hagen]

At 06:39 07/05/2004, Staszek Wawrykiewicz wrote:

>So the proposed solution for this year TL's texmf.cnf is:
>
>< TEXFONTMAPS = .;$TEXMF/fonts/map//
> > TEXFONTMAPS = .;$TEXMF/{fonts/map,dvips}//
>
>% this is OK:
>TEXPSHEADERS =  .;$TEXMF/{fonts/{enc,type1},dvips}//
>
>< ENCFONTS = .;$TEXMF/fonts/enc//
> > ENCFONTS = .;$TEXMF/{fonts/enc,dvips}//

shouldn't "dvips" be "dvips,pdftex,dvipdfmx" ?

>Anyway, the _working/global_ map files for dvips/pdftex/dvipdfm are
>maintaned by updmap and stored in $TEXMF/fonts/map/updmap/ . As I know (or
>can be wrong) only dvips can load the specific .map file from the command
>line (via -P config.XXX), so the above changes will work well for a font
>map/enc files installed in the old (dvips/) location and even they are not
>included to the global map file(s). I've just checked that.

pdftex can load the map file by means of the config file (old method, will 
become obsolete some day) as well as by means of \pdfmapfile (which has 
been around for a while, and which i use); dvipdfmx will support runtime 
mapfile loading as well (specials)

>Martin, I think that we've missanderstood that point in Bachotek.
>If we upgrade to the new pdf(e)tex, we don't need pdftex.cfg anymore.

i think that the point was in the users who have their own map file entries 
in there; all other directives would be ignored, pdftex would still load 
the cfg file if present (which is only true if users have them in their 
local tree) and a warning would be issues; also, the option was discussed 
to collect some warning and flush them at the end of the run so that users 
will not miss seeing them.

> > teTeX-3.0 will just go that way: pdfetex will be the default engine (with
> > all primitives enabled). TeX Live may well follow now, later or never...
> > It would be easier for me if the setups could be the same.
>
>More discussion is still needed... Both Thomas and me still keep our
>positions ;-))

Isn't the main problem here the forced one year cycle of new versions? I 
agree that we should be able to rigourously clean up and update (say tetex 
3) but at the same time we need to get a robust distribution in a period 
that is too short for testing all the implications of such changes. 
Unfortunately the current changes do not permit us to use updated tex/font 
files with old binaries. Fortunately we have the temf.cnf file to privide 
us backward compatibility. I can imagine that tex live ships with an 
extended texmf.cnf file (with your proposed additoons)

>
> > > - 8-bit-troubles (tcx): These have caused severe problems in the
> > >   past, but are supposed to be solved.
> >
> > We should help Olaf to find the right solution. The last statement from
> > him to me was that the automatic loading of cp8bit.tcx does not work
> > any more (due to encTeX) and that he rather desperately need feedback
> > on what to do instead.
>
>Any loading by default any cp8bit.tcx (or more transparent 8bit.tcx)
>was no good idea. Hopefully tex at all doesn't load it now. The same
>in regard of any experiments with locales...

eh ... this depends, if tex has 8-bit-in - 8-bit-out built in by default, 
ok, else we definitely need to load the cp8bit as default. Otherwise users 
who don't load it will find themselves loosing functionality they have no 
clue of how to solve. (this was last years show stopper!).

(of course i can cook up something in texexec, but it would confuse things)

Hans