At 14:01 10/07/2003 +0200, Martin Schroeder wrote:
I must confess I have not cared for annotations yet so I just hope that this is correct (it certainly sounds so) and leave that to the experts.
an option is to support this under user control: \pdfmergeannots=0 : not enabled \pdfmergeannots=1 : enabled defaulting to 0 (not enabled) that way macro packages can control it also, it will need some extensive testing, esp for user annotations which may have object references, resources etc; since this would involve parsing of content, it's also a dangerous excersise (hard to make foolproof); this means that we should be able to control this at the annotation level: - links - widgets - etc so, we should need something \pdfmergelinkannots=1 etc as well
Another important this which happens within the function out_image, is the calculation to the new coordinates of the annotation's /Rect. There are no big problems if an images is scaled with the help of <rule spec> of \pdfximage. But their are a lot of problems if macro packages do something like \pdfliteral{.5 0 0 .5 0 0 cm} for scaling and similar things for rotating images. To calculate the coordinates of /Rect, pdftex must know exactly which coordinate transformations are actually taking place. So I introduced two new primitives: \pdfsetctm and \pdfresetctm.
This I find much more interesting.
this problem is more general, since it also concerns normal (not xpdf related) code; i remember discussing this with thanh a few years a go but forgot about the implications, but for out_image situations it sounds ok to me
[...]
Since TeX does not have a function to scan floating-point numbers, I used scan_dimen as a work around to scan the arguments of \pdfsetctm. That's why you must write
\pdfsetctm 0bp 1bp -1bp 0bp 0bp
so far. It should be no problem to change this in the future.
This could be added.
i don't like the unit; we could use numbers here and assume that they are scaled points (as happened in some dvi postprocessors); an alternative is to make it a token list \pdfsetctm{....} and treat each component as what it is: floating point or dimension. Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------