iText either creates new objects or manipulates existing ones read from a
PDF. New objects are not reachable and are generally written immediately to
disk; all that is left is a PdfIndirectReference, just a number. Existing
objects exist in a PdfReader object list and are linked to the xref. In this
case the PRIndirectReference knows about the PdfReader and the object list
so, it can retrieve the object. You want to create new objects that behave
like existing ones and that will only be possible if you inject them in
PdfReader so that they behave like existing ones.
Paulo
----- Original Message -----
From: "Mark Storer" <[EMAIL PROTECTED]>
To: "Paulo Soares" <[EMAIL PROTECTED]>;
<[email protected]>
Sent: Friday, March 10, 2006 8:19 PM
Subject: RE: [iText-questions] Problem with PRIndirectObject vs
PdfIndirectObject during
>
> Third problem: Earlier, I'd created some custom field
> appearances and put them in the /I of the /MK (so my spiffy
> new button flattening code can take over). But that /I isn't
> a PRIndirectReference, its a PdfIndirectReference. How do I
> look up the true object of that PdfIndirectReference? That
> value is held only in PdfWriter.formXObjects, but you can't
> read anything from it.
When you get to there the real object was already written to disk.
I'm using a PdfStamperImp... which looks like it doesn't pass the formXObjs
off to the writer->body until close()... I take it that's what you meant by
peaceful coexistance?
Earlier, I'd changed PdfIndirectReference so that its type was always
INDIRECT (which caused some problems later on with code expecting a
PRIndirectReference). Previously, PdfBody.getIndirectReference returned an
instance of PdfIndirectReference (not PR) such that isIndirect()==false.
Very Strange to me, so I 'fixed' it. I can see the logic behind that now,
but I'm sticking to my guns on that one, and trying to fix the underlying
problem (not being able to get at newly created objects from a
PdfIndirectReference).
I'm currently experimenting with a change to PdfIndirectReference... letting
it keep a pointer to the object it reffers to. In BaseObject, setIndRef
will update the PdfIndirectReference's reference to the BaseObject in
question. I've got a hazy notion that this could cause problems, but I
can't think of a concrete reason why just yet.
It could still cause problems in a PdfStamperImp after close(), but so do
lots of other things.
If I type 'reference' a couple more times, someone may need to reffer me to
a good psychiatrist.
I can see why Acrobat's API (used in plugins, PDFL, and a couple API clones
out there) forces you to specify a document every time you create a new
object. Yow.
It seems that a better solution would be to have a generic container of
PdfIndirectObjects that could be shared by readers and writers alike
(something like a CosDoc). Build one with a PdfReader (or from scratch),
and hand it to a PdfWriter to write the file. It shouldn't be necessary to
specify a particular container when creating the Pdf* objects... when
finally added to an object that /did/ specify a container, that container
could be propigated through all the 'orphan' objects, which would then take
up residence in the container.
PdfReader would no longer be the arbiter of IndirectReferences (yup,
psychiatrist time). You'd query the container instead. It would take quite
a bit of renumbering when importing from other documents though... after
which picking out shared resources could get tricky. Hmph. Pros and cons.
Deriving an ImportedStream from PdfStream could make that go considerably
smoother (and PdfArray, and PdfDictionary... everything else would be
relatively innocuous... perhaps PdfString).
We've already talked about you sending your changes for eventual
inclusion.
Ah, but the changes I'd hold back aren't anything that would be generally
useful.
Useful:
Changing the flattening code so it can whip up appearances for fields that
don't have them, and draws everything in the correct z-order?
Sure.
Adding the ability for BaseField & co. to suck all their layout/format/etc
information from an existing field?
Yep.
Updating AcroFields.getAppearance() to support RadioCheckField and
PushbuttonField?
You got it.
[pending: The ability to look up newly created objects through a
PdfIndirectReference?
Of course.]
Not so useful:
Being able to take CIC.com's proprietary free-hand-drawing format and
sticking it into a button's icon found through a reference in the text field
where that drawing was stored as a string?
Not so handy.
Going into a LiquidOffice form, extracting the formatting information from a
particular document-level javascript stream for what we call a 'template
field' (one where the value is split across several different fields) and
splitting the value out to those different fields using our funky naming
scheme?
Nobody cares but me.
Updating one of our 'signature fields' (a stack of up to 4 different buttons
and a multi-line text field) so the correct pass/fail button is visible and
the 'sign it' button isn't covering the text field?
Not going to miss it.
That was a lot more verbose than it needed to be. Ah well. Back to work.
--Mark Storer
Senior Software Engineer
Cardiff Software
#include <disclaimer>
typedef std::Disclaimer<Cardiff> DisCard;
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Paulo
Soares
Sent: Friday, March 10, 2006 2:10 AM
To: Mark Storer; [email protected]
Subject: RE: [iText-questions] Problem with PRIndirectObject vs
PdfIndirectObject during
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Mark Storer
> Sent: Friday, March 10, 2006 12:41 AM
> To: [email protected]
> Subject: [iText-questions] Problem with PRIndirectObject vs
> PdfIndirectObject during
>
> And I just figured it out... but I'll share with everyone so
> they can avoid my mistake[s].
>
> I've just now figured out the difference between a
> PRIndirectObject and a PdfIndirectObject. PR's come from an
> existing PDF, Pdf might be something new (or a PR).
>
> I did something like this:
>
> --------------
> stamper.setFormFlatten(true);
> addSomeNewObjects();
> ripOutStuffWeWontNeed()
>
> reader.removeUnusedObjects(); // boom
>
> stamper.close();
> --------------
>
> Zeroth problem: I'm trying to make PdfObject-level changes
> from outside com.lowagie.pdf.*. Kids, don't try this at
> home, we're trained professionals... Ow! My clavicle!
>
> First problem: Removing objects from the reader won't matter
> much when you write everything out through a stamper. Silly
> me. Or will it? Does the stamper do a 'reachability' check
> later? Or does it just write everything out starting with
> the trailer, catalog, and so on until it's written everything
> reachable?
>
It writes everything that's in the object list unless it's null, of
course. This means that to erase an object it must be made null in the
object list and that the xref must be put to zero for that object.
> Second problem: When creating the new objects, PdfWriter
> gives you PdfIndirectObjects. In hooking those objects into
> the PDF, you've added non-PRs into the PdfReaders objects.
> When you call removeUnusedObjects, you've asked PdfReader to
> step through all its objects and ditch any orphans. It
> expects nothing but PR's. Bad Things happen.
>
This is really only to be used after reading the PDF.
> This caused a ClassCastException on line 2520 (after fixing
> one instance were a PdfIndirectObject worked just as well, I
> don't recall the line number on that one).
>
> I get the feeling this level of manipulation from outside
> com.lowagie.pdf is going to be increasingly painful. I
Not really but you must separate existing objects from the objects you
create. They can be mixed but you'll have to be careful. See
the code in
PdfStamperImp in the flatten method for a peaceful existence between
objects.
> really don't want to put code specific to my company within
> *.pdf, but it's looking more and more like that's my only
> route. I suppose I could stick it in a different /src tree.
> BTW: it's not like I'm doing anything magical or secret
> there, I just don't want to put my-particular-use specific
> code into the general library namespace.
>
Paulo
> --Mark Storer
> Senior Software Engineer
> Cardiff Software
>
> #include <disclaimer>
> typedef std::Disclaimer<Cardiff> DisCard;
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking
> scripting language
> that extends applications into web and mobile media. Attend
> the live webcast
> and join the prime developer group breaking into this new
> coding territory!
> http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642
> _______________________________________________
> iText-questions mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/itext-questions
>
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking
scripting language
that extends applications into web and mobile media. Attend
the live webcast
and join the prime developer group breaking into this new
coding territory!
http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642
_______________________________________________
iText-questions mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/itext-questions
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
iText-questions mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/itext-questions
