[tex-k] header special extension proposal

Hendri Adriaens Hendri at uvt.nl
Mon Aug 15 08:23:59 CEST 2005


Hi,

this is a proposal for an extension of the header special that Karl and I
have been discussing about lately. We would like to hear your reactions.

Background:
===========

I was building a package that loads an (e)ps figure, embedded in some ps
code, into the setup section of a ps document, so that the figure can be
reused in the document, hence getting smaller ps files. This can be very
useful when a document has, for instance, a logo on every page in the page
header. Furthermore, presentation packages are well known to generate huge
ps files, just because of this.

In short, the problems are:

1) \special{header= doesn't work as we need to add code around the graphic.
2) reading the graphic line by line with TeX, adding the ps code and writing
the whole block using \special{! is stopped by dvips due to its line
breaking mechanism which destroys files. And it's very slow.
3) as 2, but writing the extended file to disk first and loading it with
\special{header=, but this is slow and very cumbersome and generates a lot
of space overhead.

Conclusion:
===========

We found that the current dvips special handling does not allow for a
satisfying solution to the problem faced.

Proposal:
=========

We propose to extend the header special to allow for the following notation:
\special{header={some file.pro} pre={pre code} post={post code}}
This has the effect of downloading `some file.pro' which will be surrounded
by `pre code' and `post code' before being inserted into the setup section
of the ps document.

This should be implemented in a 2 step procedure and should not be too hard
as already available mechanisms can be used. In the first step, we decide
whether the special is of the old type (entire argument is the file name) or
of the new type. This is done by checking whether the first character of the
argument is `{'. If not, usual routines will be followed. If so, we parse
the argument in a different way to find possible occurrences of `pre=' and
`post='.

Admitted, file names starting with `{' are possible in most OS's, but we
don't expect anyone to actually do that, so this new scheme should be no
problem for existing software or documents.

We are looking forward to your ideas about the proposed extension above,
especially with respect to other dvi drivers than dvips.

Best,
-Hendri Adriaens.



More information about the tex-k mailing list