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