![](https://secure.gravatar.com/avatar/cdac1bce4ec96619cde73d2f2be4e66d.jpg?s=120&d=mm&r=g)
Hans Hagen
David Kastrup wrote:
Nor will it be in any output generated by iniTeX. Do you think we should turn off PDF/DVI generation completely in iniTeX? Prohibit people from generating visible output with it? If not, then it is hard to explain why images should be treated differently from other material.
again, i'm not talking of initex, but about what can end up in a FORMAT FILE and pdfimage data is not something to put in the format; initex can of course include images in a produced pdf file; i never denied that neiter did i say that initex shoul dnot produce dvi/pdf output
Cleaning the mem array of all references/nodes referring to images before dumping or when restoring sounds actually harder to do than dumping and restoring the relevant image arrays. The former requires walking all the structures. The latter concerns just PDF's additional arrays. Please note that so far the implementation proposals have been about disabling the image operators altogether in iniTeX (reasonably simple to implement), _not_ about removing image references when dumping and/or restoring.
again, we're talking of pdf data ending up in formats as a result of a ref to an xform, not about macro packages; instead of embedding the graphic one could use a reference to an external file (using an media related annotation) but that's something at the macro level and not pdftex internals
How you suppose that some macros can magically make the distinction between an iniTeX run for the sake of typesetting or an iniTeX run for the sake of dumping, I have no idea. -- David Kastrup