Hi, I got the latest issue of TUGboat today and read Hans' article about LuaTeX with great interest. Obviously Hans had the enhancement of [pdf]TeX in mind. But I think that much more can be done with it. Given that LuaTeX allows shell-escapes, I think that it makes a lot of sense to replace some Perl scripts by LuaTeX. For instance, Heiko fixed two bugs in epstopdf I reported but I did not get any response from the author of the C-version which still resides on CTAN. http://ctan.org/tex-archive/support/epstopdf This version is still broken. TeXLive does not provide Perl for Windows users and I suppose that MikTeX doesn't as well. Instead, binaries are provided. If someone detects a bug, a fixed Perl script can be provided for UNIX users immediately but Windows users still depend on someone who provides new binaries. Though I like Perl very much I think that LuaTeX is quite great. It can be make things much more portable. Suppose that someone ports epstopdf to LuaTeX, then Windows users can update easily. There is one problem concerning how [pdf]TeX reads the command line. [pdf]TeX expects a filename and considers all arguments which come before the filename as options. It complains if an option is not known. However, options after the filename are accessible by TeX. Try the following file: getargs.tex __________________________________________________________________ \def\OptionPrefix{-} \newlinechar=`\^^J \def\echo#1{\message{^^J#1}} \def\car#1#2\\{#1}\def\cdr#1#2\\{#2} \def\DefineOption#1#2{\expandafter\def\csname:opt:#1\endcsname{#2}} \def\ProcessOption#1{\csname:opt:#1\endcsname} \def\ProcessFile#1{\echo{File: "#1"}} \def\TestOption#1{% \expandafter\ifx\csname:opt:#1\endcsname\relax \echo{Unknown Option "#1", ignored} \else \ProcessOption{#1} \fi } \def\GetArg#1 {\setbox0=\lastbox\endgraf \if\OptionPrefix\car#1\\ \edef\Arg{\cdr#1\\} \TestOption\Arg \else \ProcessFile{#1}\expandafter\end \fi } %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \DefineOption{abc}{\echo{Known Option "abc"}} \DefineOption{def}{\echo{Known Option "def"}} \everypar{\GetArg} __________________________________________________________________ When I say tex -abc getargs -def -uvw xyz I get: $ tex -abc getargs -def -uvw xyz tex: unrecognized option `-abc' This is TeX, Version 3.141592 (Web2C 7.5.4) (./getargs.tex) Known Option "def" Unknown Option "uvw", ignored File: "xyz" No pages of output. Transcript written on getargs.log. Though it is good that TeX makes all arguments available to TeX which come after the filename, there is a problem if getargs is a format file. In this case the command line looks like getargs -abc -def -uvw xyz and everything before "xyz" is lost. In other words, if you say epstopdf -hires myfile.eps TeX will complain epstopdf: unrecognized option `-hires.' How can this problem be fixed? The current behaviour of web2c is absolutely correct but I assume that LuaTeX users need a bit more. Is it possible to convince [pdf]TeX to ignore unknown options for particular format files by adding some lines to texmf.cnf similar to TEXINPUTS.latex = ... which disable commandline option checking and pass everything to TeX? Another point: It would be nice if LuaTeX allows shell-escapes. This might be regarded as beeing unsecure. What about having a list of trusted programs in texmf.cnf? Regards, Reinhard -- ---------------------------------------------------------------------------- Reinhard Kotucha Phone: +49-511-4592165 Marschnerstr. 25 D-30167 Hannover mailto:reinhard.kotucha@web.de ---------------------------------------------------------------------------- Microsoft isn't the answer. Microsoft is the question, and the answer is NO. ----------------------------------------------------------------------------
Reinhard Kotucha wrote:
Given that LuaTeX allows shell-escapes, I think that it makes a lot of sense to replace some Perl scripts by LuaTeX. For instance, Heiko fixed two bugs in epstopdf I reported but I did not get any response from the author of the C-version which still resides on CTAN.
http://ctan.org/tex-archive/support/epstopdf
This version is still broken. TeXLive does not provide Perl for Windows users and I suppose that MikTeX doesn't as well. Instead, binaries are provided. If someone detects a bug, a fixed Perl script can be provided for UNIX users immediately but Windows users still depend on someone who provides new binaries.
i've never used epstopdf so maybe i talk non-sense, but running perl on windows is rather trivial: there is a good installer, and it comes with many libs included (more than on a standard linux install) if the win tex distributions ship with 'binaries' they are not c binaries, but probably zipped 'perl binary + script ' archives; there is actually no reason for this so if a windows user wants to use the raw scritp with his system perl, aal he/she has to do is - install perl - copy stub files [runperl.exe -> whatever.exe] - put perl scripts in tesmf scripts path and things should run ok (for context users i recommend using "texmfstart whatever.pl" in stub files)
Though I like Perl very much I think that LuaTeX is quite great. It can be make things much more portable. Suppose that someone ports epstopdf to LuaTeX, then Windows users can update easily.
so, although your proposal is ok from the prespective of portability, it's not needed from the perspective of windows concerning portability ... in principle all those shell scripts that now need to be provided as c program of perl script on windows qualify for some kind of luafying (we can even consider putting lua itself in the bin distributions; it's small) (context ships with a ruby ps->pdf script and converting that would take quite some lua code -)
There is one problem concerning how [pdf]TeX reads the command line. [pdf]TeX expects a filename and considers all arguments which come before the filename as options. It complains if an option is not known. However, options after the filename are accessible by TeX.
Try the following file:
getargs.tex __________________________________________________________________ \def\OptionPrefix{-}
\newlinechar=`\^^J \def\echo#1{\message{^^J#1}}
\def\car#1#2\\{#1}\def\cdr#1#2\\{#2}
\def\DefineOption#1#2{\expandafter\def\csname:opt:#1\endcsname{#2}}
\def\ProcessOption#1{\csname:opt:#1\endcsname}
\def\ProcessFile#1{\echo{File: "#1"}}
\def\TestOption#1{% \expandafter\ifx\csname:opt:#1\endcsname\relax \echo{Unknown Option "#1", ignored} \else \ProcessOption{#1} \fi }
\def\GetArg#1 {\setbox0=\lastbox\endgraf \if\OptionPrefix\car#1\\ \edef\Arg{\cdr#1\\} \TestOption\Arg \else \ProcessFile{#1}\expandafter\end \fi }
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\DefineOption{abc}{\echo{Known Option "abc"}} \DefineOption{def}{\echo{Known Option "def"}}
\everypar{\GetArg} __________________________________________________________________
When I say
tex -abc getargs -def -uvw xyz
I get:
$ tex -abc getargs -def -uvw xyz tex: unrecognized option `-abc' This is TeX, Version 3.141592 (Web2C 7.5.4) (./getargs.tex) Known Option "def" Unknown Option "uvw", ignored File: "xyz" No pages of output. Transcript written on getargs.log.
Though it is good that TeX makes all arguments available to TeX which come after the filename, there is a problem if getargs is a format file.
In this case the command line looks like
getargs -abc -def -uvw xyz
and everything before "xyz" is lost.
In other words, if you say
epstopdf -hires myfile.eps
TeX will complain
epstopdf: unrecognized option `-hires.'
How can this problem be fixed?
The current behaviour of web2c is absolutely correct but I assume that LuaTeX users need a bit more.
i can imagine that we provide access to the raw commandline (i assume that this info is availabl esomewhere)
Is it possible to convince [pdf]TeX to ignore unknown options for particular format files by adding some lines to texmf.cnf similar to
TEXINPUTS.latex = ...
which disable commandline option checking and pass everything to TeX?
Another point: It would be nice if LuaTeX allows shell-escapes. This might be regarded as beeing unsecure. What about having a list of trusted programs in texmf.cnf?
this is always a tricky thing and i've pondered a lot about it; there are several cases that make sense: 1 - permit nothing 2 - permit everything 3 - permit only programs in same path as calling binary (e.g. pdftex) resides 4 - permits only programs in texmftree 5 - permits only programs in given list (and maybe combinations) so we need a setup like: progname.systemlist=...;...;...; progname.systemstate=<number> for context it would be enough to have context.systemlist=texmfstart context.systemstate=5 since texmfstart will handle the rest Hans
"Hans" == Hans Hagen
writes:
so, although your proposal is ok from the prespective of portability, it's not needed from the perspective of windows
Yes, but it is a bit annoying that you have to download and install all the software under windows which is part of any Linux distribution. At work I installed cygwin for this reason. I'm really tired from downloading/installing all the tools I need. It would be ok if Perl gets installed by the TeXLive installer.
concerning portability ... in principle all those shell scripts that now need to be provided as c program of perl script on windows qualify for some kind of luafying (we can even consider putting lua itself in the bin distributions; it's small)
Maybe. But I think that as a replacement for shell scripts, Perl/Tk is a better choice (with emphasis on Tk). But then we need a Perl which is aware of kpathsea so that the module path can be set in texnf.cnf. I doubt that anyone wants to maintain it.
(context ships with a ruby ps->pdf script and converting that would take quite some lua code -)
Will look into your ruby file when I have more time. It seems that not everybody is satisfied with epstopdf...
i can imagine that we provide access to the raw commandline (i assume that this info is available somewhere)
Yes, but it would be good if we could convince tex (the program) not to complain so loudly if there is an option it doesn't know. Regards, Reinhard -- ---------------------------------------------------------------------------- Reinhard Kotucha Phone: +49-511-4592165 Marschnerstr. 25 D-30167 Hannover mailto:reinhard.kotucha@web.de ---------------------------------------------------------------------------- Microsoft isn't the answer. Microsoft is the question, and the answer is NO. ----------------------------------------------------------------------------
Reinhard Kotucha wrote:
"Hans" == Hans Hagen
writes: so, although your proposal is ok from the prespective of portability, it's not needed from the perspective of windows
Yes, but it is a bit annoying that you have to download and install all the software under windows which is part of any Linux distribution.
sure but installation of perl (ruby. puthon) is trivial under windows (btw, i alway send up installing programs like unzip and wget etc which are not part of standard suse linux installations, so there's always something left to install -)
At work I installed cygwin for this reason. I'm really tired from downloading/installing all the tools I need. It would be ok if Perl gets installed by the TeXLive installer.
ah, cygwin ... i never use that (i only copied the ssh -related- things to a special path); nowadays most tools are available as native windows binaries
concerning portability ... in principle all those shell scripts that now need to be provided as c program of perl script on windows qualify for some kind of luafying (we can even consider putting lua itself in the bin distributions; it's small)
Maybe. But I think that as a replacement for shell scripts, Perl/Tk is a better choice (with emphasis on Tk).
sure, but in that case shipping the lua interpreter as part of the tex binaries makes sense (it's small);
But then we need a Perl which is aware of kpathsea so that the module path can be set in texnf.cnf. I doubt that anyone wants to maintain it.
i wrote a kpse class in ruby so doing it in lua is probably a matter of translation ... we'll see
(context ships with a ruby ps->pdf script and converting that would take quite some lua code -)
Will look into your ruby file when I have more time. It seems that not everybody is satisfied with epstopdf...
i can imagine that we provide access to the raw commandline (i assume that this info is available somewhere)
Yes, but it would be good if we could convince tex (the program) not to complain so loudly if there is an option it doesn't know.
sure; the problem is -as always- in compatibility but i think that we should not be too afraid to change those interface aspects and i always wondered why tex complained about that - it does not hurt to ignore unknown options (well, we can always make complaining an option itself, configurable in the cnf file, off by default) Hans
"Hans" == Hans Hagen
writes:
sure but installation of perl (ruby. puthon) is trivial under windows
Some hours ago Staszek said that TL provides Perl. So my assumption was wrong.
ah, cygwin ... i never use that (i only copied the ssh -related- things to a special path); nowadays most tools are available as native windows binaries
Cygwin also provides an X11 server, hence programs like xpdf work. It's really cool. When you start cygwin, a shell window appears. Simply type `startx' and you get an XTerm. You can run any X11 application then. Before I installed cygwin I had not been aware that I can use teTeX under Windows. And I compiled GNU octave under cygwin without any problems while this is impossible under SuSE because they do not provide a Fortran compiler any more. Is't worth a try, disk space has never been so cheap as today. However, maybe you prefer the Windows GUI, but I'm very unhappy if I don't have emacs and bash and have to use programs which are compiled without libreadline.
Yes, but it would be good if we could convince tex (the program) not to complain so loudly if there is an option it doesn't know.
sure; the problem is -as always- in compatibility but i think that we should not be too afraid to change those interface aspects and i always wondered why tex complained about that - it does not hurt to ignore unknown options
(well, we can always make complaining an option itself, configurable in the cnf file, off by default)
Sounds good. Regards, Reinhard -- ---------------------------------------------------------------------------- Reinhard Kotucha Phone: +49-511-4592165 Marschnerstr. 25 D-30167 Hannover mailto:reinhard.kotucha@web.de ---------------------------------------------------------------------------- Microsoft isn't the answer. Microsoft is the question, and the answer is NO. ----------------------------------------------------------------------------
participants (2)
-
Hans Hagen
-
Reinhard Kotucha