![](https://secure.gravatar.com/avatar/1058c5aefa3802978e05193b3eb09fac.jpg?s=120&d=mm&r=g)
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. My vote is also to disable \pdfrefximage and the likes in init mode. Thanh On Wed, Jun 27, 2007 at 03:24:28PM +0200, David Kastrup wrote:
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.
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
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
My vote is also to disable \pdfrefximage and the likes in init mode.
depends a bit what 'the likes' is, i can imagine that one wants to measure the dimensions of a graphic or so and store them, but indeed the ref to an imag ecan be disabled also, those who generate a format should know what they're doing/dealing with 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 -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/c0d984e1e510cf689790a5442c079a68.jpg?s=120&d=mm&r=g)
Hans Hagen
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)
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
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
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 anyhow, it's a dump related problem, not a macro package related one 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 -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/cdac1bce4ec96619cde73d2f2be4e66d.jpg?s=120&d=mm&r=g)
Hans Hagen
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
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
David Kastrup wrote:
Hans Hagen
writes: 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
Frank Küster wrote: 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.
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
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 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 -----------------------------------------------------------------
![](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
![](https://secure.gravatar.com/avatar/565476157eb3895a9c928ffce26d988d.jpg?s=120&d=mm&r=g)
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. Best wishes, Taco
![](https://secure.gravatar.com/avatar/cdac1bce4ec96619cde73d2f2be4e66d.jpg?s=120&d=mm&r=g)
Taco Hoekwater
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
![](https://secure.gravatar.com/avatar/565476157eb3895a9c928ffce26d988d.jpg?s=120&d=mm&r=g)
David Kastrup wrote:
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)?
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. Best wishes, Taco
![](https://secure.gravatar.com/avatar/c0d984e1e510cf689790a5442c079a68.jpg?s=120&d=mm&r=g)
Hans Hagen
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. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
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 -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/cdac1bce4ec96619cde73d2f2be4e66d.jpg?s=120&d=mm&r=g)
Hans Hagen
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
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.
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. -- David Kastrup
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
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 -----------------------------------------------------------------
participants (6)
-
David Kastrup
-
Frank Küster
-
Hans Hagen
-
Martin Schröder
-
Taco Hoekwater
-
Thanh Han The