# [NTG-pdftex] images in formats

David Kastrup dak at gnu.org
Wed Jun 27 15:00:35 CEST 2007

"Martin Schröder" <martin at oneiros.de> writes:

> 2007/6/27, David Kastrup <dak at gnu.org>:
>> "Martin Schröder" <martin at oneiros.de> writes:
>> > 2007/6/27, David Kastrup <dak at gnu.org>:
>> >> 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