Hi there, what do you think about adding \pdfpagesresources primitive toks list?
Thanh: the answer is simple: nobody ever asked for it, and I don't need it for myself :). If considered it can be added without problems.
I agree we can live without \pdfpagesresources, as well as we could without \pdfpagesattr. Hovever, collecting named resources per document is much easier than per page. In many cases we don't need different /Resources dict for each page and globally assigned (identical) \pdfpageresources toks list is unnecessarily written into PDF output each time the page is shipped out. It makes a difference for big documents. Of course one can save some time and space by writing resources as objects and storing object rerefences in \pdfpageresources. But to make things cool I'd opt to add primitive \pdfpagesresources toks list. ? -- Pawe/l Jackowski P.Jackowski@gust.org.pl
Pawel Jackowski wrote:
Hi there,
what do you think about adding \pdfpagesresources primitive toks list?
Thanh: the answer is simple: nobody ever asked for it, and I don't need it for myself :). If considered it can be added without problems.
I agree we can live without \pdfpagesresources, as well as we could without \pdfpagesattr. Hovever, collecting named resources per document is much easier than per page. In many cases we don't need different /Resources dict for each page and globally assigned (identical) \pdfpageresources toks list is unnecessarily written into PDF output each time the page is shipped out. It makes a difference for big documents.
Of course one can save some time and space by writing resources as objects and storing object rerefences in \pdfpageresources. But to make things cool I'd opt to add primitive \pdfpagesresources toks list.
i'm not sure if i understand the problem, but as long as adding a top level page resource does not break individual page resources it's fine with me; i need to check the pdf ref, but do resources in the /Page object overload those on the /Pages one?; anyhow, the resources entry in a /Page object is required (with an empty dict refering to the top level one; so, whataver functionality is added, it may not change the current behaviour (needs some testing i guess) 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 Hans,
i'm not sure if i understand the problem, but as long as adding a top level page resource does not break individual page resources it's fine with me;
The only problem is that if \pdfpageresources toks list is used as global (that is probably quite common) in the PDF output we get the same code repeated as many times as number of pages in the document.
i need to check the pdf ref, but do resources in the /Page object overload those on the /Pages one?;
Resources dictionary is inheritable, but now I see that this inheritance is different than for page attributes like page boxes. I thought that if some resource can't be found in local dictionary (in /Page) it is searched in parent node (/Pages). It seems I was wrong; the following produce a corrupted PDF: \immediate\pdfobj{<>} \edef\A{/GS1 \the\pdflastobj\space0 R} \immediate\pdfobj{<>} \edef\B{/GS2 \the\pdflastobj\space0 R} \edef\next{\pdfpagesattr{/Resources << /ExtGState <<\A>> >>}}\next \edef\next{\pdfpageresources{/ExtGState <<\B>>}}\next \pdfliteral{/GS1 gs}blah \pdfliteral{/GS2 gs}blah \end It seems that /Resources dict is inherited from /Pages ONLY if there is NO local /Resources dict in /Page object. If resource dict is empty, it means that the page requires no resources. Since pdfTeX always produce /Resources dictionary for each page, the \pdfpagesresources makes no sense. Sorry for noise. Best regards, -- Pawe/l Jackowski P.Jackowski@gust.org.pl
On 2005-07-04 00:18:48 +0200, Pawel Jackowski wrote:
It seems that /Resources dict is inherited from /Pages ONLY if there is NO local /Resources dict in /Page object. If resource dict is empty, it means that the page requires no resources.
Yes. The entry for /Resources is inherited, not individual keys in the dictionary. Best Martin -- http://www.tm.oneiros.de
Pawel Jackowski wrote:
Hi Hans,
i'm not sure if i understand the problem, but as long as adding a top level page resource does not break individual page resources it's fine with me;
The only problem is that if \pdfpageresources toks list is used as global (that is probably quite common) in the PDF output we get the same code repeated as many times as number of pages in the document.
that's no problem since you can empty the toks after a shipout
i need to check the pdf ref, but do resources in the /Page object overload those on the /Pages one?;
Resources dictionary is inheritable, but now I see that this inheritance is different than for page attributes like page boxes. I thought that if some resource can't be found in local dictionary (in /Page) it is searched in parent node (/Pages). It seems I was wrong; the following produce a corrupted PDF:
\immediate\pdfobj{<>} \edef\A{/GS1 \the\pdflastobj\space0 R} \immediate\pdfobj{<>} \edef\B{/GS2 \the\pdflastobj\space0 R}
\edef\next{\pdfpagesattr{/Resources << /ExtGState <<\A>> >>}}\next \edef\next{\pdfpageresources{/ExtGState <<\B>>}}\next
\pdfliteral{/GS1 gs}blah \pdfliteral{/GS2 gs}blah
\end
It seems that /Resources dict is inherited from /Pages ONLY if there is NO local /Resources dict in /Page object. If resource dict is empty, it means that the page requires no resources.
Since pdfTeX always produce /Resources dictionary for each page, the \pdfpagesresources makes no sense. Sorry for noise.
i guessed as much -) it's made even more fuzzy by the fact that the specs say that some resources are optional but omitting them makes acrobat crash; another thing to keep in mind is that they keep changing the specs (take multiple entries: currently i think that the first one takes precedence, but in the past it has been the last; this means for instance that careless use of \pdfinfo leads to different behaviour, in itself not harmfull, but it may be worse when we deal with resources and such); best leave that part of pdftex untouched. 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 -----------------------------------------------------------------
Hans: it's made even more fuzzy by the fact that the specs say that some resources are optional but omitting them makes acrobat crash; another thing to keep in mind is that they keep changing the specs (take multiple entries: currently i think that the first one takes precedence, but in the past it has been the last; this means for instance that careless use of \pdfinfo leads to different behaviour, in itself not harmfull, but it may be worse when we deal with resources and such); best leave that part of pdftex untouched.
Lets forget about that. BR -- Pawe/l Jackowski P.Jackowski@gust.org.pl
Pawel Jackowski wrote:
Hans:
it's made even more fuzzy by the fact that the specs say that some resources are optional but omitting them makes acrobat crash; another thing to keep in mind is that they keep changing the specs (take multiple entries: currently i think that the first one takes precedence, but in the past it has been the last; this means for instance that careless use of \pdfinfo leads to different behaviour, in itself not harmfull, but it may be worse when we deal with resources and such); best leave that part of pdftex untouched.
Lets forget about that.
maybe we should have a section in the manual "considered but not implemented because ..." 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 (3)
-
Hans Hagen -
Martin Schröder -
Pawel Jackowski