# [tex-live] Re: [tex-k] TeX finding filenames with spaces

Hans Hagen pragma at wxs.nl
Wed Jan 14 09:27:05 CET 2004

At 07:48 14/01/2004, Staszek Wawrykiewicz wrote:
>On Tue, 13 Jan 2004, Thomas Esser wrote:
>
> > On Tue, Jan 13, 2004 at 02:04:10PM +0000, Sebastian Rahtz wrote:
> > > Don't panic yet. pdftex emits DVI as well as PDF, no problem. If you
> remake
> > > all the symlinks to point to "pdfetex" instead of "tex", and remake
> > > format files,
> >
> > Why fiddle around with symlinks? Just replace tex, etex and pdftex by
> > pdfetex in the fmtutil configuration:
> >    fmtutil --edit; fmtutil --all; texlinks -m
>
>As I can see, this thread has been messed to both mailing lists...
>1. (about the above) just only "very" short notes:
>    a) even having \pdfoutput=0 in the .ini file for XXX format generation,
>       pdf(e)tex still reads pdftex.cfg with output_format 1, so pdf
>       is forced anyway. In consequence, all users have to include
>       the proper command to all their existing input files. Objection!

Strange indeed, i've always objected to this, and never understood the
reason for defaulting to pdf mode; it's up to the macro package (i.e. user)
to choose the output format, one good reason being that only that way the
right initializations can take place for the chosen backend. In Context,
one of the first thing that happens is to set pdfoutput to zero. In the
case of latex: if pdflatex is used i guess that pdf can be enabled in the
format; so ... in any case pdf(e)tex should default to dvi output.

>    b) for many users pdf as default output is not needed at all!
>       they still need reliable output in dvi/ps which can simply crash
>       in the pdf way (not to mention professional usage -- playing
>       with color separations, transformations, etc). Sorry, but PS has
>       better defined definition than pdf, which is still in turn
>       of changing.

hm, since pdf is more resticted it's in many cases more robust than ps
code! actually, one reason for us to switch to pdf was that there were too
many problems with ps (especially fonts); the problem with pdf is not in
pdftex, since the pdf code conforms to pdf/x, a standardized subset and the
code resulting from the tex part is not tricky at all; the problem is in
pdf code that is included (graphics): and in that respect pdftex is
dependent on quality of third party data in a similar way as dvips is
dependent of (e)ps code by third parties (e.g. the output produced by
illustrator can be problematic in both eps as pdf format).

but, as said before: pdftex can produce 100% compatible dvi code, so users
can still use that output format (also, dvips still has to be part of tex
live, if only because it permits dvi -> ps -> pstoedit -> metapost cycles -)

>    c) I'm not against changing the main engine to pdfetex for all formats
>       provided that _all_ can use it as replacement of the TeX engine,
>       not only us, developers.

agreed, and as far as i can see this is possible with pdftex;

>    d) TeX engine and Plain should be also kept on TL.
>    e) I know the ideas expressed by Fabrice and Seb, but I think
>       that we still should provide all that metafont mess which you hate.
>       Otherwise, we have to change 'TeX Live' name to 'PDFeTeX Live' ;-}

since big texmf trees are much slower than small ones (which is why i use a
small subsets for production jobs) it makes sense to move much of the mf
related things to a separate texmf tree, probably one that will seldom
change; that way tex live can provide -at installation time- the option to
use that tree or not; we should consider using more trees anyway, since
this is one of the strong points of web2c:

texmf-unsupported
texmf-metafonts
texmf-experimental
texmf-main
texmf-notsognu

>2. (about filenames with spaces, as in Subject): in my thoughts it's
>    really good time to fix that in one way for _all_ distributions.
>    I'm only affraid about " as active character in many packages, like
>    German, and all output from TeX (\jobname, index, bibtex, html etc.).
>    Please do not consider only output from latex, which can be redefined
>    like \input.

indeed, (although i guess that those who make " active are users of
macropackages that can handle that situation); maybe the " should be an
option, and then it could be disabled for plain tex.

Hans