Taco Hoekwater writes:

noreply@sarovar.org wrote:

...

Bugs item #824, was opened at 2007-06-26 00:22 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=824&group_id=106

etc. etc.

A very quick, fast, and non-crashing solution is to disable setting \pdfoutput to non-zero in initex mode :-)

I do not think it is feasible to support the actual inclusion of image files into the format, but I dont believe that is really needed: the crash is a result of the fact that the image_array and pdf_mem are not written to the format.

So, that leaves two options: bluntly disabling \pdfrefximage et.al. in ini mode, or adding dump/undump code for those arrays. It would not be a very invasive patch, and that has my preference.

What do you think?

Well, LaTeX has a command \AtBeginDVI which has the principal purpose of saving PostScript header specials (and similar stuff) across a format dump, as used by mylatex.ltx (for example). web2c also has a trend of allowing initex for everything and making it closer to virtex (the main motivation for the latter's existence, squeezing a few dozen kilobytes of code, is no longer present). The ability to transparently dump a snapshot of TeX's state (modulo open files, but including already typeset boxes) is something which we should not lightly give up or make less functional. So it is is feasible, my vote would be on dumping the required arrays. -- David Kastrup

"Martin Schröder" writes:

2007/6/27, David Kastrup :

...

Taco Hoekwater writes:

...

A very quick, fast, and non-crashing solution is to disable setting \pdfoutput to non-zero in initex mode :-)

No, because that get's dumped and the pdf*-formats (like pdflatex.ini) set it.

My experience from the time when there was a pdftex.cfg around was that this overrode the value of \pdfoutput in the dumped format. Is this still similar, or has this changed.

...

...

So, that leaves two options: bluntly disabling \pdfrefximage et.al. in ini mode, or adding dump/undump code for those arrays. It would not be a very invasive patch, and that has my preference.

What do you think?

That's exactly what I propose to do: Disable \pdfximage and other commands (like \pdfxform and \pdfobj) that cause problems in ini mode.

...

So it is is feasible, my vote would be on dumping the required arrays.

It's not easily done; a patch would be welcomed, but be warned that this is _hard_.

I would not volunteer for further patches until I have managed to find the time to do the already promised ones. I was not sure what solution Taco had been referring to with his "not be a very invasive patch" comment above. It sounded like dump/undump, and if that would be feasible, I still think it the best idea not to make iniTeX less capable than necessary. 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.

And I seriously doubt that luaTeX needs it.

Actually, the current "dump core if hyphenation in iniTeX is attempted" inheritage from Aleph is likely even worse as an iniTeX restriction. But this is IIRC slated to get fixed (doing hyphenation on utf-8 rather than ucs-16 might help). And the image problem is a similar ball park concerning its undesirability. Again: the \AtBeginDvi command was added to LaTeX precisely in order to conserve pretypeset stuff that would otherwise get lost at a format dump. -- 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?

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? Of dumping a format with the preamble? Absolutely not. It is very relevant in preview-latex, for common editing work on single formulas easily a factor of 5. And we are talking about an interactive editing task and its response time here.

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.

...

Again: the \AtBeginDvi command was added to LaTeX precisely in order to conserve pretypeset stuff that would otherwise get lost at a format dump.

So store the commands there. Do you really need their expansion?

Not the expansion, the typeset result. This is what LaTeX uses and preserves. Since it is not untypical to put something in there which would rely on \@onlypreamble stuff, I don't see that anything except preserving the actual h/vlists could be depended on to work.

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

Where is the relevance? -- David Kastrup

"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

"Martin Schröder" writes:

2007/6/27, David Kastrup :

...

"Martin Schröder" writes:

...

\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.

This is the first user complaining in years (it has always been broken). I don't forsee many people complaining if we disable it. How many people do you know that do \includegraphics in the ini?

Disabling \pdfximage is easy, enabling it is probably much harder (Taco is investigating that), and only very few users need it (the ones raising the bug don't really unless pdfTeX dumps the complete image in the format; meta-infos won't be enough).

In DVI mode, the dumped meta-info in the special _is_ enough. It is not expected that the actual contents of included files make it into hlists/vlists or even the DVI file. If external references break when moving a format around in the tree or changing the referenced files, nobody will be very much surprised. PDFTeX should likely try to avoid crashing or acting all too unpredictable, but that's more or less all. It would seem reasonable to not change the reserved space at all in the hlist/vlist, and align the image at the upper left corner of it, regardless of what size it has now. There is the question of just when to complain when an image source has disappeared. Probably format read time would be correct. -- David Kastrup