Re: [NTG-pdftex] images in formats

"Martin Schröder" writes:

2007/6/27, David Kastrup :

...

"Martin Schröder" writes:

...

2007/6/27, David Kastrup :

...

For example, preview-latex uses mylatex.ltx to dump the state of the TeX at \begin{document} time. Not allowing any image references (like in \savebox commands) before that point of time is a rather brutal restriction.

Why do you need it

What? preview-latex? mylatex.ltx?

\savebox

It is the mechanism LaTeX _offers_ to users (it will commonly get used in connection with fancyhdr.sty, for example). And it uses a similar mechanism itself in \AtBeginDVI. Saying that it shouldn't is a bit late in the game.

...

...

and what do you gain by using \savebox?

Uh, it is _there_. For a reason. Saying that it (and similar functionality) should not get used anymore is creating a rather sordid restriction and backward incompatibility.

...

The speed increase is most likely minimal

The speed increase of what is most likely minimal?

The speed increase of using \savebox.

It is there and gets used.

...

...

and the document needs to read the image anyway -- unless you want to dump fragments of pdf code into the format.

In DVI mode, a pointer to the image gets dumped in the form of a special. A similarly sufficient amount of information would have to get there in PDF mode.

...

If we expanded the dvi model we would dump the meta information about pdf things and then undump them later. This needs code for dumping and undumping this meta information. And \immediate\pdfximage would still fail.

[...]

...

...

Don't forget: pdfTeX is one-pass, while TeX->dvips is two-pass.

Where is the relevance?

It was not designed with making two-pass-like solutions (which we are discussing here) working, instead the two passes are intermingled.

I don't see that. PDFTeX has to deal with boxes and hlists/vlists being boxed, reboxed, unboxed, thrown away and duplicated. So this is basically a two-pass process between creation of an object and a list-capable reference to it, and shipout. An object might appear in arbitrary duplication (including zero times) in multiple shipouts, so the multipass abstraction that makes it possible to copy boxes already needs to be present in PDFTeX.

The "sufficient amount of information" aka "meta information" is most likely not in the code in one piece and there is currently no way to dump and undump that. And a proper solution would not only handle \pdfximage, but also \pdfobj, \pdfxform, ...

Sure. But as I said, PDFTeX already _needs_ to organize its meta information in order to deal with box manipulations. -- David Kastrup