On Sun, 27 Nov 2011 05:39:40 -0800
Leonard Rosenthol <[email protected]> wrote:
>> You could, I suppose, just copy the source page stream into the
>> destination page stream, surrounded by the appropriate transform
>> operators.
>
> It's a bit more complex than that - but that's the "gist".
Yes, you would have to fix the object references to refer to the
destination page dictionary. Anything else?
>> I should say that one of the intended applications for this program
>> would be, for example, to lay out a 3*4 array of a single business
>> card image on a letter-size sheet of paper. Using XObjects would
>> seem to be the only way to do that without bloating the file size by
>> a factor of twelve, unless I'm missing something.
>
> You are probably missing a lot, since there isn't anything that would
> imply that one method would necessarily bloat over the other - given
> proper and complete implementation.
Suppose that for some reason, the original PDF file uses 100KB of
graphics operators, without using any (image or form) XObjects
itself. If the resulting page image is duplicated twelve ways without
making use of a "subroutine" with a Form XObject, how could an increase
of the page stream length to 1.2MB be avoided?
> Certainly, a quick & dirty implementation w/o consideration for all
> potential "bloat factors" would lead to that - but you have a higher
> chance of that happening with the Xobject model than other models.
Why would that be, since the XObject method would avoid the sort of code
duplication described above?
>> Do you have any suggestions as to how to fix the program I presented
>> in my first message? I suspect that the source XObject needs to be
>> added to the destination page dictionary, or something like that, but
>> I'm not quite clear on how to do that, as with the two lines which
>> have been commented out.
>
> It needs to be added to the Resources dictionary of the page
The PdfXObject class has a method called GetIdentifier() which is
described as "get the identifier used for drawing this object".
What does this refer to, if not an entry which has already been made in
some global resources dictionary?
PDF specification section 7.8.3 says
"For a content stream that is the value of a page's Contents entry
(or is an element of an array that is the value of that entry), the
resource dictionary shall be designated by the page dictionary's
Resources or is inherited, as described under 7.7.3.4, "Inheritance
of Page Attributes," from some ancestor node of the page object."
Why won't that work?
> - but aren't there methods for that.
I don't know; the PdfDictionary class isn't documented, as I already
mentioned.
> I still don't understand why the infrastructure of podofoimpose won't
> work for you.
It won't work for anybody; it's fundamentally broken, for any file which
uses images. See the bug report I filed months ago:
http://sourceforge.net/apps/mantisbt/podofo/view.php?id=28
> Or why it couldn't be modified to work?
If I could find out how the PdfXObject class is supposed to work in
Podofo, I might be able to fix it.
But I would also be able to write an imposition program that does a lot
more than that one.
-- Ian Bruce
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Podofo-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/podofo-users
