Hans Hagen wrote:

Thanh Han The wrote:

...

dumping an image in pdf mode is rather difficult to get right. If in dvi mode an image is "stored" by a reference to an external file, then I am afraid the speed gain is not that much. There is for sure some comfort by having a dumped file reference in the format, but again that can be also achieved for pdf mode using some macros IMHO.

to me it looks like a rather useless option to include an image in a format, just as we don't embed type 1 fonts in the format either so let's not waste energy on it

You know that you just said "To me it looks like a rather useless option to include an image in a \savebox in the LaTeX preamble", or "To me it looks like a rather useless option to support preview-latex in PDF mode even for people who use \savebox with images in their preamble"?

also, those who generate a format should know what they're doing/dealing with

David knows, but preview-latex just takes the LaTeX preamble which its users have written. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)

Hans Hagen writes:

Frank Küster wrote:

...

Hans Hagen wrote:

...

...

dumping an image in pdf mode is rather difficult to get right. If in dvi mode an image is "stored" by a reference to an external file, then I am afraid the speed gain is not that much. There is for sure some comfort by having a dumped file reference in the format, but again that can be also achieved for pdf mode using some macros IMHO. to me it looks like a rather useless option to include an image in a

Thanh Han The wrote: format, just as we don't embed type 1 fonts in the format either so let's not waste energy on it

You know that you just said "To me it looks like a rather useless option to include an image in a \savebox in the LaTeX preamble", or "To me it looks like a rather useless option to support preview-latex in PDF mode even for people who use \savebox with images in their preamble"?

no, i was talking about a 'format' i.e. a \dump'd thing, i have no clue what \savebox does, and it may do image trickery as much as it likes but in the end the image will not be in the format file

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.

...

...

also, those who generate a format should know what they're doing/dealing with

David knows, but preview-latex just takes the LaTeX preamble which its users have written.

afaik the problem only occurs when a \dump is done and an option is then to \let\dump\end or so

And this will generate a format to be used later just how?

anyhow, it's a dump related problem, not a macro package related one

mylatex.ltx is a macro package for dumping formats transparently. It is not like I have not explained several times that this is done in preview-latex by default without user intervention, for performance reasons. It is also important to fill any repeatedly/globally used saveboxes in the preamble, since otherwise it will not be possible to recompile a region (which is done by using the preamble together with the region, and no code in between). The WhizzyTeX system also dumps formats more or less at every document section, in order to provide fast screen updates. This also is transparent to the user. I find it annoying how legitimate concerns and existing _standard_ use cases and packages are simply brushed aside or ignored. While there may be priorities that make it necessary to postpone a proper implementation, it is not because people putting forward their concerns and presenting their use cases are idiots or weirdos that can safely be ignored. -- David Kastrup

Hans Hagen writes:

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

Taco Hoekwater writes:

David Kastrup wrote:

...

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.

I just uploaded a patch for this bug that dumps the image meta information to the format. That should solve the problem, I hope.

Thanks, this would definitely seem like the right thing to do. This may sound like a quite stupid question: is there a publicly accessible repository for PDFTeX (apart from TeXlive itself)? -- David Kastrup

2007/6/28, Taco Hoekwater :

Not right now. Martin and I are working on setting up a pdftex repository at supelec, but it seems Fabrice is one vacation at the moment.

Not vacation, but semesters end -- he simply has no time. Best Martin

Frank Küster wrote:

Hans Hagen wrote:

...

...

I find it annoying how legitimate concerns and existing _standard_ use cases and packages are simply brushed aside or ignored. While there may be priorities that make it necessary to postpone a proper implementation, it is not because people putting forward their concerns and presenting their use cases are idiots or weirdos that can safely be ignored. 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

I'm not sure I understand you. Do you mean that macro packages should use a different way of embedding graphics than they do now? If I understand you right, this would require that every existing macro package for graphics inclusion should be changed, because otherwise it couldn't be used together with preview-latex or whizzytex.

when used with some tool, macro packages may as well know that they're doing that; in that case one can add an extra directive in the preamble images are just part of such a story, think of multi pass data needed for initialization, immediate written objects, or opened files (where some kind of appending need to take place when the snapshot format is used, etc; if i had to deal with that in context, i'd make sure that i'd removed all things that can possibly interfere and use a special preview mode (if only not to have users confronted with messy docs that use multipass info for optimization) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

David Kastrup wrote:

Hans Hagen writes:

...

...

Hans Hagen wrote:

...

...

I find it annoying how legitimate concerns and existing _standard_ use cases and packages are simply brushed aside or ignored. While there may be priorities that make it necessary to postpone a proper implementation, it is not because people putting forward their concerns and presenting their use cases are idiots or weirdos that can safely be ignored. 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 I'm not sure I understand you. Do you mean that macro packages should use a different way of embedding graphics than they do now? If I understand you right, this would require that every existing macro package for graphics inclusion should be changed, because otherwise it couldn't be used together with preview-latex or whizzytex. when used with some tool, macro packages may as well know that

Frank Küster wrote: they're doing that; in that case one can add an extra directive in the preamble

Hans, no, they may not possibly know that: dumping a format as part of a tool like preview-latex or WhizzyTeX or mylatex.ltx _very_ much is _not_ known to macro packages: those tools would be pretty pointless if they only worked with macro packages that knew about them.

hey, i'm not saying that dumping a format is not feasible, but only that there may be problems along the road that are hard to foresee, for instance, when in such a preamble 239 bytes are written to an immediately opened file, you' better be sure that this happens again when the dumped format is loaded (i.e. reopen the file, goto pos 340, hope that the old stuff is still therem and such); same for immediate objects and so (ok, that is different for dvi because there pdf related things end up in specials); (btw, you could inject an additional style loading in front of a preview run i guess)

...

images are just part of such a story, think of multi pass data needed for initialization, immediate written objects, or opened files (where some kind of appending need to take place when the snapshot format is used, etc; if i had to deal with that in context, i'd make sure that i'd removed all things that can possibly interfere and use a special preview mode (if only not to have users confronted with messy docs that use multipass info for optimization)

Take a look at mylatex.ltx. It does exactly that and works with the overwhelming majority of LaTeX documents out of the box.

even packages like mylatex probably have to know a bit about what they're dealing with and probably assume certain things i.e. they only work with macro packages that they know about -) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------