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
