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

[Hans Hagen]

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