Just to confirm that your approach works! The PdfImportedPage objects are
now rendered consistently (also in different pdf readers).
I save the default state directly at the beginning of the document and
restore it all the way back before adding a PdfImportedPage object. When the
document contains multiple pages it is a bit more complex because the
saveState()/restoreState() must be balanced before calling newPage(). This
means that for each new page you have to restore the default state before
calling newPage() and directly save the default state after this call.
Thanks,
Bill
Van: Mark Storer [mailto:msto...@autonomy.com]
Verzonden: woensdag 25 mei 2011 20:42
Aan: Post all your questions about iText here
Onderwerp: Re: [iText-questions] Appearance of PdfImportedPage
objectinconsistent
In this case, it's Adobe. I suspect that Foxit/Others are resetting
some-but-not-all of the graphic state when displaying an XObject Form. I
say "some" only because you're not saying that they're ignoring your
clipping rectangle or transformation matrix. Ignoring the CTM would be
Blatantly Wrong, resulting in lots of pointing and screaming. Ignoring
other bits of the graphic state is equally wrong, but more subtly so
depending on which part of the state we're talking about. Your dash style
for example.
Drawing an XObject Form implicitly creates a pushState/popState combo, but
all the existing state is still there.
Ah. PDF Ref 32000_2008, section 8.10.1 "Graphics->Form Xobjects->General".
The first paragraph reads thusly:
A form XObject is a PDF content stream that is a self-contained description
of any sequence of graphics objects (including path objects, text objects,
and sampled images). A form XObject may be painted multiple times-either on
several pages or at several locations on the same page-and produces the same
results each time, subject only to the graphics state at the time it is
invoked. Not only is this shared definition economical to represent in the
PDF file, but under suitable circumstances the conforming reader can
optimize execution by caching the results of rendering the form XObject for
repeated reuse.
Emphasis added. I suspect that Foxit etc aren't being rigorous enough with
the "under suitable circumstances" bit in the last sentence.
To drive the point home, the spec further states:
When the Do operator is applied to a form XObject, a conforming reader shall
perform the following tasks:
a)Saves the current graphics state, as if by invoking the q operator (see
8.4.4, "Graphics State Operators")
b)Concatenates the matrix from the form dictionary's Matrix entry with the
current transformation matrix (CTM)
c)Clips according to the form dictionary's BBox entry
d)Paints the graphics objects specified in the form's content stream
e)Restores the saved graphics state, as if by invoking the Q operator (see
8.4.4, "Graphics State Operators")
Except as described above, the initial graphics state for the form shall be
inherited from the graphics state that is in effect at the time Do is
invoked.
If you want to get the default state back, then you need to save the state
at the
--Mark Storer
Senior Software Engineer
Cardiff.com
import legalese.Disclaimer;
Disclaimer<Cardiff> DisCard = null;
_____
From: Bill Groom [mailto:bgr...@razcall.com]
Sent: Wednesday, May 25, 2011 10:37 AM
To: 'Post all your questions about iText here'
Subject: Re: [iText-questions] Appearance of PdfImportedPage
objectinconsistent
Hi Mark,
Thanks a lot for your response. I already thought of that workaround but was
hoping for a more "elegant" solution. Apparently there is nothing to
completely reset the graphics state to the default state directly?
I also figured out that pdf readers are rendering these kind of documents in
a different way. Adobe reader for example will render the imported pdf using
the current graphics state in the document (resulting in wrong display of
image). Foxit reader and others are using the default graphics settings for
the imported pdf in the document which results in a correct rendering of the
image. I dived into the Adobe pdf reference but cannot figure out which pdf
reader is behaving according to the pdf specs at this moment. For now I will
use your suggestion.
Thanks,
Bill
Van: Mark Storer [mailto:msto...@autonomy.com]
Verzonden: woensdag 25 mei 2011 18:16
Aan: Post all your questions about iText here
Onderwerp: Re: [iText-questions] Appearance of PdfImportedPage object
inconsistent
I'm afraid this one boils down to "Doc, it hurts when I do this".
Then Don't Do That.
If a particular page depends on a default value rather than explicitly
setting it, and that value is set prior to drawing the PdfImportedPage, then
the exlicit value will "leak through".
This is where the proper use of saveState/restoreState comes in. Going by
your sample code, you've mostly got the idea already. You just need to
restoreState all the way back to the default state before doing your
clipping and drawing your imported page.
--Mark Storer
Senior Software Engineer
Cardiff.com
import legalese.Disclaimer;
Disclaimer<Cardiff> DisCard = null;
_____
From: Bill Groom [mailto:bgr...@razcall.com]
Sent: Wednesday, May 25, 2011 2:04 AM
To: itext-questions@lists.sourceforge.net
Subject: [iText-questions] Appearance of PdfImportedPage object inconsistent
In some cases it is necessary to add pdf images and graphics to a document.
To do this I use PdfImportedPage. Unfortunately the appearance of the image
in the final document is not consistent but seems to be influenced by the
current graphics state of the document. When I use for example a dashed
stroke in the document the strokes in the imported image also become dashed
(in the original image they have been defined solid).
A similar issue occurs when text in the imported graphic pdf uses a same
font as the text in the document. In the imported pdf all fonts are embedded
(the same is true for the final document). In some cases the alignment and
spacing of characters differs from the original graphic.
It is not possible to change something in the imported images/graphics. Is
there a way to force a PdfImportedPage object to be treated as a seperate,
independent pdf without being influenced by graphics state of the document?
A snippet of the code being used:
.....
contentbyte.saveState();
contentbyte.rectangle(0, 0, 200, 200);
contentbyte.clip();
contentbyte.newPath();
PdfImportedPage image = writer.getImportedPage(reader, 1);
contentbyte.addTemplate(image, 1, 0, 0, 1, 0, 0);
contentbyte.restoreState();
.....
Thanks,
Bill
------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
iText-questions mailing list
iText-questions@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/itext-questions
iText(R) is a registered trademark of 1T3XT BVBA.
Many questions posted to this list can (and will) be answered with a reference
to the iText book: http://www.itextpdf.com/book/
Please check the keywords list before you ask for examples:
http://itextpdf.com/themes/keywords.php
