pdfcurpageref -- does it make sense?
Hi, I wonder how Hans and other would solve this problem. tex doesn't have a concept of `current page' while processing the input token list. The page number can be detected reliably only using 2nd pass processing, as the page where some material ends up is known only at shipping phase. It is possible to provide a primitive which returns the *next* page object number, but IMHO it doesn't make any sense. Thanh
Feature Requests item #252, was opened at 2004-12-14 16:47 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=252&group_id=106
Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: current page object number
Initial Comment: Dear PdfTeX-developpers,
sometimes the reference to the current page object is needed within the implementation of another pdf object.
As an example may serve the `Screen Annotation' several interactive PDF features rely on.
Currently, the \pdfpageref command, which takes a page number as argument, can be used for this purpose.
It is difficult, however, to maintain a reliable page counter as the attached file demonstrates. It uses the `everyshi' package by M. Schroeder.
On the first line of every page a wrong object number is being output.
It would be very nice to have a command like \pdfcurrentpageref to be implemented in pdftex.
Thanks for your attention,
Alexander Grahn
The Thanh Han wrote:
I wonder how Hans and other would solve this problem. tex doesn't have a concept of `current page' while processing the input token list. The page number can be detected reliably only using 2nd pass processing, as the page where some material ends up is known only at shipping phase.
I use two pass solutions for that. I can imagine a primitive \pdfpageobjnum that expands at shipout time, i.e. \pdfobj{.... \pdfpageobjnum\space 0 R} in this case \pdfpageobjnum is like pdfsavepos, during shipout, those placeholders in the shipped out box are resolved; outside the otr/shipout routine it's zero, so \count15=\pdfpageobjnum leads to \count15 being 0 I guess that the reason for this request is that in media objects one needs to refer to the page where the object (or its visualization) ends up, a kin dof circular reference between definition and usage; since these page references remain in the object (and are not used elsewhere) the delayed resolution during shipout is ok;
It is possible to provide a primitive which returns the *next* page object number, but IMHO it doesn't make any sense.
indeed, things can end up many pages later (think of intermediate float flushing) 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 -----------------------------------------------------------------
Hi, using the 2nd pass processing then would solve this problem without the need to introduce a new primitive. One can record the page numbers in 1st run, and use those numbers in 2nd run as argument to \pdfpageref. Or am I missing some point? Thanh On Mon, Jan 17, 2005 at 10:11:31AM +0100, Hans Hagen wrote:
The Thanh Han wrote:
I wonder how Hans and other would solve this problem. tex doesn't have a concept of `current page' while processing the input token list. The page number can be detected reliably only using 2nd pass processing, as the page where some material ends up is known only at shipping phase.
I use two pass solutions for that.
I can imagine a primitive \pdfpageobjnum that expands at shipout time, i.e.
\pdfobj{.... \pdfpageobjnum\space 0 R}
in this case \pdfpageobjnum is like pdfsavepos, during shipout, those placeholders in the shipped out box are resolved; outside the otr/shipout routine it's zero, so
\count15=\pdfpageobjnum
leads to \count15 being 0
I guess that the reason for this request is that in media objects one needs to refer to the page where the object (or its visualization) ends up, a kin dof circular reference between definition and usage; since these page references remain in the object (and are not used elsewhere) the delayed resolution during shipout is ok;
It is possible to provide a primitive which returns the *next* page object number, but IMHO it doesn't make any sense.
indeed, things can end up many pages later (think of intermediate float flushing)
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 (2)
-
Hans Hagen -
The Thanh Han