> -----Original Message-----
> From: Kevin Galligan [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, April 11, 2002 3:52
> To: 'Jeremy Bowman'; [EMAIL PROTECTED]
> Subject: RE: PdfGraphics2D class (RE: [iText-questions] generating
> graphs )
>
> I think you'll have to forget copyArea as well. Much of the Graphics 2D
> spec is targeted to raster graphics (although printing from java apps is
> supported by the G2D object as well). There's certainly a lot we can do
> with the primitives, but some of them are really not going to work out.
> Unless the pdf spec includes a copyArea style primitive, there are really
> only 2 options. Create an off-screen buffer and paint the image to the
> pdf
> (<-- bad), or record all function calls, traslate, clip, and play back all
> the paints. I'm not very familiar with templates, but is that basically
> what a template is? Then I guess copyArea wouldn't be that bad (assuming
> you can clip the repaint of the template). Can you paint a template to a
> template? To handle copyArea you'd have to create a new template, paint
> the
> old one to it, translate, clip, paint the old template again, then go from
> there with the new template. I've done some java games, and that's the
> only
> place I've ever seen copyArea used. It seems like more of an interactive
> thing.
>
copyArea is raster oriented. If it's needed it's best to draw to a
BufferedImage.
> Some of the paint object stuff is hairy as well. Its designed to describe
> a
> raster paint. You'd have to somehow map that to pdf's equation stuff
> (which
> I'm also not an expert of). I have both the O'Reilly Java 2D Graphics and
> the Adobe PDF Reference books. I'd highly recommend both for this type of
> thing.
>
Things are better here. Jim's implementation even supports textures.
I provided an example with this yesterday.
> As far as the graphics state, I can't imagine how you would do this
> without
> that. You'd never be able to back out of your clipping. You also
> wouldn't
> be able to return the document back to its original state. If you have
> the
> saves and restores balanced it'll work. Debugging pdf output is not easy.
>
This is not hard, it's only a matter of balancing save/restore and
keeping track of the setColorFill().
> To figure out my clipping problem I have to modify the PdfContentByte code
> to print the pdf doc without encryption.
>
Use Document.compress = false to disable compression.
Best Regards,
Paulo Soares
> -Kevin
>
> > -----Original Message-----
> > From: Jeremy Bowman [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, April 10, 2002 10:26 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: PdfGraphics2D class (RE: [iText-questions] generating
> > graphs)
> >
> >
> > Wow, there was a lot of discussion on this today...I'll just
> > throw out some
> > responses to points Jim made in case any of it is useful:
> >
> > > Right now, though the drawing target has changed to a
> > template, the rest is
> > > still based around a document and writer (required in
> > constructor). Maybe it
> > > makes sense to move the whole thing over to a template base
> > like Jeremy's.
> > > What are everyone's thoughts?
> >
> > I generally like to provide as little information as possible to a
> > constructor...helps allow use in unforeseen circumstances and
> > makes the code
> > using it simpler. And you can call getPdfWriter() on the
> > template, and
> > getPdfDocument() on that writer, so I don't really see the
> > need to pass them
> > explicitly even if they are needed.
> >
> > > As for clipping, this seems to do the trick without
> > templates. I don't know
> > > enough about the internals of the
> > saveState()/restoreState() calls to know
> > > what other side effects this causes, though.
> >
> > This is what I tried first, but it generated invalid PDF
> > files more often
> > than not. I may well have been missing some subtleties of the state
> > management functions, but I've had best luck just avoiding
> > state saves and
> > restores altogether.
> >
> > > Actually, I think we are almost there. If I implement the
> > stuff from your
> > > code (copyArea and the GraphicsConfigration stuff), then
> > all I believe we
> > > are missing now is setXORMode(Color c) which I don't
> > believe is doable with
> > > pdf. (I could have used you and your book when trying to
> > figure out the
> > > AffineTransformations--it works now, but I was pulling my
> > hair out for a
> > > couple of days there).
> >
> > My copyArea() actually doesn't work...what's there was a
> > first attempt, and I
> > moved on when it didn't work properly since none of the code
> > I've seen uses
> > it. It may serve as a starting point for something that does
> > work, though;
> > haven't played with it enough to tell. I'm pretty sure XOR
> > mode isn't
> > feasible; it seems fundamentally incompatible with vector graphics.
> >
> > Jeremy
> >
> > _______________________________________________
> > iText-questions mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/itext-questions
> >
>
>
> =================================================================
> This message contains confidential business information that is
> intended for use only by the individual or entity to whom it is
> addressed. If you are not the intended recipient, you are hereby
> notified that any disclosure, interception, copying, distribution
> or the taking of any action in reliance on the contents of this
> email is prohibited. If you received this email in error, please
> notify the sender by forwarding the message back to the sender,
> and then delete the original information from your system.
> =================================================================
>
>
>
> _______________________________________________
> iText-questions mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/itext-questions
_______________________________________________
iText-questions mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/itext-questions
