Q: how to incldue an external directory listing?

[mark....@gmail.com]

I would like a

\begin{verbatim}

\end{verbatim}

block with the contents of this block taken from a external directory
listing command like:

ls */*.lisp */*/*.lisp

On a similar subject, for documents with programming examples, I
externally run a command file to execute sample programs and then
insert the generated output using something like:

\begin{lstinputlisting}[language=myruby]{code/collections.rb}
\end{lstinputlisting}

Produces:

\begin{lstinputlisting}{code/collections.rb.out} \end{lstinputlisting}

It would be great if I could execute external commands from withing
LaTex to run the sample programs automatically during the Latex
processing. ANy idea?

Thanks,
Mark

[Robin Fairbairns]

"mark....@gmail.com" <mark....@gmail.com> writes:
>I would like a
>
>\begin{verbatim}
>
>\end{verbatim}
>
>block with the contents of this block taken from a external directory
>listing command like:
>
>ls */*.lisp */*/*.lisp

\usepackage{verbatim}
...
\immediate\write18{ls */*.lisp */*/*.lisp > lisp-files}%
\verbatiminput{lispfiles}

most distributions set up with these shell escapes disabled: under
tetex 3 you enable them with

latex -shell-escape <tex file name>

>On a similar subject, for documents with programming examples, I
>externally run a command file to execute sample programs and then
>insert the generated output using something like:
>
>\begin{lstinputlisting}[language=myruby]{code/collections.rb}
>\end{lstinputlisting}
>
>Produces:
>
>\begin{lstinputlisting}{code/collections.rb.out} \end{lstinputlisting}
>
>It would be great if I could execute external commands from withing
>LaTex to run the sample programs automatically during the Latex
>processing. ANy idea?

you could also use perltex, or adapt perltex for use with ruby.

sure, you can do it. however, all mechanisms i know (straight
hand-crafted \write18 of various sorts, and perltex) are rather clunky
-- you have to start a new process to execute your shell commands or
whatever.

the future is all wonderful: jonathan fine has a mechanism that's
apparently far more efficient, and there's a version of pdftex under
development with a lua interpreter built-in (which will of course make
your coffee at the start of the run, and have dinner waiting by the
time your document's finished).
--
Robin Fairbairns, Cambridge

[Will Robertson]

Robin Fairbairns wrote:
>
> the future is all wonderful: jonathan fine has a mechanism that's
> apparently far more efficient, and there's a version of pdftex under
> development with a lua interpreter built-in (which will of course make
> your coffee at the start of the run, and have dinner waiting by the
> time your document's finished).

Ha ha ha, you make my day Robin.
It's going to be interesting to see if or how XeTeX will influence
LuaTeX's development. It's certainly unfortunate to have two
incompatible engines.

Will

[Ralf Stubner]

"Will Robertson" <wsp...@gmail.com> writes:

> It's going to be interesting to see if or how XeTeX will influence
> LuaTeX's development. It's certainly unfortunate to have two
> incompatible engines.

I am not sure if LuaTeX will take much input from the XeTeX side. AFAIK
pdfTeX is gaining its own Unicode/OpenType/... support called "oriental
TeX". There isn't much info about this on the net, but some minor things
can be found in this thread on the aleph mailing list:
<URL:http://www.ntg.nl/pipermail/aleph/2005-December/>

cheerio
ralf

[Robin Fairbairns]

oh goody! yet another tex engine thread. and being developed in
semi-secret, too! just what we need.
--
Robin Fairbairns, Cambridge

[mark....@gmail.com]

Hello Robin,

Thank you so much!

I tried your suggestion and it works great and then I did some reading
on the verbatim environment.

Best regards,
Mark Watson - Sedona Arizona

[Taco Hoekwater]

Here is the deal:

LuaTeX will be the successor of pdfTeX, I trust you all
know that by now.

There has been talk about adding OpenType support to pdfTeX
for a very long time now, I assume you know that as well.

Aleph development has practically stopped (not sure if you
all knew that).

Thanks to a joint grant from Colorado State University and TUG
that was approved at the end April of this year, it will be
feasible to integrate the Aleph functionality into LuaTeX, add
Unicode and OpenType support, and lift the quality of the Arabic
typesetting to a much higher level then it is now, all to be
finalized before the next summer.

None of this is a secret, and if you would have taken the effort
to investigate the progamme of the past EuroTeX (that, btw, was
curiously lacking participants), you would have noticed that
there was a talk and paper about this exact subject.

There is no "another tex engine" being developed, only the
natural successor of pdfTeX. Thanks to the integration of
Aleph, one separate engine will even be re-integrated.

There is a mailing list, source repository, and a website
(see http://www.luatex.org ). The language on the mailing
list is english, and the source repository is available
on-line for anybody wanting to join the project
( https://foundry.supelec.fr/projects/luatex ).

Sure, the web site is behind a bit, but I prefer writing code
(and actually making programming deadlines) over updating web
pages and pleasing c.t.t. readers. Sorry if you feel left
behind.

A note about XeTeX:

There will not be much LuaTeX can borrow from XeTeX, because
pdfTeX should stay portable and reliable (in terms of typeset
results) across all the various supported systems. XeTeX as it
stands runs only on three platforms, and uses different external
system libraries and system-installed fonts on each of those,
making it inherently non-portable in the TeX sense.

This may all change in the future, but that is the current
state of the beast.

Greetings,

Taco

[Robin Fairbairns]

"mark....@gmail.com" <mark....@gmail.com> writes:
>Thank you so much!
>
>I tried your suggestion and it works great and then I did some reading
>on the verbatim environment.

since i wrote that, i've read the intro notes on miktex 2.5, and i see
it's introduced pipe input and output methods. something very like
what you're after is mentioned in the blurb.

spooky synchronicity, i think ;-)
--
Robin Fairbairns, Cambridge

[David Kastrup]

Taco Hoekwater <ta...@elvenkind.com> writes:

> Robin Fairbairns wrote:
>> Ralf Stubner <ralf.s...@physik.uni-erlangen.de> writes:
>>
>>>"Will Robertson" <wsp...@gmail.com> writes:
>>>
>>>>It's going to be interesting to see if or how XeTeX will influence
>>>>LuaTeX's development. It's certainly unfortunate to have two
>>>>incompatible engines.
>>>
>>>I am not sure if LuaTeX will take much input from the XeTeX side. AFAIK
>>>pdfTeX is gaining its own Unicode/OpenType/... support called "oriental
>>>TeX". There isn't much info about this on the net, but some minor things
>>> can be found in this thread on the aleph mailing list:
>>> <URL:http://www.ntg.nl/pipermail/aleph/2005-December/>
>>
>> oh goody! yet another tex engine thread. and being developed in
>> semi-secret, too! just what we need.
>
> Here is the deal:
>
> LuaTeX will be the successor of pdfTeX, I trust you all
> know that by now.

[...]

From what I read about it, LuaTeX is more or less equipping a dungeon
with drapes: making the best of being locked in.

TeX has been designed with an implementation and extension language of
Pascal at a time where modularity was not more than an abstract
concept. You can read in tex.web, for example,

@ A |whatsit_node| is a wild card reserved for extensions to \TeX. The
|subtype| field in its first word says what `\\{whatsit}' it is, and
implicitly determines the node size (which must be 2 or more) and the
format of the remaining words. When a |whatsit_node| is encountered
in a list, special actions are invoked; knowledgeable people who are
careful not to mess up the rest of \TeX\ are able to make \TeX\ do new
things by adding code at the end of the program. For example, there
might be a `\TeX nicolor' extension to specify different colors of ink,
@^extensions to \TeX@>
and the whatsit node might contain the desired parameters.

The present implementation of \TeX\ treats the features associated with
`\.{\\write}' and `\.{\\special}' as if they were extensions, in order to
illustrate how such routines might be coded. We shall defer further
discussion of extensions until the end of this program.

These kinds of extensions are limited in their usefulness already:
they can't take up space in the output, for example, and can't meddle
with the typesetting algorithms. Yet they ingrain themselves into the
main loop and do far more than one could do with stuff written in
TeX's macro language.

eTeX more or less is an extension according to the original idea, but
the original idea was more or less that everybody create his own eTeX
according to the needs of a particular task. The sparsity of
individual TeX extensions pretty much shows that this concept does not
cut it.

NTS and exTeX more or less are supposed to offer better ways of
extensibility by changing to a more modular language and code basis.
Nevertheless, they merely replace one low-level procedural
implementation language by another, and still the way of interfacing
into it means that algorithmic extensions are not feasible on a
per-document or per-format style.

Lua might be nicer, but I am skeptical about whether LuaTeX has a
chance to open TeX's innards in a manner where you can indeed
implement something like the original "TeX extensions" without having
to mess with the Pascal code base and binaries.

In that respect, Ant looks more compelling as a concept.

--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
UKTUG FAQ: <URL:http://www.tex.ac.uk/cgi-bin/texfaq2html>

[William F. Adams]

Taco Hoekwater wrote:
> A note about XeTeX:
>
> There will not be much LuaTeX can borrow from XeTeX, because
> pdfTeX should stay portable and reliable (in terms of typeset
> results) across all the various supported systems. XeTeX as it
> stands runs only on three platforms, and uses different external
> system libraries and system-installed fonts on each of those,
> making it inherently non-portable in the TeX sense.
>
> This may all change in the future, but that is the current
> state of the beast.

Not quite.

XeTeX only uses two different layout options, one for OpenType fonts
which is provided on all versions of it, and another which uses AAT
(Apple Advanced Typography) and is specific to the Mac OS X version.

Usage w/ OpenType fonts uses the ICU layout code and will return
equivalent results on all systems.

Depending on how one counts platforms, there's certainly more than
three:

- Mac OS X (PPC or Intel)
- Windows (XP or 2000)
- Linux (x86, PPC, AMD64)
- Solaris (SPARC)

and it should compile on other Unix-like systems --- is there a
platform not listed above which you think should be supported which
would be worthwhile?

William

[Will Robertson]

Taco Hoekwater wrote:
> None of this is a secret, and if you would have taken the effort
> to investigate the progamme of the past EuroTeX (that, btw, was
> curiously lacking participants), you would have noticed that
> there was a talk and paper about this exact subject.

Ouch. I only wish I could have attended. Flights from Australia aren't
the cheapest.
Given that we've only just received the EuroTeX 2005 proceedings by
mail, I wouldn't be surprised to find out that the above isn't actually
yet common knowledge.

Here's a link to the slides for the pdftex extensions discussed at
EuroTeX, by the way:
<http://matexhu.org/eurotex2006/lectures/pdftex/>
(Careful of that 7MB "fontreader" PDF -- it's not interesting! In fact,
what is it?)

Slides aren't a particularly verbose way to learn from; I look forward
to the paper(s); I guess it won't be availabe for a while... All in
all, it looks very exciting, especially given the time frame. We may
all have to learn Lua before the year's out!

> A note about XeTeX:
>
> There will not be much LuaTeX can borrow from XeTeX, because
> pdfTeX should stay portable and reliable (in terms of typeset
> results) across all the various supported systems. XeTeX as it
> stands runs only on three platforms, and uses different external
> system libraries and system-installed fonts on each of those,
> making it inherently non-portable in the TeX sense.

As William has already mentioned, a document compiled with an OpenType
font will result in identical output on any platform supported by
XeTeX. This is through its use of the ICU OpenType rendering library; I
can't see any reason here to want to reinvent the wheel. Of course,
it's only a component of the system you're discussing.

Certainly seems to be interesting times ahead.
Many thanks,

Will

[Taco Hoekwater]

Hi all,

Sorry about crossposting, but I feel i have to reply to two threads
at the same time.

Will Robertson wrote:
> Here's a link to the slides for the pdftex extensions discussed at
> EuroTeX, by the way:
> <http://matexhu.org/eurotex2006/lectures/pdftex/>
> (Careful of that 7MB "fontreader" PDF -- it's not interesting! In fact,
> what is it?)

That file is a graphical presentation of traditional TeX's process
of loading a TFM file, in 700 or so steps (each a metapost graphic
page).

> As William has already mentioned, a document compiled with an OpenType
> font will result in identical output on any platform supported by XeTeX

Apologies. It seems I have misunderstood how that part of XeTeX
works. Does that imply that it can also access uninstalled
OpenType fonts directly?

I was not trying to be dismissive of XeTeX in my post. Someone
asked exactly how XeTeX would affect pdfTeX developments, so I
answered that question the way I see it.

For the record: I like the idea of XeTeX a lot. I have almost no
time to play with it myself, unfortunately.
(but that was not the question, so I didn't answer it :-))

> This is through its use of the ICU OpenType rendering library; I
> can't see any reason here to want to reinvent the wheel. Of course,
> it's only a component of the system you're discussing.

IIRC, ICU does not support the microtypography already present in
pdfTeX (font expansion, hanging punctuation). But if it does, or if
it is likely that it will start doing so in the very near future,
than it is definately worth looking into (so please let me know).

Best wishes,

Taco

[Ralf Stubner]

Taco Hoekwater <ta...@elvenkind.com> writes:

> Will Robertson wrote:
>
>> As William has already mentioned, a document compiled with an OpenType
>> font will result in identical output on any platform supported by XeTeX
>
> Apologies. It seems I have misunderstood how that part of XeTeX
> works. Does that imply that it can also access uninstalled
> OpenType fonts directly?

No, but that is irrelevant for getting identical output. System specific
libraries are only used to locate the OpenType font on the system, much
like kpsearch is used for searching in TEXMF trees. When it comes to
producing typeset output the ICU library is used on all platforms.

There have been feature requests for supporting uninstalled OpenType
fonts. AFAIK one of the tricky things here is that XeTeX itself knows
the concept of font families. So simply using something like kpsearch to
look for a given file name would be a bit limited in the general case
(but still useful in some cases).

cheerio
ralf

[William F. Adams]

Taco Hoekwater wrote:
> Apologies. It seems I have misunderstood how that part of XeTeX
> works. Does that imply that it can also access uninstalled
> OpenType fonts directly?

On Windows it can, well, it can access fonts which aren't being loaded
by Windows or a font manager, but are found by the fc-cache utility
based on a list in the fonts.conf file. On Mac OS X they need to be
loaded by the system or a font manager (well, I know Linotype Font
Explorer works for this).

But I agree, and I'd really like a similar facility to avoid the need
to remember to load fonts for XeTeX on Mac OS X as well.

> IIRC, ICU does not support the microtypography already present in
> pdfTeX (font expansion, hanging punctuation). But if it does, or if
> it is likely that it will start doing so in the very near future,
> than it is definately worth looking into (so please let me know).

Correct. There's been some discussion of this however, and if memory
serves, there's a font feature for AAT fonts which allows something
along these lines, but no fonts seem to use it.

One can of course use the code from the TeXbook for this within its
limitations, unfortunately, one has to hope the font includes a hyphen
which hangs out into the margin since one can't hack it in a .tfm as
one can w/ pdftex &c.

William