Re: dest_names_size missing in texmf.cnf
TeX Live has: % These are pdftex-specific. obj_tab_size = 20 % PDF objects dest_names_size=30 % destinations Well, I have taken this to sync all array sizes with texlive. I don't have taken settings for xmltex, jadetex stc. which are not part of teTeX, however. Thomas
Re: dest_names_size missing in texmf.cnf
On Sun, Jun 02, 2002 at 09:27:24PM +0200, Thomas Esser wrote: Well, I have taken this to sync all array sizes with texlive. I don't have taken settings for xmltex, jadetex stc. which are not part of teTeX, however. adding xmltex and passivetex to tetex would make Docbook people happy -- Sebastian Rahtz OUCS Information Manager 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
dest_names_size missing in texmf.cnf
Hi, texmf.cnf is missing some constants special for pdftex. recently I got a problem with lots of TeX buffers being exceeded (~1800 pages of output from doxygen). among those values to raise was dest_names_size which isn't mentioned at all in texmf.ch (see pdftex.ch, obj_tab_size might be another candidate ?!). btw, dest_names_size = 5 was ok for that document... Harald Koenig -- I hope to die ___ _ before I *have* to use Microsoft Word., 0--,|/OOO\ Donald E. Knuth, 02-Oct-2001 in Tuebingen._/ / /OOO\ \ \/OOO\ \ O|// Harald Koenig \/\/\/\/\/\/\/\/\/ science+computing ag// / \\ \ [EMAIL PROTECTED]^ ^
Re: dest_names_size missing in texmf.cnf
TeX Live has: % These are pdftex-specific. obj_tab_size = 20 % PDF objects dest_names_size=30 % destinations -- Sebastian Rahtz OUCS Information Manager 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
Putting texmf.cnf in a non-standard place
I'm trying to find out if it's possible to set up teTeX with texmf.cnf itself in a non-standard location. Of course, the paths for anything else can be set however you want by changing the contents of texmf.cnf; however, kpathsea still needs to be able to find the initial file in order to be able to use those paths... I can do this after the fact by setting the TEXMFCNF environment variable to point to the directory containing the preferred version texmf.cnf -- is there a way to set this at compile-time? There seems to be a DEFAULT_TEXMFCNF variable in the kpathsea sources; would just setting this to an appropriate value at compile time be sufficient? Has anyone ever tried this, and will it work? [Background as to why I might want to do this: I'm helping support the local tex installation, which is on three completely separate (and slightly different) computer systems. Cross-site customizations are put into the texmf.local directory, and each site also has a texmf.site directory with site-specific customizations. The contents of texmf.cnf should also be site-specific, so there is a different texmf.site/web2c/texmf.cnf on each site. At the moment, there's a symlink at each site from texmf/web2c/texmf.cnf to texmf.site/web2c/texmf.cnf so that it can be found. We're hoping to be able to get rid of that symlink.] Thanks a lot! MEF -- Mary Ellen Foster / ICCS / Informatics / University of Edinburgh [EMAIL PROTECTED] http://www.iccs.informatics.ed.ac.uk/~mef/ Law of Software Envelopment: Every program attempts to expand until it can read mail.
Re: Putting texmf.cnf in a non-standard place
I can do this after the fact by setting the TEXMFCNF environment variable to point to the directory containing the preferred version texmf.cnf -- is Change TEXMFCNF in texk/kpathsea/texmf.in to whatever you need. Thomas
Re: texmf.cnf for BLU
TEXMFCNF = .:{$SELFAUTOLOC,$SELFAUTODIR,$SELFAUTOPARENT}\
{,{/share,}/texmf{.local,}/web2c};c;/TeX/texmf/web2c
If I changed that to
TEXMFCNF = .:{$VARTEXMF,$SELFAUTOLOC,$SELFAUTODIR,$SELFAUTOPARENT}\
{,{/share,}/texmf{.local,}/web2c};c;/TeX/texmf/web2c
then the programs would search whatever was the value of VARTEXMF set
in the texmf.cnf at compile time, yes? if someone changes VARTEXMF at
- $VARTEXMF should be $VARTEXMF/web2c
- variables on the right side of "=" will be expanded at runtime, not
at build time
- it does not work as expected :-(
To my last point: you usually set VARTEXMF in a texmf.cnf file and not
in the environment. But, for searching texmf.cnf files, only environment
variables and the compile-time path are considered, so there is no way
for a clean solution.
Sorry for suggesting using VARTEXMF in the search path of texmf.cnf.
It was a bad idea which does not work. I don't see an easy way (without
environment variables) which helps to maintain texmf.cnf in $VARTEXMF.
Thomas
Re: texmf.cnf for BLU
* Sebastian Rahtz [EMAIL PROTECTED] writes:
If I changed that to
TEXMFCNF = .:{$VARTEXMF,$SELFAUTOLOC,$SELFAUTODIR,$SELFAUTOPARENT}\
{,{/share,}/texmf{.local,}/web2c};c;/TeX/texmf/web2c
then the programs would search whatever was the value of VARTEXMF
set in the texmf.cnf at compile time, yes? if someone changes
VARTEXMF at install time, it does not have any effect, because at
that stage it has not read texmf.cnf.
Yes, you will need to set $VARTEXMF in the environment. The $SELFAUTO*
variables are processed ok because they are in the environment.
Fabrice's proposal only works because he *does* set some environment
variables:
FPTEX = c:\Local\TeX PATH = %FPTEX%\bin\win32;%PATH% TEXMFCNF =
%FPTEX%\texmf_local\web2c
and hard-wires in this texmf_local tree.
I am reluctant to follow this, because by default it forces the
original and the local trees to be on the same drive. If someone
wants to install the original on a read-only system, and have local
configuration on a writeable system, they are screwed unless they
set environment variables, which we do not want to do.
Yes, this is the drawback. But there is an egg_and_chicken problem
there : you can't say that the location of texmf.cnf is in
... texmf.cnf itself.
I agree that my setting is not perfect, but it is simple enough for
the average windows user who sets this up on his personal machine. The
$TEXMFLOCAL tree is usually small compared to $TEXMFMAIN for those
users. People setting up this in a network environment are bound to
adjust it.
Anyway, all suggestions about what to set up are welcome. My only
requirement is that $TEXMFMAIN is not used, and that it can be erased
and replaced.
Fabrice
Re: texmf.cnf for BLU
Thomas Esser writes:
This only makes sense, if you compile kpathsea with $VARTEXMF included
in the search path for texmf.cnf files (before everything else). This is
not the case in standard teTeX, so it is correct not to copy texmf.cnf
into the VARTEXMF tree.
It does not help to set TEXMFCNF inside some texmf.cnf file to something
that includes $VARTEXMF. For texmf.cnf files, the *compile time* path
is important (I think that we all agree on not to rely on environment
variables).
For TeX Live 5, it might be possible to do this change. One migth even
consider to include $HOMETEXMF.
Can you explain this a bit more? my build-time texmf.cnf says
TEXMFCNF = .:{$SELFAUTOLOC,$SELFAUTODIR,$SELFAUTOPARENT}\
{,{/share,}/texmf{.local,}/web2c};c;/TeX/texmf/web2c
If I changed that to
TEXMFCNF = .:{$VARTEXMF,$SELFAUTOLOC,$SELFAUTODIR,$SELFAUTOPARENT}\
{,{/share,}/texmf{.local,}/web2c};c;/TeX/texmf/web2c
then the programs would search whatever was the value of VARTEXMF set
in the texmf.cnf at compile time, yes? if someone changes VARTEXMF at
install time, it does not have any effect, because at that stage it
has not read texmf.cnf.
Fabrice's proposal only works because he *does* set some environment
variables:
FPTEX = c:\Local\TeX
PATH = %FPTEX%\bin\win32;%PATH%
TEXMFCNF = %FPTEX%\texmf_local\web2c
and hard-wires in this texmf_local tree.
I am reluctant to follow this, because by default it forces the
original and the local trees to be on the same drive. If someone wants
to install the original on a read-only system, and have local
configuration on a writeable system, they are screwed unless they set
environment variables, which we do not want to do.
Staszek, since you are on the same system as me, can you describe
exactly how you would ideally like the TeX system a) compiled, and b)
installed?
sebastian
Re: texmf.cnf for BLU
Staszek Wawrykiewicz writes:
It is still not clear what can be changed in the local/user
configuration. For example, teTeX 1.0.7 texconfig do not make a copy of
texmf.cnf to the $VARTEXMF (if it was set, and as it was in previous
versions).
um. you want us to change the install programs to copy texmf.cnf if
VARTEXMF is set? I'll experiment.
Please have a look at the actual fragment of texmf.cnf from
TeX Live5 alpha:
% PostScript headers, prologues (.pro), encodings (.enc) and fonts;
% this is also where pdftex finds included figures files!
TEXPSHEADERS.pdflatex = .;$TEXMF/{tex,pdftex,dvips,fonts/type1}//
point taken. I think its too late now to change pdftex for my TeX Live
release, but Thanh should really change pdftex to look at the `normal'
path for Type1 fonts
The last one variable is rather not for ``where pdftex finds included
figures files!'', I'm rather sure that nobody put his figures here ;-),
but is _very important for finding first_ texmf/pdftex/config/psfonts.map
(which, in turn, can be different from texmf/dvips/config/psfonts.map).
The last question: if pdf* do not use psfonts.map from the dvips/config/
(or it use it as the last resort) why it use the same file name?
Some time ago it used pdftex.map and it was enought clear...
I assume that Thanh though that people _would_ use the same file, but
now we see that it isn't such a good idea (they two files in my setup
are rather different, though both derived automatically from the same
sources).
I am not sure how to solve either of your concerns about *.pdf* in
texmf.cnf, to be honest. I certainly agree that what we have now is messy
Sebastian
texmf.cnf for BLU
It is still not clear what can be changed in the local/user
configuration. For example, teTeX 1.0.7 texconfig do not make a copy of
texmf.cnf to the $VARTEXMF (if it was set, and as it was in previous
versions).
I can understand the idea of having some optimization or not allowing
somebody to mess such important file and making all needed local
changes by running only texconfig, but I'd like suggest to leave some
freedom to many experienced users (in many cases, they know better
what should be done with TeX stuff configuration than their admins ;-)
There are several reasons for having local|user|$VARTEXMF texmf.cnf:
1. the user can have his own format file, so, e.g., TEXINPUTS should be
modified (preferably) in the texmf.cnf local copy.
As it can be seen from many mails:
2. TEXEDIT can be set by the the user to the prefered editor. Some prefer
vi, some emacs, etc. Again, local texmf.cnf is the best place.
3. The user can add another variant of pdf(*)tex in texmf/web2c/fmtutil.cnf
Please have a look at the actual fragment of texmf.cnf from
TeX Live5 alpha:
% PostScript headers, prologues (.pro), encodings (.enc) and fonts;
% this is also where pdftex finds included figures files!
TEXPSHEADERS.pdflatex = .;$TEXMF/{tex,pdftex,dvips,fonts/type1}//
TEXPSHEADERS.pdfelatex = .;$TEXMF/{tex,pdftex,dvips,fonts/type1}//
TEXPSHEADERS.pdftexinfo = .;$TEXMF/{tex,pdftex,dvips,fonts/type1}//
TEXPSHEADERS.pdfcslatex = .;$TEXMF/{tex,pdftex,dvips,fonts/type1}//
TEXPSHEADERS.pdfcsplain = .;$TEXMF/{tex,pdftex,dvips,fonts/type1}//
TEXPSHEADERS.pdfetex= .;$TEXMF/{tex,pdftex,dvips,fonts/type1}//
TEXPSHEADERS.pdfjadetex = .;$TEXMF/{tex,pdftex,dvips,fonts/type1}//
TEXPSHEADERS.pdfmex = .;$TEXMF/{tex,pdftex,dvips,fonts/type1}//
TEXPSHEADERS.pdftex = .;$TEXMF/{tex,pdftex,dvips,fonts/type1}//
TEXPSHEADERS.pdftexinfo = .;$TEXMF/{tex,pdftex,dvips,fonts/type1}//
TEXPSHEADERS.cont-de= .;$TEXMF/{tex,pdftex,dvips,fonts/type1}//
TEXPSHEADERS.cont-en= .;$TEXMF/{tex,pdftex,dvips,fonts/type1}//
TEXPSHEADERS.cont-nl= .;$TEXMF/{tex,pdftex,dvips,fonts/type1}//
TEXPSHEADERS.context= .;$TEXMF/{etex,tex,pdftex,dvips,fonts/type1}//
TEXPSHEADERS = .;$TEXMF/{dvips,fonts/type1,pdftex}//
---
For each variant of pdf(*)tex we have exactly the same value (??!).
If the user add (in fmtutil.cnf) some other variant (say: pdfplatex),
he has to introduce also at least 2 lines in texmf.cnf:
TEXINPUTS.pdfplatex = .;$TEXMF/{pdftex,tex}/{platex,latex,generic,}//
(it is really needed for some optimization)
...
TEXPSHEADERS.pdfplatex = .;$TEXMF/{tex,pdftex,dvips,fonts/type1}//
(it is _not_ really needed, but I do not know how to change it
for all pdf* variants)
The last one variable is rather not for ``where pdftex finds included
figures files!'', I'm rather sure that nobody put his figures here ;-),
but is _very important for finding first_ texmf/pdftex/config/psfonts.map
(which, in turn, can be different from texmf/dvips/config/psfonts.map).
The last question: if pdf* do not use psfonts.map from the dvips/config/
(or it use it as the last resort) why it use the same file name?
Some time ago it used pdftex.map and it was enought clear...
I remember Thomas' work with updmap. Perhaps old ideas are not so bad...
Staszek Wawrykiewicz
email: [EMAIL PROTECTED]
texmf.cnf
Hi, we're using tetex 1.0.9 on a Solaris 2.6 OS. One of the users wishes to modify the value of the TEXMFCNF variable, to import his own texmf.cnf file. Apparently this worked in tetex 0.9pre, but with 1.0.9 he has the following problems: bash% export TEXMFCNF=`kpsewhich texmf.cnf`; latex Mue11 This is TeX, Version 3.14159 (Web2C 7.3.1) ---! Must increase the trie size (Fatal format file error; I'm stymied) If someone knows a solution, let me hear it, please:-) Cheers, Matthias
Re: texmf.cnf
we're using tetex 1.0.9 on a Solaris 2.6 OS. One of the users wishes to modify Hey, where did you get this? I don't know anything of a 1.0.9 version. the value of the TEXMFCNF variable, to import his own texmf.cnf file. Set TEXMFCNF to the *directory* that the texmf.cnf file is in, not to the file itself. Thomas
Re: texmf.cnf
Date: Thu, 02 Mar 2000 09:20:32 +0100 From: Matthias Schweinoch [EMAIL PROTECTED] we're using tetex 1.0.9 on a Solaris 2.6 OS. One of the users wishes to modify the value of the TEXMFCNF variable, to import his own texmf.cnf file. Apparently this worked in tetex 0.9pre, but with 1.0.9 he has the following problems: bash% export TEXMFCNF=`kpsewhich texmf.cnf`; latex Mue11 This is TeX, Version 3.14159 (Web2C 7.3.1) ---! Must increase the trie size (Fatal format file error; I'm stymied) Sounds like the sizes in his texmf.cnf are incompatible with the sizes with which the format file has been generated. He will most probably need to generate his own format files to go with his texmf.cnf settings, or adapt a few changed settings from the newly changed 1.0.9 texmf.cnf file. It might also be that some missing sizes are making tex give up. -- David Kastrup Phone: +49-234-32-25570 Email: [EMAIL PROTECTED] Fax: +49-234-32-14209 Institut für Neuroinformatik, Universitätsstr. 150, 44780 Bochum, Germany
